I thought this was about Dave2D
Dav2d
91–100 of 212 posts
Re: Dav2d
#92Earlier 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.
Re: Dav2d
#93Earlier 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.
Re: Dav2d
#94Earlier 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
Re: Dav2d
#95Sorry 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://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
#96Sorry 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 ?
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
#97Earlier 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…
Re: Dav2d
#98Re: Dav2d
#99I thought this was about Dave2D
Re: Dav2d
#100I thought this was about Dave2D