Netflix serves a tremendous amount of video, a large percent of total internet bandwidth. They spend a lot of time optimizing their video compression, which can be seen from their tech blog, and papers they publish on video compression techniques. There's no reason for an encrypted file to be more than 100 bytes larger than the unencrypted file. I highly doubt Netflix is introducing a 30% overhead for no reason.
> There's no reason for an encrypted file to be more than 100 bytes larger than the unencrypted file.
Video engineer currently implementing MPEG Common Encryption here:
Actually, there is.
MPEG CENC (Common Encryption) uses AES CTR and requires conveying one initialization vector for each audio/video frame. Those are generally 16-byte long.
To make the matter (a little) worse, MPEG CENC adds signalization to the file, to specify which parts of the streams are encrypted or not: indeed, for remux-without-decrypt reasons, each video frame must have its headers in cleartext.
In fine, you get some dozen of bytes of overhead per audio/video frame ; do the math.
Of course, this overhead remains negligible and could by no means explain a 30% size reduction when decrypting.
Buge|6 years ago
Ace17|6 years ago
Video engineer currently implementing MPEG Common Encryption here:
Actually, there is.
MPEG CENC (Common Encryption) uses AES CTR and requires conveying one initialization vector for each audio/video frame. Those are generally 16-byte long.
To make the matter (a little) worse, MPEG CENC adds signalization to the file, to specify which parts of the streams are encrypted or not: indeed, for remux-without-decrypt reasons, each video frame must have its headers in cleartext.
In fine, you get some dozen of bytes of overhead per audio/video frame ; do the math.
Of course, this overhead remains negligible and could by no means explain a 30% size reduction when decrypting.