You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Preview: a trimmed video clip is shown before it has a frame at its in-point (black at every cut) #5631
In <hyperframes-player> preview, a composition made of trimmed <video> clips (one source, data-media-start per clip) flashes black at every cut. We measured 48–132 ms of no picture at all 11 cuts of one draft, on 0.8.82 and still on 0.8.153.
Cause. When a clip's window starts, the runtime makes its element visible and, on the same tick, seeks it to its data-media-start. The element is shown while it seeks (readyState at HAVE_METADATA, seeking true), so the first frames after the cut have nothing to paint. Renders are unaffected, since they seek and wait on every frame.
What fixed it for us. Before each cut, we put the incoming clip's element on its in-point: any clip that starts within 1.5 s, is paused, isn't already seeking and isn't on its data-media-start gets currentTime = mediaStart. The runtime's activation then finds it within its hard-sync tolerance (0.5 s), doesn't seek it again, and shows a decoded frame at the cut. The 1.5 s lead covers a range request and one GOP over the network. We do this from the embedding page today, by reaching into the player's iframe. It belongs in the runtime's media sync, which already knows each clip's window and media start.
Proposed fix. In syncRuntimeMedia, for a clip that isn't active yet but starts within a lookahead window, seek its (paused) element to its mediaStart once, so it arrives at its window already decoded. Glad to send a PR with a runtime test that records the element's state at the moment it becomes visible.
Activity