Seek-to-first-frame latency — Bug 2049301

Measures video.currentTime = target latency for a buffered ±10 s seek, across three codecs (H.264 / VP9 / AV1), two loading pipelines (src progressive and MSE with separate video/audio SourceBuffers), and two playback states:

• Playback seek — the video is playing when the seek is issued, so the platform decoder is alive (flushed, not torn down).
• Dormant seek — the video is paused long enough to go dormant (Firefox releases the decoder after media.dormant-on-pause-timeout-ms, default 5 s), so each seek recreates the decoder. The harness stays paused just over that timeout before each dormant seek, which is why the dormant rows take a while. Other browsers have no dormancy concept, so for them this is simply a paused seek.

Metrics (median ms): seeked = time to the seeked event (decode reached the target frame); firstFrame = time to the first presented frame at/after the target (requestVideoFrameCallback); waiting = time to the waiting event. n/a means the event never fired — for waiting that usually just means the seek did not stall for data.

idle