Closed Bug 1061808 Opened 10 years ago Closed 10 years ago

Update OpenH264 builds for FF33 and FF34

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, Assigned: Callek)

Details

In a similar fashion to this bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1043416

We need to update OpenH264 again for FF33 and FF34. This is primarily for this null-check patch:

https://github.com/cisco/openh264/commit/863617f62044aa949d9b8af0c0a55fddacd89a46

Here are the commit details, both of these are currently tip.

For branch v1.1-Firefox33:

commit c79be44e930a840a30f65723bcb9b2e280bd904e
Merge: b4504d4 863617f
Author: ruil2 <ruil2@cisco.com>
Date:   Wed Aug 20 08:55:24 2014 +0800

For branch v1.1-Firefox34:

commit cef43e30fe3bb83ca72bdf431ac5fa7efa356dc2
Merge: c1cc195 b5a01ef
Author: dongzha <dongzha@cisco.com>
Date:   Tue Sep 2 15:50:04 2014 +0800
FYI - for anyone testing with local builds of OpenH264, MOZ_GMP_PATH has changed a bit in 34 but not 33.  So you'll need to use something like "~/tmp/gmp-gmpopenh264/1.0" for FF34.  Here's the note about this from cpearce:

With the landing of  Bug 1045209, starting today in Firefox Nightly builds the disk layout of GMPs changed to accomodate multiple versions of a GMP being resident on disk. The consequence of that is that the usage of MOZ_GMP_PATH also changed. You are now must have a version subdirectory of your "gmp-*" directory, and put your .dll/.dylib/.so and ..info files in there.

i.e. previously you could have:

MOZ_GMP_PATH=/home/username/src/gmp-foobar/

... and now you'll need:

MOZ_GMP_PATH=/home/username/src/gmp-foobar/some_arbitrary_version_string/

What you call the version subdir is completely arbitrary for the purposes of using MOZ_GMP_PATH.
Does this mean you're ready for us to do builds?
Flags: needinfo?(ethanhugg)
Yes.  Sorry if that wasn't clear.  Hopefully these will be the final builds for these versions.
Flags: needinfo?(ethanhugg)
Over to you Callek. I'll do the update metadata modifications when you're done.
Assignee: nobody → bugspam.Callek
win32 and osx is now built, catlee promised to do the linux ones shortly.

For any early-adopters they are in:

https://people.mozilla.org/~jwood/openh264/2014-09-02/

I'll leave it to catlee or ben to do the official mail/upload/whatever to their final resting place.
Builds have been sent over, here are their corresponding hashes.

ef401c8c80f98e2df8942e601ccefb41ba701753ac3b28ca8bfa1830780c27a5a17f488ba689427500555753e332a0849aac82e93ef9178c85b06f6f2d44438f  openh264-linux32-v1.1-Firefox33.zip
48fbf041b36313b65d814693c84f997a38936832b3bd6e696fefb10da16a7fc9f1a412c6e557b99d75089c70c40d393c4503c7544a8636a59ba379e406f1b8d5  openh264-linux32-v1.1-Firefox34.zip
737e49f25aace93d470f1a781c69c3cdd0c9db21afe62221fb171d38a31d8a2b55af01a69cd00e7352e7a34aa450b6b85729509f81582379394785b37997a423  openh264-linux64-v1.1-Firefox33.zip
472543802d4d5fa9144365088c81d4b0457e765e57fa153ced03c41d790007b8351f6ed702d5ed39be66cfdbdb83bcbf89341ae1551190afd29888cd7a5adfb6  openh264-linux64-v1.1-Firefox34.zip
52450eb26827e2084df3b9db1e9bc1b00d937fffdb438af070f5057878687793c1b07ac06a797901a5914a0968c825a7fd1925653511387130732027dd0803e4  openh264-macosx32-v1.1-Firefox33.zip
d993368b46d16f2ed47d908a5e20c28553627c93f41ee357fdd3aaa98318b8b31dbf3b3f7505a70f0eca25c60ad462e13ff51a8e9f5695dfa0a45f95fb834fd1  openh264-macosx32-v1.1-Firefox34.zip
525fb4851f12cc4be9c798add4414f180441eabcf71768b29394bdc5413ba5ae79bfda5f803965be61fd2b18f8eb7dd733273ed42e34ff01de31f2c8ace9df35  openh264-macosx64-v1.1-Firefox33.zip
37db5840f9de507bb76866659598184337745eb0242ecad4924cf7e5764e3a243dae77beba6f040420fddf2cacaa9d56ae3ca9519404508aaec55233e1970cfc  openh264-macosx64-v1.1-Firefox34.zip
e12ae17e53649353665adfd6bafe7da2ae8f16e460e567fda99b1a221d5ddda9f1ba054876f1e1deb654ffcf1ee0f9cdae1f84bbaf02e163778fafaef6fd62c8  openh264-win32-v1.1-Firefox33.zip
235c9a6fc530ce38a03e46c6daa4c2538a6281d5e786fcd25b3de1e7d8b4ef97cd94502fa6f55d48928805603a30c4fa0921dfc540641265c33731c3fc0254ff  openh264-win32-v1.1-Firefox34.zip
One more thing - I just built a Nightly from M-C and it's versioned 35, so we should make the FF34 build of OpenH264 download for FF35 as well.  It currently doesn't find its build of OpenH264.
I just updated the update server with the new metadata.

(In reply to Ethan Hugg [:ehugg] from comment #7)
> One more thing - I just built a Nightly from M-C and it's versioned 35, so
> we should make the FF34 build of OpenH264 download for FF35 as well.  It
> currently doesn't find its build of OpenH264.

This was filed as bug 1062259, and has been fixed as part of this.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Anthony -- Can someone on your team verify that this works for Nightly, Aurora, and Beta on all the major Desktop platforms (Windows, Mac, Linux)?  Thanks!
Flags: needinfo?(anthony.s.hughes)
Whiteboard: [qa+]
(In reply to Maire Reavy [:mreavy] (Plz needinfo me) from comment #9)
> Anthony -- Can someone on your team verify that this works for Nightly,
> Aurora, and Beta on all the major Desktop platforms (Windows, Mac, Linux)? 
> Thanks!

What specifically needs to be checked here? Is it just verifying the version of OpenH264 in add-ons manager?
Flags: needinfo?(anthony.s.hughes) → qe-verify+
Whiteboard: [qa+]
We updated the OpenH264 plugin builds for Fx33, Fx34,and Fx35.  I just want to verify that the plugin builds run for all major Desktop platforms (Windows, Mac, Linux).  You can test this by making an OpenH264 WebRTC call on each platform with each release.  Some of this testing has already been done, but I don't believe everyone has tried every combination yet.
Sorry, I'm not the most knowledgeable when it comes to this -- is there a website which specifically uses OpenH264? Does Loop *always* use OpenH264? Which competitor browser versions need to be added to the mix?
This isn't Loop.  I was ni'ing you because Nils is on PTO.  This is a platform issue.

Go to http://mozilla.github.io/webrtc-landing/pc_test.html and click "Require H.264 video".  That will force an OpenH264 call.  Then start the call.  If you get real video in one direction and a solid colored rectangle that changes color, the plugin is working.  (NOTE:  You'll want to use a new profile to force a fresh download of the plugin and wait for a couple of mins for the plugin to install.)
Thanks for that info. Does this need testing with competitor browsers in the mix too?
You need to log in before you can comment on or make changes to this bug.