Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by bug77 View Post
    I opened this thinking "who cares about decoders, encoders is where it's at".
    I care a lot. I hope that I will live to see times when encoders will be free from patents and license fees.

    The most interested are those under the MPEG LA sign (Cisco, Apple, M$) still doing everything not to lose their income from tribute from h264 and especially h265 (from every smartphone, multimedia device, cameras, etc.).

    That's why there is so much confusion here with every note about AV1.

    Comment


    • #32
      I would love to have seen rav1e included in the benchmark, it is written in Rust so should be a safer way to decode AV1. You wouldn't want the decoder to be vulnerable when parsing arbitrary random files from unknown and non-trusted sources.

      Comment


      • #33
        Originally posted by uid313 View Post
        I would love to have seen rav1e included in the benchmark, it is written in Rust so should be a safer way to decode AV1. You wouldn't want the decoder to be vulnerable when parsing arbitrary random files from unknown and non-trusted sources.
        At last check, rav1e wasn't even multi-threaded. And it's an encoder, compared to these dav1d/libgav1 benchmarks being DEcoding.
        Michael Larabel
        https://www.michaellarabel.com/

        Comment


        • #34
          Seeing the speed difference between 3600 and 3900, it's like there is zero gain from extra threads and just a slight bump from the frequency increase. And with the 9900k being top, this smells something like ...single threaded performance

          Comment


          • #35
            I would love to have seen rav1e included in the benchmark, it is written in Rust so should be a safer way to decode AV1. You wouldn't want the decoder to be vulnerable when parsing arbitrary random files from unknown and non-trusted sources.
            rav1e is an encoder.

            And even if it was a decoder, I'd prefer to be able to watch 4K60 AV1 video at full speed than slow-motion.
            Last edited by tildearrow; 06 October 2019, 12:42 PM.

            Comment


            • #36
              This is just Google's first public release. I wouldn't get all stirred up until they start putting CPU specific enhancements in it. AVX, VSX etc. Until then its a WIP.

              Comment


              • #37
                Competition is good, and I really like how AV1 has a much broader and more competitive software landscape, compared to VP9. However, libgav1 is so much behind that you have to wonder "what's the point?". Maybe it wasn't such a good idea to release it to the public so early.

                Comment


                • #38
                  Strange results when going from 1080p to 4k. For example, the Ryzen 5 3600X goes from 384 fps to 172 fps. But 4k is 4 times 1080p, not half.

                  Anyone have an idea why?

                  Comment


                  • #39
                    Originally posted by AndyChow View Post
                    Strange results when going from 1080p to 4k. For example, the Ryzen 5 3600X goes from 384 fps to 172 fps. But 4k is 4 times 1080p, not half.

                    Anyone have an idea why?
                    More independent blocks to process in parallel. You should measure effective cpu time (accumulated time spent on all cores), the more cores you throw at it, the more core time you are wasting.

                    Likely you will never decode 1080p video with more than 4 threads, if you care about efficiency. Otherwise you run into amdahls law.

                    Comment


                    • #40
                      Originally posted by coder View Post
                      Neither of those are nearly good enough for targeting ARMv7. I'd hazard a guess that they don't plan to support AV1 on it.

                      Anyway, thanks for the data. Now, it would be nice to see it on ARMv8 (anybody?). Too bad we can't use Pi v4 (at least, not on Raspbian, which still runs in ARMv7 mode).
                      https://code.videolan.org/videolan/dav1d/issues/215 If you look here dav1d on arm32 is not done Yet and if you look on the Merge requests it is Work in Progress

                      The relative speedup ranges from 2.5 to 3.8x for find_dir and around 5 to 10x for filter. The find_dir function is a bit restricted by barely...



                      Did try to compile libgav1 on my Odroid N2(arm64) on Manjaro but it does fail ...

                      Comment

                      Working...
                      X