Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

H.264 is Magic

sidbala.com

Post reply on HN
Print view View original

131–140 of 230 posts

Re: H.264 is Magic

#131

Post by TD-Linux »

brigade wrote: post #118
_puk wrote: post #97

Earlier quoted context omitted.

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.

Two additional, as Technicolor later dropped out of HEVC Advance and is now licensing theirs individually: http://www.streamingmedia.com/Articles/Editorial/Featured-Ar...

Re: H.264 is Magic

#132

Post by mbebenita »

dao- wrote: post #38
eutectic wrote: post #20

Anyone 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

Daala continues to be research platform for new ideas. New techniques are a lot easier to prototype in Daala than in more mature code bases.

Re: H.264 is Magic

#133

Post by qwertyuiop924 »

chrisseaton wrote: post #106
deanCommie wrote: post #102

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…

But actually, no. Because you could set up HTTHTTTHHHHHHHHHH the format like this:

  01001000
  11001010
That's sixteen bits for 17 coinflips. With no continuous sequences longer than seven, this format takes up one extra bit every seven flips.

How does it work? The first bit is a sign bit. If it's zero, the next seven bits are raw coinflips, 0 for tails, 1 for heads. If it's one, the second bit signifies whether the next sequence consists of heads or tails (again, 0 for tails, 1 for heads), and the remaining six bits tell how long said sequence is.

This is a fairly simple encoding for the strategy described in the article, which I thought of off the top of my head in about five minutes, and I know nothing about compression. It's slightly broken (what if the sequence ends mid-byte?), but it does kind of work. Somebody who actually knows about compression could probably do this better.

Re: H.264 is Magic

#134

Post by warpzero »

szemet wrote: post #9

I thought I'll learn something special about H.264, but all information here is high level and generic. For example if you replace H.264 with a much older technology like mpeg-1 (from 1993) every sentence stays correct, except this: "It is the result of 30+ years of work" :)

I was a bit disappointed in this article for the same reason: this is a great primer for people new to MPEG video compression, but it doesn't have anything to do with H.264.

I was hoping the author would write about H.264 specifically, for instance, how it was basically the "dumping ground" of all the little tweaks and improvements that were pulled out of MPEG-4 for one reason or another (usually because they were too computationally expensive), and why, as a result, it has thousands of different combinations of features that are extremely complicated to support, which is why it had to be grouped into "profiles" (e.g., Baseline, Main, High): http://blog.mediacoderhq.com/h264-profiles-and-levels/

I was also hoping that he would at least touch on the features that make H.264 unique from previous MPEG standards, like in-loop deblocking, CABAC Entropy Coding, etc..

Again, it's fine as an introduction to video encoding, but there's nothing in here specific to H.264.

Re: H.264 is Magic

#135

Post by mherrmann »

I recently experienced this as follows: https://www.sublimetext.com has an animation which is drawn via JavaScript. In essence, it loads a huge .png [1] that contains all the image parts that change during the animation, then uses to draw them.

I wanted to recreate this for the home page of my file manager [2]. The best I could come up with was [3]. This PNG is 900KB in size. The H.264 .mp4 I now have on the home page is only 200 KB in size (though admittedly in worse quality).

It's tough to beat a technology that has seen so much optimization!

1: http://www.sublimetext.com/anim/rename2_packed.png

2: https://fman.io

3: https://www.dropbox.com/s/89inzvt161uo1m8/out.png?dl=0

Re: H.264 is Magic

#136

Post by VikingCoder »

1maginary wrote: post #73
VikingCoder wrote: post #48

Ugh. Comparing the file size difference between a lossless PNG and a LOSSY H.264 video of a STATIC PAGE is absurd. Calling it "300 times the amount of data," when it's a STATIC IMAGE is insulting in the extreme. It really doesn't matter if the rest of the article has insights, because you lost me already.

He clarifies right after that he got to those numbers because he used a lossless vs lossy encoder. Really should've kept reading

"right after that".

No he didn't explain "right after that." He rambled on and on, and even after all of that, he STILL doesn't bring up JPG.

It's an inherently stupid comparison to make. You can't polish a turd.

Re: H.264 is Magic

#137

Post by LordDragonfang »

amelius wrote: post #4

> discard information which will contain the information with high frequency components. Now if you convert back to your regular x-y coordinates, you'll find that the resulting image looks similar to the original but has lost some of the fine details. I would expect also the edges in the image to become more blurred, as edges correspond to high-frequency content. However, this only seems to be slightly the case in th…

You can see exactly that with the speaker grill and the text (This type of transformation is notoriously bad at compressing images of text, and is why you shouldn't use jpg for pictures of text)

In this context, the edges of, say, the macbook are not "high frequency" content, since they only feature one change (low to high luminosity) in a given block rather than several (high-low-high-low-high) like for the grill.

Re: H.264 is Magic

#138

Post by titanomachy »

nightcracker wrote: post #110
agumonkey wrote: post #105

Earlier quoted context omitted.

I never learned AC. It's on my overflowing stack of thing to read about.

AC is conceptually stupidly simple. All you do is encode a string of symbols into a range of real numbers. To start your range is [0, 1). For each symbol you want to encode you take your range and split it up according to your probabilities. E.g. if your symbols are 25% A, 50% B and 25% C, then you split up that range in [0, 0.25) for A, [0.25, 0.75) for B and [0.75, 1) for C. Encoding multiple symbols is just applyi…

Nice explanation. Can you explain how to remove ambiguity relating to string length?

"0" = 0.0b = 0 falls in the range [0,0.25) so it's a valid encoding for "A"; but isn't it also a valid encoding for "AA", "AAA", etc.?

AA = [0,0.25) * [0, 0.25) = [0, 0.125), and so on.

It seems that adding "A"s to a string in general doesn't change its encoding.

Post reply on HN