The DAV1D AV1 Video Decoder Has Become Very Fast

[microcode]

I think being able to encode a full-length, 1080-lines movie within 24h on ordinary hardware would be a huge progress. At the moment it would take considerably longer than 1 MONTH.

Well, quit complaining and get to work. Just because your specific use case is not practical yet, doesn't mean decoder work is not already useful.

[NiLSPACE]

It seems rav1e also became really fast: https://github.com/xiph/rav1e/commit...76265bc570f0c1

[shmerl]

It seems rav1e also became really fast: https://github.com/xiph/rav1e/commit...76265bc570f0c1

Interesting, and it's written in Rust!

[Spazturtle]

I think being able to encode a full-length, 1080-lines movie within 24h on ordinary hardware would be a huge progress. At the moment it would take considerably longer than 1 MONTH.

The issue is that it isn't very good at parallel encoding 1 video, but if you encode 30 full length movies it will still take 1 month and then you have reached your rate of 1 video per 24h. That is why Google don't give a shit about speeding it up, for them it is already as fast as it will ever be.

[hajj_3]

As far as watching YouTube goes, that's true. BTW you basically are getting it already. Chromium/Chrome already supports AV1

chrome uses AOM decoder not this faster Dav1d encoder so decoding will be slow in chrome compared to firefox 65.

Maybe Microsoft could ship it as well, if they don't have their own software decoder ready.

Microsoft already have an AV1 decoder: https://www.microsoft.com/en-gb/p/av...otverviewtab

[uid313]

But is Dav1d written in Rust?
rav1e is written in Rust.

As far as watching YouTube goes, that's true. BTW you basically are getting it already. Chromium/Chrome already supports AV1, I think (not sure about Firefox, maybe the nightly builds?) and recent VLC builds have full decoding support built-in.

But I also want to be able to re-encode my movies to minimise storage space, same thing for personal videos etc. For all that, AV1 is still the distant future.

https://caniuse.com/#feat=av1

[Creak]

The issue is that it isn't very good at parallel encoding 1 video, but if you encode 30 full length movies it will still take 1 month and then you have reached your rate of 1 video per 24h. That is why Google don't give a shit about speeding it up, for them it is already as fast as it will ever be.

I don't think that is true. Indeed, if you have a whole datacenter to encode videos, encoding is faster than with just a single rig. But the faster the encoder is, the more videos can be encoded at the same time, while consuming less energy, which is also a big concern for Google. And datacenters are rarely just for one task, so by speeding up the encoder, it would give more time to other tasks.

Also, about the article, I don't think it's actual assembly code, but more like SIMD intrinsics, which are more portable and maintainable than assembly code.

[TemplarGR]

What about AVX "1" support? The announcement only talks about AVX2 and SSE. No AVX optimizations?

[oibaf]

What about AVX "1" support? The announcement only talks about AVX2 and SSE. No AVX optimizations?

If you have a AVX CPU you still have SSSE3, for which support is in development: https://code.videolan.org/videolan/d...e_requests/320

[Spazturtle]

I don't think that is true. Indeed, if you have a whole datacenter to encode videos, encoding is faster than with just a single rig. But the faster the encoder is, the more videos can be encoded at the same time, while consuming less energy, which is also a big concern for Google. And datacenters are rarely just for one task, so by speeding up the encoder, it would give more time to other tasks.

Lets break performance down into 2 parts, performance per thread and the number of threads it can use.

Google only care about the first part because they are always encoding multiple videos in parallel. Home users care more about the 2nd part, because they are usually encoding 1 video at a time.

If the encoder can encode 10FPS per thread but can only use 1 thread, and improving that to 12FPS takes the same amount of work at making the encoder use up to 4 threads, Google will chose to improve the FPS per thread instead of increasing the total number of threads it can use. So both Google and home users see a 20% improvement, whilst it the thread count had been improved Google would have seen no improvement and home users would have seen a 300% improvement.