Live data from Hacker News

H.264 is Magic

sidbala.com

111–120 of 230 posts

Re: H.264 is Magic

#111

Earlier quoted context omitted.

Not really - the knowledge of what an alphabet can be universally agreed upon and doesn't need to be transmitted with the data. The metaphor here is that software and hardware-based decoding can now be much more powerful because the hardware is more powerful than it used to be. And of course the truth is you would just transmit "H_10" with the universally agreed upon knowledge that "H" is "Heads" and "_" is number of…

> you would just transmit "H_10" with the universally agreed upon knowledge that "H" is "Heads" and "_" is number of times. Yes I get that the alphabet is already agreed upon. But if I only transmit H or T (uncompressed) that's just one bit needed per symbol. So I can transmit HHHHHHHHH in ten bits. If I introduce this simplified compression to the system and add 0-9 to the alphabet, that now needs four bits per symb…

you know it was just an example in terms of what you might tell a friend over the phone about a coin flip right? i suppose you'd send your friend a huffman tree and then say "1110"

Re: H.264 is Magic

#112

> Chroma Subsampling. Sadly, this is what makes video encoders designed for photographic content unsuitable for transferring text or computer graphics. Fine edges, especially red-black contrasts start to color-bleed due to subsampling. While a 4:4:4 profile exists a lot of codecs either don't implement it or the software using them does not expose that option. This is especially bad when used for screencasting. Anoth…

This is also the bane of powerpoint presentations. Many TVs only support 4:2:0, so red on black text quickly becomes an smudgey mess.

Re: H.264 is Magic

#113

Earlier quoted context omitted.

> you would just transmit "H_10" with the universally agreed upon knowledge that "H" is "Heads" and "_" is number of times. Yes I get that the alphabet is already agreed upon. But if I only transmit H or T (uncompressed) that's just one bit needed per symbol. So I can transmit HHHHHHHHH in ten bits. If I introduce this simplified compression to the system and add 0-9 to the alphabet, that now needs four bits per symb…

you know it was just an example in terms of what you might tell a friend over the phone about a coin flip right? i suppose you'd send your friend a huffman tree and then say "1110"

This entire thread makes me think of that Silicon Valley scene[1].

[1] https://www.youtube.com/watch?v=-5jF5jtMM_4

Re: H.264 is Magic

#114

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

The first thing I noticed was the ringing, which is an artifact of low-pass filtering so it's a nice opportunity to go into problems with that kind of filtering. Other than that I think it was an ok teaser that gives an idea of how compression is done and what the trade-offs are.

Re: H.264 is Magic

#115
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.

Basically we can represent any signal as an infinite sum of sinusoids. If you know about Taylor expansion of a function, then you know that the first order term is the most important, then the second and so on. Same principle with the sinusoids. So if we remove the sinusoids with very high frequency we remove the terms with least information.

Re: H.264 is Magic

#116
This is a really well written article. Exactly why I love HN. Sometimes you get this nice technical intros into fields you thought were black magic.

Re: H.264 is Magic

#117
post #70
post #23

Earlier quoted context omitted.

It is an open standard. Anyone can purchase and implement it, and it was developed by ISO. The technologies are not royalty free in the US. Don't conflate the two. * Edit: I emphasize this mainly because the terms have a specific meaning in standards jargon but also because it places the blame for software patent abuses on the wrong parties (the standards developers rather than the lawyers and legislators).

OK, so it is open, but not free ? Is it available for academic purposes free of cost ?

You have to pay royalties to actually use it, but if you just want to read the thing, you can get it for free from the ITU. https://www.itu.int/rec/T-REC-H.264-201602-S/en

Re: H.264 is Magic

#118
post #97
post #33

Earlier quoted context omitted.

H.265 gets you half the file size for ten times more in royalty fees, or saving 50% of bandwidth for 1000% more in royalty.

Do you have a reference for that? I was under the impression that the first 100,000 units are free, and then 20c per unit afterwards to a max of $25m. H264 drops to 10c per unit after 5m units, to a max of $6.5m. You need to be shipping 125 million units annually to hit the full $25m. Yes it's more, but it's not quite ten times. And notably if the chip maker pays the royalties, then the content creators don't need to…

HEVC got an additional licensing pool in HEVC Advance that demanded significantly greater license fees on top of MPEG LA's.

Said group's demands are basically the reason Netflix started considering VP9.

Re: H.264 is Magic

#119

"This concept of throwing away bits you don't need to save space is called lossy compression." What a terrible introduction of lossy compression. This would mean that if I empty the thrash bin on my desktop, it's lossy compression. The concept of going through all compression ideas that are used is pretty neat though.

> This would mean that if I empty the thrash bin on my desktop, it's lossy compression.

It is.

Re: H.264 is Magic

#120
post #91
post #65

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

Now I'm out of my depth, but I think motion compensation does okay at rotation and scaling. The motion vector varies throughout the frame, and I think codecs interpolate it, so all kinds of warping can be represented.
Post reply on HN