[matthuisman]

Thanks @learningit

Maybe you can weigh in on an issue.

Quite a few of mine and others add-ons are starting to depend on Widevine playback via Inpustream.

Inputstream doesn't include the Widevine DRM so it needs to be manually downloaded and installed.

A solution to this was to make a helper add-on library that downloads the correct widevine and installs it.
The add-on doesn't contain the DRM, but just downloads it and installs it (like the getwidevine.sh but for all systems)
Any add-ons that then need Widevine can simply put the helper module as a dependency and call a simple function in their code to install it if required.

What would be the chance of getting something like this into the official Repo?

[learningit]

Thanks @learningit

Maybe you can weigh in on an issue.

Quite a few of mine and others add-ons are starting to depend on Widevine playback via Inpustream.

Inputstream doesn't include the Widevine DRM so it needs to be manually downloaded and installed.

A solution to this was to make a helper add-on library that downloads the correct widevine and installs it.
The add-on doesn't contain the DRM, but just downloads it and installs it (like the getwidevine.sh but for all systems)
Any add-ons that then need Widevine can simply put the helper module as a dependency and call a simple function in their code to install it if required.

What would be the chance of getting something like this into the official Repo?

I have asked others in the team to respond to your question. I know the team is interested in Widevine support, but I recall some sort of a license issue relative to putting the library in the repo. Maybe your helper addon is a solution to that issue, I really don't know. I'll try to get you an answer on this if a team member doesn't directly respond in a day or two.

[matthuisman]

@learningit

Great

Also, is the team aware that (non-included) binary add-ons are pretty much not going to work in KODI UWP (Windows Store) version?

eg. Widevine won't work as the downloaded libwidevine.dll refuses to load.
https://social.msdn.microsoft.com/Forums...=wpdevelop

It's not even possible to manually copy the dll into the uwp program directory due to extreme windows permissions.

[learningit]

I'm going to ask a moderator to split this thread and move the widevine discussion to the development section of the forum. It's more appropriate there.

[natethomas]

I believe at the last devcon, we came to the conclusion that it would be very difficult, lincense-wise, to have Kodi download a closed binary. I do not recall what our position was on prompting the user with a yes/no asking if they'd like to download themselves using a helper addon. Spiff or Koying may have some input.

[Koying]

I don't remember exactly what came up from devcon, either.

My position is still that, as a GPL project, we can NOT use a closed-source library at all, UNLESS it is a system library.

Pragmatically, we COULD (and that is what is currently done) bend the rule to extend the notion of system library to "whatever library is on the device".

My bottom-line is: OK to use widevine as long as it's on the device one way or another, but we CANNOT, as Kodi, do anything to facilitate the download of the library, or we would be VERY hypocritical and cynical in the way we apply GPL.

Nothing prevents a 3rd party addon to do so, though.

PS: Missed the point about the 3rd party addon being in the Kodi repo.
Well, I guess the repo itself has nothing to do with GPL, so It'd be ok for me, as long as the Team has nothing to do with it, besides hosting.

[matthuisman]

The add-on would notify the user that a 3rd party closed source binary is required and the user would need to OK the download.

@glennguy version already does this I think.

It could be named something like "script.module.inputstream-helper"

In the future, if more closed source encryption support is added to inputsream, the add-on could be updated to handle those.
It could also do other checks. eg. check if HLS is supported (by checking the inpustream version is greater than 2.X)

Developers of add-ons could add the helper as a dependency.
Import the module in code and run a few simple functions

require_widevine()
supports_hls()

[natethomas]

Nothing prevents a 3rd party addon to do so, though.

PS: Missed the point about the 3rd party addon being in the Kodi repo.
Well, I guess the repo itself has nothing to do with GPL, so It'd be ok for me, as long as the Team has nothing to do with it, besides hosting.

I'm fine with this. So we just need a non-team member to be the guy providing the addon, and I guess we're good.

[Koying]

Yeah. Furthermore, an addon downloading widevine would be perfectly GPL compatible, as it wouldn't execute any closed-sourced code, just manipulating a file, so really no "legal" reason to deny it.

[emilsvennesson]

This is great news because I also have a few add-ons that require the Widevine binary.

I have started working on a service that downloads the binary and puts it in the decrypter path specified in the inputstream.adaptive settings. The source is available at https://github.com/emilsvennesson/service.widevine.

[matthuisman]

@emilsvennesson

I think a module would be a better idea than a service.
Allows for checking / installing only at a required time, and allows add-ons to check and use different behavior.
eg. if HLS is available - use that, else just pass to KODI.

I also don't see how your code works for any ARM devices (Raspberry Pi).
Also quite a few missing edge cases (eg. Android, Windows Store Version, ).

