CENC v2/3: Only video data in slice NALs SHOULD be encrypted

[kqyang]

CENC v2 and v3 suggests that only video data in slice NALs SHOULD be encrypted; other NAL types should be left in clear.

9.5.2.2 Subsample encryption applied to NAL Structured Video (Normative)

NAL Structured Video samples SHALL be exactly spanned by one or more contiguous Subsamples. The slice data in a video NAL MAY be spanned by multiple Subsamples to create multiple clear and protected ranges, or to span protected slice data that is larger than the maximum size of a single BytesOfProtectedData field, with BytesOfClearData size equal to zero in each Subsample. Multiple unprotected NALs SHOULD be spanned by a single Subsample clear range, but a large clear range MAY be spanned by multiple Subsamples with zero size BytesOfProtectedData.

• For AVC video using ‘avc1’ sample description stream format, the NAL lengthSizeMinusOne field and the nal_unit_type field (the first byte after the length) of each NAL unit SHALL be unencrypted, and only video data in slice NALs SHOULD be encrypted.

Note 1: Encrypted slice headers were not prohibited in the first edition of this standard but were prohibited by application specifications. A “SHOULD” requirement to leave slice headers unencrypted for ‘avc1’ allows possible legacy content with encrypted slice headers to remain conformant to this new edition. But, new content should not encrypt slice headers, or it may not decode properly in secure video decoders.

[kqyang]

• For other NAL Structured Video sample description stream formats (e.g. ‘avc3’, ‘hvc1’, ‘hev1’, etc.), only video slice data SHALL be protected. For avoidance of doubt: Video NAL slice, size and type headers SHALL be unencrypted and other NAL types SHALL be unencrypted.