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

181–190 of 230 posts

Re: H.264 is Magic

#181

Post by shabbyrobe »

astrange wrote: post #170
the8472 wrote: post #108

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

It's easy to make a 4:2:0 upscaler that doesn't color bleed. Everyone just uses nearest-neighbor, which sucks, and then blames the other guy.

How would you make a 4:2:0 upscaler that doesn't color bleed?

Re: H.264 is Magic

#182

Post by i336_ »

I found this explanation of Xiph.org's Daala (2013) very interesting and enlightening in terms of understanding video encoding: https://xiph.org/daala/

Related:

BPG is an open source lossless format for images that uses HEVC under the hood, and is generally better than PNG across the board: http://bellard.org/bpg/

For a runner-up lossless image format unencumbered by H265 patents (completely libre), try http://flif.info/.

Re: H.264 is Magic

#183

Post by sundvor »

algesten wrote: post #44

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

Yep, me too - more like, if I was blind, I wouldn't notice the difference. Which is why the bitrate is always the first thing I look at when sourcing video.

Re: H.264 is Magic

#184

Post by crimsonalucard »

lostgame wrote: post #75

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…

FAIL. "10 tosses, all heads" is 20 characters while "HHHHHHHHHH" is 10 characters. You've conducted expansion rather than compression.

Re: H.264 is Magic

#186

Post by LASR »

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

Earlier quoted context omitted.

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.

Thanks for the feedback! Sorry if I was unclear. The comparison with PNG is very intentional to illustrate the vast difference in the compression efficiencies involved. I do state the difference clearly here though:

> This concept of throwing away bits you don't need to save space is called lossy compression. H.264 is a lossy codec - it throws away less important bits and only keeps the important bits.

> PNG is a lossless codec. It means that nothing is thrown away. Bit for bit, the original source image can be recovered from a PNG encoded image.

Re: H.264 is Magic

#187

Post by Retra »

crimsonalucard wrote: post #184
lostgame wrote: post #75

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…

FAIL. "10 tosses, all heads" is 20 characters while "HHHHHHHHHH" is 10 characters. You've conducted expansion rather than compression.

"10H" is the string you should be comparing it to (or something equivalent.)

Re: H.264 is Magic

#188

Post by userbinator »

agumonkey wrote: post #94
lostgame wrote: post #75

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…

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.

I think the LZ family are all pretty intuitive --- just replace repeated sequences with a reference to where they occurred before. Even human languages have things like contractions, abbreviations, and acronyms. Thus it is, at least to me, somewhat surprising that LZ was only documented academically several decades after Huffman; perhaps it was thought to be too trivial? LZ can also be thought of as an extension of RLE.

In any case, an LZ decompressor fits in less than 100 bytes of machine instructions and a simple compressor can be implemented in not more than several hundred, all the while providing extremely high compression for its simplicity. It will easily outperform order-0 static or dynamic Huffman on practical files like English text, and would probably make a good assignment in an undergraduate-level beginning data structures/algorithms/programming course; yet it seems more popular to give an assignment on Huffman using trees, which is somewhat ironic since in the real world Huffman is implemented using bit operations and lookup tables, not actual tree data structures.

To give a trivial example, LZ will easily compress ABCDABCDABCDABCD while order-0 Huffman can't do much since each individual symbol has the same frequency.

Re: H.264 is Magic

#189

Post by userbinator »

erydo wrote: post #91
amluto wrote: 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…

It seems like a pretty difficult problem since there are so many permutations of applicable transformations.

That's part of why video encoding can be very slow --- with motion compensation, to produce the best results the encoder should search through all the possible motion vectors and pick the one that gives the best match. To speed things up, at a slight cost in compression ratio, not all of them are searched, and there are heuristics on choosing a close-to-optimal one instead: https://en.wikipedia.org/wiki/Block-matching_algorithm

Re: H.264 is Magic

#190

Post by mort96 »

crimsonalucard wrote: post #184
lostgame wrote: post #75

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…

FAIL. "10 tosses, all heads" is 20 characters while "HHHHHHHHHH" is 10 characters. You've conducted expansion rather than compression.

That example is about conveying the information verbally to another human, so syllables is interesting, not characters. "h h h h h h h h h h" is 10 syllables, "10 tosses, all heads" is 4 (and could be compressed further to "10 heads").
Post reply on HN