Rework to DRM config, new properties, introducing DRM auto-selection, XML wrapper support

[CastagnaIT]

Description

This PR is currently WIP not buildable, for now opened PR for feedback and/or clarifications

UPDATE:
I WILL DO SEPARATE PR'S TO ACHIEVE THIS CHANGE, SINCE SOURCE CODE CHANGES ARE TOO BIG, PARTS OF SPECS ON THIS PR ARE OUTDATED

New properties

There are two new properties, and both require JSON values (dumped as string), i have chosen JSON because is easy to implement into python addons, a bit less on binary addon, but JSON string can also be manually constructed with not too much problems.
i have prefer add two separated props to avoid to do too nested JSON dictionaries, that otherwise make more complex add JSON values to playlist files like STRM:

inputstream.adaptive.drm
This property is to set general DRM parameters, based on CDM Key System

JSON structure:

{
    "com.widevine.alpha": {
        "persistent_storage": bool,
        "force_secure_decoder": bool,
        "streams_pssh_data": str,
        "pre_init_data": str,
        "priority": int
    },
    "com.microsoft.playready": {
        ...
    }
}

inputstream.adaptive.drm_license
This property is to set license DRM parameters, based on CDM Key System

JSON structure:

{
    "com.widevine.alpha": {
        "wrapper": str,
        "wrapper_params": dict,
        "server_certificate": str,
        "server_url": str,
        "req_headers": str,
        "req_params": str,
        "req_data": str
    },
    "com.microsoft.playready": {
        ...
    },
    "none": {
        ... // special case that can be used to set parameters for encrypted streams like HLS AES-128
    }
}

The JSON parameters to be set in the new configuration are not much different from the old properties,
and you can guess, i will add some more info later

Deprecated properties

The two new properties, will deprecate these old ones,
and they will be removed on future Kodi (major) versions
more likely in the Kodi 22 RC (theorically first quarter of 2025):

inputstream.adaptive.license_type
inputstream.adaptive.license_key
inputstream.adaptive.license_data
inputstream.adaptive.license_flags
inputstream.adaptive.server_certificate
inputstream.adaptive.pre_init_data

Auto-selection of CDM

The idea is to make CDM selection automatic without that an addon have to specify which one should be used.
This can be possible since we know that supported CDM on the operative system, and we know also what DRM's are supported on a manifest

XML license wrapper support

License wrapper term i mean the things that are set in to inputstream.adaptive.license_key [Response-Data] field, where we currently support base64 and JSON, wrappers

Since here the code that manage the license wrapper has been reworked (for widevine), add the XML wrapper support its a very small change, so is included here

Breaking changes

This huge change is thought to be backward compatible with the existing (deprecated) properties.

For now the only breaking change is on inputstream.adaptive.license_key [Response-Data] field, where the HB type has been removed. This because we have no info about this addition, i have not found info on web, nor addon that use it, therefore if in future someone will complain about this removal, we can obtain more info about it to reimplement it.

Motivation and context

Main reasons:

• with multiple DRM support we have to provide a way to set configuration parameters for each DRM, the use case is when a manifest support more DRMs and the target system that play the stream support all them or one of them
• video addons may support more DRM, that can depends also on the OS used, so we can automatize the CDM selection based on what the system supports and what the manifest supports, without that a video addon have to find a way to manually handle this
• more times is happened that video addon devs are confused by our complex properties because are not easy to understand, unfurnately we cannot simplify too much things, but at least we can remove the pipe | uses in the inputstream.adaptive.license_key that is the most complex property and make more clear parameters to be set
• group all DRM configuration with less properties that can be in future expanded without add or change existing properties

How has this been tested?

WIP

Screenshots (if appropriate):

Types of change

• Bug fix (non-breaking change which fixes an issue)
• Clean up (non-breaking change which removes non-working, unmaintained functionality)
• Improvement (non-breaking change which improves existing functionality)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that will cause existing functionality to change)
• Cosmetic change (non-breaking change that doesn't touch code)
• None of the above (please explain below)

Checklist:

• I have read the Contributing document
• My code follows the Code Guidelines of this project
• My change requires a change to the Wiki documentation
• I have updated the documentation accordingly

[dtngfan85]

Can you at least find a way to make them backwards compatible without removing these parameters that are in heavy use? Requiring json formatted data is likely going to cause problems for m3u playlists where they use KODIPROP fields, providers will need to create seperate playlists for Nexus, Omega or whatever future release this potentially lands in as not all their users will be migrating to the next version at the same time, and would make it impossible for end users who want to help bug test a future development release if their m3u playlist source hasn't yet adapted to the new parameters.

Also, the license_key parameter is also used to pass along headers for AES protected HLS streams if the AES key server requires cookies or a specific user-agent that is different than the headers for the manifest or ts segments.

[ghost]

I get these errors when trying to build on arch aarc64 after modifying the PKGBUILD file to pull from your repo. I installed rapidjson.

https://pastebin.com/HXzLfrSL

[CastagnaIT]

@stuckinthe written in the description WIP not buildable at current stage the code was written without building

Can you at least find a way to make them backwards compatible without removing these parameters that are in heavy use?
Requiring json formatted data is likely going to cause problems for m3u playlists where they use KODIPROP fields, providers will need to create seperate playlists for Nexus, Omega or whatever future release

Also, the license_key parameter is also used to pass along headers for AES protected HLS streams if the AES key server requires cookies or a specific user-agent that is different than the headers for the manifest or ts segments.

this is already taken into account,
as written in to PR description above, this is backward compatible, even for HLS case.

to set the parameters for HLS case, you will need to set the keysystem (from JSON example above) instead of com.widevine.alpha with none value, in this way you can set parameters for HLS encrypted

the final intention is to remove deprecated properties on future Kodi releases,
so yes before or after you need to do a migration and will be mandatory, old ways properties will not be kept
otherwise we keep carrying around old implementations and new developments would be meaningless

the intention is merge this with Kodi 21, so that devs/users can start know of this change
to take in account that Kodi 21 should have the final release on first quarter of 2024

therefore action to removing the deprecated properties will take place only on Kodi 22
that more likely will have the final release not before of the first quarter of 2025

so for now we are talking about of about year and a half (first quarter of 2025) of time to give devs/users to migrate things,

so you are saying that in the 2025 is not enough time?...

we can also try to think to give more time, so on Kodi 23,
this will fall in theory of first quarter of 2026,
but imo this is unrealistic for development purpose

[CastagnaIT]

closed because superseeded by #1724