Enable openh264 plugin for win64-aarch64

VERIFIED FIXED in Firefox 67

Status

()

enhancement
P2
normal
Rank:
15
VERIFIED FIXED
3 months ago
a month ago

People

(Reporter: dminor, Assigned: dminor)

Tracking

(Blocks 1 bug)

66 Branch
mozilla68
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox67 verified, firefox68 verified)

Details

Attachments

(2 attachments)

Assignee

Description

3 months ago

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.

Assignee

Updated

3 months ago
Depends on: 1515210
Assignee

Updated

3 months ago
Assignee: nobody → dminor
Assignee

Comment 2

2 months ago

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.

Assignee

Comment 3

2 months ago

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.

Assignee

Comment 4

2 months ago

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!

Flags: needinfo?(bugspam.Callek)
Assignee

Updated

2 months ago
Rank: 15
Priority: P3 → P2

(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.

Assignee

Comment 6

2 months ago

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 8

2 months ago
Pushed by Callek@gmail.com:
https://hg.mozilla.org/mozilla-central/rev/00c5ef76d951
Fix openh264 win64-aarch64 platform so signing can find it. r=dminor a=apavel|sheriffduty

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

Flags: needinfo?(bugspam.Callek)
Attachment #9053641 - Attachment description: Bug 1533071 - Enable OpenH264 plugin for win64-aarch64 → Bug 1533071 - Enable OpenH264 plugin for win64-aarch64; r=jya

Comment 10

2 months ago
Pushed by dminor@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/b53ad3248711
Enable OpenH264 plugin for win64-aarch64; r=jya

Comment 11

2 months ago
bugherder
Status: NEW → RESOLVED
Last Resolved: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
Assignee

Comment 12

a month ago

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
  1. Select 'Require OpenH264 Video'
  2. Unselect 'Enable Identity Provider'
  3. Click start.
  4. 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.
Attachment #9053641 - Flags: approval-mozilla-beta?
Assignee

Updated

a month ago
Flags: qe-verify?

Let's have QA verify in nightly first.

Flags: qe-verify? → qe-verify+
QA Whiteboard: [qa-triaged]

Comment 14

a month ago

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?

Flags: needinfo?(dminor)
Assignee

Comment 15

a month ago

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

Flags: needinfo?(dminor)

Comment 16

a month ago

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.

Flags: qe-verify+

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.

Attachment #9053641 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

Comment 19

a month ago

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.

Flags: needinfo?(dminor)
Assignee

Comment 20

a month ago

(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!

Flags: needinfo?(dminor)

Comment 21

a month ago

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

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.