Closed Bug 1388771 Opened 3 years ago Closed 2 years ago
Update Widevine CDM to version 1008 (Windows, Mac, and Linux)
We are planning to update the CDM when bug 1383769 is fixed. The detail will be provided once we verified the new CDM on Windows, Linux and Mac.
We probably want to depend on bug 1382882, which is the entire releng stack. I think we're done with the signing server side (bug 1383769) but we still have to land on m-c (bug 1383771). We can uplift bug 1383771 to beta once it looks good on central.
Depends on: 1382882
We change our target to version 984. So I'd like to change the bug title and wait for the sig file landed in Nightly. Thank you Aki.
Summary: Update Widevine CDM to version 1008 (Windows, Mac, and Linux) → Update Widevine CDM to version 984 (Windows, Mac, and Linux)
We finally resolved the last blocking issue for CDM 1008, so we decided to focus on pushing 1008 CDM to Nightly and Beta. Change the title back.
Depends on: 1392485
Summary: Update Widevine CDM to version 984 (Windows, Mac, and Linux) → Update Widevine CDM to version 1008 (Windows, Mac, and Linux)
Beta could be tested with CDM 1008 only bug 1392485 and bug 1383771 have been uplifted.
See Also: → 1383771
We have a new Widevine CDM version 220.127.116.118 to deploy on desktop. Please update the balrog rules for Firefox 57 (currently in Nightly) as follows: Linux 32bit URL: https://redirector.gvt1.com/edgedl/widevine-cdm/18.104.22.1688-linux-ia32.zip SHA512: 5af0f41dddf3077c2977a775a3009c435569892f7efa2110932424fda3556d6ecee76fbb1e9633e72b72e09a92b0b7fa2ac159e1741b0d4cd94e095b6e121bce FileSize: 2289324 Linux 64bit URL: https://redirector.gvt1.com/edgedl/widevine-cdm/22.214.171.1248-linux-x64.zip SHA512: 37e037a5e0c320a6a577492050d86b2bbd00239610785b0f07326e6c47b6d1899ac4f6874ad1436982a95a13c11fd73e10e9287d88da0c1036dd6eb36fe91e65 FileSize: 2207964 MacOS 10.9+ URL: https://redirector.gvt1.com/edgedl/widevine-cdm/126.96.36.1998-mac-x64.zip SHA512: 950b2e1e74dc685294540e2969050a5558e9314d17a122b38b61de35897e692da247bff820fa3df721c607b38aa3bd95f36f7d4da83fb11a67ec9b1198890be8 FileSize: 1755276 Windows 7+ 32bit URL: https://redirector.gvt1.com/edgedl/widevine-cdm/188.8.131.528-win-ia32.zip SHA512: 4630796cf6e5cc832317bf07bcda70f46432111d0bb381da9e2ebf9350cbac7790d6db1c34c7e3bced774a9b7811310cf21011fccbff779ac76d237505b5f117 FileSize: 2544372 Windows 7+ 64bit URL: https://redirector.gvt1.com/edgedl/widevine-cdm/184.108.40.2068-win-x64.zip SHA512: 2c3ebe3a5c3fa62e2fb2e41080d576c71fa060cb81ef415815652a020bb3da16de28d9a2d0d5af4f71df920abd159d6c3cf27ebdd1d65daf62cee6282f9def85 FileSize: 2537223 I've manually tested the new 1008 CDM with latest Nightly on Win7(32/64bits), Win8.1(32/64bits) and Win 10(32/64bits), MacOS, Linux(32/64bits). Hello Mihai, Could you please help on this? Since bug 1380175 was taking charge of you? Once it was pushed out to Nightly, we will test it and request pushing out to Beta then. Thanks you. Blake Wu will send notification of this update to the release-drivers mailing list.
Done! I have sent out the email.
Absolutely, just one question though. We currently serve: Widevine-220.127.116.113 to <56.0a1 users Widevine-18.104.22.1680 to users above that. Which of the following scenarios do we want next? 1) keep existing restrictions and also add Widevine-22.214.171.1248 to >= 57.0a1 so that: Widevine-126.96.36.1993 to <56.0a1 users Widevine-188.8.131.520 to <57.0a1 users Widevine-184.108.40.2068 to all above 2) Widevine-220.127.116.110 to <57.0a1 users Widevine-18.104.22.1688 to users above that I could be wrong, but my gut feeling says we'd go for option 1) since 56.0 is not yet releases and going with option 2 would mean we're serving Widevine-22.214.171.1240 (which is still riding the trains in beta currently) to previous release populations. Am I right?
Hi Mihai, Yes, currently, we wanna apply option 1. I think bug 1392485 will be uplifted to Beta soon and will be built into 56.0bX(X depends on the build date) We will request Beta updating the Balrog rule to serve 1008 CDM. So the rule will be changed like: Widevine-126.96.36.1993 to <56.0a1 users Widevine-188.8.131.520 to <56.0bX users && Widevine-184.108.40.2060 to <57.0a1 users Widevine-220.127.116.118 to >= 56.0bX and >=57.0a1 I don't know how you distinguish if user's Nightly firefox is before Bug 1392485 landed since 57.0a1 is always the same in Nightly by my observation. Is that clear to you? ni? cpearce that keep him updated. Thank you very much.
Flags: needinfo?(jacheng) → needinfo?(cpearce)
Dumping some context for later on: JamesCheng> mtabara: 57.0a1 always confuse me. If it is a fixed value ,how can you tell the version among Nightly 17:43:19 <mtabara> you can't. the version in nightly changes every 6 seeks 17:43:32 <mtabara> I guess we'd need to filter by buildid in this case 17:45:08 <JamesCheng> So if user did not update Nightly, they might use 1008 cdm without the fix,right? 17:48:38 <@catlee> yes, we can filter by buildid 17:56:30 <@catlee> JamesCheng: each build gets a buildid that increases over time 17:56:51 <@catlee> We can use that to serve updates to some nightly users but not others 17:57:23 <JamesCheng> catlee: thanks but I don't know if we can use the buildid in the Balrog rule 17:57:32 <@catlee> We can 17:58:28 <mtabara> we'll use the next nightly or so after that change from 1392485 landed 17:58:40 <JamesCheng> ok, thanks for the information. 17:59:35 <mtabara> JamesCheng: what's the ETA for this? 18:00:30 <JamesCheng> mtabara: what you mean "ETA"? 18:00:39 <mtabara> expected time of arrival 18:01:04 <mtabara> as in, when is the 1008 expected to be live? today/tomorrow or can it wait till next week 18:01:19 <JamesCheng> next week is OK 18:01:58 <JamesCheng> we need to test it in Nightly and request the rule update in Beta also 18:02:16 <@catlee> JamesCheng: I'm curious how you're testing this on Try. Are you testing with real DRM content? 18:02:24 <@catlee> or are there test endpoints for development? 18:02:42 <JamesCheng> catlee: I tested using Netflix(real DRM content) 18:03:01 <JamesCheng> catlee: I download the target.zip from treeherder 18:03:33 <JamesCheng> mtabara: The final goal should be making all 56 user use 1008 CDM. 18:04:22 <mtabara> ok
After IRC discussion, Assume that Bug 1392485 will be uplifted and will be built into 56.0bX Bug 1392485 was landed in Nightly with 57.0a1 with buildid YYY So the final rule could be like, Widevine-18.104.22.1683 to <56.0a1 users Widevine-22.214.171.1240 to <56.0bX users && Widevine-126.96.36.1990 to <57.0a1 with buildid YYY users Widevine-188.8.131.528 to >= 56.0bX and >=57.0a1 with buildid YYY Hope it's ok for you to regulate the Balrog rule?
Just noting that the changes in bug 1392485 landed in time for the beta 8 build.
The newer CDMs don't work with older Firefox. So we need to keep serving the older CDMs to older Firefox for the rest of time.
This is based on https://bugzilla.mozilla.org/attachment.cgi?id=8886353&action=edit , but with the information from comment #5.
Comment on attachment 8903279 [details] widevine-184.108.40.2068.json - fix the mac url lgtm based on diffing this against the 970 release blob and running my check script over it.
Attachment #8903279 - Flags: review?(nthomas) → review+
Current status: - added the release to balrog from the json - added 2 nightlytest rules. These look good currently. # gives us 1008 curl https://aus5.mozilla.org/update/3/GMP/57.0a1/20170830220349/WINNT_x86_64-msvc-x64/en-US/nightlytest/default/default/default/update.xml # gives us 970 curl https://aus5.mozilla.org/update/3/GMP/57.0a1/20170829220349/WINNT_x86_64-msvc-x64/en-US/nightlytest/default/default/default/update.xml - scheduled priority bumps for the existing widevine rules. I also changed rule 611 to only apply to version <57.0a1. These currently need signoff from QE and Relman. https://aus4-admin.mozilla.org/rules/scheduled_changes - Once those are signed off, we need to change the 2 nightlytest rules 646 and 647, to s,nightlytest,nightly*, Then we should re-test the above two curl commands.
I believe we are updated to 1008 on the nightly channel now. We'll still need to make rule changes for beta 9? 10? when we want to roll out there.
Hi Aki, I've tested and it works well on all platforms. If I tested the new CDM manually on Beta(maybe 56.0b8), I will request the Balrog rule updating. Should I use this bug for updating request or I need to create a new bug? Thanks.
Either works for me.
Hi Aki, I bumped into a problem, http://searchfox.org/mozilla-central/rev/999385a5e8c2d360cc37286882508075fc2078bd/browser/app/profile/channel-prefs.js#5 The channel-prefs.js in my install folder records "pref("app.update.channel", "nightly");". But when I use ./mach run, the channel-prefs.js records "pref("app.update.channel", "default")". And the widevinecdm didn't appear in update.xml with "default" channel . For "nightly" channel, widevinecdm appears . Is it related to the Balrog rules on "default" channel which may need to align "nightly" channel? Thanks.  https://aus5.mozilla.org/update/3/GMP/57.0a1/20170904100131/Linux_x86_64-gcc3/en-US/default/Linux%204.8.0-53-generic%20(GTK%203.18.9%2Clibpulse%208.0.0)/default/default/update.xml  https://aus5.mozilla.org/update/3/GMP/57.0a1/20170904100131/Linux_x86_64-gcc3/en-US/nightly/Linux%204.8.0-53-generic%20(GTK%203.18.9%2Clibpulse%208.0.0)/default/default/update.xml
ni Aki as comment 20 described.
You're able to build with the channel changed, via mozconfig... I believe setting MOZ_UPDATE_CHANNEL in env works. widevinecdm 1008 is only set to download if the update channel is nightly* ... this is to avoid adding it to beta/esr/release. Does that work? Or do we need to make changes?
I will try it when I'm in office. But why it did work before this bug landed? I don't need to set anything in mozconfig, then I can get the CDM with my local build firefox.
The rule is only set to update <57.0a1 on all channels; nightly is set to update to 970 up to a certain buildid, and then 1008 after that buildid. Do we require a default widevinecdm? Should we pin it to 970 or 1008?
To put it another way - normally the GMP rules don't have any channel set, so local builds get GMP information too. While we're in the process of deploying there are channel specific rules, which block the information being available to channels which aren't yet included. Eventually we'll get back to rules without channels set. But would a local build have the .sig files that the CDM needs ?
(In reply to Nick Thomas [:nthomas] from comment #25) > To put it another way - normally the GMP rules don't have any channel set, > so local builds get GMP information too. While we're in the process of > deploying there are channel specific rules, which block the information > being available to channels which aren't yet included. Eventually we'll get > back to rules without channels set. But would a local build have the .sig > files that the CDM needs ? No, local build didn't have .sig files. But we still can debug non-VMP part of logic through local build. Originally, when I run a local build firefox, the downloader can get the widevine CDM from AUS server. But now it cannot. I don't really know the detail of your rule, just curious why it worked before.
(In reply to Aki Sasaki [:aki] from comment #24) > The rule is only set to update <57.0a1 on all channels; nightly is set to Does "default" include in all channels? If so, there is no information in the update.xml, so GMP downloader do not have chance to download the CDM. Ideally, the rule of local build(central code base) should keep up with official Nightly. We should be able to download the CDM for local debugging. > update to 970 up to a certain buildid, and then 1008 after that buildid. > Do we require a default widevinecdm? Should we pin it to 970 or 1008?
Hi Aki, We've tested Beta on all supported platforms. We would like to request the Beta Balrog rule update according to my comment 10. The 1008 CDM is available from 56.08b So the rule could be ======================================== Bug 1392485 was landed in Nightly with 57.0a1 with buildid YYY Widevine-220.127.116.113 to <56.0a1 users Widevine-18.104.22.1680 to <56.0b8 users && Widevine-22.214.171.1240 to <57.0a1 with buildid YYY users Widevine-126.96.36.1998 to >= 56.0b8 and >=57.0a1 with buildid YYY ======================================== Thank you so much.
Ok. I think my scheduled changes will work. - Rule 357 catches everyone < 56.0a1 (release and esr and older betas/nightlies) and and is the 188.8.131.523 watershed. https://aus4-admin.mozilla.org/rules/357 - Rule 611 currently catches everyone < 57.0a1 (betas and older nightlies) and is the main 184.108.40.2060 watershed. https://aus4-admin.mozilla.org/rules/611 There is a scheduled change to rule 611, to set it to <56.0b8, so 56.0b8 and 56.0b9 users will fall through to the next rules. - Rule 646 catches everyone on nightly* channel, <58.0a1, <20170830220349. It is the nightly 57 220.127.116.110 watershed. https://aus4-admin.mozilla.org/rules/646 We don't have to change this one, I don't think. - Rule 647 currently updates non-watershed nightly* users to 18.104.22.1688. There is a scheduled change to set it to all channels, so anyone not caught by a watershed will update to 1008. https://aus4-admin.mozilla.org/rules/647 These changes need signoff; I'd also love logic review here from both the dev+releng teams. These are scheduled for 8am PDT Tuesday morning should they get signoff; if we're sure about these changes, we can change the time.
We're sure about these changes, Thank you. BTW, I couldn't open the link you provided. I want to see if "all channels" contained "default" channel for my local build.
(In reply to James Cheng[:JamesCheng] from comment #30) > We're sure about these changes, Thank you. > > BTW, I couldn't open the link you provided. > > I want to see if "all channels" contained "default" channel for my local > build. I don't see your ldap within Balrog permissions. Also, to access that URL you need to be behind VPN.
(In reply to Aki Sasaki [:aki] from comment #29) > - Rule 647 currently updates non-watershed nightly* users to 22.214.171.1248. > There is a scheduled change to set it to all channels, so anyone not caught > by a watershed will update to 1008. > https://aus4-admin.mozilla.org/rules/647 We can't see this rule, and I think it's a good thing for James and I to not have balrog privileges, so can you clarify what you mean by this please? When you say "all channels", do you mean everything not covered by the other rules? So that would include locally built 57 builds, and Firefox 56 and later, so including Beta 56 and Nightly 57 users? Thanks!
As comment 27 said, by testing, the "default" channel didn't be included. Could you please check is there any change that make default channel behave abnormally? Thanks.
"All channels" includes the default channel. The changes in comment #29 haven't been signed off, so they're not live yet.
Sounds like Aki, James, and jlorenzo are in agreement about the rules as they stand now in balrog, so I will sign off for relman that we would like to make this change and start rolling out the widevine update.
The rule changes are live.
I test the local build today. I can retrieve the CDM which has been listed in updates.xml  Thank you.  https://aus5.mozilla.org/update/3/GMP/57.0a1/20170905120923/Linux_x86_64-gcc3/en-US/default/Linux%204.8.0-53-generic%20(GTK%203.18.9%2Clibpulse%208.0.0)/default/default/update.xml
I think we're done here :) Please reopen or file new if I'm wrong.
Assignee: nobody → aki
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.