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.

[michaelarnauts]

@samnazarko related to this: Inputstream.adaptive itself is installed outside the Kodi addon folder on osmc, making it impossible to update Inputstream through a zip file from Kodi, only by replacing the files manually. Also on an update of the osmc-media-center package, replaced files are overridden.

This is something I'm currently having issues with, since an add-on I'm developing requires an updated inputstream.adaptive that isn't released yet. To support osmc, users have to manually change the files instead of updating with a zip trough Kodi itself.

[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.

[dagwieers]

@michaelarnauts OSMC is build on Debian and inputstream.adaptive is managed as a Debian package: https://github.com/peak3d/inputstream.adaptive/tree/master/debian

[samnazarko]

@michaelarnauts The InputStream Adaptive add-on is a binary add-on. Binary add-ons are compiled and distributed by OSMC directly as they are not particularly portable -- they are coupled to architecture and Kodi 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?