Kodi Community Forum
peak3d development roadmap - Printable Version

+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Development (https://forum.kodi.tv/forumdisplay.php?fid=32)
+--- Forum: Kodi Application (https://forum.kodi.tv/forumdisplay.php?fid=93)
+--- Thread: peak3d development roadmap (/showthread.php?tid=303609)

Pages: 1 2 3 4 5 6 7

RE: peak3d development roadmap - matthuisman - 2017-08-24

addon_path = xbmc.translatePath(addon.getAddonInfo('path')).decode("utf-8")
(this is the inpustream add-on path - not the user addon path)

So priority is

1) inpustream/libssd_wv
2) inpustream/lib/libssd_wv
3) /usr/lib/libssd_wv
4) internet

And that will run everytime the installed version of inpustream changes.

RE: peak3d development roadmap - Milhouse - 2017-08-24

(2017-08-24, 04:40)matthuisman Wrote: And that will run everytime the installed version of inpustream changes.

Thanks for the clarification.

Sorry to be pedantic but I know chuff all about addons. Smile

Do you mean:

A) that the helper add-on runs only whenever the version of inputstream.adaptive changes (ie. the helper add-on is called via the Kodi add-on update mechanism, when the inputstream.adaptive addon is updated)?
or
B) the helper addon runs *whenever* inputstream.adaptive is run (but the helper addon only updates the files when the inputstream.adaptive version changes)?

If (A), then that might be an issue with an OS built-in addon as I doubt the helper addon will know when the inputstream.adaptive addon has changed - Kodi will simply shutdown with version 2.0.1 of the addon, the OS is updated, and the next time Kodi starts the inputstream.adaptive version will now be 2.0.2 (or whatever).

If (B), that sounds fine. Smile

(And yes, this is an issue probably unique to my test builds, but having add-ons built-in makes testing so much easier, particularly when trying to identify regressions etc. etc.)

RE: peak3d development roadmap - matthuisman - 2017-08-24

The helper add-on is used by any add-on that needs to playback DRM content (as a dependency of that add-on.)

In the "user addon", it calls

wvhelper.check()
before it tries to play any DRM content.

that check function runs and makes sure everything is OK and returns a True or False.

the check is very fast (cheap) if everything is already setup (checks two files exists and checks a setting in a file matches the inpustream addon version).

So, my suggestion would be that KODI has an official DRM Helper addon.

Any addons that have DRM protected content, have this helper add-on as a dependency.
Before these add-ons try to play something, they call the check_drm() function.

inpustream doesn't actually need this helper for non DRM things (eg. HLS).
Just for widevine videos etc.

So, add-on creators who want to play widevine videos simply add the helper library as a dependency and call a wvhelper.check() method before playing any protected content.
Easy Smile
They don't need to worry about anything except if that function raises an error or returns False

RE: peak3d development roadmap - Milhouse - 2017-08-24

Excellent, sounds perfect. Thanks for taking the time to explain it! Smile

RE: peak3d development roadmap - matthuisman - 2017-08-24

no worries.

The helper add-on is not a binary add-on just a simple python library so it would be platform independent.
It also requires no changes to inpustream at all.

It simply makes add-on developers job easier for implementing DRM playback Smile

FYI, here is my current implementation
wvhelper module (script.module.wvhelper)
https://pastebin.com/5w71kzM7
(it's a mess as it's been constantly "hacked" together as things have changed - quite often with inputstream at present)

and a snippet of the video addon that calls it (plug.video.tvnz.ondemand):
https://pastebin.com/z2C1Kdyk

A complete new helper would be written from scratch for official repo.
It would also allow parameters of the DRM that is required (Widevine, + others?).

eg. drmhelper.require('widevine') or drmhelper.require('otherdrm')

However, there is no point starting this if it would still break KODIs GPL

RE: peak3d development roadmap - peak3d - 2017-08-24

libssd_wv is part of inputstream.adaptive and is meant to be located beside inputstream.adaptive so/dll.
It is compiled / installed during the build / install step of inputstream.adaptive.

The old libssd_wv in cdm folder (from earlier installations without libssd_wv included) should be removed.

There should be really no need anymore (except maybe older kodi 17 versions) to do any manual copy operations on libssd_wv.

RE: peak3d development roadmap - matthuisman - 2017-08-24

@peak3d

Is this true for PPA supplied inpustream in Ubuntu etc?
What about non-official builds for other devices (i386 etc)?

Missed questions:
Also, any progress on getting inpustream to work in Windows Store version?
I think something to do with the sandbox stopped it working.
Oh, and is HLS support only in 18? Or is it in 17.4?

RE: peak3d development roadmap - Milhouse - 2017-08-24

(2017-08-24, 08:27)peak3d Wrote: libssd_wv is part of inputstream.adaptive and is meant to be located beside inputstream.adaptive so/dll.
It is compiled / installed during the build / install step of inputstream.adaptive.

The old libssd_wv in cdm folder (from earlier installations without libssd_wv included) should be removed.

There should be really no need anymore (except maybe older kodi 17 versions) to do any manual copy operations on libssd_wv.

Unfortunately that isn't working.

