[question] Impact of "Chromium CDM" and Widevine deprecation

[f1multiviewer]

Given the move from Google to deprecate the Widevine CDM for Chrome and Chromium browsers, I was wondering if this will also impact Electron, and how Electron ECS/Castlabs EVS will be impacted by it. What do developers have to do (if any) to ensure their services can continue to run?

https://bitmovin.com/google-deprecating-widevine-drm-cdm/
https://www.xda-developers.com/google-is-deprecating-widevine-for-chromium/

[khwaaj]

As stated in the articles only old versions of the CDM will be revoked, and well before that time a new CDM version will be available. As long as automatic updates have not been disabled (i.e. the Component Updater for all currently supported versions of ECS) a user is unlikely to even notice this happening.

There are a couple of theoretical edge cases:

• If an instance is left open for an extended period of time, a restart may be needed for the update to take effect
• If an instance is opened/closed only in quick succession there may not be time to perform the update

[f1multiviewer]

Oh, if that's the case, I misunderstood! So they are only deprecating the older Widevine CDM, and the only reason why it's newsworthy is because browsers ship with the CDM and Electron downloads it at the first launch? If so, I think this is answered and can be closed, thanks! 🙏

edit: I know why I was confused, I read this one first: https://chromeunboxed.com/chrome-107-arrives-with-full-hvec-support-and-widevine-deprecation/ and that one seems to suggest something completely different (but wrong?):

With Chrome 107, Google has begun the deprecation of Widevine to prepare the way for a new CDM that launched in Chrome Canary back in September. The new CDM will ship to other Chromium-based browsers over the coming weeks in preparation for Widevine being blocked entirely.

[khwaaj]

It is mostly correct too, although the last sentence is certainly misleading. The new CDM launched in Canary some time back and will progressively be promoted until it reaches all Chrome installations sometime mid-November, including forks. The misleading part is "Widevine being blocked entirely", which should actually only apply the the old CDMs. The new CDM, version 4.10.2557.0 IIRC, will not be revoked.

I'd leave this open at least until December, just in case someone else has the same question. You're not the first to ask so there is clearly some confusion around the reporting on this topic.

[f1multiviewer]

Thanks! Is there any way to get the current CDM version and know when it's updated? I think there were events on app but I no longer see them in the type definitions, are they still available?

[khwaaj]

Since ECS moved to using the Component Updater there are no longer any events the same way they existed in the prior implementation. You can however use the components API, specifically the status() function, to retrieve the version of the loaded CDM (or CDMs). The example code in the README has a very simple example of this that just logs the result to the console.

[f1multiviewer]

Alright, that's nice :) Does it only check for updates when the application first boots? (e.g. when it calls whenReady?) Or can updates happen at any time?

[khwaaj]

The whenReady() call will force an immediate installation if no CDM can be found/registered, otherwise it will rely on the Component Updater checking for and installing updates in the background (same as Chrome).

[charlesstrube]

Hello,
Do we have to manually update the Widevine CDM in our electron app? This page suggests that we should use the chrome library and put it in.

[khwaaj]

No, if you are using ECS the update is automatic (unless you explicitly disable it).

The linked instructions do not apply to ECS, only stock Electron, and since VMP was introduced are they are not really viable for macOS/Windows either. There is also the fact that bundling the CDM might require you to become a MPEG-LA licensee because of the integrated decoders (as opposed to dynamically installing it from Google servers, like ECS does).

[demchuk-alex]

Hey, @khwaaj thanks a lot for sheding some light :), however, I'm still a bit confused say we have old ECS version 6 with its CDM v4 do we need to update ECS to be able to update to the latest CDM or once old CDM is revoked, next ECS launch will update it automatically? Thanks in advance

[khwaaj]

Well, version 6 is certainly not a supported version anymore, that is for sure! 😁

That said, Google still publishes the CDMs to Lorry (this one should land sometime around mid-November), which is the old delivery method used in the wvvmp releases, so the CDM will be installed (unless you disable it) and is likely to work as well. The earliest officially supported version of Chromium for this CDM is 95 though, which would mean ECS 16, so I can't promise there won't be issues.

[charlesstrube]

To be sure, in order to get the latest version of Widevine, should we upgrade to ECS version 16?

[khwaaj]

You will get the new CDM even with an older ECS version, but I'd still recommend upgrading to a currently supported version, which would mean ECS 19 or later. ECS 16 is just the first version to pass the official minimum Chromium version requirement for the new CDM (95), it is no longer maintained/updated.

[demchuk-alex]

