Bugzilla

Tracking bug for reducing video decode and seek latency. This is distinct from the existing video-performance trackers (bug 1445470, bug 1889230), which cover playback smoothness, power, and compositing -- bug 1445470 explicitly found that decode is not its bottleneck. This meta is about the time to produce decoded frames, and in particular accurate seeks, where the decoder must re-decode from the prior keyframe to the target.

Background: on macOS the decode path is effectively single-in-flight at every layer (state machine, reader, IPC to the decoder process, and the platform decoder), so the hardware decoder is fed one frame at a time and stays mostly idle during a seek's keyframe->target re-decode. Other browsers (e.g. Chrome) keep several independent decode requests in flight and stream each result back, saturating the decoder while still stopping at the target.

Scope of work tracked here:

- Short term: keep the platform decoder pipeline filled during the keyframe->target re-decode instead of decoding one frame at a time, and stop dropping the decode threshold when the decoder is restarted cold after a seek.

- Larger effort ("Option A", path to parity): move the whole decode path from single-in-flight to N independent, concurrent decode requests that each stream their result back, mirroring Chrome's decoder-stream model. This spans all layers: the state machine (request-ahead with reordering), the reader (multiple inputs in flight), the decoder-process IPC (per-request promises and shmem lifetime), and the platform decoder (a queue of pending decode promises). This is the route to decode/seek latency on par with or better than other browsers, and is the higher-risk piece.

- Reducing per-seek decoder restart/teardown cost (cold starts after dormancy) and related demux/IPC overhead per decode request.

Individual improvements are tracked as dependencies.

Tracking bug for reducing video decode and seek latency. This is distinct from the existing video-performance trackers (bug 1445470, bug 1889230), which cover playback smoothness, power, and compositing -- bug 1445470 explicitly found that decode is not its bottleneck. This meta is about the time to produce decoded frames, and in particular accurate seeks, where the decoder must re-decode from the prior keyframe to the target.

Background: on macOS the decode path is effectively single-in-flight at every layer (state machine, reader, IPC to the decoder process, and the platform decoder), so the hardware decoder is fed one frame at a time and stays mostly idle during a seek's keyframe->target re-decode. Other browsers (e.g. Chrome) keep several independent decode requests in flight and stream each result back, saturating the decoder while still stopping at the target.

Scope of work tracked here:

- Short term: keep the platform decoder pipeline filled during the keyframe->target re-decode instead of decoding one frame at a time, and stop dropping the decode threshold when the decoder is restarted cold after a seek.

- Larger effort: move the whole decode path from single-in-flight to N independent, concurrent decode requests that each stream their result back, mirroring Chrome's decoder-stream model. This spans all layers: the state machine (request-ahead with reordering), the reader (multiple inputs in flight), the decoder-process IPC (per-request promises and shmem lifetime), and the platform decoder (a queue of pending decode promises). This is the route to decode/seek latency on par with or better than other browsers, and is the higher-risk piece.

- Reducing per-seek decoder restart/teardown cost (cold starts after dormancy) and related demux/IPC overhead per decode request.

Individual improvements are tracked as dependencies.

Tracking bug for reducing video decode and seek latency. This is distinct from the existing video-performance trackers (bug 1445470, bug 1889230), which cover playback smoothness, power, and compositing -- bug 1445470 explicitly found that decode is not its bottleneck. This meta is about the time to produce decoded frames, and in particular accurate seeks, where the decoder must re-decode from the prior keyframe to the target.