FairPlay/CENC cbcs mode compliance

We want to protect media content in fmp4 format for HLS. The content are encoded in H.264 and H.265. Apple devices need to be supported. So FairPlay/CENC cbcs mode are key DRM methods. Following questions have emeged once we started the development work:


1. For H.264 sample encryption, Apple's FairPlay spec says to leave the first 32 bytes of VCL NALU clear (1 byte for VCL NALU type + following 31 bytes). Then pattern (1:9) encryption starts. But in CENC spec (ISO-23001-7:2016), it requires to leave 1 byte for VCL NALU type + slice header to be clear. Then patern (1:9) encryption starts. Which spec should we follow to encrypt h.264 samples in fmp4 format? We think what Apple's FairPlay spec describes is a better method. But we will comply with the standard regardless;


2. In Section 9.5.2.2 of ISO-23001-7:2016, it is mentioned that:

"

Encrypted slice headers were not prohibited in the first edition of this part of ISO/IEC 23001 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.

"

Our video codec type is "avc1". Does that mean we are allowed to enctypt the slice headers of video also?


3. Where can we find the guidlines fot H.265 encryption by FairPlay/CENC cbcs mode?


Thanks!

Replies

I think the Apple's FairPlay spec is for MPEP2TS only? All the fmp4 format is using the CENC spec, same for H.265, as H265 can't be used in MPEG2TS with FPS.

Thanks for pointing this out. I was trying to implement ISO/IEC 23001-7 as well, and parsing the slice header to figure out where the slice data begins was going to be a big pain, as far as I can tell. I'm guessing Apple decided the same thing and just chose to allow 31 bytes for the header, which I'm assuming is more than enough to be safe.


This approach still complies with the ISO spec, because you can specify the length of clear bytes in the sample auxiliary info. That is, you could choose to leave 100 bytes clear if you wanted to, and the decrypter should still know what to do if you update the `senc` accordingly.

What I see with the latest (Version 16.0 17614.1.25.9.10) Safari while using so-called Modern EME is that it only supports '1 byte for VCL NALU type + slice header' scheme. Anything other than that silently fails and 'senc' box is completely ignored