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

Dav2d

jbkempf.com

Post reply on HN
Print view View original

151–160 of 212 posts

Re: Dav2d

#151

Post by Dylan16807 »

avaer wrote: post #150

If decode is becoming so complicated and expensive the hardware can't handle it, why not just go full neural, send latents, and run decode on tensor cores? The answer is probably the same as for why not AV2 everything; a lot of hardware couldn't support it today. But in 10 years? It seems we're running up against fundamental limits of human-engineered video codecs at this point. There might be a lesson in there.

What makes you think that would use less resources?

And it's not really hardware hitting limits, it's specifically software decoding on somewhat weaker machines.

Re: Dav2d

#152

Post by itishappy »

avaer wrote: post #150

If decode is becoming so complicated and expensive the hardware can't handle it, why not just go full neural, send latents, and run decode on tensor cores? The answer is probably the same as for why not AV2 everything; a lot of hardware couldn't support it today. But in 10 years? It seems we're running up against fundamental limits of human-engineered video codecs at this point. There might be a lesson in there.

This is a software decoder designed to run on general purpose hardware.

Adding custom hardware like tensor cores to the stack would serves a different use case.

Re: Dav2d

#153

Post by Dylan16807 »

cogman10 wrote: post #131
dcsommer wrote: post #128

Earlier quoted context omitted.

Codecs are difficult and expensive to develop. Therefore they get reused in many contexts, including security critical ones. Sandboxing is shown over and over to not be a great security solution, so what this means in practice is that security-critical software that needs software decoding get pwned because software engineers don't care to prioritize it in the first place. Why shouldn't safety be the default? If you…

> Why shouldn't safety be the default? Because safe code isn't fast enough to decode live video. > If you really want to, it wouldn't be too hard to maintain a patch on top of rustc to drop the bounds checks if you want to compile object files without them. Yeah, but then you are undermining safety in a critical way that does lead to security vulnerabilities (buffer overflow). And you are also now maintaining and req…

> Because safe code isn't fast enough to decode live video.

I strongly doubt that.

And if any implementation of AV2 can be "fast enough", then there should be no question at all that we can write "fast enough" safe decoders for every other codec. Absolutely no way safe code is inherently that much slower.

Re: Dav2d

#154

Post by itishappy »

cesarb wrote: post #116
jbk wrote: post #16

Earlier quoted context omitted.

Because it's 5 times more complex, you need to get the maximum performance available. Therefore more ASM than ever. Rust does not bring more performance. Just more safety.

> Rust does not bring more performance. Just more safety. Though more safety can in some cases bring a bit more performance. For instance, with Rust you can often avoid "defensive copies" of objects.

When writing a high performance video codec avoiding defensive copies of objects is something you want always, not just often.

C makes it easy to be fast but hard to be safe. Rust makes it easy to be safe but hard to be fast.

Also note that video codecs tend to wrap C or Rust around handcrafted ASM. Performance is king.

Re: Dav2d

#155

Post by reactordev »

BetterThanSober wrote: post #80
kaka314 wrote: post #66

Earlier quoted context omitted.

Too much traffic from HN? ``` Too Many Requests The page you have tried to access is not available because the owner of the file you are trying to access has exceeded our short term bandwidth limits. Please try again shortly. Details: Actioning this file would cause "jbkempf.com//blog/2026/dav2d/" to exceed the per-day file actions limit of 160000 actions, try again later ```

I don't know if I'm underestimating HN's reach but I doubt we did that, probably traffic from a much bigger aggregator/forum

The HN hug of death is real. If you aren’t prepared, it can set fire to your server room.

Re: Dav2d

#156

Post by avaer »

Dylan16807 wrote: post #151
avaer wrote: post #150

If decode is becoming so complicated and expensive the hardware can't handle it, why not just go full neural, send latents, and run decode on tensor cores? The answer is probably the same as for why not AV2 everything; a lot of hardware couldn't support it today. But in 10 years? It seems we're running up against fundamental limits of human-engineered video codecs at this point. There might be a lesson in there.

