1113777 - Update OpenH264 plugin to 1.3

Status: RESOLVED FIXED

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

Description

[Ethan Hugg [:ehugg]]

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.

Comment 1

[Ethan Hugg [:ehugg]]

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.

Comment 2

[Ethan Hugg [:ehugg]]

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

Comment 3

[James Willcox (:snorp) ([e-mail]) (he/him)]

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

Comment 4

[Ethan Hugg [:ehugg]]

Four new bugs found on this branch we should fix before building and posting to CDN:

Bug 1114990
Bug 1114992
Bug 1114993
Bug 1114996

Comment 5

[Maire Reavy [:mreavy]]

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?

Comment 6

[Ethan Hugg [:ehugg]]

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.

Comment 7

[Ethan Hugg [:ehugg]]

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

Comment 8

[James Willcox (:snorp) ([e-mail]) (he/him)]

Ethan, were you able to get the Android builds going for this release?

Comment 9

[Ethan Hugg [:ehugg]]

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.

Comment 10

[Maire Reavy [:mreavy]]

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!

Comment 11

[Ethan Hugg [:ehugg]]

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.

Comment 12

[Ethan Hugg [:ehugg]]

From the resolution of bug 1122316 I assume that we do not need to make the OSX 32bit plugin any more.  Is this correct?

Comment 13

[Nils Ohlmeier [:drno]]

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

Comment 14

[Nils Ohlmeier [:drno]]

For the record: desktop computers with 32bit processors got last shipped by Apple in 2006/2007 (depending on the exact device).

Comment 15

[Maire Reavy [:mreavy]]

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

Comment 16

[Maire Reavy [:mreavy]]

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.

Comment 17

[Ethan Hugg [:ehugg]]

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

Comment 18

[Ethan Hugg [:ehugg]]

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

Comment 19

[Jordan Lund (:jlund)]

In production: https://hg.mozilla.org/build/mozharness/rev/45c4782532a4

Comment 20

[Ethan Hugg [:ehugg]]

OpenH264 plugin 1.3 is now downloaded for FF34+ as of today, so I'm marking this bug as fixed