MP4 is seriously one of the easiest binary formats to parse, and even if you couldn't use an existing parser it would probably be the simplest part of whatever you were actually building.
Unless you've written a Widevine client, downloaded from DASH, parsed MP4, decrypted MP4 samples, then reassembled the decrypted fragments, then you're really not in a position to be making this claim. I have done all the above, and the MP4 parsing was by far the most difficult part of the process, and that includes parsing Protocol Buffers for use with Widevine. The sheer volume of different box types is what makes it difficult. Over 100 types, see for yourself:
It's actually my go-to project when I'm trying to learn a new language, because the problem itself is simple enough to understand, but it forces you to learn the idioms about the language you're learning. What is the idiomatic way to represent different box types? How do you read values with specific endianness from a buffer? How do you seek through a file's contents without loading the whole 10GB movie into memory?
Matroska/WebM is so much simpler and easier to parse, you can essentially abstract it away in a JSON-like DOM (obviously without loading 1GB of data into memory) and just get what you want, it's great.
I’m not sure why you’re comparing a codec to a container format?
"Box level" is apparently referring to types of cryptography, "S-boxes are non-linear transformations of a few input bits that provide confusion and P-boxes simply shuffle the input bits around to provide diffusion"[1] The basic function of S-Box[2] is to transform 8 bits input data into 8 bits of secret data using a precomputed look-up-table (LUT). A "permutation box (or P-box) is a method of bit-shuffling used to permute or transpose bits across S-boxes inputs, retaining diffusion while transposing."[3]
[1] https://www.linkedin.com/learning/symmetric-cryptography-ess...
http://fileformats.archiveteam.org/wiki/Boxes/atoms_format
Encryption of boxes, not encryption with boxes. (the existence of AES sboxes is coincidental, and is not what was being discussed)
Let each of them know, please, that I and my compadres apologize for referring to MPEG-4 Part 2 as MP4 to save time, and refer to the container as MPEG-4 Part 14 to avoid ambiguity. Major faux pas there, how embarrassing, mea culpa, and thank you for taking the time to set us straight by letting us know what every single other person does.
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.
This isn't true at all. True, HEVC doesn't support Box level encryption like MP4 does, but nothing is stopping anyone from just AES encoding an entire fragment, as has been used for years with HLSe. The fact that MP4 uses box level encryption is one of the stupidest tech-related things I have ever seen. It forces anyone who wants to decrypt (or encrypt) to write a full MP4 parser, instead of just utilizing existing encryption tools on some "dumb bytes". Once people realize that you can just use HLSe method with HEVC, websites can then pull the keys from the M3U files and just return them from Widevine license requests instead.