Closed
Bug 1133784
Opened 10 years ago
Closed 10 years ago
Update OpenH264 plugin to version 1.4
Categories
(Core :: Audio/Video: GMP, defect)
Core
Audio/Video: GMP
Tracking
()
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.
Reporter | ||
Comment 1•10 years ago
|
||
A new version would also have the plugin side of bug 1125047 that landed in FF38.
Reporter | ||
Comment 2•10 years ago
|
||
A new version would have the plugin side of the video playback bug 1121258.
Reporter | ||
Comment 3•10 years ago
|
||
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.
Reporter | ||
Updated•10 years ago
|
Summary: Release next OpenH264 plugin version → Update OpenH264 plugin to version 1.4
Comment 4•10 years ago
|
||
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.
Reporter | ||
Comment 5•10 years ago
|
||
Maire, do we need to push on this to get the builds going?
Flags: needinfo?(mreavy)
Comment 6•10 years ago
|
||
(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)
Reporter | ||
Comment 7•10 years ago
|
||
Yes it is ready. Details are in comment #3.
Flags: needinfo?(ethanhugg)
Updated•10 years ago
|
Flags: needinfo?(catlee)
Comment 8•10 years ago
|
||
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
Comment 9•10 years ago
|
||
(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)
Comment 10•10 years ago
|
||
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)
Comment 11•10 years ago
|
||
(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)
Reporter | ||
Comment 12•10 years ago
|
||
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)
Comment 13•10 years ago
|
||
(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)
Comment 14•10 years ago
|
||
(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.
Comment 15•10 years ago
|
||
That made the difference - I got 1.4 on Linux and Mac now.
Flags: needinfo?(ethanhugg)
Comment 16•10 years ago
|
||
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.
Reporter | ||
Comment 17•10 years ago
|
||
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.
Reporter | ||
Comment 18•10 years ago
|
||
We've always been loading them over http. The bug for loading the OpenH264 plugin over https is bug 1102531
Comment 19•10 years ago
|
||
(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.
Comment 20•10 years ago
|
||
I added a rule to keep Android on 1.3 on the nightlytest channel.
Comment 21•10 years ago
|
||
v1.4 is live for gecko 40+ users now. Android is excluded for now and it stays on v1.3
Comment 22•10 years ago
|
||
I updated the nightlytest channel rules to serve v1.4 for Gecko 39+ (Aurora aka Dev Edition). Android is still on v1.3.
Reporter | ||
Comment 23•10 years ago
|
||
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.
Comment 24•10 years ago
|
||
(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)
Comment 25•10 years ago
|
||
(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)
Comment 26•10 years ago
|
||
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)
Comment 27•10 years ago
|
||
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)
Reporter | ||
Comment 28•10 years ago
|
||
OpenH264 v1.4 is now shipping for all desktop versions 37+, so marking this as fixed.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Comment 29•10 years ago
|
||
catlee, do you have the url to the 32bit mac build ? Does cisco have it up on their host already ?
Flags: needinfo?(catlee)
Comment 30•10 years ago
|
||
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)
Comment 31•10 years ago
|
||
I've added that build to GMP-201506014-CDM-v11-OpenH264-v1.4.json, which is the latest and greatest.
Comment 32•10 years ago
|
||
Also updated GMP-20150423-CDM-v4-OpenH264-v1.4 and GMP-20150423-No-CDM-OpenH264-v1.4
Comment 33•9 years ago
|
||
At some point, either May 19 or July 9, we started serving OpenH264 v1.4 to Android too.
Assignee | ||
Updated•2 years ago
|
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.
Description
•