[robinebers]

Why

When the preview waits for a clip's data, it shows Buffering and holds the film. If that data never arrives, the film waits forever.

This happens on a composition page opened on its own, outside the player. That page loads every clip at once, and in Chrome and Firefox the open downloads fill the connection, so the request for the clip the film needs is never answered. The film from the freeze fix (#4) stops this way at 0:17 and is still stopped four minutes later.

What

If the film has waited 5 seconds and the clip it needs has received nothing new, the preview lets go of every clip that is not on screen. Their downloads end, the connection frees up, and the waiting clip's data arrives. The clips it let go of load again when they come up. A clip that loads slowly but still receives data is waited for as before.

Test plan

The test film from #4 (2:16, 37 clips cut from two long .mov files served over HTTP/3), opened directly as a page without the player, headless:

Run	Chrome 157	Firefox 160
Before (the freeze fix alone)	stops at 0:17, still stopped 4 minutes later	stops at 0:17, still stopped 4 minutes later
After	plays to the end, 16 s and 8 s stalled in 2 runs	plays to the end, 9 s stalled
In the player, after	plays to the end, 0 s stalled	plays to the end, 0 s stalled

• Unit tests. init.buffering.test.ts has two new tests:

  • a hold whose clip gets no data for 5 s frees the clips that are not due, and the film plays on once the clip has data
  • a hold whose clip is still receiving data frees nothing

  The first fails without this change. The core suite, runtime CI and typecheck pass locally.

• Unit tests added/updated

• Manual testing performed

• Documentation updated (if applicable): no docs describe this behaviour

• Comments follow CONTRIBUTING.md "Comments": they say why, not what, and a bug fix says what the code must do and how to reproduce the bug

Related work

Stacked on #4. In Firefox, releasing a clip relies on that PR's release fix; without it, Firefox fetches metadata for every clip it lets go of. Upstream, open it after #4's change lands.

How

• Detecting a stuck hold. While the film is held for data, the transport tick notes the held clips' readyState and buffered seconds. After 5 s with no change, it releases every clip outside the current window that holds a request (any readyState above 0, or still loading) at preload="none", and keeps waiting. If nothing changes, it repeats every 5 s.
• Why 5 s. It is the same bound isUnplayable uses for a clip stalled since its first play request. That rule misses this clip, which reports readyState 1 while still loading.
• Where it matters. Inside the player and Studio's preview, fix(player): stop the preview freezing when many clips share one long recording #4 already holds clips back, so this is a safety net there. It mainly helps pages that load everything at once, and hosts or networks not measured here.
• Size. The runtime grows by 487 bytes.