Attempt to load Widevine CDM interface 10 before falling back to CDM interface 9

RESOLVED FIXED in Firefox -esr60

Status

()

defect
P2
normal
RESOLVED FIXED
7 months ago
4 months ago

People

(Reporter: bryce, Assigned: bryce)

Tracking

unspecified
mozilla64
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr6065+ fixed, firefox64 fixed)

Details

Attachments

(2 attachments)

(Assignee)

Description

7 months ago
The groundwork to have Firefox able to instantiate Widevine CDMs with interface verison 10 has been landed across several bugs:
- bug 1486502
- bug 1487811
- bug 1491117
- bug 1491889

As part of our update to Widevine CDM version 4.10.1146.0 (where the second number is the interface version: 10), we should have Firefox attempt to load CDMs with the newer interface, and fall back to version 9 of the interface if this does not succeed.

This is the strategy previously used during updates, and means that we do not need to roll out central changes at the same time as updating balrog rules. Users will have compatibility with the current CDM (interface 9) until we deploy 10, at which point that will also work.

One area to keep an eye on as we do this is the new CDM's expectation of explicit flagging of samples as encrypted or unencrypted. Previously the CDM would determine this by examining clear and encrypted ranges passed to it -- 0 encrypted ranges would be interpreted as clear. Now, however samples must be explicitly marked with an enum, and a sample marked as encrypted with 0 encrypted ranges will be refused by the CDM. The WebM case for this was handled in bug 1491117. However, I plan to  implement further checks and logging to detect and fix up such samples that would be rejected by the CDM. This will allow us to track if any demuxers are still emitting data that could be problematic while we bake the new interface.
(Assignee)

Comment 2

7 months ago
With the addition of an explicit encryption enum for CDM10 input data, if a
sample has 0 encrypted bytes it must be marked as unencrypted. Historically we
could let the CDM figure out based on the unencrypted + encrypted bytes.
However, if we mark a sample as encrypted but it has 0 encrypted bytes, the CDM
will fail to decrypt.

This changeset adds a check to gracefully handle samples that are marked as
encrypted but with no encrypted ranges. In such cases we mark the data as
unencrypted and log that such data was encountered. This means we don't break
playback of encrypted media should we overlook such cases, but have better
detection via logging.
Comment on attachment 9012025 [details]
Bug 1494178 - Add check to ChromiumCDMChild to mark samples with 0 encrypted bytes as unencrypted. r=cpearce

Chris Pearce (:cpearce) has approved the revision.
Attachment #9012025 - Flags: review+
Comment on attachment 9012026 [details]
Bug 1494178 - Attempt to instantiate CDM10 before CDM9. r=cpearce

Chris Pearce (:cpearce) has approved the revision.
Attachment #9012026 - Flags: review+

Comment 8

7 months ago
Pushed by bvandyk@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/e6f8e822851a
Add check to ChromiumCDMChild to mark samples with 0 encrypted bytes as unencrypted. r=cpearce
https://hg.mozilla.org/integration/autoland/rev/14e7673d10f7
Attempt to instantiate CDM10 before CDM9. r=cpearce

Comment 9

7 months ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/e6f8e822851a
https://hg.mozilla.org/mozilla-central/rev/14e7673d10f7
Status: NEW → RESOLVED
Last Resolved: 7 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
(Assignee)

Updated

4 months ago
Blocks: 1518525
(Assignee)

Comment 10

4 months ago

Comment on attachment 9012025 [details]
Bug 1494178 - Add check to ChromiumCDMChild to mark samples with 0 encrypted bytes as unencrypted. r=cpearce

[ESR Uplift Approval Request]

If this is not a sec:{high,crit} bug, please state case for ESR consideration: Please see Bug 1518525 for details and motivation.

Further notes: this is the fourth bug in a series tracked by bug 1518525. Could we please uplift all patches on this bug? Please see https://treeherder.mozilla.org/#/jobs?repo=try&revision=b9976fb4de94bf0933f1faa8118154961fac20fb&selectedJob=220243631 for a try push where these patches have been grafted onto esr60.

User impact if declined: Failure to playback premium media.

Fix Landed on Version: 64

Risk to taking this patch: Low

Why is the change risky/not risky? (and alternatives if risky): The code here landed and baked since 64. I have verified that the code works when grafted onto esr60.

String or UUID changes made by this patch: None.

Attachment #9012025 - Flags: approval-mozilla-esr60?

Comment on attachment 9012025 [details]
Bug 1494178 - Add check to ChromiumCDMChild to mark samples with 0 encrypted bytes as unencrypted. r=cpearce

Needed for ESR60 to continue to support Widevine video playback in the very near future. Approved for 60.5.0esr.

Attachment #9012025 - Flags: approval-mozilla-esr60? → approval-mozilla-esr60+
You need to log in before you can comment on or make changes to this bug.