Support vendor distributed Widevine

[samnazarko]

Hi,

I reached out to @dagwieers initially via email as this isn't an issue per se.

It would be good to start a discussion about how to handle vendor distributed versions of Widevine. We (OSMC) would like to distribute our own version of Widevine. We have satisfied the legal requirements to distribute these libraries directly for some supported platforms.

Understandably, this add-on is brought in as a dependency by a number of add-ons that utilise Widevine. I'd suggested a symlink (such as /usr/lib/libwidevine-cdm.so -> /usr/lib/libwidevine-vendor.so to signal recognition), but @dagwieers has mentioned quite correctly that this wouldn't be suitable for Windows.

In short, it would be good to adapt this add-on so it can detect a vendor provided version of Widevine and devolve updates to the distribution.

Cheers

Sam

[dagwieers]

I have had some time to think about this, and there are multiple paths we could take this:

1. Support custom Widevine sources Code structure #94
   • so that inputstreamhelper would still be downloading and managing the library just like today
   • but different methods/sources could be added, selectable by the end-user
2. Support detection of a special vendor library, e.g. libwidevinecdm-vendor.so
   • when detected, copy this library instead and disable downloading or updating this library
3. Disable inputstreamhelper when a certain condition is met
   • this then would be clearly communicated to the user as a fait accompli

My preference would be (1) so that a lot of the logic is shared. We already support 2 sources of Widevine (based on platform/architecture). And the upside is that if this vendor library is updated, the user still has means to backup and rollback earlier versions. A lot of the issues remain with a vendor library (i.e. playback/performance regressions may exist with a vendor library as well).

My main concern with (2) or (3) is the possibility of conflict between more than one version (think about a platform enforcing one thing, and another add-on enforcing something else). When inputstreamhelper is no longer involved (and just acting on things) we may not offer sufficient control to the end-user, and having them jump through hoops to get a working system.

We already decided we wanted to restructure the code to split off the Android, ARM and non-ARM cases. If we do this in a modular way, any vendor could add a new "source" with different check/download/identify code and inputstreamhelper could still allow the end-user to choose between methods that fit a certain platform/architecture (if there is more than one).

This would make it possible to also include a source for: http://k.mjh.nz/.decryptmodules/widevine/
knowing it won't ship with the Kodi repository for legal reasons.

If OSMC (or any vendor really) would like to offer a different default source, they could ship with an upstream version of ISH, with a modified settings.xml defaulting to their source out-of-the-box, and ISH updates would not harm that default selection (and the user can still opt to use a different source).

Mind you that inputstreamhelper is now the main way of managing Widevine, but in the future may also include other DRM schemes, or inputstream protocols.

[mediaminister]

In my opinion, in an ideal world, InputStreamHelper add-on doesn't exist.

If a vendor decides to support Widevine out of the box, we should respect this and let the vendor manage Widevine.

I think it's best we treat this case like Android which has a built-in Widevine version.

[samnazarko]

@dagwieers Thanks for writing some initial thoughts.

I've had a look at the Inputstream Helper interface to refresh my memory of how everything fits together.

1. Sounds like a good option, however it should be noted that our Widevine libraries wouldn't be fetched from a direct URI but rather delivered via a Debian package. OSMC updates are handled by APT. So perhaps a blend of 1 & 2 is a good idea -- where the user can specify a source for Widevine, but 'Use Vendor' (which appears at the presence of libwidevinecdm-vendor.so) is default.

I can appreciate the possibility of regressions and remember seeing this issue with even software decoding a few weeks ago. I'm not sure whether we'd be allowed to offer rollback support for our version of libwidevine as it could allow users to re-install vulnerable versions and be seen as a defeat mechanism.

Cheers

[dagwieers]

@samnazarko The rollback mechanism (as it is implemented now) is limited to backups made on the local system. So a version that is no longer offered (and was never downloaded before) would not be available.

The main reason for the rollback mechanism is that we have been bitten by this once recently, and we took a few actions to improve the reliability of ISH since.

A combination of 1 and 2 is certainly possible.

[dagwieers]

Ok, so 3 weeks have passed. There hasn't been a lot of enthusiasm for my proposal, so I guess it is better to implement (2) now. We can still combine this with a more comprehensive solution in the future if need be.

So I think we can continue with the proposal of @samnazarko:

• When a file named libwidevinecdm-vendor.so is detected and it is different from libwidevinecdm.so we copy it into place
• And in this case we disable most of the functionality of inputstreamhelper

This also means we somehow have to detect this from the settings to influence/disable the add-on settings, as we do for Android.

It would be nice to have a solution ship with the upcoming v0.5.0.

[samnazarko]

Sounds good. Will it be possible to drop our Widevine in to the Kodi system path, or does it need to live under the user's .cdm directory? Ideally we can add it to the former, which means that working Widevine isn't dependent on the user's Kodi directory not being changed or restored from another system.

[dagwieers]

I would put it in a single location, the DECRYPTERPATH from inputstream.adaptive (on LibreELEC this would be /storage/.kodi/cdm). Not sure if there is a use-case to put it elsewhere?

[dagwieers]

I have a first implementation ready. This should handle a vendor-supplied Widevine as discussed.

What is missing from this implementation is disabling most of the settings when a vendor-supplied Widevine exists.

[mediaminister]

I don't think this ready yet for an urgent v0.4.4 release.

[dagwieers]

@mediaminister I don't think so either, it needs to be tested and there is still a TODO list attached to the PR.

[michaelarnauts]

@samnazarko Do you have a status update for this? I'd this something that's still being worked on? I suppose this is mainly legal stuff with Google?

[samnazarko]

Our solution works without changes to InputStream; but we haven't approached the packaging side of things yet (i.e. how to tell Kodi that our Widevine should be used instead).

[samnazarko]

I've sent you a message in the Team Kodi Slack advising of our progress.

When I try and play content via Netflix, I'm told that our Widevine version is out of date. Our version is based on Widevine version 4.10.1503.4, which is the latest browser CDM version (Q3 2020) and it is reported correctly in InputStream Helper.

Despite disabling InputStream Helper's auto-updating feature in the settings menu, it tries to download the Chromebook image (testing on armhf userland).

[mediaminister]

When I try and play content via Netflix, I'm told that our Widevine version is out of date.

Despite disabling InputStream Helper's auto-updating feature in the settings menu, it tries to download the Chromebook image

If you provide a debug log, I can investigate and fix these bugs.

[dagwieers]

After a discussion on the Add-ons internal Slack channel with all stakeholders we eventually concluded to use the original design again 😄

I summarized it on the Wiki at: https://github.com/emilsvennesson/script.module.inputstreamhelper/wiki/Vendor-supplied-Widevine-CDM

[TheGarageRocks]

While I understand the reasoning behind this whole thought process it does indeed present me with a problem.

I have an android 5.1 box, vendor supplied widevinecdm. Widevinecdm is way too old and vendor upgrades stopped at least 5 years ago. Problem is ISH detects this really old widevine and there is no option to install a newer non vendor supplied version. The option "Install widebine from:url........whatever.bin.zip" does nothing. Is this the expected behavior? If so how may I upgrade widevine?

[mediaminister]

Widevine is not available as a library CDM on Android. Google doesn't provide a compatible binary that InputStreamHelper can download and install. On Android Widevine is supported via the Android MediaDrm API.
I guess you need to upgrade the Android version of your box to watch Widevine protected content.