Output Protection

[haudiobe]

The 5th edition of DASH adds Output Protection. Was this ever discussed to be added to the CPS guidelines. It would be important to understand why this was added in MPEG as a must, but now it is not added to the CPS text. Alex Giladi again was instructive on this one.

[ZmGorynych]

OutputProtection and ContentProtection@robustness are needed for multi-key encryption. The section below is from a draft of SCTE 214-1:202X and can be adopted (and adapted) to the CPS text.

Multi-key encryption

There may be cases in which there is a need to encrypt content of the same type in the same MPD with different keys. This requirement often arises when the content protection requirements such as hardware vs software implementation ("robustness") and output protection differ across different video resolutions.

In this case, subsets of representations sharing the same key will be combined into adaptation sets. For example, a 4K video ladder, may be broken into three adaptation sets, SD (up to 540p resolution), HD (720p and 1080p resolution) and UHD (above 1080p resolutions). These adaptation sets are aligned and are seamlessly switchable.

1. All representations in an AdaptationSet shall share the same key;
2. Adaptation sets containing parts differently encrypted parts of perceptually identical content shall be aligned and switchable per definition of adaptation set switching in ISO/IEC 23009-1.
3. If the use of different keys is due to robustness or/and output protection, then these should be explicitly stated: a. If a particular level of DRM robustness (e.g. hardware decryption and decoding) is required, this needs to be specified in the ContentProtection@robustness attribute. The value of the attribute is DRM-specific and is typically described in the DRM documentation. b. If a particular HDCP level is required for playback of a specific adaptation set, then the OutputProtection descriptor shall be used

NOTE: use of robustness and output protection signaling is declarative and is needed to prevent download of segments which are expected to be undecodable by the client. The source of truth is the DRM, and not MPD signaling.

[nicoweilelemental]

From a CPIX standpoint, we don't need anything new as regards ContentProtection@robustness, as this is covered by the DRMSystem.ContentProtectionData element.

As regards the OutputProtection element, I would suggest to add a DRMSystem.OutputProtectionData element and specify that it needs to be added as a child element to the Representation onto which a given DRMSystem is applied.

[lpiron]

Regarding ContentProtection@robustness, please have a look at https://github.com/Dash-Industry-Forum/CPIX/issues/31 where we concluded that the ContentProtection tag was not part of the data under the DRMSystem.ContentProtectionData element. This would then not be possible to have the @robustness part of the data.

[lpiron]

A new section has been added (section 7.4)

[nicoweilelemental]

If we add a new DRMSystem.OutputProtectionData element, we need to make sure it can carry the information needed for HLS manifest signaling (EXT-X-STREAM-INF@HDCP-LEVEL and @ALLOWED-CPC) https://datatracker.ietf.org/doc/html/draft-pantos-hls-rfc8216bis-10#section-4.4.6.2

[ZmGorynych]

It looks like ALLOWED-CPC is conceptually equivalent to @.***

On Wed, Jul 6, 2022 at 10:51 AM Nicolas Weil @.***> wrote:

If we add a new DRMSystem.OutputProtectionData element, we need to make sure it can carry the information needed for HLS manifest signaling @.*** and @ALLOWED-CPC)

https://datatracker.ietf.org/doc/html/draft-pantos-hls-rfc8216bis-10#section-4.4.6.2

— Reply to this email directly, view it on GitHub https://github.com/Dash-Industry-Forum/IOPv5/issues/18#issuecomment-1176452203, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGEYZKD5P5Q4SZMNLLSUHDVSW2S7ANCNFSM5E7HTB7A . You are receiving this because you commented.Message ID: @.***>

[nicoweilelemental]

Summarizing where it seems (?) we are on this topic:

• we add a DRMSystem.OutputProtection element (0...1, xs:base64binary) where we will carry the whole DASH OutputProtection tag
• we add a DRMSystem.HdcpLevel element (O, xs:string) where we will carry the HLS EXT-X-STREAM-INF@HDCP-LEVEL value, which is a technically an enum (TYPE-0, TYPE-1, NONE) but we don't know how the HLS spec will evolve, so we make it a string
• we add a DRMSystem.ContentProtectionRobustness element (O, xs:string) where we will carry the DASH ContentProtection@robustness value
• we add a DRMSystem.ContentProtectionAllowedCpc element (O, xs:string) where we will carry the HLS EXT-X-STREAM-INF@ALLOWED-CPC value

[melads]

Hi, joining late to this discussion, so apologies if I'm missing some context. Trying to share my thoughts from DRM system architecture point of view.

No doubt the output protection and content Protection robustness signaling need to find their way to the manifests, and as such need to have their way to be signaled in CPIX. However, I am wondering as to the flow of this information - which component in the system is the SOURCE for this information? I am thinking this information should come from the ingest side (content provider/content management system) and not from the DRM system. As such, I am also not expecting the DRM system to be mandatory in the ingest process, get this information and serve it to the encryptor/Manifest creator.

In the opposite direction - I don't expect the DRM system to get this information from the encryptor when a license request needs to be served. I assume, again, the source of the information would be the entity that manages content, authorizes the license request and knows which rules and restrictions need to be applied for each content. This interface is usually not carried in a CPIX format.

Comments/clarifications/thoughts would be appreciated. Moshi

[nicoweilelemental]

The encryptor/manifest creator needs the information to generate the proper manifest signaling, so the DRM system has got to provide the information in the CPIX response. How the DRM system gets the information in the first place, through the CPIX request coming from the encryptor, or out of band from a CMS, is a different question. I suggest we should keep both options open.

[melads]

I wouldn't say that the DRM system has got to provide this information to the encryptor/manifest creator. I would say that if the DRM system has got this information it MAY provide it to the encryptor/manifest creator, but would leave the door open to the encryptor/manifest creator to get this info from another source (out of band).

This by itself should not impact the interface definition, but should be clarified in the accompanying text.

[lpiron]

Call December 6 2023 The OutputProtection should be at the ContentKey level as it is not dependent on the DRM system