1486482 - [meta] Update Widevine CDM to Version 4.10.1146.0 (Windows, Linux, Mac)

Status: RESOLVED FIXED

(Core :: Audio/Video: Playback, enhancement, P2)

Description

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

We should update Widevine to 4.10.x to keep up to date and maintain compatibility with sites that use the Widevine content decryption module (CDM). This includes updating our GMP code in central to handle the new interface for this CDM, and updating Balrog rules to serve the new CDM.

Compared to the current versions of the CDM we're supporting[0] we will need to accommodate a number of differences (non-exhaustive):
- The interface to the CDM has changed significantly, with new functions being added, as well as a number of data structures. Many of the data structures used with CDMs before 4.10.x are now deprecated.
- The versioning scheme has change from 1.x.y.z style to x.y.z.0 style. Code that does version handling will need to be updated.
- Zeroing ctors for POD structures have been removed from the new header so we need to modify our usage to ensure data is initialized explicitly where required.

I expect us to follow our current pattern of supporting the new CDM and the version before it. This is going to require some work, given the number of interface changes made.

[0]: https://searchfox.org/mozilla-central/rev/e126996d9b0a3d7653de205898517f4f5b632e7f/dom/media/gmp/widevine-adapter/content_decryption_module.h

Comment 1

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Elaborating on comment #0, particularly to clarify my "changed significantly" statement regarding the interfaces involved, which was not a great choice of words without specifics. The CDM has some new features, one of which (hardware secure codecs) we are not going to implement as part of this update. Aside from this, we do need to handle some updated structs and IPDL, but my original comment may have oversold this. Details follow.

The CDM + Firefox interface has the follow new features:
- The ability for the CDM to accept a new encryption scheme.
- The ability to signal to the CDM it should use hardware secure codecs.

To support new encryption schemes the structs used to init the CDM now have a member to explicitly specify the encryption used. The input buffers to the CDM have a member to explicitly specify the encryption on the sample being fed, as well as a pattern member to specify the pattern if using encryption schemes that support patterns -- cbcs, though more could be added in future. The new structures also have padding added to ensure alignments.

Aside from these changes, the new data structures are the same as the old. So while the pre-CDM10 data structs are now deprecated, the changes from CDM9 to CDM10 structures here are not radical.

Right now we're not supporting hardware secure codecs, and will not as part of this update, so the only changes being made to accommodate this are passing an additional bool to the CDM's init which we can hardcode as false.

Changes are being made to our IPDL to support the new encryption scheme part of the CDM, as well as remove the old CDM8 functionality we no longer use. Many of these changes have already landed in bug 1487811: CDM8 only functions are removed, we now pass a enum to indicate encryption scheme used, rather than a bool.

Further changes to the IPDL will be made to support CDM10's callback to indicate it has initialized (bug 1491889), as well as to pass an encryption pattern (bug 1487416 or follow up to that bug).

The interface we expose to the web will only change once we've implemented new encryption schemes, at which point we'll surface the new encryption scheme via MediaKeySystemAccess[0].

[0]: https://searchfox.org/mozilla-central/rev/0b8ed772d24605d7cb44c1af6d59e4ca023bd5f5/dom/media/eme/MediaKeySystemAccess.cpp#270

Comment 2

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

After more investigation I think we should target version 4.10.1146.0 of the CDM. I had communicated the possibility of other version during some discussions, but this is the version currently being indicated by the Widevine cmd version file as suitable[0].

[0]: https://dl.google.com/widevine-cdm/versions.txt

Comment 3

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Tracked for 64 based on Bryce's email to r-d. JCristau, FYI

Comment 4

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

We're currently testing the new CDM across nightly. We've got some more incremental work to do before closing this bug, but barring any issues we expect to be serving the new version of the CDM from now on.

Comment 5

[Julien Cristau [:jcristau] (back April 22)]

We seem to have a spike in mozilla::gmp::GMPChild::ProcessingError crashes with the new CDM, with MOZ_CRASH(aborting because of MsgProcessingError)

https://crash-stats.mozilla.com/signature/?version=64.0a1&signature=mozilla%3A%3Agmp%3A%3AGMPChild%3A%3AProcessingError

Comment 6

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

This looks like users on older nightly releases not having all the code pieces to handle the new CDM. Requesting revision to the rules used to avoid this.

Comment 7

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

Current status: The CDM update has been rolled out to Nightly builds that were built in October. Bug 1496501 was discovered in testing and is now resolved. We're waiting on Widevine to provide a fix for bug 1495751. Note that crash rates are low for that bug, and we can ship the fixed CDM to beta.

Shipping support for the cbcs encryption scheme support is unlikely in the 64 release. I am currently working on this, but we need to rework a non trivial amount of our mp4 parsing to do so. This does not block the CDM update and can be added in a later release, such as 65. As such, removing cbcs parsing bug from deps list.

Given the above, I think we're looking good to go with this to continue to ride the trains.

Comment 8

[Bryce Seager van Dyk [:bryce] (he/him) - Not reading bugmail]

We've pushed another update to fix bug 1495751, which resulted from this. I believe that concludes the work related to this update. Resolving.