2004850 - WebRTC simulcast video stops sending after running for a while

Status: VERIFIED FIXED

(Core :: WebRTC, defect, P1)

Description

[Shaofan Qi]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36

Steps to reproduce:

Send H.264 simulcast video with a single active layer.

I couldn’t reproduce the issue with the simulcast sample. I’ve uploaded the logs, let me know if you need more. For now, I’m unable to share a test link to my environment.

Actual results:

Video stopped sending after a while.

Expected results:

Video should have kept sending.

Comment 1

[Shaofan Qi]

Attachment: MOZ_LOG="webrtc_trace:5,GMP:5,GMPPlugin:5"

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::WebRTC' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[Andreas Pehrson [:pehrsons]]

Which version of Firefox was this on? I landed another fix to GMP/OpenH264 recently in bug 1992567 that could possibly be related. Latest Nightly and Beta 147 (later today) should have it.

I'll check the log later, adding ni.

Comment 4

[Shaofan Qi]

Tested this 147 nightly https://ftp.mozilla.org/pub/firefox/nightly/2025/12/2025-12-07-21-28-32-mozilla-central/
and this beta https://ftp.mozilla.org/pub/firefox/releases/147.0b1/, same issue. Logs constantly display W/GMP GMP Encode: Max number of frames already in flight. Dropping this one.

Comment 5

[Andreas Pehrson [:pehrsons]]

Thanks, that log statement likely means it's a regression from bug 1992567. I'll take a look.

Comment 6

[Andreas Pehrson [:pehrsons]]

It seems from the log that we release an encoder with a frame in flight, and therefore miss the notification that the input frame was encoded or released. Not a biggie per se, but I then assume libwebrtc re-uses the encoder, because it's only after this encoder release that all encode tasks are dropped. Thanks for filing this so early, should be an easy fix.

Comment 7

[Andreas Pehrson [:pehrsons]]

Attachment: Bug 2004850 - Clear WebRTC GMP encoder input image map on Release (from libwebrtc) and termination (from IPC). r?bwc

This covers some corner cases, for instance when libwebrtc releases the encoder
with a frame in flight, then re-uses it.

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/b6938aa4847b
https://hg.mozilla.org/integration/autoland/rev/409971c463d8
Clear WebRTC GMP encoder input image map on Release (from libwebrtc) and termination (from IPC). r=bwc

Comment 10

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/409971c463d8

Comment 11

[Shaofan Qi]

This looks like a regression in version 147, will 147 include the fix? This issue is easily reproducible in our product and makes it effectively unusable.

Comment 12

[Andreas Pehrson [:pehrsons]]

[Tracking Requested - why for this release]:
Sending H264 video over WebRTC is broken in some circumstances.

I'll make sure to get it uplifted to 147, adding tracking to that effect.
Have you had a chance to verify the fix in latest Nightly?

Comment 13

[Shaofan Qi]

Thanks, Andreas. I tested the latest nightly build (https://archive.mozilla.org/pub/firefox/nightly/2025/12/2025-12-10-06-43-34-mozilla-central/) and couldn’t reproduce the issue. Looks good on my end.

Comment 14

[Andreas Pehrson [:pehrsons]]

Thanks for confirming!

Comment 15

[Andreas Pehrson [:pehrsons]]

Attachment: Bug 2004850 - Clear WebRTC GMP encoder input image map on Release (from libwebrtc) and termination (from IPC).

This covers some corner cases, for instance when libwebrtc releases the encoder
with a frame in flight, then re-uses it.

Original Revision: https://phabricator.services.mozilla.com/D275605

Comment 16

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined: Video-conferencing sites using the H264 video codec with the OpenH264 encoder (i.e. all desktop platforms) may stop sending video mid-call
• Code covered by automated testing: no
• Fix verified in Nightly: yes
• Needs manual QE test: no
• Steps to reproduce for manual QE testing:
• Risk associated with taking this patch: low
• Explanation of risk level: Trivial change
• String changes made/needed: None
• Is Android affected?: no

Comment 17

[Ryan VanderMeulen [:RyanVM]]

Is there any chance we could add a test for this?

Comment 18

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/71dfa04b1e7f
https://hg.mozilla.org/releases/mozilla-beta/rev/f88a7cb8fdac

Comment 19

[Andreas Pehrson [:pehrsons]]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #17)

Is there any chance we could add a test for this?

With the right amount of manipulation of the fakeopenh264 plugin we use in CI, we could. I'm not sure how easy that is though. I'll ask around.

Comment 20

[Andreas Pehrson [:pehrsons]]

Attachment: Bug 2004850 - Clear WebRTC GMP encoder input image map on Release (from libwebrtc) and termination (from IPC).

This covers some corner cases, for instance when libwebrtc releases the encoder
with a frame in flight, then re-uses it.

Original Revision: https://phabricator.services.mozilla.com/D275605

Comment 21

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr140/rev/9a55bd91f69c