@khwaaj I was able to update to version electron 21.2.3+wvcus however the after first launch there is no CDM folder, it used to be in win ~\AppData\Roaming .... and now it's empty is it expected or it should be other place?

[khwaaj]

If you updated from an older version, i.e. from a wvvmp version to a wvcus version, there are breaking changes to the API. Instead of waiting for widevine-ready you need to use the new components API, as described in the README. Not sure if you have already updated your app to support this, but not using the components API to wait for Widevine to become ready would give the problem you are seeing.

[shmulka]

Google's, Chrome updates information service Is now returning the new CDM version 4.10.2557.0. Hopefully this will be reflected soon in ECS. I am currently running ECS 19.0.15 with auto updates enabled but CDM still updates only up to version 4.10.2449.0.

[khwaaj]

That particular file means that Lorry has been updated, e.g. the delivery mechanism used by the older wvvmp releases. This typically happens after CUS has been updated, but apparently not in this case as I'm still seeing 4.10.2449.0 being delivered too (unless I use the test-request channel). It could be that they are doing a staggered rollout to avoid taxing the CUS servers too hard.

[shmulka]

@khwaaj I can see Widevine CDM has now upgraded to 4.10.2557.0 and working as expected.
If I delete the CDM folder to retest the upgrade, why is version 4.10.2391.0 installed first and only then followed by the 4.10.2557.0 update?

[khwaaj]

Why is version 4.10.2391.0 installed first and only then followed by the 4.10.2557.0 update?

I'm not sure, but I'm seeing the same behavior. This is not something that ECS does, so it is some CUS server-side decision to first deliver the older version. This should change before the older CDMs are revoked, but I'll be sure to ask when I get the chance..

[shmulka]

@khwaaj - to address a use case of users launching the app with the old CDM version after it has been deprecated. I assume an app relaunch will be required after the new CDM has finished downloading?

[khwaaj]

Short answer: Yes.

Longer answer: It's complicated. It really comes down to of the CDM utility process has launched or not, if not then a restart would technically not be required. This in turn depends on what features has been used in the opened browser window(s), and down the rabbit hole we go. All in all, I'd assume a restart is required 🙂

[shmulka]

In regard to restarting after version 4.10.2557.0 has completed downloading.
In the delivery mechanism used by the older wvvmp release we could use the 'widevine-update-pending' event as a cue on when to restart. As the new mechanism does not fire an event when the CDM has completed downloading, it seems we need to write our own custom check to watch for any CDM folder changes?
This would especially be required for use cases where:
App is launched with a deprecated CDM.
App is already running while CDM is deprecated.

[khwaaj]

Why is version 4.10.2391.0 installed first and only then followed by the 4.10.2557.0 update?

I'm not sure, but I'm seeing the same behavior. This is not something that ECS does, so it is some CUS server-side decision to first deliver the older version. This should change before the older CDMs are revoked, but I'll be sure to ask when I get the chance.

I confirmed with the Widevine team that this is a temporary situation, and the rule that is behind it will be removed "soon".

[khwaaj]

In the delivery mechanism used by the older wvvmp release we could use the 'widevine-update-pending' event as a cue on when to restart. As the new mechanism does not fire an event when the CDM has completed downloading, it seems we need to write our own custom check to watch for any CDM folder changes?

@shmulka, if you think you'll need this, then yes - you'll have to monitor for updates manually since this type of API is not provided after the update to wvcus. Instead of monitoring the file system, you could also monitor using the components.status() API, which will provide the necessary information. IIRC the status field will even say updated if an update has been applied.

Typically the edge cases you speak of should be rare since there is often a grace period between a new CDM release and removal of the old one, even Chrome doesn't handle them, but they are certainly possible under some circumstances. In this case the grace period is relatively short as well, which increases chances of this happening somewhat.

[shmulka]

@khwaaj, monitoring the components.status() is a good idea, but it seems there is a another issue now.
While approx a minute after startup , the status does change from status=new, version=4.10.2391.0 to status=updated , version=4.10.2557.0, no actual update occurs. The only folder visible is of version 4.10.2391.0 while status continues to return status=updated , version=4.10.2557.0.

[khwaaj]

@shmulka, indeed, I see the same thing (tested several different ECS versions). There has to be something wrong with the service at the moment, as it appears to update but the updates are never applied regardless of what I do. I'll escalate.

[khwaaj]

@shmulka, it should be back to working now, but also still serving 4.10.2391.0 initially (and then updating). There was some kind of issue with the configuration change, so it was rolled back and will be revisited.