>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?
Transcoding like that is very heavily frowned upon. A scene group would not risk their reputation like that.
I suspect what they are referring to there is the process of remuxing the file and removing extra audio streams, ie. a BD50 BluRay of "They Shall Not Grow Old" comes in at 20GB with two audio streams, DTS-HD and Dolby Digital. The remux of that BluRay comes in at 16GB and has an identical bit-rate on the video stream, but the Dolby Digital audio stream has been removed, as well as the menu graphics (though this would not apply to a WEB stream).
No its not, look at piratebay. By far the most downloaded versions are 1.5-3GB 1080p rips, or much smaller 720p ones. And on some 55" screen, they are just fine
The scene releases are usually the highest quality possible released in exclusively closed private trackers - sometimes only paid accounts are accepted as a member (if at all).
Everything else probably 95% you see in the wild are transcoded to lower bitrate and stripped out of all the extra files in the container (sub/multiple audio stream/highbitrate audio) to smalled files - because thats what most people want:
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".
Presumably 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 :/
Sorry - clearly wasn't thinking straight - their alternative approach has this same issue (and having now read the article! - They do plan around this)
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.
I 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.
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?