DASH 5.8.4.1 ContentProtection descriptor usage in conflict with CENC usage

[sandersaares]

DASH says:

When multiple ContentProtection elements are present with different SystemID values, each element shall describe a key management and protection scheme that is sufficient to access and present the Representation.

This seems to say that a single ContentProtection should be enough to access content. However, this contradicts common practice where you actually have two:

1. The "mp4protection" one from DASH says "this is encrypted with scheme ABC"
2. A DRM system specific one says "use DRM system XYX"

Both are relevant in practice.

Am I reading this statement in DASH correctly? Does it also seem to conflict with real world usage to others? Perhaps we can propose a change to DASH if so.

[haudiobe]

(IOP 2019/09/10) fix it in DASH-IF to connect mp4 with a requirement for a second ContentProtection element. Possibly check in MPEG, add to DUI

[sandersaares]

1. On the issue of signaling the content protection when the common encryption is used, we believe that the descriptor carrying DRM information may also include encryption information and therefore the inclusion of a separate descriptor is unnecessary. We would suggest DASH-IF to investigate such an approach.

I believe this above comment from MPEG addresses this issue.

I propose next steps as:

1. No action in terms of changes to DASH-IF guidelines - we keep requiring the standard practice of mp4protection descriptor to signal Common Encryption scheme and optionally allow separate descriptors for DRM signaling.
2. Request MPEG to adjust DASH so that a combination of "mp4protection + DRM-system-specific" descriptors is permitted for DRM system activation.

Rationale: this is how it works today. And it works fine. Inertia will keep it working no matter what the standard says. It is more valuable to bring the standard in line with common implementation here, especially as it does not really sacrifice anything.