Announcement

Collapse
No announcement yet.

RAV1E: The "Fastest & Safest" AV1 Encoder

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

  • RAV1E: The "Fastest & Safest" AV1 Encoder

    Phoronix: RAV1E: The "Fastest & Safest" AV1 Encoder

    Following the news about VP9 and AV1 having more room to improve particularly for alternative architectures like POWER and ARM, a Phoronix reader pointed out an effort that Mozilla is behind on developing the "rav1e" encoder...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Why is encoding VP9/AV1 too slow, besides lack of optimizations? Is the algorithm too complex or what?

    Comment


    • #3
      Originally posted by tildearrow View Post
      Why is encoding VP9/AV1 too slow, besides lack of optimizations? Is the algorithm too complex or what?
      Reference encoders for h264 and hevc are also unusably slow, it's not their point to be fast, they're meant to validate the standard (the priority is correctness). It took x264 and x265 years of writing assembly code to become as fast as they are. In this case, libaom is the reference and rav1e has just started.

      This doesn't explain why vp9 encoding with libvpx is so slow, as it's been around for years and is meant as an end-user encoder as well as being the reference. The answer is, It's about priorities - vp9 was for a very long time used only for youtube, and Google can afford to encode several videos in parallel, which is very different from a home user who typically encodes videos one at a time. So libvpx is just plain bad at threading because Google simply didn't care.
      Last edited by Gusar; 15 July 2018, 03:32 AM.

      Comment


      • #4

        Is it google not caring or rather Google and the entire industry moving on? My impression is that Google moved on when the industry got on board with the idea of an open standard.
        Originally posted by Gusar View Post
        Reference encoders for h264 and hevc are also unusably slow, it's not their point to be fast, they're meant to validate the standard (the priority is correctness). It took x264 and x265 years of writing assembly code to become as fast as they are. In this case, libaom is the reference and rav1e has just started.

        This doesn't explain why vp9 encoding with libvpx is so slow, as it's been around for years and is meant as an end-user encoder as well as being the reference. The answer is, It's about priorities - vp9 was for a very long time used only for youtube, and Google can afford to encode several videos in parallel, which is very different from a home user who typically encodes videos one at a time. So libvpx is just plain bad at threading because Google simply didn't care.

        Comment


        • #5
          Originally posted by wizard69 View Post
          Is it google not caring or rather Google and the entire industry moving on? My impression is that Google moved on when the industry got on board with the idea of an open standard.
          Also mine. Their VP10 project (successor of VP9) was the starting point of AV1

          Comment


          • #6
            Originally posted by Gusar View Post
            This doesn't explain why vp9 encoding with libvpx is so slow, as it's been around for years and is meant as an end-user encoder as well as being the reference. The answer is, It's about priorities - vp9 was for a very long time used only for youtube, and Google can afford to encode several videos in parallel, which is very different from a home user who typically encodes videos one at a time. So libvpx is just plain bad at threading because Google simply didn't care.
            Certainly, Google has it's own internal custom proprietary hardware specifically designed (by Google) in for parallelized encoding/decoding in real time and optimized for a minimum amount of energy or resource usage. And this independently by media stream standard.

            Comment


            • #7
              Originally posted by Gusar View Post
              So libvpx is just plain bad at threading because Google simply didn't care.
              Can confirm. I've tried VP8 and VP9 - and written them off as useless garbage. I tried very hard to make the encode use more than one core. And it turns out that after reading all the documentation and tuning it it's quite possible to make it use one and a half cores.

              The sad part is that given the speeds of VP9 encoding with one and a half threads it's .. potentially possibly not that slow. If we blindly assume that it by magic code could scale to the amount of cores on the system and run faster times the amount of system cores then it's be just fine. As it stands right now, though.. I'm not going to render a video in VP9 and wait two months for it to finish. AV1 will pretty much be dead to me too if it's situation remains similar.

              Comment


              • #8
                Originally posted by xiando View Post
                I've tried VP8 and VP9 - and written them off as useless garbage.
                As if encoding matters a whole lot for most people. Decoding is what's important. Just because some people lack patience or don't want to have them run overnight or in the background doesn't make them "useless garbage".

                Especially people who compromise quality for "encoding speed" truly piss me off. It's just like software compilation, there's still people who don't compile with every optimization on on release builds because "they want it done fast" and then have thousand or millions suffer with a worse quality (video or software, same thing) and have to decode/run worse shit because of impatience of a few people.

                Comment


                • #9
                  Originally posted by Weasel View Post
                  As if encoding matters a whole lot for most people. Decoding is what's important. Just because some people lack patience or don't want to have them run overnight or in the background doesn't make them "useless garbage".
                  Don't know what kind of videos you're making but if you're covering some news event then you'll film and get some good a and b roll before and a bit after lunch and then edit and encode and upload. "overnight" isn't an option. same applies if you're live-streaming, if you can't encode real-time with a codec then that codec's no good. vp9 doesn't work for either of those use-cases - thus it's useless.

                  Comment


                  • #10
                    Originally posted by xiando View Post
                    vp9 doesn't work for either of those use-cases - thus it's useless.
                    I can get libvpx-vp9 to encode 1080p@30fps in real-time on my Ryzen 1700X, but only barely, and with settings that compromise heavily on quality. libx264 is much better suited for this purpose though, and probably does like 80-90fps at similar quality. With decent quality settings vp9 falls down into single digit fps, like 2-3fps and only manages to load the cpu at about 25% which does make me a bit sad, but it's usable for short videos.

                    Edit: Software decoding performance is pretty good for vp9 though, which is nice.
                    Last edited by Brisse; 15 July 2018, 10:13 AM.

                    Comment

                    Working...
                    X