1802829 - WebRTC H.264 failing for web conferencing

Status: VERIFIED FIXED

(Core :: WebRTC, defect, P1)

Description

[Kevin Brosnan [Ex-Mozilla]]

From github: https://github.com/mozilla-mobile/fenix/issues/27982.

H264 is something I need for watching hyperbeam with my friends on mobile. without it, I get a nice lil error on my screen that H264 is not supported on my device, which is a Pixel 7 Running grapheneOS. and tell me to install the official firefox from the app store. So I did. But I got the same error. However if I downloaded the brave browser and went back into hyperbeam, It works again. And whats even stranger is that on my samsung S21 phone. hyperbeam also works just fine in the browser.

The best I could find recently was this question on stack overflow.

https://stackoverflow.com/questions/74483260/does-geckoview-firefox-webrtc-support-av1-h264-codecs-on-android

Apparently very select devices (Most notably, pixel phones) Just have H264 disabled completely for firefox it seems and doesnt matter wether you use software or hardware encoding, It just doesnt work. How can this go about being fixed?

┆Issue is synchronized with this Jira Task

Change performed by the Move to Bugzilla add-on.

Comment 1

[Kevin Brosnan [Ex-Mozilla]]

I can reproduce this on a Pixel 6 Pro running Android 13 with https://mozilla.github.io/webrtc-landing/pc_test.html when forcing h.264.

Comment 2

[Jim Mathies [:jimm]]

I'm pretty sure we would only advertise H264 support if the underlying device + OS supports for it. We don't support the Cisco OpenH264 plugin on Android. However, I can repro on this demo page on a stock pixel. Will ask the webrtc team to take a look.

Comment 3

[Jim Mathies [:jimm]]

Attachment: demo output

Comment 4

[Jim Mathies [:jimm]]

https://jsfiddle.net/jib1/02j8q6h9/show

Comment 5

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

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

:mjf, since you are the author of the regressor, bug 1790097, could you take a look?

For more information, please visit auto_nag documentation.

Comment 6

[Kevin Brosnan [Ex-Mozilla]]

We have platform encoders for webrtc Android https://searchfox.org/mozilla-central/source/dom/media/platforms/android

Comment 7

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

The bug is marked as tracked for firefox109 (nightly). We have limited time to fix this, the soft freeze is in 9 days. However, the bug still isn't assigned.

:jimm, could you please find an assignee for this tracked bug? Given that it is a regression and we know the cause, we could also simply backout the regressor. If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit auto_nag documentation.

Comment 8

[Jim Mathies [:jimm]]

For avc codecs, on my Pixel 3 I have:

c2.qti.avc.decoder
OMX.qcom.video.decoder.avc

similar strings for VP8, VP9, and HEVC.

Comment 9

[Andreas Pehrson [:pehrsons]]

Attachment: Bug 1802829 - Add "c2.exynos" as hardware capable codec prefix. r?jolin

Comment 10

[Andreas Pehrson [:pehrsons]]

This string is tied to the device, so all releases are affected.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c706e2c4e3f3
Add "c2.exynos" as hardware capable codec prefix. r=jolin,geckoview-reviewers,m_kato

Comment 12

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/c706e2c4e3f3

Comment 13

[Ryan VanderMeulen [:RyanVM]]

Should we uplift this to 108 also? Please nominate for approval if so.

Comment 14

[Andreas Pehrson [:pehrsons]]

Comment on attachment 9305982 [details]
Bug 1802829 - Add "c2.exynos" as hardware capable codec prefix. r?jolin

Beta/Release Uplift Approval Request

• User impact if declined: No hardware encoding for webrtc on some Android devices (Samsung Exynos and Google Tensor chipsets). Also no H264 encoding for webrtc on the same Android devices (we gate it on hardware being available, and we have no other encoders to fall back to on Android).

Android in particular is well served by a hardware encoder for performance and battery life reasons.

This might also impact whether these Android devices can use a hardware decoder for H264 (mp4) playback, but I haven't looked into it.

• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: On an Android device with a Samsung Exynos or Google Tensor chipset, verify that its list of media codec strings does not contain a string with the prefis "OMX.Exynos". Instead it should have "c2.exynos". This list can be inspected with various apps, try searching for "Media Codec Info".

If the above is verified; STR:

• Open https://mozilla.github.io/webrtc-landing/pc_test.html
• Check "One-way call"
• Check "Video-only call"
• Check "Require H.264 video"
• Click Start
• Approve the prompt if there is one
• Scroll to the bottom and check the last line of the log

This bug is verified if the last line says "PCx: HIP HIP HOORAY"
This bug is NOT verified if the last line says "No H264 found in the offer!!!"

Normally you should expect two video elements (local and remote) if this is working properly, but this depends on bug 1803368 (>=109) and somewhat bug 1803530 (>=108). However, if you do see the second video element with live video that also means this bug is verified.

• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This adds a string to our list of hardware capable android codecs. Theoretical worst case is we try to use one of those codecs and they don't work. We did support them in the past however, when these handsets used a different string. I wouldn't expect support/behavior to be different this time around.
• String changes made/needed:
• Is Android affected?: Yes

Comment 15

[Dianna Smith [:diannaS]]

Comment on attachment 9305982 [details]
Bug 1802829 - Add "c2.exynos" as hardware capable codec prefix. r?jolin

Approved for 108.0rc1

Comment 16

[Dianna Smith [:diannaS]]

https://hg.mozilla.org/releases/mozilla-beta/rev/964ef9e38a08

Comment 17

[Lorand Janos]

Verified as fixed on the latest available Nightly 109.0a1 (2022-12-03) build, using the following devices:

• Google Pixel 4 (Android 13).
• Google Pixel 6 (Android 13) - With Google Tensor chipset.
• Oppo Find X5 (Android 12).
  Tested with the above given steps, using the given link, the last line says "PCx: HIP HIP HOORAY".