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

H.264 is Magic (2016)

sidbala.com

Post reply on HN
Print view View original

151–160 of 229 posts

Re: H.264 is Magic (2016)

#151

Post by jillboyce »

mihaic wrote: post #104
throw0101a wrote: post #3

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.

There is an open source AV1 encoder implementation available: https://github.com/AOMediaCodec/SVT-AV1

Re: H.264 is Magic (2016)

#152

Post by brigade »

AceJohnny2 wrote: post #134
astrange wrote: post #124

Earlier quoted context omitted.

JPEG2000 wasn't technically better enough; wavelets are too blurry and less efficient to decode. For some reason there was an epidemic of terrible codec designs for a decade or two, though it could've all been patent avoidance.

Wavelets were a great idea... except AFAIK we never figured out fast algorithms or hardware implementations to optimize processing them, the way we did with Fourier Transform and the FFT algorithm and IDCT blocks.

A lifting implementation of a wavelet is pretty low complexity, iirc the CDF 9/7 used in JPEG2000 was effectively a 5-tap filter. Implementation-wise, the biggest issue is that approximately no one bothered optimizing their memory access patters for CPU caches with anywhere near the same attention FFTs got. Then unlike block-based codecs, you basically need to store 16-bit coefficients for an entire frame for 8-bit pixels, instead of per-block.

But ultimately, DCTs make it way cheaper to encode similar but wrong details, where in wavelets details are effectively repeated across multiple highpass bands so the only cheap option is to not code detail.

Re: H.264 is Magic (2016)

#153

Post by HedgeGriffon »

brigade wrote: post #146
ibigb wrote: post #126

Earlier quoted context omitted.

A jpeg pixel is 64 (=8 x 8), 8 bit coefficients which are summed together for each pixel. That result is not 8 bits, but more; that is a misunderstanding, often repeated. A jpeg is capable of over 11 bits dynamic range. You can figure out that an 11 bit dynamic range image has more than 8 bits. See the wikipedia.

Alternatively, if you're being confused by the quoted intermediate DCT precision, that's not relevant to the final output either. You cannot implement any transform, DCT especially, without having intermediate values with a greater range than the input or output. Like, even a simple average of two 8-bit values (a+b)/2 has an intermediate range of 9 bits. The JPEG spec does specify both 8 and 12 bit sample precision f…

Libjpeg does have support for it. Unfortunately, you have to have two copies of the library, one for 8 bit and one for 12. And you have to rename all the API methods in one of the libraries so you dont get name collisions. I believe that LibTIFF has a build configuration for this so that 12bit JPEG data can be encapsulated in a TIFF file.

Re: H.264 is Magic (2016)

#154

Post by mkl »

Markoff wrote: post #94
lnanek2 wrote: post #88

Earlier quoted context omitted.

As a mobile developer I generally see WEBP getting served to Android devices and HEIC to Apple devices. Is there any advantage to JPEG XL over those? If our app supported older iOS devices, maybe JPEG would be needed as a fallback, but it seems like JPEG XL wouldn't be compatible with old devices anyway, right?

you can serve new devices with JPEG XL and convert it back to JPEG without loss on server for old devices

I think you might have that backwards. JPEG can be losslessly converted to JPEG XL with better compression (~20% smaller), but I haven't seen anything about going the other direction. I'm not sure how it would be possible with JPEG XL's different sized blocks and different available transforms. https://en.wikipedia.org/wiki/JPEG_XL

Re: H.264 is Magic (2016)

#155

Post by Paianni »

mihaic wrote: post #104
throw0101a wrote: post #3

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.

No, OS support for H.264 happened because the industry wanted more efficient codecs, and it didn't have much competition at the time. H.265 and AV1 are both competing to replace H.264 and so far neither have a clear lead.

Re: H.264 is Magic (2016)

#156

Post by LeoPanthera »

yboris wrote: 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/

Is this too late? iPhones are shooting in HEIF now, which means there's already millions of HEIF images in the world. Surely that is the de-facto next generation image standard.

Re: H.264 is Magic (2016)

#157

Post by kmeisthax »

Maakuth wrote: post #37
vetinari wrote: post #22

Earlier quoted context omitted.