Have a look at my WV module:
https://github.com/matthuisman/kodi-repo...-0.1.1.zip
& also glennguy's module:
https://github.com/xbmc-catchuptv-au/scr....drmhelper

If you aim to only have it in KODI 18 Repo - then don't worry about the ssd_wv stuff (as it's included with kodi 18).
Also remove the add-on dependency on inpustream - check for it instead in the code.
So, you can give a nice error instead of a "dependency error".

[emilsvennesson]

@emilsvennesson

I think a module would be a better idea than a service.
Allows for checking / installing only at a required time, and allows add-ons to check and use different behavior.
eg. if HLS is available - use that, else just pass to KODI.

I also don't see how your code works for any ARM devices (Raspberry Pi).
Also quite a few missing edge cases (eg. Android, Windows Store Version, ).

Have a look at my WV module:
https://github.com/matthuisman/kodi-repo...-0.1.1.zip
& also glennguy's module:
https://github.com/xbmc-catchuptv-au/scr....drmhelper

If you aim to only have it in KODI 18 Repo - then don't worry about the ssd_wv stuff (as it's included with kodi 18).
Also remove the add-on dependency on inpustream - check for it instead in the code.
So, you can give a nice error instead of a "dependency error".

It's more a proof-of-concept right now and far from finished. I agree that a module probably is a better approach and there is definitely other edge cases that needs to be implemented. Is there any reason why you think inputstream.adaptive should not be listed as a dependency? I don't see how this is would be any different from other dependencies in addon.xml. It saves a lot of hassle because it automatically makes sure that inputstream.adaptive exists and is enabled.

Regarding ARM based devices: I have yet to find an official and reliable source for this architecture. I see that you're redistributing the binary yourself which I doubt is even legal without a redistributing license.

[matthuisman]

@emilsvennesson

Let's say a user didn't install inputstream when installing KODI in Windows.
My add-on requires the helper module.
The helper module dependency breaks on inpustream.
User get's a non helpful dependency error and my add-on fails to install.
Now the user can't use my add-on at all (some streams don't even need widevine).

Vs
User installs my add-on.
Plays normal streams fine.
Goes to play a DRM stream.
Helper module gives a nice "Inpustream addon is not found. blah blah"
Glennguy's module even can go and download the binary add-on for the user.

You could have the dependency as optional - this would be OK.
You still would need to check if the add-on is there in code though.

I think the less dependencies the better.
And a dependency on a binary add-on just seems too risky as these are often not installed via kodi repo.
Keep dependencies to actual Python packages (requests etc) that are pretty much guaranteed to work everywhere.

Also think about that this might in the future not only be for inpustream.
Other binary add-ons could come out that help playback certain content.

so, maybe name it something more generic:
script.module.playback-helper


https://github.com/xbmc-catchuptv-au/scr...mconfig.py
has some legit sources for ARM boards.
Unfortunately, needs to download entire chrome and then pull the widevine from that.

I just up'd them to my github for my own repo just to make it quicker D/L for end users.
I'll remove with first take down notice and switch to the other method.

For the kodi repo add-on, using a "legit source" would of course be needed


I think @glennguy 's module would be pretty much ready to go into the official repo if he wanted to.

[emilsvennesson]

@emilsvennesson

Let's say a user didn't install inputstream when installing KODI in Windows.
My add-on requires the helper module.
The helper module dependency breaks on inpustream.
User get's a non helpful dependency error and my add-on fails to install.
Now the user can't use my add-on at all (some streams don't even need widevine).

Vs
User installs my add-on.
Plays normal streams fine.
Goes to play a DRM stream.
Helper module gives a nice "Inpustream addon is not found. blah blah"
Glennguy's module even can go and download the binary add-on for the user.

You could have the dependency as optional - this would be OK.
You still would need to check if the add-on is there in code though.

I think the less dependencies the better.
And a dependency on a binary add-on just seems too risky as these are often not installed via kodi repo.
Keep dependencies to actual Python packages (requests etc) that are pretty much guaranteed to work everywhere.

Also think about that this might in the future not only be for inpustream.
Other binary add-ons could come out that help playback certain content.

so, maybe name it something more generic:
script.module.playback-helper


https://github.com/xbmc-catchuptv-au/scr...mconfig.py
has some legit sources for ARM boards.
Unfortunately, needs to download entire chrome and then pull the widevine from that.

I just up'd them to my github for my own repo just to make it quicker D/L for end users.
I'll remove with first take down notice and switch to the other method.

For the kodi repo add-on, using a "legit source" would of course be needed


I think @glennguy 's module would be pretty much ready to go into the official repo if he wanted to.

Unfortunately, that module is also relying on third party sites (again, which I doubt is legal) which is a big no-no.

I did my own take on this and have submitted the module to the official repository: https://github.com/xbmc/repo-scripts/pull/598.