inputstream.ffmpegdirect

[jairoxyz]

Will support for inputstream.ffmpegdirect be added at some point?

Thanks! Great tool!

Jx-

[dagwieers]

This relates to #177.

The main problem here is that if inputstream.ffmpegdirect is used for e.g. MPEG DASH, it will fail to work with DRM streams. So there is no granular way to configure this where needed, except maybe from the add-on itself.

@jairoxyz How do you see this work?

[jairoxyz]

Thanks for looking into this @dagwieers . ffmpegdirect is still evolving and maybe DRM will be added at some point but adaptive is the better option for DASH and multibitrate HLS, I believe. ffmpegdirect is really fast and smooth with TS and HLS, so an idea would be to limit it to these two types. But you are right, people can still set 'mpd' on the listitem manifest_type and try to play DRM streams. No way to control it except maybe by handling the listitem with inputstreamhelper, too. But then DRM is a known limitation with ffmpegdirect and not a problem of inputstreamhelper. Same would happen for any wrong protocol used, wouldn't it?

Cheers,

Jx-

[jairoxyz]

PS: just for the sake of testing if the helper in principle works with ffmpegdirect, I overrode

inputstreamhelper.config.INPUTSTREAM_PROTOCOLS

with

INPUTSTREAM_PROTOCOLS = {
            'mpd': 'inputstream.adaptive',
            'ism': 'inputstream.adaptive',
            'hls': 'inputstream.adaptive',
            'rtmp': 'inputstream.rtmp',
            'ts': 'inputstream.ffmpegdirect',
            'm3u': 'inputstream.ffmpegdirect'
        }

and it works like a charm:

DEBUG: [script.module.inputstreamhelper]: jsonrpc payload: {'jsonrpc': '2.0', 'id': 1, 'method': 'Addons.GetAddonDetails', 'params': {'addonid': 'inputstream.ffmpegdirect'}}
DEBUG: [script.module.inputstreamhelper]: jsonrpc response: {"id":1,"jsonrpc":"2.0","result":{"addon":{"addonid":"inputstream.ffmpegdirect","type":"kodi.inputstream"}}}
DEBUG: [script.module.inputstreamhelper]: inputstream.ffmpegdirect is installed.
DEBUG: [script.module.inputstreamhelper]: jsonrpc payload: {'jsonrpc': '2.0', 'id': 1, 'method': 'Addons.GetAddonDetails', 'params': {'addonid': 'inputstream.ffmpegdirect', 'properties': ['enabled']}}
DEBUG: [script.module.inputstreamhelper]: jsonrpc response: {"id":1,"jsonrpc":"2.0","result":{"addon":{"addonid":"inputstream.ffmpegdirect","enabled":true,"type":"kodi.inputstream"}}}
DEBUG: [script.module.inputstreamhelper]: inputstream.ffmpegdirect 1.6.0 is enabled.
DEBUG: [script.module.inputstreamhelper]: inputstream.ffmpegdirect 1.6.0 is installed and enabled.

Cheers,

Jx-

[dagwieers]

@jairoxyz We can do this already, as there is no conflict with any existing functionality. But for mpd or hls we need to think about on what level we want this to be configurable. That is why I asked you how you envision this integration.

My proposal in #177 was related to giving the user the option what the default behaviour is, but that is something that does not look very convenient if we are talking about things that are not drop-in replacements (e.g. wrt DRM).

[jairoxyz]

@dagwieers I don't know much about DRM and what happens if you try to play it with ffmpegdirect or another inputstream addon that can't handle it ( I assume it simply wont play) but regarding #177, I think this would be very handy and you could provide default settings for all protocols available so far by adding for ex "is_ts" and "is_mpeg" and default these to ffmpegdirect. This would not interfere with mpd/drm.

You can then probably make multiselects and limit:

• mpd to adaptive
• ism to adaptive
• hls to adaptive, ffmpegdirect
• rtmp to rtmp
• ts to ffmpegdirect
• mpeg to adaptive, ffmpegdirect

Plus you can check afterwards that adaptive is really selected for mpd and drm. For HLS it really makes sense to let the user choose between adaptive or ffmpegdirect as both addons will be able to play those streams but offer different advantages depending on the user environment and needs.

Thanks,

Jx-

[dagwieers]

The problem with having this selection in inputstreamhelper is that people may not realize the effect of switching from inputstream add-on. So while they may have read that using ffmpegdirect works great for add-on X, they may not realize this breaks Netflix. And only at some other point in time find Netflix is not working and complain about this.

This makes support a lot harder. That is why I think we have to avoid this and leave it up to specific add-ons which inputstream add-on is to be used, rather than leave it up to inputstreamhelper.

[dagwieers]

@phunkyfish What is your advise on this? I am not completely sure what the desired behaviour is that we want to have for users.

Also wrt. #177 which proposes to make the inputstream-mapping configurable from the settings.

Another option is a fallback mechanism that e.g. in case of DRM ffmpegdirect could call onPlayBackError() and potentially another inputstream add-on could be tried. There is an open feature request to have this in inputstream.adaptive as well so that specific Widevine DRM issues can be handled by inputstreamhelper retroactively (rather than proactively on every playback).

In this case inputstreamhelper would become a service acting on specific playback errors, rather than a library call assisting in playback. But that's just a theory at the moment...

[phunkyfish]

The next feature coming in ffmpegdirect will be timeshift which may mean more users want to use it even though does support not adaptive bitrates (but obviously they will still need it for any DRM).

I’m trying think of a quick and easy way to know if a stream must use one or another but other than caching the preference I think it would need something like PlaybackError() at least once. Just not sure how that gets implemented though. I assume the inputstream API would need to change.

[phunkyfish]

The issue with TS files is you have to play the file to know it is one. Other formats you have the benefit of inspecting the M3U/XML.