Apple won't add it; they traditionally ignore free codecs, and even if they implement them, it is so limited, so it is usable only in the narrow situation, where it is required (see Opus, for example). On the PC side, decoding is supported by Intel (since Tiger Lake), Nvidia (since 30x0) and AMD (since RDNA2). On the mobile side, it is supported by bunch of mobile chip vendors, like Mediatek or Samsung; so you can ha…

Apple is even a governing member of the alliance behind AV1 ( https://en.wikipedia.org/wiki/Alliance_for_Open_Media ), so the case could be different than with previous free codecs.

Apple didn't care about free codecs before H.265 for the same reason ISO and Leonardo Chiariglione didn't: "the best codecs require big $$$ to research and competitive royalty-free codecs will stifle innovation by not sending money back to researchers"[0]. The ISO business model was to not care about patents as long as everyone agreed to charge FRAND rates, so they could just pick the best technology and rely on their creators' patent royalties to fund research. For Apple, they don't care about the cost, as long as the codec is suitable to implement in iPhones.

That business model broke once Velos Media and Access Advance realized they could game the system by offering a handful of net-implementer companies severely reduced patent rates if they agreed to license their patents or, better yet, pull out of MPEG-LA entirely. The end result is that companies have to license significant portions of H.265 multiple times from three different patent pools... and most people who are even remotely cost-sensitive just aren't bothering with it at all and are sticking with H.264 or moving to AV1.

Apple has yet to implement AV1 in hardware, which makes using the codec exclusively a non-starter as they have a very dim opinion of software decoders. I imagine they joined AOM to either hedge some bets or extract leverage from H.265/H.266 patent owners. The thing is that their business absolutely does not require the existence of a viable royalty-free codec, unlike Google's, which does. We'll know if Apple's actually decided to join the Free video party if they actually ship an AV1 decoder in their silicon.

[0] Leonardo is very vocally opposed to AOM's lack-of-a-business-model, see:

https://blog.chiariglione.org/a-crisis-the-causes-and-a-solu...

https://blog.chiariglione.org/a-future-without-mpeg/

https://blog.chiariglione.org/revisiting-the-patents-in-stan...

If you're wondering, he's the former chair of MPEG, before ISO decided to cut up MPEG into a bunch of different pieces and more or less left him without a job. He's salty about that too: https://blog.chiariglione.org/iso/

Re: H.264 is Magic (2016)

#158

Post by Thoreandan »

chrisshroba wrote: post #135
userbinator wrote: post #20

H.264 patents are not expiring yet, if anyone was wondering. 2027 seems to be when that happens. On the other hand, I believe H.263 patents already expired, and MPEG-4 ASP (DivX etc.) is expiring this year.

What does it mean for developers that it is patented?

You could write a complete from-scratch decoder, and be sued if you distribute it.

This is the case with MPEG-2 formats used in DVD Video, and the reason that the VLC Media Player exists as a French student research project distributed as source code instead of a normal library.

Related: https://www.gnu.org/philosophy/software-patents.en.html

Re: H.264 is Magic (2016)

#159

Post by jerich »

tzs wrote: post #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 maki…

For the first question, I ended up using this trick for a video editing app on Android phones about 10 years ago in order to cut video together on low end, out of date (Android 2.3) phones. They couldn’t handle video compression in a reasonable time and we didn’t want to upload/download to process on a server.

The point of the app was to sync the cuts to music cues, so each clip had a defined length. I ended up doing it all through file manipulation. You can cut into a video file starting at any arbitrary I-frame then trim it to the desired length. I would cut the input videos down to size then concatenate the files, replacing the audio with the new soundtrack at the end.

It worked great, only took a few seconds to create the final edit. Of course you couldn’t overlay text or filter video, but I still think it was a valid solution.

With the requirement of starting each clip on an I-frame, there was some imprecision in where your cut would actually start—an arteur might have a problem with their masterpiece being butchered that way, but it would certainly work well for some special cases like efficient distribution or being able to show a diff that a video was unaltered outside of timing cuts.

Re: H.264 is Magic (2016)

#160

Post by bumblebritches5 »

yboris wrote: 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/

No post body was provided.
Post reply on HN