DAV1D vs. LIBGAV1 Performance - Benchmarking Google's New AV1 Video Decoder

[coder]

Without comparing the output quality the FPS measure is meaningless.

Are they comparable? One could balance more quality for less speed which great.

The output is fully specified by the standard. There should be no difference. Any changes introduced during decoding will accumulate and lead to picture corruption.

That said, of course you can do post-processing. However, I don't expect that should be built into the decoder libraries - and certainly not enabled by default.

Please also compare some output frames.

It wouldn't hurt, though all you'd be doing is basically checking for bugs.

Now, encoding quality is a different matter, entirely.

[bug77]

I opened this thinking "who cares about decoders, encoders is where it's at". But when a decoder can't push 24 or 30 fps, wow! Just wow!

[coder]

I opened this thinking "who cares about decoders, encoders is where it's at". But when a decoder can't push 24 or 30 fps, wow! Just wow!

The thing is: it doesn't matter how fast a decoder is, until it's functional enough to completely and correctly decode the input. So, as long as they architected it to eventually deliver good performance, the optimizations can come later.

It's a lot harder to end up with a good result, if you start with something that's fast, but buggy, poorly-structured, and full of holes.

Keep in mind that if their decoder isn't well-threaded and doesn't yet use SIMD, they might have an easy order of magnitude of speedups in store.

[tildearrow]

I, for one, welcome increased "competition" in the space since I think different projects using different approaches can challenge as well as teach. I wonder what inspired Google to invest engineers' time into this. At first I thought it may be licensing, but dav1d is BSD licensed (not copyleft, business-friendly). Maybe Google just has engineers who think they can do better than dav1d and what we've seen so far all foundational.

But what if they just contri-

Competition works for a product made by a company, or for pricing, but for open source? They should've contributed into dav1d instead. See ffmpeg vs libav. What's the point?

Nooooo, you beat me

[microcode]

Without comparing the output quality the FPS measure is meaningless.
Are they comparable? One could balance more quality for less speed which great.

Please also compare some output frames.

...? Output quality, at least in software, is basically standardized for AV1 decoders.

[latalante]

Competition works for a product made by a company, or for pricing, but for open source? They should've contributed into dav1d instead. See ffmpeg vs libav. What's the point?

For sure? If there is no competition, why do you speak about it?

For what reason the day after the decoder code whose is made public (git log contains 3 commits), it is compared with a product that has existed for over a year, with the number of commits exceeding 1000. Why?

[NateHubbard]

For what reason the day after the decoder code whose is made public (git log contains 3 commits), it is compared with a product that has existed for over a year, with the number of commits exceeding 1000. Why?

So a brand new thing is out there, and you just want to ignore it? I assume all of us, including Michael, wanted to know what it brought to the table and that's why we read this article.
I'm expecting there will be a followup article eventually showing improvement. Perhaps more than one article.

[pyler]

And I dont think google compiles this new av1 decoder with gcc.. Probably they have fast path for clang only..

[geearf]

So a brand new thing is out there, and you just want to ignore it? I assume all of us, including Michael, wanted to know what it brought to the table and that's why we read this article.

What did you expect it to bring to the table so early? Even more when it says it's currently optimized only for Android and it's not being tested that way...

[NateHubbard]

What did you expect it to bring to the table so early? Even more when it says it's currently optimized only for Android and it's not being tested that way...

I guess I wouldn't know unless someone tested it. Since Michael did, now I don't have to.