Announcement

Collapse
No announcement yet.

Intel's Open-Source VP9 Video Encoder Just Scored A Massive ~3x Performance Boost

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

  • Intel's Open-Source VP9 Video Encoder Just Scored A Massive ~3x Performance Boost

    Phoronix: Intel's Open-Source VP9 Video Encoder Just Scored A Massive ~3x Performance Boost

    Intel's open-source team continues showing the power of optimizations... Or rather in this case, a three fold performance improvement due to previously limiting an AVX-512 routine that also works on AVX-2 CPUs. SVT-VP9 is now a lot faster on AVX2 CPUs from both Intel and AMD...

    http://www.phoronix.com/scan.php?pag...-3x-AVX2-Boost

  • #2
    Does it trade quality off or not?

    Comment


    • #3
      Originally posted by tildearrow View Post
      Does it trade quality off or not?
      Hadn't noticed any quality issues on past AVX_512 encodes so wouldn't imagine so, but will try to work on a test for that in the next comparison (PTS does support doing image quality comparisons as long as the 'result' can be expressed consistently for parsing).
      Michael Larabel
      http://www.michaellarabel.com/

      Comment


      • #4
        Originally posted by Michael View Post

        Hadn't noticed any quality issues on past AVX_512 encodes so wouldn't imagine so, but will try to work on a test for that in the next comparison (PTS does support doing image quality comparisons as long as the 'result' can be expressed consistently for parsing).
        Maybe you can compare the output images between versions, as done in FifoCI. Here is an example:

        Comment


        • #5
          Originally posted by tildearrow View Post

          Maybe you can compare the output images between versions, as done in FifoCI. Here is an example:

          It's somewhat similar to how PTS is capable of. Here is a 10 year old example - https://www.phoronix.com/scan.php?pa...nvik_iqc&num=1 - I did have some better examples of outlining the changed pixels but can't seem to find that example article at the moment. Those capabilities are in place but a matter of reliably being able to query the same frame/output, etc.
          Michael Larabel
          http://www.michaellarabel.com/

          Comment


          • #6
            SSIM/VMF normalized encodes would be an interesting thing to do, not sure exactly how that could be accomplished, worth talking to the SVT folks about it.

            Comment


            • #7
              Originally posted by tildearrow View Post
              Does it trade quality off or not?
              Just enabling the AVX2 codepath presumably doesn't. But whether the SVT encoder in general does versus other encoders is a good question.
              Last edited by smitty3268; 09-09-2019, 03:58 AM.

              Comment


              • #8
                I just spent a good chunk of the night messing with the svt encoders to determine the "quality" aspect myself, and I have good news and bad news...

                The good news is the quality of the vp9 encoder is quite good, maybe a little better than libvpx at the same speed (I'm mostly interested in real-time encoding)

                The bad news is that the encoder (ffmpeg plugin) is extremely picky. I was able to make a pkgbuild after many hours of experimenting with the existing ones and finding them lacking (segfaults and such).. I'm able to encode to an IVF container (no audio), but sometimes it doesn't work, sometimes it does.. sometimes I can encode audio/video into a .nut container and it looks fantastic, and other times it has a persistent jerkiness to it every half second... If the video portion actually outputs at all.

                MKV and webm are both broken, they know about the problem with webm but didn't seem like they had any intention to fix it (their stance seemed to be that it works in .IVF so it's not their problem)

                It's coming along nicely, and definitely not a trade-off compared to libvpx, unless you count it actually working reliably as a downside.... But the visual quality is definitely there, and the speed is much better than libvpx. I finally got to see a vp9 encoder use more than 50ish % of my 2700, it maxes it out.

                Will love to see more patches to this to make it much more useable with ffmpeg, though... A total train wreck currently in that department.

                Comment


                • #9
                  gpu compute is much more powerful than avx2 or avx512
                  so what's wrong with gpu vp9 encoding?

                  Comment


                  • #10
                    Originally posted by pal666 View Post
                    gpu compute is much more powerful than avx2 or avx512
                    so what's wrong with gpu vp9 encoding?
                    Making the best decisions on how to pack things the best way is an almost entirely serial process. Gpu encoding would need severe restrictions (directly affecting quality) to not end up slower than a cpu encode.
                    It could help in alot of preprocessing, but likely going back and forth between (multiple) cpu cores and gpu adds alot latency and overhead.

                    Comment

                    Working...
                    X