Simplifying representation of multi-key encrypted video tracks #400
Labels
discussion needed
Issue needs general input from IOP members to move forward
move to cps tf
Issue should be addressed by the content protection and security taskforce
In order to present premium video content across a wide ecosystem devices it is becoming increasingly necessary to utilize an extensive set of encryption keys to maintain robust security of content distribution.
To illustrate this let me use a practical example of encryption key assignment for an encode that tops out at UltraHD + HDR:
Due to the varying security environments that different resolutions of video will be distributable in and contractual requirements dictating explicit key separations, you end up with needing 8 keys to represents 2 encoding ladders.
When representing this in DASH, we currently have the following constraint (IOP v4.3 7.7.1 ISO BMFF Content Protection Constraints):
This means a multi-key encrypted video asset like the example above would require 8 Adaptation Sets where the 4 for SDR and 4 for HDR are signalled to be cross-adaptable (integer values equal for
AdaptationSet@segmentAlignment
orAdaptationSet@subsegmentAlignment
). Here is a partial illustration of this phenomenon with the SDR Adaptation Sets, HDR and audio omitted for size:Even using
SegmentBase
this is a verbose manifest, if someone were to useSegmentTimeline
the repeating of the timeline would exponentiate the size here. While the DASH AMD1 mechanism for compressing ContentProtection usage can be utilized, it does not address the Adaptation Set structure verbosity. During playout the expectation would be for the player to consider the Adaptation Sets as a fully adaptable range and we would prefer to optimize the key acquisition flow to fetch all keys immediately and dynamically remove from adaptation consideration Representations that the CDM cannot support protection of.After researching options for awhile, we could not find a solid reason for this restriction to continue existing as multi-key support across CDMs is fairly widespread and the fraction of devices that cannot will properly fallback to challenges based on the ISOBMFF signalled KID for the segments. Therefore we would like to propose the following changes to the DASH-IF guidelines, but we think similar restriction reductions may be needed in the DASH CMAF Profile as well:
default_KID
, when this is true:ContentProtection
element for schemeurn:mpeg:dash:mp4protection:2011
with@value="cenc"
and@cenc:default_KID
set to the Representationdefault_KID
ContentProtection
elements at the Adaptation Set level should provide multi-key signalsContentProtection
element for schemeurn:mpeg:dash:mp4protection:2011
with@value="cenc"
should have@cenc:default_KID
set to a list of alldefault_KID
in the Adaptation Set separated by a space, per ISO/IEC 23001-7:2016ContentProtection
elements should includecenc:pssh
elements containing system specific data that signals multiple KIDshttps://dashif.org/identifiers/content_protection/least_restrictive_key
where@value
is the least restrictive KIDWe believe these changes will allow for players to optimize their start-up flows, while having in-manifest signalling of encryption key KIDs in order to properly communicate with the system CDM and blacklist representations the CDM has determined it cannot provide protection for.
Utilizing this proposal the above example would be simplified to the following:
The text was updated successfully, but these errors were encountered: