1533071 - Enable openh264 plugin for win64-aarch64

Status: VERIFIED FIXED

(Core :: WebRTC: Audio/Video, enhancement, P2)

Description

[Dan Minor [:dminor]]

We started building the openh264 plugin for win64-aarch64 over in Bug 1515210. We also need to enable and test it in Firefox. That will require undoing some of the work in Bug 1527811.

I'm not certain of the priority of this. According to Bug 1515210 comment 9, we don't use openh264 for decoding, and we don't currently support video calls on win64-aarch64, so it doesn't seem like encoding is a high priority until that is fixed, although we could test using screen sharing. Marking as P3 for now.

Comment 1

[Dan Minor [:dminor]]

Attachment: Bug 1533071 - Enable OpenH264 plugin for win64-aarch64; r=jya

Comment 2

[Dan Minor [:dminor]]

With a bit of work, I was able to get a download of the plugin working from a local server and test it using mozilla.github.io/webrtc-landing/pc_test.html. It will run for a few minutes and then my laptop gets a "green screen of death" with a "Video Scheduler Interal Error" and restarts itself. I'm not certain if this a problem with OpenH264, our gmp process, or something else, although running the same page using the VP8 codec is stable.

I'm going to park my patch to enable the plugin here for now. I think it makes sense to do an official build of the plugin for win64-aarch64, sign it and send it to Cisco for hosting, but leave it disabled by default in Firefox. That will make it easier to test the plugin in the future.

Comment 3

[Dan Minor [:dminor]]

cpearce pointed out that "Video Scheduler Internal Error" would indicate that we're using the WMF decoder. Sure enough, things seem much more stable if I set the media.navigator.mediadatadecoder_h264_enabled pref to false.

Comment 4

[Dan Minor [:dminor]]

Callek, could you please have a look at getting a signed version of the win64-aarch64 openh264 plugin to Cisco for hosting? I just discussed this with mreavy on irc and it sounds like software encoding/decoding is fine for now, so we shouldn't let the crash I mentioned above hold this up. Thanks!

Comment 5

[Justin Wood (:Callek)]

