Live data from Hacker News

H.264 is Magic (2016)

sidbala.com

111–120 of 229 posts

Re: H.264 is Magic (2016)

#111
post #49

PSA: For images, there's a finally successor to jpeg: JPEG XL (.jxl) - has lossy and lossless mode; is progressive (you can download just the first parts of the bitstream to get a lower resolution image; and other benefits!) https://jpegxl.info/

>For images, there's a finally successor to jpeg

We've heard this a few times... JPEG2000, WebP, HEIF, AVIF. I bet JPEG XL will finally be it!

Re: H.264 is Magic (2016)

#112
post #104

See also H.265: * https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding And now even H.266: * https://en.wikipedia.org/wiki/Versatile_Video_Coding Also, at what point will AV1 become "mainstream"? How prevalent is it? Still seems that hardware decoding (never mind encoding) support is still only so-so.

What I think the AV1 initiative neglects as a way of spreading their tech would be giving away a great open implementation of an encoder. x265 and x264 spread their respective codecs all over the internet through pirated content, which forced adoption. The fact that you can play .mkv files almost anywhere now is a testament to that.

I think backing companies like Google and Netflix don't care about that. They need hardware decoding support in phones and TVs, and they will serve av1 from their platforms and save a lot of money. It might become the dominant codec without you even noticing it.

Re: H.264 is Magic (2016)

#113
post #96

Earlier quoted context omitted.

Did they avoid the prohibitive licensing that left JPEG 2000 dead in the water?

should be FOSS and loyalty free https://gitlab.com/wg1/jpeg-xl/-/blob/main/LICENSE

That license doesn't say anything about patents. This one does: https://gitlab.com/wg1/jpeg-xl/-/blob/main/PATENTS and only says that patents owned by Google are covered. So it may be that other companies patent the technology. The information in the repository is not enough to decide whether JPEG XL is safe to use.

Re: H.264 is Magic (2016)

#114
post #46

> "a technical walkthrough" > "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." Ahh, my favorite kind of technical walkthrough. Love it

> You wouldn't say HHHHHHHHH. You wouldn’t and shouldn’t. There are only nine “H” in there!

One could read that as having an implicit ellipsis, ie. "HHHHHHHHH..." After all, you would and should say HHHHHHHHH on the way to saying HHHHHHHHHH.

Re: H.264 is Magic (2016)

#115
Two questions for the compression gurus here.

Suppose you have a bunch of raw video. You take extracts of it and put them together to make a movie, M1. You make an H.264 encoded copy of that. Let's call it C1.

You then make a new cut of your movie, M2, which is mostly the same footage as M1 except that you've shortened a few scenes and lengthened others. You make an H.264 encoded copy of that. Call this C1.

When making C1 and C2 your H.264 encoders have to decide which frames to turn into I-frames and which to turn into P-frames.

If they just do something simple like make every Nth frame an I-frame then after the first different between M1 and M2 it is unlikely that C1 and C2 will have many I-frames in common, and therefore also not have many P-frames in common.

If they look for scene changes and make new I-frames on scene changes, then we might expect that at least for the scenes that start identically in M1 and M2 they will get identical I-frames and P-frames up to their first edit if any.

Scenes that are edited in the front would still end up encoded totally different in C1 and C2.

Question: are there any encoders that when encoding M2 to produce C2 can be given M1 and C1 as references using them to adjust I-frame spacing so as make as many C2 I-frames as possible match C1 I-frames?

That would allow C2 to be stored efficiently as a binary diff from C1. This could be handy if C1 and C2 needed to be checked into a version control system, or you needed to distribute C2 over a low bandwidth or expensive link to someone who already had C1.

The second question concerns recompressing after decompression. I actually thought of this question in terms of audio so will ask in those terms, but I guess it applies to video too.

Suppose someone has an uncompressed source S. They compress it with a lossy compressor producing C and distribute C to you. You decompress C producing S'.

You then compress S' with a lossy compressor (the same type that the original producer used--e.g.., if C is an MP3 you use an MP3 compressor) producing C'. I don't know about video, but for audio (at least back in days when MP3 was starting to get big) C' would be lower quality than C.

Are there any compressors that can figure out that they are dealing with something that already has undergone the "throw out imperceptible parts to make it more compressible" step done and just skip to the next stage, so they produce a C' that is a lossless representation of S'?

Re: H.264 is Magic (2016)

#116
Just got a drone air 2s and it recorded in h.265. I tried to play it on 2013 MacBook retina and it plays a frame every minute or so. I can play 4k h.264 no problem. Am I missing something why its not playing

Re: H.264 is Magic (2016)

#117
post #73

One thing I was curious about is how the PNG would compare after running it through an optimizer since that would be a more fair comparison since the H.264 encoding does optimize. Even so, I bet the H.264 would fare well. I did an experiment with using single-frame H.264 instead of images on a site: I think it’s a viable technique but didn’t have time to flesh it out in full. If you have some kind of asset pipeline f…

It would be better for you to serve .webp and .avif (or optionally .heif for apple devices) inside a tag with .jpg or .png as fallback, as these formats are designed for static images, but are based on I-frame compressors for vp9, av1 and hevc respectively.

Re: H.264 is Magic (2016)

#118
post #99
post #49

PSA: For images, there's a finally successor to jpeg: JPEG XL (.jxl) - has lossy and lossless mode; is progressive (you can download just the first parts of the bitstream to get a lower resolution image; and other benefits!) https://jpegxl.info/

As a professional photographer I can’t believe we’ve been stuck with jpeg so long - 8 bits simply aren’t enough and lossy saving is a bummer. I’ll need both Capture One and Lightroom to support whatever gets decided on though, and that could take a while.

JPEG2000 is a good option for lossless compression. JPEG XL seems to offer better result and improvements now, but it isn't yet mainstream and has competition.

Re: H.264 is Magic (2016)

#119
post #104

Earlier quoted context omitted.

What I think the AV1 initiative neglects as a way of spreading their tech would be giving away a great open implementation of an encoder. x265 and x264 spread their respective codecs all over the internet through pirated content, which forced adoption. The fact that you can play .mkv files almost anywhere now is a testament to that.

I think backing companies like Google and Netflix don't care about that. They need hardware decoding support in phones and TVs, and they will serve av1 from their platforms and save a lot of money. It might become the dominant codec without you even noticing it.

Sure, but I meant that hardware support is implemented if vendors are forced to support something -- such as user downloaded files.

Netflix will serve both av1, h265 and h264, so my TV doesn't have to implement av1 support.

Re: H.264 is Magic (2016)

#120
post #49

PSA: For images, there's a finally successor to jpeg: JPEG XL (.jxl) - has lossy and lossless mode; is progressive (you can download just the first parts of the bitstream to get a lower resolution image; and other benefits!) https://jpegxl.info/

>For images, there's a finally successor to jpeg We've heard this a few times... JPEG2000, WebP, HEIF, AVIF. I bet JPEG XL will finally be it !

In the specifics: WebP is pretty popular in my experience.

In general: I expect that eventually something else will win, even if it takes a long time. There's too much room for improvement for the ecosystem to fossilize just yet.

Post reply on HN