[dazzatronus]

html5 clips bake one at a time, first come first served, and a clip joins the queue when its page finishes loading. Clips load track by track, so bakes follow track order, not when clips play. An edit whose opening html5 clip sits on a lower track bakes it last, and pressing play straight away shows that clip as a still frame until every other clip has baked.

Bakes now go through a queue that picks each time a slot frees: the clip under the playhead, then those ahead in start order, then those already passed. It reads the playhead at each pick, so a seek re-sorts what's waiting. A clip joins once every html5 page still mounting has mounted, so clips that load together are ordered together. Bakes stay one at a time, cached frames still skip the queue, and a re-bake at a larger size takes the same queue. The test that kept the old chain from holding finished bakes is gone: the queue drops each bake as it starts.

Risk: the first bake waits for every html5 page to mount. On the edit below that adds 0.13 s; pages that inline large files at different speeds add more, up to the 10 s iframe load timeout.

Verify: npm run verify:ci passes, with 2,401 tests, and the new html5 test fails on main. On an edit with html5 clips at 54.4 s, 24.4 s and 0 s on tracks top to bottom, at 393 × 852, the opening clip is baked at 27.9 s instead of 75.0 s, and all three by 62.4 s instead of 75.1 s (headless Chrome, software GL).

Merge subject: the default, fix: bake html5 clips in playback order from the playhead, which releases a patch.

[github-actions]

🎉 This PR is included in version 2.29.3 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