Playing a dense timeline without stutter

The video composer plays back in the browser using real <video> elements composited with CSS. That's fast, simple and good at seeking, right up until you ask it to play a timeline with two dozen clips on it.

A 25-clip project played for a couple of seconds and then stuttered badly. Short projects were completely fine. We suspected decode cost, then the network, and both turned out to be innocent.

Playback kept a warm-up window so a clip would be ready before the playhead got to it. That window was sixty seconds long. Now think about a project shorter than sixty seconds. "Every clip starting within the window" quietly means every clip in the project. That is twenty-four videos decoding at once, each holding its own memory and its own layer on screen. And each of them re-rendered on every tick of a 60 Hz clock.

We now load a small, fixed set: the clips under the playhead, the nearest few starting soon after it, and anything just past its end so a cut does not blink. On the same 24-clip timeline:

Warm-up lead before a clip goes active stayed comfortable at over two seconds, so nothing regressed into blank frames.

Our first attempt gated playback on the clips under the playhead alone. That broke playback in the middle of a timeline, and it was maddening to track down. Video went dark a few seconds in while the audio and text carried on. Only the video needed something that was no longer loaded. The gate has to cover what's coming, not only what's here.

None of this is verifiable in a backgrounded tab. Browsers throttle animation frames when a tab is hidden, so the clock never ticks and the timecode sits at zero looking broken. Every measurement here was taken with the tab in front.