Closed Bug 1831342 Opened 2 years ago Closed 2 years ago

Nightly regression: Video massively stutters with OpenH264 2.3.1. Video ends a bit too soon and stutters sometimes with OpenH264 2.3.2

Categories

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

Product:
Core
Component:
Audio/Video: GMP
Platform:
x86_64
Linux
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
115 Branch
Tracking Flags:
Tracking Status
firefox-esr102 --- unaffected
firefox112 --- unaffected
firefox113 --- unaffected
firefox114 --- wontfix
firefox115 --- verified

People

(Reporter: jan, Assigned: aosmond)

References

(Regression)

Details

(Keywords: nightly-community, regression)

Attachments

(1 file)

Bug 1831342 - Add pref to control whether the reorder queue is used with GMP plugins.
48 bytes, text/x-phabricator-request
pascalc
: approval-mozilla-release-
Details | Review

KDE Wayland, Debian Testing

(I have set 114 to affected because Fedora already ships media.gmp.decoder.enabled=true with OpenH264 loaded via env var.)

Regression range: https://hg.mozilla.org/integration/autoland/shortlog/2608d24551f96df26c57909f4781e03e4de9c8b4

OpenH264 2.3.1

mozregression STR:

  1. Go to Plugins > click on wheel > Search for updates
  2. Test videos

first bad:

  • youtube.mp4 massively stutters
  • Twitter Transrapid video massively stutters
  • Twitter offshore video massively stutters

mozregression --repo autoland --launch 2608d24551f96df26c57909f4781e03e4de9c8b4 --pref media.gmp.decoder.enabled:true media.gmp.decoder.preferred:true media.gmp-manager.url:"https://aus5.mozilla.org/update/3/GMP/%VERSION%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/nightlytest/%OS_VERSION%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/update.xml" -P stdout -a about:addons -a https://bug1619882.bmoattachments.org/attachment.cgi?id=9149605 -a https://twitter.com/ChristophHorst3/status/1653421571808059392 -a https://twitter.com/50Hertzcom/status/1628740928042065927

last good:

  • youtube.mp4 seems fine (?)
  • Twitter Transrapid video doesn't stutter
  • Twitter offshore video seems fine (?)

mozregression --repo autoland --launch 8b802ba29bf8e6ced1b869e49adc97f2dcc23427 --pref media.gmp.decoder.enabled:true media.gmp.decoder.preferred:true media.gmp-manager.url:"https://aus5.mozilla.org/update/3/GMP/%VERSION%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/nightlytest/%OS_VERSION%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/update.xml" -P stdout -a about:addons -a https://bug1619882.bmoattachments.org/attachment.cgi?id=9149605 -a https://twitter.com/ChristophHorst3/status/1653421571808059392 -a https://twitter.com/50Hertzcom/status/1628740928042065927

OpenH264 2.3.2
Downloaded from bug 1827333 comment 5, extracted and put into correctly named folders.

first bad:

  • youtube.mp4 stutters at 15s and 21s.
  • Twitter Transrapid video doesn't stutter, but ends too soon:
    Expected: We should see how the end of the train disappears at the left.
    Actual: The video ends when the end of the train hasn't reached the center of the video's width.
  • Twitter offshore video sutters sometimes.

MOZ_GMP_PATH="~/Downloads/gmp-gmpopenh264/system-installed" mozregression --repo autoland --launch 2608d24551f96df26c57909f4781e03e4de9c8b4 --pref media.gmp.decoder.enabled:true media.gmp.decoder.preferred:true media.gmp-gmpopenh264.autoupdate:false media.gmp-gmpopenh264.version:"system-installed" -P stdout -a https://bug1619882.bmoattachments.org/attachment.cgi?id=9149605 -a https://twitter.com/ChristophHorst3/status/1653421571808059392 -a https://twitter.com/50Hertzcom/status/1628740928042065927

last good:

  • youtube.mp4 doesn't stutter at 15s and 21s.
  • Twitter Transrapid video: The end of the train correctly disappears at the left.
  • Twitter offshore video doesn't seem to stutter, but playback seems to be slowed down sometimes.

MOZ_GMP_PATH="~/Downloads/gmp-gmpopenh264/system-installed" mozregression --repo autoland --launch 8b802ba29bf8e6ced1b869e49adc97f2dcc23427 --pref media.gmp.decoder.enabled:true media.gmp.decoder.preferred:true media.gmp-gmpopenh264.autoupdate:false media.gmp-gmpopenh264.version:"system-installed" -P stdout -a https://bug1619882.bmoattachments.org/attachment.cgi?id=9149605 -a https://twitter.com/ChristophHorst3/status/1653421571808059392 -a https://twitter.com/50Hertzcom/status/1628740928042065927

Sometimes I got a Sandbox warning when switching tabs, at the moment I don't know if it's related to OpenH264:

1:14.86 INFO: b'Sandbox: attempt to open unexpected file /sys/devices/system/cpu/cpu0/cache/index2/size'
1:14.86 INFO: b'Sandbox: attempt to open unexpected file /sys/devices/system/cpu/cpu0/cache/index3/size'
1:14.86 INFO: b'Sandbox: attempt to open unexpected file /sys/devices/system/cpu/present'
1:14.86 INFO: b'Sandbox: attempt to open unexpected file /sys/devices/system/cpu/possible'

OpenH264 1.8.1.2

1.8.1.2 is broken in general, no regression. It's not a problem because if Openh264 wouldn't be enabled, decoding would fail due to missing decoder.

Testcase: "Video can't be played because the file is corrupt", but audio works.
Twitter: "The video could not be played".

