Closed Bug 1113777 Opened 10 years ago Closed 10 years ago

Update OpenH264 plugin to 1.3

Categories

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

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

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: ehugg, Unassigned)

References

Details

There have been a number of security fixes in OpenH264 which I will link to this bug. Also this version has a number of improvements and is compliant with more of the H264 specs. Release notes - https://github.com/cisco/openh264/blob/v1.3-Firefox36/RELEASES The branch to build from is 'v1.3-Firefox36' on github.com/cisco/openh264 It builds with the branch 'Firefox36' of github.com/mozilla/gmp-api, but should be compatible with older versions up to 34. The gmp-api has changed but not in a way that is significant to OpenH264. Testing would need to verify this of course. On the Linux and OSX builds the library we use will be named like libgmpopenh264.so.0 with a link from the usual name. You will want update your scripts to rename that file to libgmpopenh264.so to put into the download. Also there has been some progress on the effort to use this for the Android version of Firefox so you should consider making an android build as well. A sample of building for android can be found here - https://github.com/ethanhugg/openh264/blob/travis.android/.travis.yml We should wait until we get feedback from the Android team to see how they are bulding it. I will needinfo them here. Also, Bug 1074395 has a request about versioning of OpenH264 that should be considered. CCing Nils as I assume we will want buy-off from Testing before posting builds to the CDN.
Blocks: 1106397
Blocks: 1106398
Blocks: 1106399
Blocks: 1106402
Blocks: 1106404
Blocks: 1109371
Assuming we would like an android build on the CDN, we need feedback from the Android team about how you have been building it and what you recommend.
(In reply to Ethan Hugg [:ehugg] from comment #1) > Assuming we would like an android build on the CDN, we need feedback from > the Android team about how you have been building it and what you recommend.
Flags: needinfo?(snorp)
(In reply to Ethan Hugg [:ehugg] from comment #1) > Assuming we would like an android build on the CDN, we need feedback from > the Android team about how you have been building it and what you recommend. We are using NDK 8e, platform-9 right now for gecko (gcc 4.6?). I guess it makes sense to use the same for openh264. The openh264 build requires SDK stuff too, but that's just for the example app (AFAIK), so I don't care about that.
Flags: needinfo?(snorp)
Four new bugs found on this branch we should fix before building and posting to CDN: Bug 1114990 Bug 1114992 Bug 1114993 Bug 1114996
Blocks: 1114990
Blocks: 1114992
Blocks: 1114993
Blocks: 1114996
Hey Ethan -- At this point, I assume we'll build early in the new year (Jan 5 or a little later). Does that timing sound about right to you?
Flags: needinfo?(ethanhugg)
That sounds fine, we should have things settled by then. My assumption is that we'll put this version in for 36+ and let it ride the train from there.
Flags: needinfo?(ethanhugg)
Blocks: 1115349
Blocks: 1115381
Tested this morning with 32 and 64bit ASAN builds and it appears that the known sec bugs have been fixed in the latest v1.3-Firefox36 branch. Tip of this branch is currently this commit: https://github.com/cisco/openh264/commit/1d32e96ab7e761afe09e9cb114b919c9b08eb54f
Ethan, were you able to get the Android builds going for this release?
Flags: needinfo?(ethanhugg)
I don't make the builds. The Mozilla build team makes the builds and we host them on the CDN. Android should build and work with this release.
Flags: needinfo?(ethanhugg)
FYI: I talked with catlee and ehugg, and I'd like to target end of next week to build and deploy an update to the OpenH264 plugin for desktop. We'll also push out an Android version of the plugin, but we won't gate updating the desktop versions plugin on Android if we run into delays with Android. If anyone feels we need to push out an update sooner, please chime in now (or soon) on this bug -- else it will go out end of next week. Thanks!
From discussion with Randell via IRC - another build we should consider making for this in Win64 so that it's ready for a future Win64 release.
Blocks: 1114748
Blocks: 1113806
Depends on: 1122316
From the resolution of bug 1122316 I assume that we do not need to make the OSX 32bit plugin any more. Is this correct?
(In reply to Ethan Hugg [:ehugg] from comment #12) > From the resolution of bug 1122316 I assume that we do not need to make the > OSX 32bit plugin any more. Is this correct? I can't answer this for sure. I just learned that the reason why we still ship a universal Mac binary with 32bit support is that there are people our there which run 10.6 on 32bit hardware.
For the record: desktop computers with 32bit processors got last shipped by Apple in 2006/2007 (depending on the exact device).
Nils was able to do minimal testing of the OSX 32bit plugin. So my suggestion is that we make it available this time with the following message (I'm open to wordsmithing): "The OSX 32bit plugin has been minimally tested. All are welcome to use it and report bugs, but bugs that are specific to it being 32bit will be a very low priority to fix. Our intention is to phase out the 32bit version of the OSX plugin."
I believe we're a "go" for releasing updates to the desktop plugin next week. Target date is Tues, Jan 27th. I'm about to post a note to release-drivers. FYI: We should have a plugin build for Android, ready for testing, sometime next week. Catlee is doing the build.
(In reply to Maire Reavy [:mreavy] (Plz needinfo me) from comment #15) > Nils was able to do minimal testing of the OSX 32bit plugin. So my > suggestion is that we make it available this time with the following message > (I'm open to wordsmithing): "The OSX 32bit plugin has been minimally > tested. All are welcome to use it and report bugs, but bugs that are > specific to it being 32bit will be a very low priority to fix. Our > intention is to phase out the 32bit version of the OSX plugin." This is fine, but I'm not sure we need to say anything. Nils did try it out and I'm not sure we'll have very many 32bit OSX users using WebRTC.
(In reply to Maire Reavy [:mreavy] (Plz needinfo me) from comment #16) > I believe we're a "go" for releasing updates to the desktop plugin next > week. Target date is Tues, Jan 27th. I'm about to post a note to > release-drivers. > > FYI: We should have a plugin build for Android, ready for testing, sometime > next week. Catlee is doing the build. One more thing on this. You should make sure that the files sent to Cullen to be put on the CDN are named in the way that satisfies the request in bug 1074395.
Depends on: 1127591
No longer depends on: 1127591
OpenH264 plugin 1.3 is now downloaded for FF34+ as of today, so I'm marking this bug as fixed
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.