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

171–180 of 229 posts

Re: H.264 is Magic (2016)

#171

Post by goeiedaggoeie »

xiphias2 wrote: post #148
planck01 wrote: post #112

Earlier quoted context omitted.

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.

Couldn’t they reuse the tensor cores that are shipped in every device at this point? There are already lots of papers on compressing images using deep learning, I don’t see any reason why the companies couldn’t make a video standard that relies on that hardware.

having a hardware encoder and decoder on a device is super useful for streaming content of that device. Not sure I would want to use other compute for that, that compute is much better used doing CV on the video stream :)

Re: H.264 is Magic (2016)

#172

Post by PoignardAzur »

Thoreandan wrote: post #158
chrisshroba wrote: post #135

Earlier quoted context omitted.

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

I'm... not sure what you mean about VLC? It started out as a student project, but now VideoLabs is a for-profit company, and there is a libVLC.

Re: H.264 is Magic (2016)

#173

Post by mgdlbp »

ollybee wrote: post #77

There was once a blog titled "Diary Of An x264 Developer" that gave some interesting detail of how h264 worked and the and the x264 implementation. It's still available on via the internet archive.

(https://web.archive.org/web/2012/http://x264dev.multimedia.c...)

Tied as the leading implementation by 2006, pulled far ahead in SSIM in 2010, and all FOSS. Hat off to Glaser and Merritt!

An interesting Baader–Meinhof for me when I first heard: Glaser (as Dark Shikari) used to be active on HN and wrote the quote (oft misattributed to Descartes),

  Any community that gets its laughs by pretending to be idiots will eventually be flooded by actual idiots who mistakenly believe that they're in good company.
regarding 4chan in 2009. (https://news.ycombinator.com/item?id=1012082)

If you frequently read older threads, get ready to start noticing the username!

Re: H.264 is Magic (2016)

#174

Post by knolan »

vagab0nd wrote: post #128
knolan wrote: post #127

Earlier quoted context omitted.

Can you provide a reference where one could get started with this?

It's been a long time. But I remember I started with this page [0]. There are also many resources on github, like [1] or [2], but I haven't tried them. 0: https://trac.ffmpeg.org/wiki/Debug/MacroblocksAndMotionVecto... 1: https://github.com/LukasBommes/mv-extractor 2: https://github.com/jishnujayakumar/MV-Tractus

Thank you!

Re: H.264 is Magic (2016)

#175

Post by joshspankit »

PaulDavisThe1st wrote: post #165
joshspankit wrote: post #41

Earlier quoted context omitted.

You don’t have to wonder: There have been many truly patent free codecs and the answer is mostly “Try to convince companies to adopt it even though they have a vested interest in using codecs they control” For example: FLAC

FLAC is actually much more widely supported than, for example, Vorbis.

FLAC was released in 2001 and widely popular by at least 2006.

With much fanfare, iOS11 (2017) was the first time iOS supported playing FLAC files and that was (and still is) not the Apple-branded “Music” app but only in the “Files” app.

Re: H.264 is Magic (2016)

#176

Post by CSSer »

brigade wrote: post #141
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?

I don't believe any platforms or browsers have enabled JPEG-XL support yet, so right now you'd need to ship the decoder yourself anyway. But, it's at least as much better than WebP as WebP was better than JPEG. And unlike HEIC, web browsers are considering supporting it, though AVIF is currently ahead of JPEG-XL in browser support. JPEG-XL also currently beats HEIC and AVIF at medium to high quality, but it's a fair…

> though AVIF is currently ahead of JPEG-XL in browser support.

It certainly looks like AVIF is ahead because it has landed in and Firefox and Chrome, but it's blocked in Safari by a required OS change[0] (iOS/macOS support if I understand the comment correctly?). Additionally, there's no implementation in Edge (even though it's chromium)[1]. Sorry, I wish I had more details but I'm not sure where to look to find a status update on that.

Meanwhile, JPEG-XL has support behind a feature in every major browser except Safari[2]. As you and others have noted, there seems to be a lot of buzz and excitement around JPEG-XL throughout the ecosystem. The webkit folks seem to be making an effort to get the ball rolling[3]. I might be misinterpreting something but it all looks very encouraging at any rate. It almost seems like it might gain wide support in Firefox and Chromium (Chrome & Edge) around the same time with Webkit following (hopefully) closely thereafter. Heck, I don't see why Webkit doesn't just abandon AVIF and focus on rolling out JPEG-XL.

[0]: https://bugs.webkit.org/show_bug.cgi?id=207750#c25

[1]: https://caniuse.com/avif

[2]: https://caniuse.com/jpegxl

[3]: https://bugs.webkit.org/show_bug.cgi?id=233364

Re: H.264 is Magic (2016)

#177

Post by xiphias2 »

goeiedaggoeie wrote: post #171
xiphias2 wrote: post #148

Earlier quoted context omitted.

Couldn’t they reuse the tensor cores that are shipped in every device at this point? There are already lots of papers on compressing images using deep learning, I don’t see any reason why the companies couldn’t make a video standard that relies on that hardware.

having a hardware encoder and decoder on a device is super useful for streaming content of that device. Not sure I would want to use other compute for that, that compute is much better used doing CV on the video stream :)

Why do you think so? Those tensor processors are actually already optimized for video processing: all of the complex postprocessing in the iPhone camera app is done by the tensor cores inside the M1 chip. I wouldn't be suprised if it would already far be able outperform the mentioned codecs, but of course it needs lots of software development that can only be done by the big companies.

Re: H.264 is Magic (2016)

#178

Post by Teknoman117 »

xiphias2 wrote: post #177
goeiedaggoeie wrote: post #171

Earlier quoted context omitted.

having a hardware encoder and decoder on a device is super useful for streaming content of that device. Not sure I would want to use other compute for that, that compute is much better used doing CV on the video stream :)

Why do you think so? Those tensor processors are actually already optimized for video processing: all of the complex postprocessing in the iPhone camera app is done by the tensor cores inside the M1 chip. I wouldn't be suprised if it would already far be able outperform the mentioned codecs, but of course it needs lots of software development that can only be done by the big companies.

In something like a mobile device, every watt counts. If it takes more energy to decode video on the tensor cores than it does to have a dedicated hardware block, you keep the hardware video decoder.

Re: H.264 is Magic (2016)

#179

Post by Teknoman117 »

throw0101a wrote: post #42
ksec wrote: post #27

Earlier quoted context omitted.

The Broadcasting industry has definitely sided with VVC. So 8K broadcast will likely be using VVC along with possibly LCEVC [1] as announced by the Brazilian SBTVD standard. The AV1 question is harder to answer. One could argue VP9 is good enough and a few more years before it reach 100% VP9 hardware decoding on Smartphone. Of course Google could force the usage of AV1 in the future if they slowly phaseout VP9 video…

> Even to this day I still do not believe Apple will support AV1 decode, at least not until Google forced the AV1 usage. Even though they joined AOM four years ago: * https://venturebeat.com/2018/01/04/3-reasons-apple-just-join... * https://appleinsider.com/articles/18/01/04/apple-joins-allia... * https://bitmovin.com/apple-joins-av1-codec-consortium/ * https://www.streamingmedia.com/Articles/ReadArticle.aspx?Art...

They're also a member of Khronos which oversees things like OpenGL and Vulkan, but they deprecated the former and never implemented the latter.

Re: H.264 is Magic (2016)

#180

Post by bobsmooth »

donkarma wrote: post #95
jancsika wrote: post #57

> 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 obviously an oversimplification, but you've transformed some data into another shorter representation o…

It's curious because where do you draw the line between an algorithm that compresses information and an algorithm that just stores the inforamtion in the algorithm.

Kolmogorov complexity is a good place to start.
Post reply on HN