CENC v1 vs CENC v3 and encrypted video slice headers

[jpiesing]

In https://github.com/w3c/encrypted-media/issues/563:, there is a discussion about incompatibility between CENC v1 and CENC v3, particularly concerning the following;

"For NAL structured video, in CENCv1 video slice headers can be encrypted. And in CENCv3 and later, they must remain unencrypted:

Common Encryption specifies subsample encryption for NAL structured video that only encrypts video data, and leaves other NAL types, all NAL size and type headers, and video slice headers unencrypted.

What does the content for the DASH-DRM reference app have? Are the video slide headers encrypted or unencrypted?

If they're encrypted then we need some test content with them unencrypted. If they're unencrypted, we should consider if it's useful to have 1 piece of test content with them encrypted. If they're a mixture, perhaps we leave them as-is.

[Murmur]

We use GPAC for drm packaging and it defaults to encryptSliceHeader=no (CENCv3). encryptSliceHeader=yes: enables old behavior for cenc scheme for AVC in avc1 mode, for which slice headers (and other nal such as SEI) can be encrypted.

I made a small test with "yes" param but am not sure how properly verify the results, tests do get the different results such as

• SEI box payload is encrypted with "yes" and clear text visible with "no" param.
• ffmpeg Error applying bitstream filters to a packet: Invalid data found when processing inputPacket messages with "yes" and no error message with "no" param, this happens on every slice packet.

I would say all refapp content is CENCv3: only slice data is encrypted and headers are unencrypted.

copy /B i.mp4 + 1.m4s 1.mp4
ffmpeg -i 1.mp4 -c:v copy -an -bsf:v h264_mp4toannexb -y 1.h264
ffmpeg -i 1.mp4 -c copy -bsf:v trace_headers -f null -
ffmpeg -i 1.h264 -c copy -bsf:v trace_headers -f null -
h264_parse 1.h264

This issue applies on "legacy" AVC1(h264) encoding where CENCv1(old) may still be avail in an older content as noted here. https://github.com/shaka-project/shaka-packager/issues/40

H265 and H264(avc3 format):
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.

H264 (avc1 format):
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.

[bobcampbell-resillion]

Based on the note above from @Murmur the IITF discussed this and agreed that this could be closed with no action required at this time.