Announcement

Collapse
No announcement yet.

FFmpeg's VP9 Decoder Is Much Faster Thanks To GSoC 2017

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

  • #11
    Originally posted by uid313 View Post

    WebM is a video container format for the web which you can reference in HTML code using the <video> element tag.
    The WebM video container format can contain the VP9 codec.
    The VP9 decoder unless it uses Rust to make it safe could be exploitable if it has any bugs which could be found using a fuzzer then embedding a malicious payload in the VP9 data that the decoder chokes on.
    The decoder has nothing to do with any of that. You're confusing it with the media player, which would read headers from the container and be compromised.

    Comment


    • #12
      Originally posted by arjan_intel View Post
      Is there going to be a PTS test for VP9 decode ?
      Should be pretty straightforward as already an ffmpeg test profile. Will see if I can find the time to do one this weekend.
      Michael Larabel
      https://www.michaellarabel.com/

      Comment


      • #13
        Originally posted by Gusar View Post
        No, it's the crappiness of libvpx. It's a terrible encoder, both speed and quality-wise. There's a better encoder out there, Netflix uses it, however it's a commercial product: https://www.twoorioles.com/eve-for-vp9/
        Yes, I did notice some quality issues. Did some PSNR and SSIM tests and libvpx scores very high in these tests, and yet it looks subjectively worse than HEVC (x265), and sometimes even worse than x264.

        Comment


        • #14
          Originally posted by Brisse View Post
          Did some PSNR and SSIM tests and libvpx scores very high in these tests, and yet it looks subjectively worse than HEVC (x265), and sometimes even worse than x264.
          That's because PSNR and SSIM have no correlation whatsoever to visual quality. Netflix's VMAF is supposedly better in this regard, however I wouldn't trust even that one. The only thing that can be trusted is your eyes.

          The absolute worst thing an encoder can do is optimize for PSNR and/or SSIM. x264 actually has switches to optimize for them. You know what these switches ("--tune psnr" and and "--tune ssim") do? They turn off all options that make the encoding look good! Really. "--tune ssim" disables all psycho-visual optimizations, "--tune psnr" in addition also disables adaptive quantization. With these options off, the metric scores are much higher, but the video itself looks like crap. PSNR in particular favors a blurry image, while the human eye will favor a sharper picture even if it's slightly distorted.

          Tuning for metrics is good only for pretty graphs to put on presentation slides. But when I'm looking at videos, I'm looking at, you know, the video! And not pretty graphs. So the only tuning that *really* matters is x264's "--tune film" (or "--tune animation" if you're encoding cartoons).
          Last edited by Gusar; 08 September 2017, 10:49 AM.

          Comment


          • #15
            Originally posted by uid313 View Post

            WebM is a video container format for the web which you can reference in HTML code using the <video> element tag.
            The WebM video container format can contain the VP9 codec.
            The VP9 decoder unless it uses Rust to make it safe could be exploitable if it has any bugs which could be found using a fuzzer then embedding a malicious payload in the VP9 data that the decoder chokes on.
            It seems to me that the optimized parts use AVX machine code and not any programming language. Using Rust or even C would only make it slow.

            A fuzzer would be a good idea as well as manual inspection of the code.

            Comment


            • #16
              Originally posted by Azrael5 View Post
              When will it be implemented on linux distros ? AVX instructions are obligatory or also properly video cards can manage it?
              The code is already in the ffmpeg git repository and since June/July I believe.

              It then depends on how fresh your Linux distro is. The new VP9 code will likely become part of the next major release of ffmpeg, which looks to be version 3.4 (currently latest version is 3.3.3). So if your distro already ships recent snapshots of 3.4 then you might already have it. But if not then you'll have to wait for 3.4.

              Comment


              • #17
                In case anyone wonders what tiles are, Wikipedia has a great illustration:




                VP9 allows parallelism in frames and tile columns. The number of tile columns depends on resolution (shown: 720p). AV1 will additionally have optional parallelism in tile rows – a big win for multithreaded encoding.
                Last edited by andreano; 08 September 2017, 02:41 PM.

                Comment


                • #18
                  Originally posted by starshipeleven View Post
                  Ok, so in your other post you wanted to write "but does it use Rust?" in the first sentence.
                  Once I read "use rust" in his post I rolled my eyes so hard I went dizzy.

                  Comment


                  • #19
                    Originally posted by uid313
                    Use Rust
                    Applies equally well to all other software decoders ever (yes you can write inline assembly in Rust too). Such as, if you prefer, OpenH264, which is what Firefox uses on any non-VP9 video site.
                    Last edited by andreano; 08 September 2017, 03:13 PM.

                    Comment


                    • #20
                      Originally posted by labyrinth153 View Post
                      Once I read "use rust" in his post I rolled my eyes so hard I went dizzy.
                      You probably thought that when his English isn't as good as yours then he has got to be dumber than you.

                      Comment

                      Working...
                      X