What makes you think that would use less resources? And it's not really hardware hitting limits, it's specifically software decoding on somewhat weaker machines.

It could help in the same way that running things in a shader uses less resources than running it on CPU. You're flattening the pipeline, and you can optimize better with simpler primitives and less branches.

Re: Dav2d

#157

Post by avaer »

itishappy wrote: post #152
avaer wrote: post #150

If decode is becoming so complicated and expensive the hardware can't handle it, why not just go full neural, send latents, and run decode on tensor cores? The answer is probably the same as for why not AV2 everything; a lot of hardware couldn't support it today. But in 10 years? It seems we're running up against fundamental limits of human-engineered video codecs at this point. There might be a lesson in there.

This is a software decoder designed to run on general purpose hardware. Adding custom hardware like tensor cores to the stack would serves a different use case.

Right, I'm sure it's way faster in specialized hardware.

What I'm saying is the performance problem is a "code smell". The algorithms are getting so complicated that perhaps we are approaching fundamental limits of heuristiccs; we might get better + faster results ditching "smart" algorithms and just learning the codec in a much higher dimensional space.

Again specialized hardware, but a different approach to it.

Re: Dav2d

#158

Post by overfeed »

Ecco wrote: post #130
esposm03 wrote: post #127

Earlier quoted context omitted.

Yes. An uncompressed 1080p, 60fps video with 24-bit color depth would need around 3Gbps to be streamed. And even if you don't need to stream it, that would still consume a sizeable portion of the write throughput of the fastest SSDs currently available; if you go up to 4K, you'd actually exceed that by a lot (not to mention, 1tb of storage would last for about 10 minutes of video).

Using raw uncompressed bitrate is a bit disingenuous. How about comparing an older, widely supported codec like H.264 as a baseline?

> Using raw uncompressed bitrate is a bit disingenuous

It is not disingenuous given the context. Gp was responding to ggp's hypothetical:

>> Is there a compelling reason encoding needs to be done locally?

Re: Dav2d

#159

Post by Gigachad »

weiliddat wrote: post #49
breve wrote: post #40

Earlier quoted context omitted.

Hardly niche. My laptop isn't new and it has hardware AV1 decoding and encoding. My 10 year old iPhone 7 can play 1080p AV1 video in software for over 200 minutes with VLC. The iPhone 7 was released in 2016, a year and a half before AV1. The dav1d decoder is mighty. Netflix uses AV1: https://netflixtechblog.com/av1-now-powering-30-of-netflix-s... YouTube uses AV1. It's tough to be more mainstream than that. Right cli…

Supported is different from doing it well though. You do notice the performance hit even on TVs that playback YouTube videos on AV1. Even on 1080p videos running on AV1 on 1x, the TV system bogs down and any kind of interaction has a variable 1-3s lag. On some TVs if you do 1.25x the TV automatically "downgrades" the resolution to 480p to avoid dropping frames. I wish there was an option to still use VP9 / H.264 on t…

My TV lags out even when doing nothing. So I use it as a dumb panel and let another device handle the streaming and decoding. Also has the benefit of blocking LG from loading adverts all over the UI.

Re: Dav2d

#160

Post by Gigachad »

amiga386 wrote: post #117
pantalaimon wrote: post #113

I'm not quite convinced a 25% reduction in size is worth effectively obsoleting all devices that have hardware decoders for AV1 but will struggle to decode AV2

Modern video services perform multiple encodings with different codecs, bitrates and screen dimensions, and serve up the most appropriate format that the client device can decode. Youtube has hundreds of format variants: https://gist.github.com/MartinEesmaa/2f4b261cb90a47e9c41ba11... Devices with AV1 hardware decoding - rare as they are - won't be obsoleted for a long time.

Even devices that don't aren't becoming obsolete. My M1 macbook does not have a hardware decoder and youtube seems to choose AV1 whenever it's available. The software decoder does not noticeably warm the laptop.
Post reply on HN