Closed Bug 1133784 Opened 9 years ago Closed 9 years ago

Update OpenH264 plugin to version 1.4

Categories

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

Product:
Core
Component:
Audio/Video: GMP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: ehugg, Unassigned)

References

Details

No new release of OpenH264 is planned, so I'm creating this as a meta-bug to link all of the things that could be fixed by a new version.
Blocks: 1058887
Blocks: 1126855
Blocks: 1130225
Blocks: 1130224
A new version would also have the plugin side of bug 1125047 that landed in FF38.
A new version would have the plugin side of the video playback bug 1121258.
Blocks: 1145964
Blocks: 1145390
The OpenH264 plugin version 1.4 is now ready.  It can be found here:
https://github.com/cisco/openh264/tree/v1.4-Firefox38
Current tip is commit 4adf9cd6dd1358eefe3cbb5eddbfbf4ff06cfa65

It builds with the gmp-api from Firefox38 but should work on versions 37-39.

Version 1.4 changes relevant to Firefox:
- Decoder error fix to match bug 1125047 which also fixes bug 1145390
  This makes playback smoother in cases of packet loss.
- Compatible with video playback landed in FF38, bug 1121258
- Fix to vui to be compatible with H264 in the new Chromebook
- Fixes sec bugs 1058887, 1130225, 1130224 and 1145964