mozregression --repo autoland --launch 2608d24551f96df26c57909f4781e03e4de9c8b4 --pref media.gmp.decoder.enabled:true media.gmp.decoder.preferred:true -P stdout -a about:addons -a https://bug1619882.bmoattachments.org/attachment.cgi?id=9149605 -a https://twitter.com/ChristophHorst3/status/1653421571808059392

0:42.92 INFO: b'[Child 27511, MediaDecoderStateMachine #1] WARNING: Decoder=7f883911e900 Decode error: NS_ERROR_DOM_MEDIA_DECODE_ERR (0x806e0004) - virtual void mozilla::GMPVideoDecoder::Error(GMPErr): GMPErr:7: file /builds/worker/checkouts/gecko/dom/media/MediaDecoderStateMachineBase.cpp:164'

mozregression --launch 2023-04-11 --pref media.gmp.decoder.enabled:true media.gmp.decoder.preferred:true -P stdout -a about:addons -a https://bug1619882.bmoattachments.org/attachment.cgi?id=9149605 -a https://twitter.com/ChristophHorst3/status/1653421571808059392

:aosmond, since you are the author of the regressor, bug 1827703, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Flags: needinfo?(aosmond)

Set release status flags based on info from the regressing bug 1827703

status-firefox115: --- → affected

Martin, what are your thoughts about Fedora shipping an updated OpenH264 plugin in advance or in tandem with Firefox 114? It just forked to beta, so we have a month before we push it to release.

Presumably the issues we have highlighted during our QA cycle are ones users already experience with the 2.3.0 release the distros ship today, except we have improved the frame sequencing bits on the Firefox side in general (plus there are more knobs they can switch depending on their experience).

Flags: needinfo?(aosmond) → needinfo?(stransky)

Cisco has not published binaries on GitHub with our changes, but they have deployed our signed binaries on their web server as you can see from bug 1827333 comment 5.

(In reply to Andrew Osmond [:aosmond] (he/him) from comment #3)

Martin, what are your thoughts about Fedora shipping an updated OpenH264 plugin in advance or in tandem with Firefox 114? It just forked to beta, so we have a month before we push it to release.

It may be fine but we need to ask Fedora folks to build that files. So you need OpenH264 2.3.2 for Firefox 114, right?
Fedora builds OpenH264 on its own and then uploads binary files back to Cisco where they're downloaded by Fedora users.
So do I understand correctly that files from https://bugzilla.mozilla.org/show_bug.cgi?id=1827333#c5 needs to be shipped with FF 114?

Flags: needinfo?(stransky) → needinfo?(aosmond)

Do you need to build, or are you able to use the binaries we had Cisco ship already? If the latter, it may be easier for me to uplift a patch behind a pref to disable the timestamp reordering.

We aren't ready to commit to shipping the OpenH264 update on our side, but given Linux distros are already doing it, it would be best if you used a plugin with our changes. They are backwards compatible so you can use the new plugin with an old Firefox without any breaking changes.

Flags: needinfo?(aosmond) → needinfo?(stransky)

I can make an upliftable patch. All the distros will have to do is flip the pref appropriately.

Flags: needinfo?(stransky)
Assignee: nobody → aosmond
Status: NEW → ASSIGNED

This patch adds a pref to disable use of the reorder queue with the GMP
video decoder. Disabling it will allow improved compatibility with the
older OpenH264 plugins. This is useful mostly for Linux distros which
rebuild Firefox and enable the GMP video decoder on their own.

Pushed by aosmond@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/935749f46831 Add pref to control whether the reorder queue is used with GMP plugins. r=media-playback-reviewers,padenot

https://hg.mozilla.org/mozilla-central/rev/935749f46831

Status: ASSIGNED → RESOLVED
Closed: 2 years ago
status-firefox115: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → 115 Branch

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.

Flags: needinfo?(aosmond)

Verfied fixed on KDE Wayland, Debian Testing, Intel. Thanks!

GMP-OpenH264 2.3.1 (from bug 1827333 comment 1):

Status: RESOLVED → VERIFIED

Comment on attachment 9334464 [details]
Bug 1831342 - Add pref to control whether the reorder queue is used with GMP plugins.

Beta/Release Uplift Approval Request

  • User impact if declined: This patch adds a pref which can be disabled by some Linux distributions who already use OpenH264 as fallback decoder (media.gmp.decoder.enabled=true) but still have old OpenH264 2.3.1. True (default) means stuttering playback with 2.3.1, but fine with 2.3.2. False means always fine.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): This patch adds a pref that allows to turn off the new behavior to go back to the previous behavior.
  • String changes made/needed:
  • Is Android affected?: No
Attachment #9334464 - Flags: approval-mozilla-beta?

Comment on attachment 9334464 [details]
Bug 1831342 - Add pref to control whether the reorder queue is used with GMP plugins.

114 is merged to the release branch now, morphing the request. As it just landed and doesn't affect official builds, we can let it bake a couple of weeks on beta and target our planned 114 dot release.

Attachment #9334464 - Flags: approval-mozilla-beta? → approval-mozilla-release?
QA Contact: tzsoldos

Based on comment 12 I will set the flag to verified on nightly 115.

status-firefox115: fixed → verified

Comment on attachment 9334464 [details]
Bug 1831342 - Add pref to control whether the reorder queue is used with GMP plugins.

We are two weeks away from 115 shipping to release, I think this can ride the trains, thanks.

Attachment #9334464 - Flags: approval-mozilla-release? → approval-mozilla-release-
Flags: needinfo?(aosmond)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: