The comparison doe not make any sense, and no h264 is not magic!!:
- The guy is comparing a lossless format PNG to H264 which is a lossy video format, that is not fair.
- he is generating a 5 frame video and compared to 1 frame image, only the I-frame at the begining of the video matter in that case al the others are derived from it, P-Frame.
- What is the point of having that comparaison we already have images format comparable to the size of a H264 I-frame and using the same science (entropy coding, frequency domain, intra frame MB derivation...)?
H.264 is Magic
121–130 of 230 posts
Re: H.264 is Magic
#122Try scrubbing backwards. H264 seeking only works nice if you're fast-forwarding the video. Actually, that is kind of magical.
Re: H.264 is Magic
#123Earlier quoted context omitted.
RLE a given. It's true that the average person rarely understand that this is what computers call compression, but everything after that involves a bit of thinking. Optimal huffman.
IMO Huffman is conceptually more complicated (not the implementation, but the logic) than arithmetic coding. And Huffman isn't optimal unless you are lucky, unlike arithmetic coding.
Huffman seems simpler to me, but I've implemented both at various times so that might colour my perspective.
Re: H.264 is Magic
#124Absolutely love this: 'Suppose you have some strange coin - you've tossed it 10 times, and every time it lands on heads. How would you describe this information to someone? You wouldn't say HHHHHHHHH. You would just say "10 tosses, all heads" - bam! You've just compressed some data! Easy. I saved you hours of mindfuck lectures.' This is a really great, simple way to explain what is otherwise a fairly complex concept…
I definitely wouldn't say "HHHHHHHHH," since I tossed it 10 times, not 9.
Saying "10 tosses, all heads" reduces the chance of omitting a toss in data entry, which is all to the better.
Re: H.264 is Magic
#125The comparison doe not make any sense, and no h264 is not magic!!: - The guy is comparing a lossless format PNG to H264 which is a lossy video format, that is not fair. - he is generating a 5 frame video and compared to 1 frame image, only the I-frame at the begining of the video matter in that case al the others are derived from it, P-Frame. - What is the point of having that comparaison we already have images forma…
Did you read the article?
The point you are making here is PRECISELY the point that the author was making in the article: that a lossy format can be far, far smaller. He then goes into the details (from a high-level point of view) of what kinds of losses H264 incurs.
Re: H.264 is Magic
#126Earlier quoted context omitted.
I try to use VLC when I can because it offers intuitive playlist support, but for high-resolution H.264 and friends I usually have to switch to Media Player Classic. VLC is willing to let my entire screen look like a blob of grey alien shit for 10 seconds instead of just taking a moment to reconstruct frames. And its hardware acceleration for newer codecs is balls. Sucks because otherwise, it's right up there with f2…
I stopped using VLC when I found mpv [0]. I really like it because it exposes everything from the CLI, so once you're familiarized with the flags you're interested in using, it's easy to play anything. For everyday usage it "just works" too, as expected of any video player. [0] https://mpv.io/
I'll check it out and let you know what I think. Thanks~
Re: H.264 is Magic
#127Nice article! The motion compensation bit could be improved, though: > The only thing moving really is the ball. What if you could just have one static image of everything on the background, and then one moving image of just the ball. Wouldn't that save a lot of space? You see where I am going with this? Get it? See where I am going? Motion estimation? Reusing the background isn't motion compensation -- you get that…
Your example seems to assume translation only. I wonder how difficult/useful it would be to identify other kinds of time-varying characteristics (translation, rotation, scale, hue, saturation, brightness, etc) of partial scene elements in an automated way. Along the same lines, it would be interesting to figure out an automated time-varying-feature detection algorithm to determine which kinds of transforms are the ri…
Most codecs split the image into prediction blocks (for example, 16x16 for MPEG-2, or from 4x4 to 64x64 for VP9). Each of these blocks has its own motion vector. All of the transformations you mentioned look like a translation if you look at them locally, so they can all be fairly well represented by this. Codecs have, in the past, attempted global motion compensation, which tries to fully model a camera (rotating, translating, lens distortion, zooming) but all of those extra parameters are very difficult to search for.
Daala and AV1's PVQ is an example of a predictor for contrast and brightness (in a very broad sense).
Re: H.264 is Magic
#128Anyone who likes this would probably also enjoy the Daala technology demos at https://xiph.org/daala/ for a little taste of some newer, and more experimental, techniques in video compression.
Note that Daala has been discontinued in favor of AV1: https://en.wikipedia.org/wiki/AOMedia_Video_1 Previously Daala was presented as a candidate for NETVC but apparently this didn't go anywhere? https://en.wikipedia.org/wiki/NETVC
A lot of Daala tools are now being copied into AV1, the largest being PVQ: https://aomedia-review.googlesource.com/#/c/3220/
Re: H.264 is Magic
#129Right at the beginning, he says uncompressed video is "RGB". This has never been true, even before computers. Uncompressed video is YUV or one of the variants.
Re: H.264 is Magic
#130Can someone explain how the frequency domain stuff works? I've never really understood that, and the article just waves it away with saying it's like converting from binary to hex.
Image and video codecs don't actually use the fourier transform as presented in the article, they use the DCT. Check out the example section on Wikipedia: https://en.wikipedia.org/wiki/Discrete_cosine_transform
The JPEG article also has a very good, step by step example of the DCT, followed by quantization and entropy coding: https://en.wikipedia.org/wiki/JPEG