Live data from Hacker News

H.264 is Magic

sidbala.com

171–180 of 230 posts

Re: H.264 is Magic

#171
post #67
post #59

Can 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.

It's a bad analogy. Binary and hex are just different formats for representing the same number. Spatial domain and frequency domain are different views of a complex data set. In the spatial domain, you are looking at the intensity of different points of the image. In the frequency domain, you are looking at the frequencies of intensity changes in patterns in the image. A good way to develop an intuition for the fouri…

> Spatial domain and frequency domain are different views of a complex data set.

Or in this case, a real data set.

Re: H.264 is Magic

#172

"See how the compressed one does not show the holes in the speaker grills in the MacBook Pro? If you don't zoom in, you would even notice the difference. " Ehm, what?! The image on the right looks really bad and the missing holes was the first thing I noticed. No zooming needed. And that's exactly my problem with the majority of online video (iTunes store, Netflix, HBO etc). Even when it's called "HD", there are comp…

I find the 480p setting on my plex server at home actually looks better than most of the 1080p HD streams on the internet.

Although to be fair, I suspect that a lot of times what I'm looking at are mpeg videos that have been recompressed a half dozen or more times with different encoders. Each encoder having prioritized different metrics. So, the the quality gets worse until it doesn't really matter how good the compression algorithm is. Each new re-compression is basically spending 3/4 of its bits maintaining the compression artifacts from the previous two passes.

Re: H.264 is Magic

#174
The PNG size seems to be misrepresented. The actual PNG is 637273 bytes when I download it, and 597850 if I recompress it to make sure we're not getting fooled by a bad PNG writer.

So instead of the reported 916KiB we're looking at 584KiB.

This doesn't change the overall point, but details matter.

  $ wget https://sidbala.com/content/images/2016/11/FramePNG.png
  --2016-11-04 22:08:08--  https://sidbala.com/content/images/2016/11/FramePNG.png
  Resolving sidbala.com (sidbala.com)... 104.25.17.18, 104.25.16.18, 2400:cb00:2048:1::6819:1112, ...
  Connecting to sidbala.com (sidbala.com)|104.25.17.18|:443... connected.
  HTTP request sent, awaiting response... 200 OK
  Length: unspecified [image/png]
  Saving to: ‘FramePNG.png’

  FramePNG.png                      [                                              ] 622.34K  --.-KB/s   in 0.05s

  2016-11-04 22:08:08 (12.1 MB/s) - ‘FramePNG.png’ saved [637273]

  $ pngout FramePNG.png
   In:  637273 bytes               FramePNG.png /c2 /f5
  Out:  597850 bytes               FramePNG.png /c2 /f5
  Chg:  -39423 bytes ( 93% of original)

Re: H.264 is Magic

#175

Absolutely 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…

That's how compression was first explained to me, and it really stuck with me ever since. It was in the context of an image though, and instead of heads, it was red pixels. What's really cool is that the simple explanation can be extended to explain things like why ciphertext doesn't compress well: because ciphertext has no patterns

Not compression per se, but I remember when I was reverse engineering maps for Chip's Challenge. I would often see a tile (represented as a byte) that was encoded as 0xFF0502. I ended up realizing it meant "Repeat 'tile 2' 5 times." It was fun to figure that out as a kid.

Re: H.264 is Magic

#176
post #168

Absolutely 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 would probably say I found a two headed coin. I also like how "HHHHHHHHHH" is shorter than "I tossed it 10 times, all heads"

Which is shortest, you can recover the original dataset from any of the following:

- heads, heads, heads, tails, tails, heads

- hhhtth

- h3t2h

- 3b1

Re: H.264 is Magic

#177

Related, how h265 works: http://forum.doom9.org/showthread.php?t=167081 This is a great overview and the techniques are similar to those of h264. I found it invaluable to get up to speed when I had to do some work on the screen content coding extensions of hevc in Argon Streams. They are a set of bit streams to verify hevc and vp9, take a look, it is a very innovative technique: http://www.argondesign.com/products/ar…

Heh, happy to see doom9 still alive and kicking. They were the n°1 resource in the early days of mainstream video compression.

It's not really alive and kicking. The forum is still active but the rest of the site hasn't been touched since 2008.

Re: H.264 is Magic

#178
post #174

The PNG size seems to be misrepresented. The actual PNG is 637273 bytes when I download it, and 597850 if I recompress it to make sure we're not getting fooled by a bad PNG writer. So instead of the reported 916KiB we're looking at 584KiB. This doesn't change the overall point, but details matter. $ wget https://sidbala.com/content/images/2016/11/FramePNG.png --2016-11-04 22:08:08-- https://sidbala.com/content/images…

Why even compare PNG and H.264 to begin with? PNG is a lossless compression format. A better comparison would be something lossy like JPG, which could easily shrink the size to ~100 kB. The point still stands, but at least it's a more relevant comparison.

Re: H.264 is Magic

#179

Absolutely 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…

That's only one half of the problem - you now have an alphabet five times the size so you have actually increased the size of the message! You also need to explain how to encode this efficiently to explain compression.

wouldn't you just convert the alphabet to 0-1? Shouldn't the 0-1 compression be the most optimal? That is, you can't find a better deal with any alphabets or numerical?

Re: H.264 is Magic

#180
post #168

Absolutely 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 would probably say I found a two headed coin. I also like how "HHHHHHHHHH" is shorter than "I tossed it 10 times, all heads"

The all-heads sequence is exactly as likely as any other sequence.
Post reply on HN