1657239 - Increased frame drops for 60 fps videos on Windows

Status: RESOLVED FIXED

(Core :: Audio/Video: Playback, defect)

Description

[Markus Stange [:mstange]]

This was reported in bug 1655221 comment 5.

On Windows, for hardware-decoded video, we only buffer 3 frames in the compositor. This means that we don't have a lot of leeway when we choose which video frame to present in the current composite; the buffering window should be centered around the timestamp that we use for picking the video frame.

Bug 1653355 changed the timestamp we use when picking video frames in the compositor: Rather than picking the video frame for "the current time" at the time of the composite, we now use "the next vsync time" to pick the video frame. In theory, this should lead to improved AV sync; the compositing pipeline takes at least one vsync interval to put the composited pixels onto the physical screen.

However, picking video frames "in the future" makes us more likely to hit the end of the range of buffered video frames. This is what was observed in the profile: https://share.firefox.dev/2XoT83K (see the "0 remaining images" markers)
This leads to dropped frames.

We either need to revert the "one frame in the future" behavior, or we need to make sure the window of buffered frames is shifted into the future as well. Or maybe we want to wait for bug 1539735, which is expected to completely change the buffering mechanism anyway.

I think for now, backing out bug 1653355 is the right way forward.

Comment 1

[Markus Stange [:mstange]]

Backout of bug 1653355 is on autoland: https://hg.mozilla.org/integration/autoland/rev/85ef536d88c9fb798a1bb0b96369fd7a68a7b0d9

Comment 2

[Markus Stange [:mstange]]

https://hg.mozilla.org/mozilla-central/rev/85ef536d88c9fb798a1bb0b96369fd7a68a7b0d9