Live data from Hacker News

Dav2d

jbkempf.com

91–100 of 212 posts

Re: Dav2d

#92
post #60

Earlier quoted context omitted.

Intel's Arc dGPUs were really compelling for dedicated AV1 encode and decode, especially the small form factor of some cards. You could even fit it as a secondary card in a PC dedicated to recording and encode workflows for OBS. Hope we get a similar option with future lineups that support AV2, especially given how popular video creation and streaming are now.

Is there a compelling reason encoding needs to be done locally? The point of encoding is to reduce downstream bandwidth for the viewer, and upstream bandwidth for the distribution network. The content creator only needs to upload it once.

Video calls & streaming.

Re: Dav2d

#93
post #81

Earlier quoted context omitted.

What does "complexity" mean here? Computation required?

dav1d is the av1 decoder and it’s an insane feat of engineering. Written in assembly, it even eschews the normal c calling convention to get even better performance.

The normal C calling convention is really only for cross-binary calls (e.g. between shared libraries). If you're not doing that you can ignore it; it's not a weird thing to do. It would be odd to strictly follow it in assembly and I assume compilers don't either.

Re: Dav2d

#94

Earlier quoted context omitted.

The safety can be worth it in certain cases. Like when handling untrusted input. And it's not just Rust: look at WUFFS for example. WUFFS can actually rival handwritten implementations in certain cases.

but not these cases

I don't see why not. What makes you think this is unique?

Re: Dav2d

#95
post #7

Sorry if this sounds naive, but does it make sense to write a codec library in C/ASM considering how well Rust is progressing, especially when, as the author puts it, AV2 decoding is roughly five times more complex than AV1 decoding ?

I don't know why you've been down-voted. It definitely isn't an optimal decision. A video codec isn't all assembly. There's plenty of plain unsafe C code. E.g. this is the first random file I clicked. It has a ton of raw C pointer stuff just begging to be exploited.

https://code.videolan.org/videolan/dav2d/-/blob/main/src/dat...

There is a project to write an AV1 decoder in Rust: Rav1d (really stretching the name here).

https://github.com/memorysafety/rav1d

They got within 5% of the performance of dav1d and held a contest to close the gap but I think I read somewhere that this wasn't achieved.

https://www.memorysafety.org/blog/rav1d-perf-bounty/

They claimed

> This is enough of a difference to be a problem for potential adopters, and, frankly, it just bothers us.

But in my opinion nobody actually cares about 5% in absolute terms. It's likely just Rust naysayers using that as an excuse.

I think the likely reason for dav2d using C is that they can reuse lots of code and infrastructure from dav1d. But I agree it would be much better if they worked on Rav2d instead (these names!). You can hardly complain about a 5% overhead if you're opting in to 5x more decoding complexity.

Re: Dav2d

#96
post #7

Sorry if this sounds naive, but does it make sense to write a codec library in C/ASM considering how well Rust is progressing, especially when, as the author puts it, AV2 decoding is roughly five times more complex than AV1 decoding ?

https://youtu.be/nepKKz-MzFM&t=7195

If you can stand Lex Friedman for a bit, the VLC authors talk about why you use ASM for a video decoder instead of pure C or rust.

Re: Dav2d

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

More reason to never use the builtin stuff in a tv. Cheap sticks can handle decoding fine.
Post reply on HN