Support vendor widevine library

[dagwieers]

This adds support for a vendor-supported Widevine library.

TODO:

• Show actual version, not stored version
• Update stored version
• Get timestamp from library to show in info pane
• Do not show Chrome OS information when using vendor library
• Disable settings/operations

This fixes #229

[dagwieers]

The information pane will look like this:

Kodi information

• Kodi version: 18.5
• Kodi platform/architecture: Linux/arm

InputStream information

• InputStream Helper version: 0.4.3
• InputStream Adaptive version: 2.4.0

Widevine information

• Widevine version: 4.10.1440.18 (supplied by vendor)

Please report issues to:

• https://github.com/emilsvennesson/script.module.inputstreamhelper/issues

[dagwieers]

We need to test this functionality on Windows and macOS, mostly to test the behavior using hardlinking and exception handling.

[dagwieers]

@horstle Hardlinking here is not just useful to save disk space, but it makes testing if two files are the same file a lot more efficient than the worst case scenario: comparing complete content. Especially if this has to happen on every playback...

[horstle]

I don't have any problem with (hard)links. I just prefer avoiding/minimising differences in behaviour on different platforms, but let's not start that discussion again.

[dagwieers]

@horstle Oh, I didn't want to start a polemic, I just found a better reason to use them (when they are supported)

[dagwieers]

@samnazarko Would it be useful to show the library timestamp as well in the information pane (i.e. ctime or mtime) so the user has an indication when the library was made/added?

[samnazarko]

I don’t think it’s necessary to show any significant versioning details for vendor based Widevine libs. I’ll send our current version to your email shortly so you can have a look On 23 Dec 2019, at 11:03, Dag Wieers <[email protected]> wrote:  @samnazarko<https://github.com/samnazarko> Would it be useful to show the library timestamp as well in the information pane (i.e. ctime or mtime) so the user has an indication when the library was made/added? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#240?email_source=notifications&email_token=AAHDWLDCWL27KVY3LGOJPQDQ2CLJXA5CNFSM4J6OCP3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHQ4GNQ#issuecomment-568443702>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAHDWLA5TYBN6PZOLVHJWE3Q2CLJXANCNFSM4J6OCP3A>.

[dagwieers]

@samnazarko Without versioning information, how would users relate issues to versions/updates. Especially in the light of regressions (as have been reported in the past).

[samnazarko]

From a distribution perspective, we would expect a user to say it worked in the January version of OSMC but broke / regressed in February. Our release notes would show a version bump. Our lib is stable and is somewhat pegged to CDM updates. I know there have been regressions with SW decoding but don’t anticipate this for HW decoding - it either works or it doesn’t. On 24 Dec 2019, at 19:41, Dag Wieers <[email protected]> wrote:  @samnazarko<https://github.com/samnazarko> Without versioning information, how would users relate issues to versions/updates. Especially in the light of regressions (as have been reported in the past). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#240?email_source=notifications&email_token=AAHDWLEJFSN7XGHHBAMBLLDQ2JQWNA5CNFSM4J6OCP3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHTSCVY#issuecomment-568795479>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAHDWLCCABTTTAKNYZOYLNTQ2JQWNANCNFSM4J6OCP3A>.

[samnazarko]

I've emailed through our current Widevine package.

[dagwieers]

I had to rework this PR for a big code restructure and prefered to start from scratch while keeping the original branch. So there is now a new PR #311 with the necessary changes for vendor widevine support.

Most of the non-vendor related changes in this PR were recently merged as part of #310

And we can close this one.