Looks like playback depends on "ticks" arriving from browser to the JS library, and library selects a frame according to the scroll location.

Mobile devices send this data constantly and periodically, making it smoother; yet desktop browsers do not, appearing choppy.

It works as intended on my iPhone X, yet stutters on an infinitely more powerful desktop, and only possible explanation is this.

“Thus, to achieve maximum performance under all circumstances, it is still recommended to encode videos with keyframe = 1, if possible”

Which negates the title. Not using long-GOP encoding really defeats the purpose of using a codec like h.264/h.265. For delivering files via streaming, this is a pretty obscure thing to do. It’s no less obscure than using trick play techniques of encoding the video using long-GOP, but in multiple streams where each stream is at different rates. This is how the set top boxes would do the fast forward/reverse play.

Am I missing something? Performance on both Chrome and Firefox on OSX was pretty poor (or maybe the video just doesn't have enough frames to make it smoother.) Doesn't seem to respond to touch events, either...

I can’t think of a single time I have not been annoyed at scrolling video playback.

Not because of performance, though. I just think autoplay is a cheap trick to try to gain my attention, and if I’m scrolling, it’s because I didn’t want to see the damn video in the first place.

This is more like a slideshow, than a video, on my M1 Max.

I think this is great and can be useful for many UXs, but it needs a fallback so it isn't only reliant on scroll state.

I had the page load in the background, so the video didn't load, and I'm guessing when I brought the tab into focus a position event wasn't fired (or not how the library was expecting it), so I didn't get anything until I refreshed.

Yes, it is a bit jittery, and could use improvements, but nothing some lerping of positioning, etc probably can't solve.

In Firefox 120.01 on Mac OS the frame only receives an update once scrolling is fully stopped. I.e. if I use the scroll bar to scroll, the video is updated only on mouseup.

This page crashed my phone browser.

This might not be for every use case but definitely useful for some

Kinda choppy on Chrome/Win10, even after buffering the images. Smooth on Chrome/S21 FE, but only after it downloaded all the single frames.

Missed opportunity to name it scrollymcvideo.js

Very choppy on F-Droid Fennec and the video doesn't show on android Chromium, hopefully all users only use Chrome anyway

works well on Chrome on a Pixel 6 Pro. extremely janky and terrible in Firefox for Android on the same device. I recorded a small video to demonstrate. https://youtu.be/cK7KlcH1uPs?si=m3q7S9Ml0aS_IFoX

In response to other comments, works perfectly on Android WebView & Firefox. Actually pretty cool.

I use Vivaldi on all platforms and I would never see this on desktop because of the built in ad and blocker tracking. It did not load the video of the bridge until I specifically turned the blockers off.

I guess this must be the way that those terrible ads that appear to hide behind the text of a content farm article when you scroll, for my browser to block it outright.

That tells me this is going to be used by advertisers so I can't even get away from scrollable video ads because they're going to try to play as I scroll.

This will be great for advertisers since sites will be able to quantify how much of the advertising video was served to users based on how far down they scrolled!

This will be great for everyone's experience on the web. /s