(In reply to Dan Minor [:dminor] from comment #4)

Callek, could you please have a look at getting a signed version of the win64-aarch64 openh264 plugin to Cisco for hosting? I just discussed this with mreavy on irc and it sounds like software encoding/decoding is fine for now, so we shouldn't let the crash I mentioned above hold this up. Thanks!

I'll see about doing that from our end tomorrow, I'll note that balrog wise things will be easier if we can ship aarch64 version along with the other 1.8.1 desktops at the same time to beta, rather than needing extra rules (but it is possible if there is a need to split the cadence)

I'm leaving the n-i on me until I can deliver this.

Comment 6

[Dan Minor [:dminor]]

I think Beta is fine, since we have this pref'ed off anyway. We can land the patch to pref this on Nightly and test before landing that patch to Beta. Thanks!

Comment 7

[Justin Wood (:Callek)]

Attachment: Bug 1533071 - Fix openh264 win64-aarch64 platform so signing can find it. r=dminor

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/mozilla-central/rev/00c5ef76d951
Fix openh264 win64-aarch64 platform so signing can find it. r=dminor a=apavel|sheriffduty

Comment 9

[Justin Wood (:Callek)]

Handed off to cisco, I'll update dan when we are ready to test for nightly.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b53ad3248711
Enable OpenH264 plugin for win64-aarch64; r=jya

Comment 11

[Narcis Beleuzu [:NarcisB]]

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

Comment 12

[Dan Minor [:dminor]]

Comment on attachment 9053641 [details]
Bug 1533071 - Enable OpenH264 plugin for win64-aarch64; r=jya

Beta/Release Uplift Approval Request

• Feature/Bug causing the regression: None.
• User impact if declined: Unable to use OpenH264 for making WebRTC calls.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: 1. Visit https://mozilla.github.io/webrtc-landing/pc_test.html

2. Select 'Require OpenH264 Video'
3. Unselect 'Enable Identity Provider'
4. Click start.
5. Local and fake remove video streams should be present in both video controls.

You may need to be running a Beta version of Windows for the camera to work, it is disabled in Firefox for older versions of Windows for ARM64. I've requested that OpenH264 1.8.1 be shipped to Beta, but those rules may not have been updated yet. If you check about:config for the key 'media.gmp-gmpopenh264.version', it will not be set if downloading the plugin failed. It is working in Nightly in my local testing.

• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This is just a pref switch to enable OpenH264. It has been tested on Nightly and seems fine. If it causes problems, we can easily pref it back off again.
• String changes made/needed: None.

Comment 13

[Pascal Chevrel:pascalc (PTO until Sept 2)]

Let's have QA verify in nightly first.

Comment 14

[Timea Cernea [:tbabos][inactive]]

Hey Dan,

I'm having troubles to verify this issue on Lenovo Yoga (arm64).
I installed all the new windows updates and also checked for the "media.gmp-gmpopenh264.version" pref in about:config (it has 1.8.1 version).
By following the steps, I check "Require H.264" and "Enable Identity Provider Domain" and after starting there will be no video stream but only the following error: Failure callback: "The object can not be found here"

Nightly version: 68.0a1 (2019-04-17)
Windows version: 1809 (OS build 17763.437)

Given the above, would a Windows Beta version be needed to verify this?

Comment 15

[Dan Minor [:dminor]]

Hi Timea,

Yes, you need to have the Windows Beta version "Windows 10 Home Insider Preview" installed. I have 1903 (OS build 18875.1000). The camera does not work on earlier versions of Windows due to problems with the DirectShow support.

Thanks for having a look!

Dan

Comment 16

[Timea Cernea [:tbabos][inactive]]

Thanks for the info Dan!
After switching to Windows 10 Home Insider Preview (version 1903/ OS build 18875.1000):

• reproduced the issue on affected Nightly from 2019-03-06: There will be no camera preview for the second PC and the "No H264 found in the offer!!" message is displayed.

Verified-Fixed on the latest Nightly 68.0a1 (2019-04-22) since both previews are displayed in the webRTC call and the PC1 and PC2 - "Hip Hip Hooray" - messages appear at the end of the log.

Waiting for uplift to Beta.

Comment 17

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9053641 [details]
Bug 1533071 - Enable OpenH264 plugin for win64-aarch64; r=jya

Enables the OpenH264 plugin for Windows AArch64 builds for Win10 1903 users. Approved for 67.0b13.

Comment 18

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/releases/mozilla-beta/rev/2e258ddb1483

Comment 19

[Timea Cernea [:tbabos][inactive]]

Verified on latest Beta 67.0b13.

Please note that once per profile, when the testcase is run for the first time, the issue seems to not be fixed (TypeError: code is undefined - in browser console). Leaving the test to run for like 30 seconds, refreshing the page and starting it again will show the expected/fixed result.
Afterward, it will work fine on that profile.

Dan, did you experience this while testing Nightly? Could this be an issue?
When I tested Nightly, might've left the test on-going for that short time needed for it to work and this issue slipped due to that.

Comment 20

[Dan Minor [:dminor]]

(In reply to Timea Babos from comment #19)

Verified on latest Beta 67.0b13.

Please note that once per profile, when the testcase is run for the first time, the issue seems to not be fixed (TypeError: code is undefined - in browser console). Leaving the test to run for like 30 seconds, refreshing the page and starting it again will show the expected/fixed result.
Afterward, it will work fine on that profile.

Dan, did you experience this while testing Nightly? Could this be an issue?
When I tested Nightly, might've left the test on-going for that short time needed for it to work and this issue slipped due to that.

Hi Timea,

This is a known issue. The OpenH264 plugin is downloaded from a Cisco hosted CDN, it sometimes takes a minute or two for the download to complete. Cisco hosts the plugin for us for legal reasons, so unfortunately there is nothing we can do about this. Thank you for your help testing this!

Comment 21

[Timea Cernea [:tbabos][inactive]]

Ah, that makes sense. Thanks Dan!
Closing as Verified - Fixed.