1284285 - [meta] OpenH264 plugin release v1.7.1

Status: RESOLVED FIXED

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

Description

[Hank Peng]

This is a meta bug to track all the things that should be got into the next release of OpenH264 with version >1.6.0.

Comment 1

[Hank Peng]

The gmp-openh264 v1.7.1 is ready to pickup. The code branch is v1.7.1-Firefox39: https://github.com/cisco/openh264/tree/v1.7.1-Firefox39. The current tip commit is https://github.com/cisco/openh264/commit/6c2e7008f8bbe2ff90100972f97071eb87ec37cb.

Note: 
1. The previous release is v1.6.0. We'd like to skip the plugin release v1.7.0, in order to include the fix of bug "OpenH264: UBSan index out of bounds in [@WelsDec::WelsInitRefList]" (https://bugzilla.mozilla.org/show_bug.cgi?id=1368873). 

2. The domain name of CDN download URL is https://c7ab4fbd1155b1257820-fefb1450afc680271ea365edabf976ea.ssl.cf1.rackcdn.com/ other than http://ciscobinary.openh264.org/ since this release.

Comment 2

[Nick Thomas [:nthomas] (UTC+12)]

I'm tracking the Release Engineering work over in bug 1380605. Regarding your notes

1, No problems with skipping 1.7.0 from my point of view
2, We'll need to whitelist the new domain in the Firefox update server, is it likely to change again or often ?

Comment 3

[Hank Peng]

Hi Nick,
The CDN domain name should be static and rarely changes. Thanks.

Comment 4

[Hank Peng]

Hi Nich,
We noticed that the new domain name (https://c7ab4fbd1155b1257820-fefb1450afc680271ea365edabf976ea.ssl.cf1.rackcdn.com) to host the binaries is the internal container name of the CDN, which should not be used by the users directly. 

We are fixing it now. Please don't use it in your production. Sorry for the inconvenience.

Comment 5

[Nick Thomas [:nthomas] (UTC+12)]

OK, waiting for more information.

Comment 6

[Hank Peng]

Hi Nick,
We managed to keep the previous CDN domain name (http://ciscobinary.openh264.org/) and finished the deployment. You can go ahead with your integration and send the plugin binaries to me when ready. Thanks.

Comment 7

[Nick Thomas [:nthomas] (UTC+12)]

OK, thanks for the update.

Comment 8

[Hank Peng]

The plugin binaries and deployed into CDN. 

http://ciscobinary.openh264.org/SHA512SUMS
http://ciscobinary.openh264.org/SHA512SUMS.asc
http://ciscobinary.openh264.org/openh264-android-aarch64-6c2e7008f8bbe2ff90100972f97071eb87ec37cb.zip
http://ciscobinary.openh264.org/openh264-android-aarch64-6c2e7008f8bbe2ff90100972f97071eb87ec37cb.zip.asc
http://ciscobinary.openh264.org/openh264-android-arm-6c2e7008f8bbe2ff90100972f97071eb87ec37cb.zip
http://ciscobinary.openh264.org/openh264-android-arm-6c2e7008f8bbe2ff90100972f97071eb87ec37cb.zip.asc
http://ciscobinary.openh264.org/openh264-android-x86-6c2e7008f8bbe2ff90100972f97071eb87ec37cb.zip
http://ciscobinary.openh264.org/openh264-android-x86-6c2e7008f8bbe2ff90100972f97071eb87ec37cb.zip.asc
http://ciscobinary.openh264.org/openh264-linux32-6c2e7008f8bbe2ff90100972f97071eb87ec37cb.zip
http://ciscobinary.openh264.org/openh264-linux32-6c2e7008f8bbe2ff90100972f97071eb87ec37cb.zip.asc
http://ciscobinary.openh264.org/openh264-linux64-6c2e7008f8bbe2ff90100972f97071eb87ec37cb.zip
http://ciscobinary.openh264.org/openh264-linux64-6c2e7008f8bbe2ff90100972f97071eb87ec37cb.zip.asc
http://ciscobinary.openh264.org/openh264-macosx64-6c2e7008f8bbe2ff90100972f97071eb87ec37cb.zip
http://ciscobinary.openh264.org/openh264-macosx64-6c2e7008f8bbe2ff90100972f97071eb87ec37cb.zip.asc
http://ciscobinary.openh264.org/openh264-win32-6c2e7008f8bbe2ff90100972f97071eb87ec37cb.zip
http://ciscobinary.openh264.org/openh264-win32-6c2e7008f8bbe2ff90100972f97071eb87ec37cb.zip.asc
http://ciscobinary.openh264.org/openh264-win64-6c2e7008f8bbe2ff90100972f97071eb87ec37cb.zip
http://ciscobinary.openh264.org/openh264-win64-6c2e7008f8bbe2ff90100972f97071eb87ec37cb.zip.asc

Comment 9

[Nick Thomas [:nthomas] (UTC+12)]

From bug 1380605 we have 1.7.1 on the nightlytest channel now, and it passes a quick smoketest on mac. 

Anthony, are you on the hook for organizing some QE against Nightly ? I don't have any pointers to what we did for 1.6, sorry.

Comment 10

[Maire Reavy [:mreavy]]

Hi Nick, I'm the one who always handled the QE for this against Nightly.  I'm needinfo'ing Nils because my intention is to hand this off to responsibility off to him going forward.

Nils -- We'll want to coordinate with release-drivers that a new version of OpenH264 is coming and make sure that the timing works for them. We can talk about how to do that tomorrow on irc or slack -- or in our meeting with jib and Anthony.

Comment 11

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Nick - Nils is it.

Comment 13

[Nils Ohlmeier [:drno]]

I manually tested the 1.7.1 plugin on Linux, Win and Mac in Fx 56, 57 and 58.

The only issue I found is bug 1397539, but as that is already an existing bug for the current 1.6 plugin I don't think it's blocking this release.

I'm going to propose to release drivers to push this out through the channels next week if possible.

Comment 14

[Nick Thomas [:nthomas] (UTC+12)]

We pushed 1.7.1 to users with 58.0a1 on Friday Oct 20th (ie current mozilla-central version).

Comment 15

[Nick Thomas [:nthomas] (UTC+12)]

We've now pushed 1.7.1 to users with 57.0a1 or higher (ie current mozilla-beta, plus current and previous and m-c versions).

Comment 16

[Nick Thomas [:nthomas] (UTC+12)]

That includes devedition too.

Comment 18

[Nick Thomas [:nthomas] (UTC+12)]

Now available to users for 56.0a1 and higher, which includes the current 'release' builds. Only ESR52 left to consider now.

Comment 19

[BugBot [:suhaib / :marco/ :calixte]]

Moving to p3 because no activity for at least 24 weeks.
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

Comment 20

[Nick Thomas [:nthomas] (UTC+12)]

ESR52 is EOL, and ESR60 gets 1.7.1, so nothing more to do here.