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?
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).
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:
Small Video easily playable on a regular screen.
Creates an obvious problem though.
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".
Edit: I just saw parents reply. It took a while to type this out on my phone :/
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.