This topic was inspired by this thread and originated here …
It got split into it's own thread to not high jack the original thread and has the goal to explore the great combination of pre-rendered video and Hype. It has the goals to...
avoid multiple movies
avoid switching movies at all
easy sync between Hype and Video
The basic idea was to use a single movie that is mirrored and attached to itself (in premiere or some online tool). Then through some simple time index flipping one could always play forward even though giving the illusion of switching direction. This should be smooth in browsers and also work on mobile (in theory).
Humble beginning. All the code running it is currently on a button. Movie is in a symbol. Video data is not really optimized for web but it’s just a concept …
var symbolInstance = hypeDocument.getSymbolInstancesByName('video')[0];
var video = symbolInstance.element().querySelector('video');
var continueAtTime = null;
var midpoint = video.duration/2;
if (!video.dataset.hasOwnProperty('isForward')){
video.dataset.isForward = true;
continueAtTime = 0;
video.addEventListener('timeupdate', function(e){
var isForward = video.dataset.isForward == 'true';
if ( isForward && video.currentTime > midpoint ) {
video.currentTime=midpoint;
video.pause();
}
});
} else {
video.dataset.isForward = !(video.dataset.isForward == 'true');
}
if (continueAtTime==null){
continueAtTime = ((video.currentTime - midpoint) * -1) + midpoint;
}
video.currentTime = continueAtTime;
video.play();
This might be speced but the reality isn’t really matched by this:
I do get this on Chrome “Error in undefined: NotSupportedError: Failed to set the ‘playbackRate’ property on ‘HTMLMediaElement’: The provided playback rate (-1) is not in the supported playback range.”
But even if that can be solved in some browsers most online video formats are based around progressive codecs … giving them a beneficial play direction as full key frames are spaced out and in between are progressively added fragments in a frame by frame (diff) manner until the next full key frame is displayed. Hence, there should be a buffer (and performance) issue while running backwards through stream optimized footage.
If you find a way to demonstrate a well performing negative playback I’d love to update my mind about it! Honestly, I am eager to find a better solution as this approach doubles the video length.
Positive playback rate higher than one is more broadly supported, though. So, if I develop this any further that should come in hand to fast-forward if the video should match another time stamp and is only progressing at the regular playback rate to get there one could dynamically speed it up. Given a situation where the video is synced to some sort of user interaction or scrolling for example. Sidenote: Positives rates between zero and one are not that interesting either as they feel like dropped frames and should look choppy and stop motion like.
In the current version they added the requirement to throw an exception if the requested playbackrate isn’t supported. Hence, exactly what Chrome is currently doing. https://html.spec.whatwg.org/#dom-media-playbackrate
Ah, I only tested it in Safari. I was able to play a video backwards, but the audio was chopped up. It was sorta backwards, more like audio snippets that would play forward, but those blocks of audio were played in reverse.
If playbackRate is negative, the media is not played backwards.
Well, if I ever get around to finishing Intensifies, the slow speeds are really good for captioning. The negative rates are kinda like a jog shuttle. It's a WKWebView project, so I've mostly been testing Safari. (I can't even get the video to load in Chromium / Firefox. HA HA!)
Given any decent implementation for Hype there is much potential for amazing projects.
Just look at stuff like…
The second example “Notre Dame” actually somehow plays some videos in reverse. Either they are jumping with currentTime or they got a hack like this… need to explore:
Update: They are using only currentTime on the videos that can play backwards even when going forward. It seems like it is linked to the scroll with a lasso in between variable that tracks behind to lessen the expected choppiness while jumping time index to sync up scroll and video.
