[rogers12]

That's an interesting perspective. Some corrections are in order.

MP4 encryption, specifically Common Encryption addition to ISO BMFF has two levels of partial encryption.

- Each frame's media bytes are encrypted independently of other frames. MP4 boxes themselves are not encrypted. This is done so that applications can parse container metadata such as codec params and timestamps without depending on the secure decrypt and decode layer.

- Each frame consists of codec protocol messages such as NAL Units for H.264 and HEVC, OBUs for AV1, and uncompressed and compressed headers and tile headers for VP9. Subsample encryption leaves message headers unencrypted, but encrypts their contents. This is done for efficiency of the secure decode hardware. Clear and encrypted byte ranges are stored in MP4 boxes.

MP4 encryption of course fully supports HEVC using both mechanisms.

Widevine in general supports HEVC. The Widevine module in Chrome has to include a decoder for each supported codec. They probably skipped HEVC to avoid increasing download size for users.

[svnpenn]

I don't buy these rationalizations at all. As was previously said, HLSe has been using fragment level encryption for many years, with AVC and MP4, so we know its possible. This is not theoretical. https://paramountplus.com and https://cbc.ca and others use HLSe on some streams currently. You don't need box level encryption, and requiring it just add pointless MP4 parsing and overhead.

[rogers12]

They're not rationalizations. They're implementation choices under legal, engineering and product constraints. In particular, Paramount and CBC allow themselves to use HLS encryption forbidden under typical content protection contracts.