- ContentPrtotection Descriptor -
When generating content keys using CPIX, the main input parameters are contentId, encryptionScheme and intendedTrackType.
It is proposed to enable a DASH client to request a license based on these parameters, under the assumption that they provide enough information for the license server to fetch a set of keys. This method allows the client to request keys BEFORE their keyId is published in the manifest, and it is another way of requesting a license, living side by side with a KeyId/PSSH based license request.
To serve that, it is proposed to add the contentId and intendedTrackType at the adaption set level, as part of the generic contentProtection descriptor.
As authorization of content is usually at the level of contentId and track types (e.g SD/HD/UHD), this information in the manifest could be used by license server to communicate to the client to which tracks it is authorized, and as such to guide he client not to try to play segments from non-authorized adaptation sets.
Based on such authorization information, the client would also be able to avoid requesting licenses to unauthorized adaptation sets, and spare excessive load from the client, network and backend servers.
- PSSH version 2 structure -
Same signaling may also be included in the PSSH box structure. PSSH v1 includes the list of keyIds signlaed in the DRM specific data, and it is now proposed to include also contentId, encryptionScheme and intendedTrackType.
Note that encryptionScheme is also to be added, where in the contentProtection descriptor it already exists (value attribute).
Including this information in the PSSH box, possibly with some standardization for contentId structure, will provide a standard way of communicating this information to the license server as part of license request, outside of the license challenge.
When generating content keys using CPIX, the main input parameters are contentId, encryptionScheme and intendedTrackType.
It is proposed to enable a DASH client to request a license based on these parameters, under the assumption that they provide enough information for the license server to fetch a set of keys. This method allows the client to request keys BEFORE their keyId is published in the manifest, and it is another way of requesting a license, living side by side with a KeyId/PSSH based license request.
To serve that, it is proposed to add the contentId and intendedTrackType at the adaption set level, as part of the generic contentProtection descriptor.
As authorization of content is usually at the level of contentId and track types (e.g SD/HD/UHD), this information in the manifest could be used by license server to communicate to the client to which tracks it is authorized, and as such to guide he client not to try to play segments from non-authorized adaptation sets.
Based on such authorization information, the client would also be able to avoid requesting licenses to unauthorized adaptation sets, and spare excessive load from the client, network and backend servers.
Same signaling may also be included in the PSSH box structure. PSSH v1 includes the list of keyIds signlaed in the DRM specific data, and it is now proposed to include also contentId, encryptionScheme and intendedTrackType.
Note that encryptionScheme is also to be added, where in the contentProtection descriptor it already exists (value attribute).
Including this information in the PSSH box, possibly with some standardization for contentId structure, will provide a standard way of communicating this information to the license server as part of license request, outside of the license challenge.