Hacker News Reader

Comment by freedomben | Hacker News Reader

> Does is(sic) also work with DRM?

> That’s where the catch is, unfortunately. The biggest drawback is that HEVC with Widevine DRM is not supported at this point, only clear, unprotected content. It’s unclear whether Google has plans to add support for this in the future or not.

That was my first question. I hoped against hope that it wasn't a trojan horse for some new DRM.

Surely they are going to add Widevine support at some point, but I can't help but rejoice a bit to hear that the latest/greatest coding doesn't support DRM. Even the possibility of a DRM-free future is a wonderful dream.

View on HN

> HEVC with Widevine DRM is not supported

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 encrypting 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.

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.

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.

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.

> True, HEVC doesn't support Box level encryption like MP4 does

I’m not sure why you’re comparing a codec to a container format?

Based on the Quicktime File Format, MP4 is most usually only a container these days. Moving Pictures Experts Group developed the MPEG-4 standard with many parts[1] including a codec called MPEG-4 aka MP4V or just MP4, which was still popular for SD video encoding only a few years ago, though not exclusively, and it is still available to encode video in Apple Quicktime (MPEG-4 Basic, MPEG-4 Advanced), ffmpeg, HandBrake, etc., but I doubt that's what GP meant, at least, I'm not aware of any codec supporting encryption, but I really hardly know anything, so there's that. At any rate, "MP4" alone is ambiguous because it can be either the container and/or the codec.

[1] https://en.wikipedia.org/wiki/MPEG-4

Noone calls MPEG-4 Part 2 "MP4". Usually it's MPEG-4 Video, MPEG-4 ASP, or (when using that encoder) Xvid.

> Noone calls...

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.

I agree with your assessment. The reference to “box” makes me think it was definitely the container. I also don’t see the codec called MP4, it’s usually spelled out MPEG-4.

".mp4" is just a file extension, the source of the colloquial name for the container. But both the container and the codec are named MPEG-4 and both are colloquially called "MP4."

"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...

[2] https://en.wikipedia.org/wiki/S-box

[3] https://en.wikipedia.org/wiki/Permutation_box

different box

What other "box level encryption" is there?

http://fileformats.archiveteam.org/wiki/ISO_Base_Media_File_...

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)

Thanks, I really had no idea what he was talking about... fucking movie atoms. I've always hated those things, and the idea of encrypting them makes them even more sadistic.

> It forces anyone who wants to decrypt (or encrypt) to write a full MP4 parser

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.

> 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:

https://godocs.io/github.com/edgeware/mp4ff/mp4

I haven't done anything with Widevine , but I have written multiple BMFF parsers, and I'm intimately familiar with how many different boxes/atoms there are. Luckily you can implement them incrementally because the box hierarchy is so normalized.

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?

I’ve written a (partial) zero-alloc MP4 decoder and it was definitely not as easy as the other poster makes it sound.

Back a while I tried to implement a MP4 demuxer, and I can kind of relate to that. The mdat box is sometimes an opaque blob and you need to parse the codec framing to split packets (fMP4 helps with this a bit), each codec has its own set of boxes, and the specs for each of them are paywalled...

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.

Reply on news.ycombinator.com