5 ms·
>After starting with a large raw file, the finalized version ready for release is around 30% smaller, around 7GB for a 1080p file. Huh? Are they recompressing
by Buge 7y ago
>After starting with a large raw file, the finalized version ready for release is around 30% smaller, around 7GB for a 1080p file.
Huh? Are they recompressing it? How else would it shrink? If they're recompressing it, why don't they just use a capture card and avoid the hassle of reverse engineering stuff?
- anateus 7y agoThe encrypted file can be bigger than the decrypted version for a bunch of different reasons, that's like what's going on here.
- Buge 7y agoNetflix 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.
- Ace17 7y ago> 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.
- pavs 7y agoRe-encoding with lower bitrate. 99% of the people won't be able to tell the difference.
- Buge 7y agoYes, but then why do they need to reverse engineer anything? Can't they use a capture card?
- gsich 7y agoThey can, it's called "webrip" then (also in the article). Creates an obvious problem though.
- Slartie 7y agoWhat is this "obvious problem"? Aside from the quality loss due to re-encoding - which should be identical to the loss encountered when capturing digital video and audio output, assuming the capture is done correctly - I fail to see anything "obvious".
- vijayr02 7y agoI assume it's per stream identifiable information added by the stream provider, making the identity of the ripper traceable
- vijayr02 7y agoSorry - clearly wasn't thinking straight - their alternative approach has this same issue (and having now read the article! - They do plan around this)
- noodlesUK 7y agoPresumably this is still present in the encoded stream they decrypt. I believe the way around this is by prepaid accounts etc and throwaway emails. High end piracy like this is big business. Correct me if I’m wrong about the IDs in the stream though. Edit: I just saw parents reply. It took a while to type this out on my phone :/
- gsich 7y agoI remember that in DVB-S (maybe T/C too?) streams there is a constant bitrate, with additional empty packets (PID 8191 in MPEG-TS). Removing those usually results in a ~30% reduction. But I can't imagine that Netflix or Amazon uses such null bytes.