Note: we found a problem with nasm 2.11.08 and OSX. details here:
https://github.com/cisco/openh264/issues/1860
I believe the Mozilla build team is using yasm, so this should be a non-issue.
Summary: Release next OpenH264 plugin version → Update OpenH264 plugin to version 1.4
Not sure who is doing the builds, but once they're ready please hand over to do the metadata - it's gotten more complicated since we added EME into the GMP mix, and I'd like to try and write up some docs while I do this update.
Maire, do we need to push on this to get the builds going?
Flags: needinfo?(mreavy)
(In reply to Ethan Hugg [:ehugg] from comment #5)
> Maire, do we need to push on this to get the builds going?

Yes, I'd love to start the builds going.  Catlee has done all the builds in the past, and I expect he'll do the builds for v1.4.

Ethan -- Are we ready for a v1.4 build?  (I believe we are, but just want to confirm.)

Catlee -- Can you kick off the builds for v1.4 once we have confirmation from Ethan that we're ready? This is not a rush; we just want to start the process to get v1.4 out the door since it has some important fixes.
Flags: needinfo?(mreavy)
Flags: needinfo?(ethanhugg)
Flags: needinfo?(catlee)
Yes it is ready.  Details are in comment #3.
Flags: needinfo?(ethanhugg)
Depends on: 1154693
Flags: needinfo?(catlee)
(In reply to Chris AtLee [:catlee] from comment #8)
> CDN links here:
> https://ciscobinary.openh264.org/openh264-linux32-
> 4adf9cd6dd1358eefe3cbb5eddbfbf4ff06cfa65.zip  
> https://ciscobinary.openh264.org/openh264-linux64-
> 4adf9cd6dd1358eefe3cbb5eddbfbf4ff06cfa65.zip  
> https://ciscobinary.openh264.org/openh264-macosx64-
> 4adf9cd6dd1358eefe3cbb5eddbfbf4ff06cfa65.zip  
> https://ciscobinary.openh264.org/openh264-win32-
> 4adf9cd6dd1358eefe3cbb5eddbfbf4ff06cfa65.zip  
> https://ciscobinary.openh264.org/openh264-win64-
> 4adf9cd6dd1358eefe3cbb5eddbfbf4ff06cfa65.zip  
> https://ciscobinary.openh264.org/openh264-android-
> 4adf9cd6dd1358eefe3cbb5eddbfbf4ff06cfa65.zip

I mentioned this on IRC, but just so it doesn't get lost:
Are we still doing 32-bit Mac versions of this plugin? We have them for 1.3, but I don't see one in this list.
Flags: needinfo?(catlee)
Catlee told me on IRC that we're going to want 32-bit Mac builds at some point. In the meantime, I've set-up updates on the "nightlytest" channel for everything else. Can someone have a look and verify things for me? You'll need to modify defaults/pref/channel-prefs.js and change the app.update.channel to "nightlytest" before launching your browser.
Flags: needinfo?(mreavy)
Flags: needinfo?(ethanhugg)
(In reply to Ben Hearsum [:bhearsum] from comment #10)
> Catlee told me on IRC that we're going to want 32-bit Mac builds at some
> point. In the meantime, I've set-up updates on the "nightlytest" channel for
> everything else. Can someone have a look and verify things for me? You'll
> need to modify defaults/pref/channel-prefs.js and change the
> app.update.channel to "nightlytest" before launching your browser.

Thanks, Ben.  I'm also adding JuanB (our WebRTC QA lead) to the needinfo so he can try it too.  We just got the 32-bit OSX build from Catlee;  we have a 32-bit iMac in the lab, and I've asked Juan to try it out for us.
Flags: needinfo?(mreavy) → needinfo?(jbecerra)
Perhaps it's just me but I could not get this to work with either release or debug Nightly on OSX using the update channel "nightlytest".  I used a fresh profile and it did not attempt to download either version of the plugin or even appear to call the GMPInstallManager.  I did see this warning:

1429828857107	addons.update-checker	WARN	Update manifest for {972ce4c6-7e08-4474-a285-3208198ce6fd} did not contain an updates property

Does it work for anyone else?
Flags: needinfo?(ethanhugg)
(In reply to Ethan Hugg [:ehugg] from comment #12)
> Perhaps it's just me but I could not get this to work with either release or
> debug Nightly on OSX using the update channel "nightlytest".  I used a fresh
> profile and it did not attempt to download either version of the plugin or
> even appear to call the GMPInstallManager.  I did see this warning:

If you're using a 32-bit OS this doesn't surprise me...but I doubt that's the case.

> 1429828857107	addons.update-checker	WARN	Update manifest for
> {972ce4c6-7e08-4474-a285-3208198ce6fd} did not contain an updates property
> 
> Does it work for anyone else?

It sounds like your browser isn't getting a response at all. Can you set app.update.log to true, open the Browser Consolecheck for regular Firefox updates, and then paste the "https://aus4.mozilla.org" URL you get?
Flags: needinfo?(ethanhugg)
(In reply to Ethan Hugg [:ehugg] from comment #12)
> Perhaps it's just me but I could not get this to work with either release or
> debug Nightly on OSX using the update channel "nightlytest".  I used a fresh
> profile and it did not attempt to download either version of the plugin or
> even appear to call the GMPInstallManager.  I did see this warning:
> 
> 1429828857107	addons.update-checker	WARN	Update manifest for
> {972ce4c6-7e08-4474-a285-3208198ce6fd} did not contain an updates property
> 
> Does it work for anyone else?

I'm not even sure this is related to OpenH264, now that I have a second look at it. I'm pretty sure messages from the GMP media manager wouldn't say "addons.update-checker". I could be wrong, though.

I tried to get my Mac to update as well, but I ended up with a different error when right clicking OpenH264 in the addons manager and selecting "Find Updates":
Exception trying to format object for log message: [Exception... "Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIIncrementalDownload.loadGroup]"  nsresult: "0x80004001 (NS_ERROR_NOT_IMPLEMENTED)"  location: "JS frame :: resource://gre/modules/Log.jsm :: ParameterFormatter.prototype.format :: line 668"  data: no] Stack trace: ParameterFormatter.prototype.format()@resource://gre/modules/Log.jsm:668 < BasicFormatter.prototype.formatText()@resource://gre/modules/Log.jsm:569 < BF_format()@resource://gre/modules/Log.jsm:582 < App_append()@resource://gre/modules/Log.jsm:747 < Logger.prototype.log()@resource://gre/modules/Log.jsm:386 < LoggerRepository.prototype.getLoggerWithMessagePrefix/proxy.log()@resource://gre/modules/Log.jsm:501 < Logger.prototype.error()@resource://gre/modules/Log.jsm:394 < GMPProvider_updateTask()@resource://gre/modules/addons/GMPProvider.jsm:287 < throw()@self-hosted:641 < TaskImpl_run()@resource://gre/modules/Task.jsm:315 < Handler.prototype.process()@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:870 < this.PromiseWalker.walkerLoop()@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:746 < this.PromiseWalker.scheduleWalkerLoop/<()@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:688 < <file:unknown>

Same thing happened when I checked on Linux.

I'm guessing this is because the URLs we're pointing at throw cert errors. Eg: https://ciscobinary.openh264.org/openh264-win32-4adf9cd6dd1358eefe3cbb5eddbfbf4ff06cfa65.zip tells me "ciscobinary.openh264.org uses an invalid security certificate. The certificate is only valid for the following names: *.akamaihd.net, *.akamaihd-staging.net, a248.e.akamai.net, *.akamaized.net, *.akamaized-staging.net"

There's no reason to use SSL for these, so I'll switch them to http and see if that helps.
That made the difference - I got 1.4 on Linux and Mac now.
Flags: needinfo?(ethanhugg)
Pushing these out is going to be pretty complicated. I'm going to be away next week so someone else is going to have to take care of it. Right now there's 7 rules set-up in Balrog for GMP on the nightlytest channel. I've drawn up a table of the state of things right now over at https://wiki.mozilla.org/User:Bhearsum/GMP_Updates which I hope will help in testing/verification. Note that the first 4 columns talk about current state of the "nightlytest" channel. I couldn't figure out a way to represent the data where it wolud be accurate for both channels.

If testing looks good (including pushing 1.4 for Android on Nightly), here's what I suggest:
* Delete all of the existing rules with product="GMP" but no channel set. There is a bug in these rules that's causing the wrong version of OpenH264 to get served to Windows XP users which is fixed in the new set of nightlytest rules.
* Duplicate each of the product="GMP", channel="nightlytest" rules, with the following tweaks
** Drop the channel restriction
** Reduce the priority (while maintaining the relative priority of the new rules). Subtracting 50 from the priority of each rule should do the trick.

When we want to push to Aurora, the rules that point at the GMP-20150423-No-CDM-OpenH264-v1.4 and GMP-20150423-CDM-v8-OpenH264-v1.4 blobs need to have their version restrictions changed from "40.0a1" to "39.0a1".

When we want to push to Beta, those rules need to have their version changed to "38.0a1". At this point there will be an existing rule with the same restrictions that points at CDM 8, OpenH264 (GMP-20150415) that should be deleted.

When we want to push to Release, the rules need to have their version changed to "37.0a1". The rule that points at GMP-20150423-CDM-v8-OpenH264-v1.4 also needs to be changed to point at GMP-20150423-CDM-v4-OpenH264-v1.4. The rule with the same restrictions that points at CDM 4, OpenH264 1.3 (GMP-v1.4-20150316) should be deleted at this time.

All of the above assumes that there's nothing special going on with Android. If it needs to be held to 1.3 an extra rule needs to be added before pushing to Nightly with the following values:
* product: GMP
* mapping: GMP-v1.3-201501271800
* priority: higher than the priority of the GMP-20150423-CDM-v8-OpenH264-v1.4 rule
* background rate: 100
* build target: Android_arm-eabi-gcc3

You can test to make sure this works by adding an equivalent rule with channel set to "nightlytest" if you need to do this.
This worked for me now on OSX64.   With a fresh profile, it downloaded 1.4 into a '1.4' directory.  Diff says it's the same as the release and works with pc_test.
We've always been loading them over http.  The bug for loading the OpenH264 plugin over https is bug 1102531
(In reply to Ethan Hugg [:ehugg] from comment #18)
> We've always been loading them over http.  The bug for loading the OpenH264
> plugin over https is bug 1102531

Yeah, this was my mistake. There's really no reason to load them over https because we serve a sha512 sum over https that the client verifies.
I added a rule to keep Android on 1.3 on the nightlytest channel.
v1.4 is live for gecko 40+ users now. Android is excluded for now and it stays on v1.3
I updated the nightlytest channel rules to serve v1.4 for Gecko 39+ (Aurora aka Dev Edition). Android is still on v1.3.
Just tried this out on Win32 and OSX64 with fresh profiles on Nightly.  Got 1.4, verified it was the same as what Chis sent out, and it worked with pc_test on the landing page.
(In reply to Maire Reavy [:mreavy] (Plz needinfo me) from comment #11)
> (In reply to Ben Hearsum [:bhearsum] from comment #10)
> > Catlee told me on IRC that we're going to want 32-bit Mac builds at some
> > point. In the meantime, I've set-up updates on the "nightlytest" channel for
> > everything else. Can someone have a look and verify things for me? You'll
> > need to modify defaults/pref/channel-prefs.js and change the
> > app.update.channel to "nightlytest" before launching your browser.
> 
> Thanks, Ben.  I'm also adding JuanB (our WebRTC QA lead) to the needinfo so
> he can try it too.  We just got the 32-bit OSX build from Catlee;  we have a
> 32-bit iMac in the lab, and I've asked Juan to try it out for us.

I see that this got added to the blob at some point too...removing needinfo for catlee.
Flags: needinfo?(catlee)
(In reply to Ben Hearsum [:bhearsum] from comment #24)
> (In reply to Maire Reavy [:mreavy] (Plz needinfo me) from comment #11)
> > (In reply to Ben Hearsum [:bhearsum] from comment #10)
> > > Catlee told me on IRC that we're going to want 32-bit Mac builds at some
> > > point. In the meantime, I've set-up updates on the "nightlytest" channel for
> > > everything else. Can someone have a look and verify things for me? You'll
> > > need to modify defaults/pref/channel-prefs.js and change the
> > > app.update.channel to "nightlytest" before launching your browser.
> > 
> > Thanks, Ben.  I'm also adding JuanB (our WebRTC QA lead) to the needinfo so
> > he can try it too.  We just got the 32-bit OSX build from Catlee;  we have a
> > 32-bit iMac in the lab, and I've asked Juan to try it out for us.
> 
> I see that this got added to the blob at some point too...removing needinfo
> for catlee.

Actually....I just realized that we're pointing at nothing for them still, eg:
        "Darwin_x86-gcc3-u-i386-x86_64": {
          "fileUrl": "http://TODO",
          "hashValue": "TODO",
          "filesize": 0
        },

Considering this is shipped for the release channel we should probably get this fixed ASAP.
Flags: needinfo?(mreavy)
Juan -- We want to push out v1.4 of the plugin of the bug for OSX 32-bit builds.  Can you confirm in this bug that v1.4 works against Fx38 for OSX 32-bit?  If so, we'll push it out Monday along with pushing out all builds to Fx37.  

(I realize Fx37 is basically obsoleted now that Fx38 is released, but it can take a while for folks to update.)
Flags: needinfo?(mreavy)
I tested v1.4 on Mac OS X 10.6x with Firefox 38.x running in 32bit mode. I ran the example in mozilla.github.io/webrtc-landing/pc_test.html and that worked.
Flags: needinfo?(jbecerra)
OpenH264 v1.4 is now shipping for all desktop versions 37+, so marking this as fixed.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Blocks: 1156342
No longer blocks: 1156342
catlee, do you have the url to the 32bit mac build ? Does cisco have it up on their host already ?
Flags: needinfo?(catlee)
catlee tells me the hash in the filename is for the source, and lo, this works
http://ciscobinary.openh264.org/openh264-macosx32-4adf9cd6dd1358eefe3cbb5eddbfbf4ff06cfa65.zip
Flags: needinfo?(catlee)
I've added that build to GMP-201506014-CDM-v11-OpenH264-v1.4.json, which is the latest and greatest.
Also updated GMP-20150423-CDM-v4-OpenH264-v1.4 and GMP-20150423-No-CDM-OpenH264-v1.4
At some point, either May 19 or July 9, we started serving OpenH264 v1.4 to Android too.
Component: OpenH264 → Audio/Video: GMP
Product: External Software Affecting Firefox → Core
You need to log in before you can comment on or make changes to this bug.