Earlier quoted context omitted.
Return of the 8MB Shrek encodes?
6MB should be enough for everyone!
Almost half of the file is audio, so you're not saving as much.
Dav2d
191–200 of 212 posts
Re: Dav2d
#192'AV2 decoding is roughly five times more complex than AV1 decoding. In practice, that means software running on today’s hardware will struggle to decode AV2 in real time without careful, architecture-specific optimization' AV1 software decoding is already very intensive so AV2 decoding benchmarks are the next thing that would be really interesting (or mortifying) to see.
> AV1 software decoding is already very intensive
I think you might be misunderestimating how incredible the dav1d AV1 decoder is. Not only does it require less total time than the reference decoder to decode the same video, but it can spread that out over far more threads. I was unable to watch 4k 60fps av1 video on my media center PC (it's from 2019, so predates hardware av1 decoding, and, well, the CPU was a little long in the tooth) until I switched to dav1d. With dav1d I am now able to watch 4k 60fps av1 using software decoding, and my machine uses 10% CPU while doing so. Really amazing piece of software.
With any luck, the dav2d 5x claim will hold true, and 10% CPU usage will scale to 50% CPU usage, meaning I'm still able to watch 4k 60fps video on my media center without a hardware upgrade. (that machine doesn't have hyperthreading, so 50% cpu is actually 50%, not 100% in a fancy suit)
Re: Dav2d
#193Earlier quoted context omitted.
> 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.
Show me the AV1, H.265, or even H.264 decoder that doesn't ultimately rely heavily on hand written assembly to achieve "fast enough". You can doubt all you like. Ultimately, there's a reason why dav1d includes hand coded SIMD for common platforms. It's simply impossible to get a compiler to emit something like this [1]. [1] https://github.com/videolan/dav1d/blob/master/src/x86/ipred_...
Is it simply impossible to get compiled code within a factor of five? That claim needs strong evidence.
More importantly, if you can show that your assembly code isn't altering pointers it shouldn't alter, and isn't going out of bounds on its reads, you're most of the way to having assembly in your verified safe code. And rough bounds checking with padding can as cheap as a bitmask.
Re: Dav2d
#194If 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.
I wouldn't want it myself, but, video games already do something like this - AI upscaling. Render the game at lower resolution / quality settings, then use AI to upscale and fill in the blanks.
This could work / works for video too, give it lower resolution / quality images and AI upscale. Its predecessor would calculate intermediate frames for example.
Re: Dav2d
#195What's next, Dav4d?
Dav67d
Re: Dav2d
#196Not to be confused with Da4vid (world-class hacker and owner of the Black sun) or D4vd (rap artist and alleged murderer)
Re: Dav2d
#197Earlier quoted context omitted.
Show me the AV1, H.265, or even H.264 decoder that doesn't ultimately rely heavily on hand written assembly to achieve "fast enough". You can doubt all you like. Ultimately, there's a reason why dav1d includes hand coded SIMD for common platforms. It's simply impossible to get a compiler to emit something like this [1]. [1] https://github.com/videolan/dav1d/blob/master/src/x86/ipred_...
Is it simply impossible to get compiled code within a factor of five ? That claim needs strong evidence. More importantly, if you can show that your assembly code isn't altering pointers it shouldn't alter, and isn't going out of bounds on its reads, you're most of the way to having assembly in your verified safe code. And rough bounds checking with padding can as cheap as a bitmask.
> Is it simply impossible to get compiled code within a factor of five? That claim needs strong evidence.
1. I didn't make that claim.
2. A negative assertion doesn't require evidence. If I say "this is impossible to do" the burden to disprove me is showing it's actually possible. You can't prove a negative. For example, if I say "the tooth fairy doesn't exist" I don't need to provide evidence of the tooth fairy's non-existence. If you disagree, you need to provide evidence to the contrary.
Re: Dav2d
#198Earlier quoted context omitted.
Is it simply impossible to get compiled code within a factor of five ? That claim needs strong evidence. More importantly, if you can show that your assembly code isn't altering pointers it shouldn't alter, and isn't going out of bounds on its reads, you're most of the way to having assembly in your verified safe code. And rough bounds checking with padding can as cheap as a bitmask.
> Is it simply impossible to get compiled code within a factor of five? That claim needs strong evidence. 1. I didn't make that claim. 2. A negative assertion doesn't require evidence. If I say "this is impossible to do" the burden to disprove me is showing it's actually possible. You can't prove a negative. For example, if I say "the tooth fairy doesn't exist" I don't need to provide evidence of the tooth fairy's no…
> 1. I didn't make that claim.
Then you didn't read my previous comment correctly. AV2 must be "fast enough" if the designers aren't crazy. And AV2 is 5x slower than AV1. Therefore if compiled code is within a factor of five of hand-written assembly, it's "fast enough" for AV1, and h.264, and probably h.265 too.
You were disagreeing with my claim that other codecs could be "fast enough" with a safe compiler, right? If you weren't disagreeing, I don't know why you challenged me to show you some particular kind of code.
> 2. A negative assertion doesn't require evidence. If I say "this is impossible to do" the burden to disprove me is showing it's actually possible. You can't prove a negative. For example, if I say "the tooth fairy doesn't exist" I don't need to provide evidence of the tooth fairy's non-existence. If you disagree, you need to provide evidence to the contrary.
You're saying it's "simply impossible" for a compiler to optimize instructions to a certain level. But anything one person can code, another person can teach a compiler to do in similar situations. I don't need to show you an example, I just need to point you at the Church-Turing thesis and related documents.
Re: Dav2d
#199Earlier quoted context omitted.
6MB should be enough for everyone!
Almost half of the file is audio, so you're not saving as much.
Hopefully audio codecs will progress as well.
I noticed that too. When I tried extreme screen recording compression with AV1 audio became a noticeable part of the bottleneck.
Re: Dav2d
#200'AV2 decoding is roughly five times more complex than AV1 decoding. In practice, that means software running on today’s hardware will struggle to decode AV2 in real time without careful, architecture-specific optimization' AV1 software decoding is already very intensive so AV2 decoding benchmarks are the next thing that would be really interesting (or mortifying) to see.
> AV1 software decoding is already very intensive I think you might be misunderestimating how incredible the dav1d AV1 decoder is. Not only does it require less total time than the reference decoder to decode the same video, but it can spread that out over far more threads. I was unable to watch 4k 60fps av1 video on my media center PC (it's from 2019, so predates hardware av1 decoding, and, well, the CPU was a littl…
dav2d author here - the 5x number is just where we currently are, it's not the theoretical limit. We're hopeful that a significant amount of the increase we observe in dav2d relative to dav1d is in math code, which should be easier to optimize using hand-written assembly or other algorithmic optimizations. If that holds true, the practical slowdown once everything has been optimized may be substantially less, possibly 2x.