Announcement

Collapse
No announcement yet.

How VP9 Video Encode/Decode Compares To H.264/H.265

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

  • How VP9 Video Encode/Decode Compares To H.264/H.265

    Phoronix: How VP9 Video Encode/Decode Compares To H.264/H.265

    If you're curious how the open-source VP9 codec performs for video encoding and decoding comparing to H.264 and H.265/HEVC, there's some interesting numbers out this weekend...

    http://www.phoronix.com/scan.php?pag...H264-H265-Perf

  • #2
    What's the status on VP10, Daala, and Thor?

    Also, FFVP9 seems impressively fast.

    Comment


    • #3
      VP10, Daala and Thor are still in development, Daala and Thor are candidates for NETVC.

      Google (VPx), Mozilla (Daala) and Cisco (Thor) are all members of the new Alliance for Open Media, so it is possible that VP10, Daala and Thor might end up merging into one codec.

      Comment


      • #4
        IIRC, VP9 and HEVC have been designed so that they can be parallized easier/better. Those speed tests were made with a single core, so the new codecs would probably compare better if you'd give them more cores.

        Comment


        • #5
          Not sure whether h264 HW acceleration has been disabled.

          @jf33: he did try that (by the end of the article) to figure out how these implementations scale. By knowing how they scale and how they perform in a mono-core setup you get results easier to generalise. They are also far more interesting.

          Comment


          • #6
            Originally posted by peppercats View Post
            What's the status on VP10, Daala, and Thor?
            VP10 presentation: https://www.youtube.com/watch?v=gkz1ZvejmEc
            Daala presentation: https://www.youtube.com/watch?v=g7fVwIZBW8Q
            Thor presentation: https://www.youtube.com/watch?v=g6m_N3QlqOI

            All presentations are from the recent VideoLAN Developer Days. Daala is coming along nicely, but is at the same time quite far away, finalization is planned for May 2017. Thor isn't meant to ever be complete, it's meant as a test bed for features that'll eventually make NetVC and/or the Alliance codec (Daala has already been stealing Thor features). VP10 is still basically about figuring out new features.

            Originally posted by peppercats View Post
            Also, FFVP9 seems impressively fast.
            That's because Ronald has been optimizing the hell out of it. The power of assembly and someone who can wield that power (I really admire people who know how to write assembly). Also, the power of SSE2/(S)SSE3/AVX/AVX2

            Comment


            • #7
              Originally posted by jf33 View Post
              IIRC, VP9 and HEVC have been designed so that they can be parallized easier/better. Those speed tests were made with a single core, so the new codecs would probably compare better if you'd give them more cores.
              If you're talking about encoding here, they'd actually compare worse. At least libvpx would, because it only has crappy tile-based multithreading, while x264 and x265 have much more efficient frame-based multithreading. The "designed for better parallelization" stuff refers to decoding actually, in particular about dedicated hardware decoders.

              Comment


              • #8
                Yeah, VP9 software decode performance is great, but that doesn't help if the encoder is so slow that you can't encode video for it in reasonable time. The libvpx VP9 encoder is easily an order of magnitude slower than x264 when using a single core and multicore scaling is a (stale) joke. It's so bad that using VP9 easily becomes impractical.

                Comment


                • #9
                  Originally posted by Gusar View Post
                  VP10 presentation: https://www.youtube.com/watch?v=gkz1ZvejmEc
                  Daala presentation: https://www.youtube.com/watch?v=g7fVwIZBW8Q
                  Thor presentation: https://www.youtube.com/watch?v=g6m_N3QlqOI

                  All presentations are from the recent VideoLAN Developer Days. Daala is coming along nicely, but is at the same time quite far away, finalization is planned for May 2017. Thor isn't meant to ever be complete, it's meant as a test bed for features that'll eventually make NetVC and/or the Alliance codec (Daala has already been stealing Thor features). VP10 is still basically about figuring out new features.


                  That's because Ronald has been optimizing the hell out of it. The power of assembly and someone who can wield that power (I really admire people who know how to write assembly). Also, the power of SSE2/(S)SSE3/AVX/AVX2
                  I assume that ffvp9 is only optimized for x86 SIMD, and not for ARM NEON yet. Any chance that Google or Mozilla use ffmeg instead of libvpx?
                  Or does Google plan to improve libvpx for Android and Chrome to put them on par with ffmeg?
                  Last edited by newwen; 28 September 2015, 06:13 AM.

                  Comment


                  • #10
                    Originally posted by brent View Post
                    The libvpx VP9 encoder is easily an order of magnitude slower than x264 when using a single core and multicore scaling is a (stale) joke. It's so bad that using VP9 easily becomes impractical.
                    Which is a shame really. A better vp9 encoder, one with frame-based multithreading and a focus on visual quality rather than SSIM (which is a really bad measure of visual quality) would really be something. But as it is, vp9 will not see usage beyond youtube.


                    Originally posted by newwen View Post
                    I assume that ffvp9 is only optimized for x86 SIMD, and not for ARM NEON yet. Any chance that Google or Mozilla use ffmeg instead of libvpx
                    Or does Google plan to improve libvpx for Android and Chrome to put them on par with ffmeg?
                    That's a good question about ARM Neon. Ronald's focus has indeed been x86(-64). On Android the goal is to use hardware decoders anyway. I'm currently aware of one phone having a hardware vp9 decoder, the Galaxy S6, though more phones are for sure coming.

                    When it comes to desktop browsers, at least on Linux, both Firefox and Chrome use ffmpeg only for h264 decoding, vp9 is decoded with libvpx. Not really sure why that is. On Windows, Firefox (and likely Chrome too) uses dxva2 for hardware h264 decoding. If hardware isn't available, Chrome uses ffmpeg while Firefox uses Microsoft's decoder.


                    Edit: There's a slide in Ronald's presentation saying there are indeed no Neon optimizations in ffvp9. And AVX2 optimization is still missing in some places, so the x86 decoder can become even faster than it already is.
                    Last edited by Gusar; 28 September 2015, 08:34 AM.

                    Comment

                    Working...
                    X