[Kodi 22] InputStream Adaptive - breaking change feature

[CastagnaIT]

on your addon you are using the custom X-Limit-Video header on license response to apply the HDCP resolution limit

plugin.video.youtube/resources/lib/youtube_plugin/kodion/network/http_server.py

Lines 773 to 774 in 94cd361

	self.send_header('X-Limit-Video',
	'max={0}px'.format(size_limit))

from the next ISA version of Kodi v22 (at the time im writing not released yet)
to enable this feature you have to set check_hdcp parameter to LICENSE
it will no longer be enabled by default since its a provider customization

wiki: https://github.com/xbmc/inputstream.adaptive/wiki/Integration#inputstreamadaptiveconfig-
ref. PR: xbmc/inputstream.adaptive#2037

example
listitem.setProperty('inputstream.adaptive.config', '{"check_hdcp": "license"}')

[MoojMidge]

Thanks for the heads-up.

Pretty sure the ability of this addon to play DRM protected content is broken. Haven't had the motivation to look into in too much detail, but YouTube utilise a custom license request/authorisation mechanism that needs to be reverse engineered, so the particular section of code you identified won't really do anything anyway.

Regardless, the question arises as to what is the purpose of gating this functionality behind the inputstream.adaptive.config property and check_hdcp entry of the associated JSON property value?

An addon relying on this functionality won't know whether it is required until the license request is made and the response received, at which point it is too late to add the listitem property.

It means that the addon would always need to add this property regardless of whether it was actually required, just in case it was needed so that the custom header would be used.

Given that the response headers would be parsed anyway it seems like there is no real need to have the new property when using the custom header, because InputStream.Adaptive would already be able to determine if the header was present. This would avoid the breaking change.

Makes more sense to use the property when actually parsing custom DRM config JSON payloads, but not so much for the custom header.

Just idle discussion - feel free to ignore if it makes things easier or control flow simpler in the InputStream.Adaptive side of things, by processing all such related DRM config parameters in the same manner.

[CastagnaIT]

I didn't know it was broken i rarely use YouTube on Kodi

Regardless, the question arises as to what is the purpose of gating this functionality behind the inputstream.adaptive.config property and check_hdcp entry of the associated JSON property value?

Yeah i had thought about that, but i couldn't find a good solution because of streams management complications

just to keep these two features working (JSON HDCP path / X-Limit-Video header)
until "now" ISA is forced to initialize all streams with DRM by creating a potentially large number of DRM sessions that won't be used for playback
which isn't really a big deal to do

so gate them with the inputstream.adaptive.config property allow ISA to know in advance
if must initialize all DRM streams or if can initialize only the stream that is actually open/used for playback
so disabling the behavior (to init all streams) by default is, atm, the best option
so as not to limit the effectiveness of the next DRM improvements, since these cant be applied along with "check_hdcp" feature