Found in

• Firefox Nightly 114.0a1 nightlytest channel

Tested platforms

• Affected platforms: Ubuntu 18, Ubuntu 22.04

Preconditions

• media.gmp.decoder.enabled=true
• media.gmp.decoder.preferred=true
• media.gmp.decoder.multithreaded=true

Steps to reproduce

1. Open one demo from https://drive.google.com/drive/u/2/folders/1EGT2oDBmIQCP71fXTdq2-PZ3oaohPvhi

Expected result

• Demo should correctly play.

Actual result

• The demo does not play (when you click on the play button, only red color is displayed for a second).

Regression range

• New feature implementation.

We don't expect any 6.2 labelled demo to work, but all of the others should. Which ones are broken?

None of them work as expected.
And for the following demos, only red color is displayed for a second:

• rainbow-h264-main-4.0
• rainbow-h264-main-5.2
• rainbow-h264-high-5.2
• rainbow-h264-high-4.0
• rainbow-h264-high444-4.0
• rainbow-h264-high444-5.2

If I set the "media.gmp.decoder.preferred" pref to false, all the demos work.

Since this is a fallback solution we can live with problems with certain formats. Worth looking at to see if there's an easy fix, but if not, this is something we can handle in follow up work after we ship.

So disabling the new pref I added media.gmp.decoder.reorder_frames helps with this. It appears the reordering mechanism is causing us to drop the last couple of frames. In practice this isn't a problem because a video will typically have 30fps, whereas the demos only do 1 fps and a handful at that.

Making drain pull all of the frames out mostly resolves the problem. I usually see us dropping the last frame in the playback. This is a bug in the OpenH264 plugin, technically our GMP wrapper piece. Drain doesn't post to the underlying worker thread and it probably should. This will guarantee we finish the last outstanding request.

We can fix this as well, but given that it requires a reshipping of the plugin and that it will only affect the very last frame some of the time, it isn't a high priority.

This patch makes it so that the drain operation on a GMPVideoDecoder
will actually make it return all frames, not just those that are over
the reference frame threshold. Because this is the end of the video, we
know no more frames are supposed to be coming. This resolves issues with
very slow where we noticeably drop the last few frames.

Note that we still have an issue with the final frame itself. This is a
plugin bug unfortunately, so we need to fix it within OpenH264's GMP
integration code.

Candidate for uplift (mostly for Linux) to 114. Will request uplifts once we do some verification.

https://hg.mozilla.org/mozilla-central/rev/2924f4e40363

The patch landed in nightly and beta is affected.
:aosmond, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox114 to wontfix.

For more information, please visit BugBot documentation.

Tested on Ubuntu 22 platform using latest nightly Fx 116.0a1 with pref's media.gmp.decoder.preferred = false and media.gmp.decoder.reorder_frames = true, both are set by default, the demos from description plays as expected with the new plugin version 2.3.2. Note that I verified the pref's state on Fx 115.0b2 and the both are set by default, the pref's are in the same state as on latest nightly, tested the demo videos and works as expected with the old plugin version 1.8.1.2.