Closed Bug 1284285 Opened 8 years ago Closed 6 years ago

[meta] OpenH264 plugin release v1.7.1

Categories

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

defect

Tracking

()

RESOLVED FIXED

People

(Reporter: hankpeng, Assigned: hankpeng)

References

Details

(Keywords: meta)

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.
Assignee: nobody → hankpeng
Blocks: 1368873
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.
Summary: New release of OpenH264 (>1.6.0) → OpenH264 plugin release v1.7.1
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 ?
Flags: needinfo?(hankpeng)
Hi Nick, The CDN domain name should be static and rarely changes. Thanks.
Flags: needinfo?(hankpeng)
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.
Flags: needinfo?(nthomas)
OK, waiting for more information.
Flags: needinfo?(nthomas)
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.
Flags: needinfo?(nthomas)
OK, thanks for the update.
Flags: needinfo?(nthomas)
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
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.
Flags: needinfo?(ajones)
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.
Flags: needinfo?(drno)
Nick - Nils is it.
Flags: needinfo?(ajones)
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.
Flags: needinfo?(drno)
We pushed 1.7.1 to users with 58.0a1 on Friday Oct 20th (ie current mozilla-central version).
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).
That includes devedition too.
Keywords: meta
Priority: -- → P1
Now available to users for 56.0a1 and higher, which includes the current 'release' builds. Only ESR52 left to consider now.
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
Priority: P1 → P3
Summary: OpenH264 plugin release v1.7.1 → [meta] OpenH264 plugin release v1.7.1
ESR52 is EOL, and ESR60 gets 1.7.1, so nothing more to do here.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
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.