I have the following:

Code:
rpi22:~ # ls -la /usr/lib/kodi/addons/inputstream.adaptive
total 1304
drwxr-xr-x    2 root     root          4096 Aug 24 08:23 .
drwxrwxr-x   17 root     root           339 Aug 24 06:04 ..
lrwxrwxrwx    1 root     root            28 Aug 24 08:18 inputstream.adaptive.so -> inputstream.adaptive.so.18.0
lrwxrwxrwx    1 root     root            30 Aug 24 08:18 inputstream.adaptive.so.18.0 -> inputstream.adaptive.so.2.0.12
-rw-r--r--    1 root     root        748216 Aug 24 08:18 inputstream.adaptive.so.2.0.12
-rwxr-xr-x    1 root     root        573192 Aug 24 08:18 libssd_wv.so

If I remove /storage/.kodi/cdm/libssd_wv.so, then I'm not able to view any Netflix or Amazon videos:

Code:
09:22:24.043 T:1820324752   DEBUG: codec is: ec-3
09:22:24.073 T:1494324112   DEBUG: AddOnLog: InputStream Adaptive: Download http://localhost:58667/manifest?id=80114990 finished
09:22:24.073 T:1494324112    INFO: AddOnLog: InputStream Adaptive: Successfully parsed .mpd file. #Streams: 21 Download speed: 1758606.3183 Bytes/s
09:22:24.073 T:1494324112   ERROR: AddOnLog: InputStream Adaptive: Unable to handle decryption. Unsupported!
09:22:24.073 T:1494324112   DEBUG: AddOnLog: InputStream Adaptive: Session::~Session()
09:22:24.074 T:1494324112   ERROR: CVideoPlayer::OpenInputStream - error opening [http://localhost:58667/manifest?id=80114990]
09:22:24.074 T:1494324112  NOTICE: CVideoPlayer::OnExit()

Full debug log: http://sprunge.us/EUTi

However, if I create /storage/.kodi/cdm/libssd_wv.so as sym link to /usr/lib/kodi/addons/inputstream.adaptive/libssd_wv.so (or /usr/lib/libssd_wv.so - can't recall now why I have it twice!), or as a complete copy (rather than sym link), then the same videos will play successfully.

So Kodi (latest master) isn't "finding" /usr/lib/kodi/addons/inputstream.adaptive/libssd_wv.so even though it is located alongside the addon shared library, but Kodi will find libssd_wv.so in the cdm directory. Am I right in suggesting that Kodi not finding libssd_wv.so alongside the addon library may be some sort of long standing issue/bug?

RE: peak3d development roadmap - JinJin - 2017-08-24

Just tested it with kodi 17.4 for windows and its at least working there without ssd_wv.dll in cdm folder.

RE: peak3d development roadmap - peak3d - 2017-08-24

(2017-08-24, 09:59)matthuisman Wrote: Is this true for PPA supplied inpustream in Ubuntu etc?
What about non-official builds for other devices (i386 etc)?

Should be included in all distos / os versions.
libssd_wv is part of the main CMakeLists file, if someone knocks it out, its not my issue.

(2017-08-24, 09:59)matthuisman Wrote: Missed questions:
Also, any progress on getting inpustream to work in Windows Store version?
I think something to do with the sandbox stopped it working.
Oh, and is HLS support only in 18? Or is it in 17.4?

- Not aware about windows store issues, sry,
- Most HLS things are backported to 17.4, last 3 days development will follow.

RE: peak3d development roadmap - peak3d - 2017-08-24

I made some corrections regarding the search paths to reflect situation we have in LE.
Should work for the other OS as well.

RE: peak3d development roadmap - Milhouse - 2017-08-24

Yep, works fine now, many thanks. No need for libssd_wv.so to be in the cdm directory (and the latest version of inputstream.adaptive no longer looks for it in there).

RE: peak3d development roadmap - matthuisman - 2017-08-24

Great!

So I only need to check for libssd_wv if KODI version is before 17.4?
KODI 17.4 and higher has at least inpustream version 2.0.10 which ALWAYS includes the libssd_wv and doesn't need it in CDM folder?

I guess the good news is that I don't need to host any 2.X libssd_wv files.
If inpustream 2.X always includes libssd_wv, then there is no need.
So, just need to host the 1.X libssd_wv.

I'll have another play with Windows Store version and see if I can find out what's going on Smile

RE: peak3d development roadmap - Milhouse - 2017-08-24

(2017-08-24, 23:20)matthuisman Wrote: So I only need to check for libssd_wv if KODI version is before 17.4?
KODI 17.4 and higher has at least inpustream version 2.0.10 which ALWAYS includes the libssd_wv and doesn't need it in CDM folder?

The fix is in the inputstream.addon and no change needed to Kodi, so in theory the fix could made available in Kodi 17.4. In that case it might be safer to check the version of inputstream.adaptive and if the version is >= 2.0.13 then there's no need to worry about libssd_wv.so.

RE: peak3d development roadmap - matthuisman - 2017-08-25

Hmmm.
My Windows 17.4 has 2.0.10 and it doesn't require the file in the CDM directory.