Announcement

Collapse
No announcement yet.

Rav1e 0.5 Beta Released For This Rust-Written AV1 Encoder

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

  • Rav1e 0.5 Beta Released For This Rust-Written AV1 Encoder

    Phoronix: Rav1e 0.5 Beta Released For This Rust-Written AV1 Encoder

    Audio/video encoders and decoders are one of the areas where usage of the Rust programming language has increasing interest for speed and safety. One of the most promising Rust-written encoders at the moment is Rav1e for AV1 video encoding and it's now working towards its v0.5 release...

    https://www.phoronix.com/scan.php?pa...Rav1e-0.5-Beta

  • #2
    when it comes to performance we've generally found SVT-AV1 to be faster at this point in time.
    Is this still true if you consider FPS at given picture quality?

    Comment


    • #3
      Rust is really nice for decoders, interpreters, and parsers thanks to things such as Option<T>, Result<T, E>, and the match statement.

      But I am frustrated with Rust's lack of support for declaring async functions in traits and lack of async streams. 😢
      It makes it difficult to share code by creating a function that takes in either UnixListener or a TcpListener as argument, or a function that takes in either a UnixStream and TcpStream as argument.

      Comment


      • #4
        Originally posted by uid313 View Post

        But I am frustrated with Rust's lack of support for declaring async functions in traits and lack of async streams. 😢
        It makes it difficult to share code by creating a function that takes in either UnixListener or a TcpListener as argument, or a function that takes in either a UnixStream and TcpStream as argument.
        The former is being worked on, not sure about the latter since streams opens up a massive can of worms especially in a language like Rust that is strongly typed

        For those wondering how Rust programs can end up beating C equivalents, one of the things that Rust allows is fearless concurrency and memory safety. Although C theoretically speaking can be just as fast as Rust, due how terrible it is in handling concurrency as well memory safety issues a lot of people end up coding in a style that is very conservative/fearful due to how easy it is to make hard to track bugs.

        When you have a tool that mathematically validates data flow (which is what Rust's linear type system is essentially proving), you can go completely crazy adding in optimizations (such as multi threading) without needing to worry about race conditions and continue working on such codebases without fear of regressions.

        No Rust doesn't magically solve all logic bugs, but it makes a portion of them impossible which means you can spend the gained time/effort in other areas.

        Comment


        • #5
          Originally posted by uid313 View Post
          Rust is really nice for decoders, interpreters, and parsers thanks to things such as Option<T>, Result<T, E>, and the match statement.

          But I am frustrated with Rust's lack of support for declaring async functions in traits and lack of async streams. 😢
          It makes it difficult to share code by creating a function that takes in either UnixListener or a TcpListener as argument, or a function that takes in either a UnixStream and TcpStream as argument.
          Yes, no language offers all the constructs ever invented. And even if it did, you'd be complaining it takes ages to compile, right?

          To me, Rust was surprisingly productive, even if my background is not C or C++. It's not one of the languages that are not easy on the eyes though. Then again, the same was said about C code, back in the day: "it's meant to be run, not read".
          Last edited by bug77; 10 August 2021, 02:59 AM.

          Comment


          • #6
            Originally posted by mdedetrich View Post
            Although C theoretically speaking can be just as fast as Rust
            Maybe it is the opposite: C is lower level than Rust, at most Rust has to catch up (at most).


            Originally posted by mdedetrich View Post
            Although C theoretically speaking can be just as fast as Rust, due how terrible it is in handling concurrency as well memory safety issues a lot of people end up coding in a style that is very conservative/fearful due to how easy it is to make hard to track bugs.
            C does not handle concurrency in any way, does it?
            The programmer has to do all the burden of handling concurrency and memory sharing.
            Rust does it at the highest level, enforcing the programmer does not make such mistakes at all. The programmer is freed of thinking about manually handling such tasks, but on the opposite has a stricter programming language logic.

            Despite the purpose of C and Rust is the same, they are very different beasts.

            Comment


            • #7
              Originally posted by mdedetrich View Post

              The former is being worked on, not sure about the latter since streams opens up a massive can of worms especially in a language like Rust that is strongly typed

              For those wondering how Rust programs can end up beating C equivalents, one of the things that Rust allows is fearless concurrency and memory safety. Although C theoretically speaking can be just as fast as Rust, due how terrible it is in handling concurrency as well memory safety issues a lot of people end up coding in a style that is very conservative/fearful due to how easy it is to make hard to track bugs.

              When you have a tool that mathematically validates data flow (which is what Rust's linear type system is essentially proving), you can go completely crazy adding in optimizations (such as multi threading) without needing to worry about race conditions and continue working on such codebases without fear of regressions.

              No Rust doesn't magically solve all logic bugs, but it makes a portion of them impossible which means you can spend the gained time/effort in other areas.
              AFAIR C99 doesn't define thread and it doesn't have any memory issues.
              All issues come from programmers, because everything (almost) in C is manual which gives you great control but is very error prone.

              C is lower level than Rust, but both languages are made for low level programming.
              I think, that a good analogy would be a comparison of assembler with C, and C with Rust

              C is better than assembler in all cases except theoretical performance, and was designed to replace it
              Rust is better than C in all cases except theoretical performance, and was designed to replace it
              Last edited by RedEyed; 10 August 2021, 02:20 AM.

              Comment


              • #8
                aomenc is the best encoder to use. the quality gains over svt-av1 is a large amount

                Comment


                • #9
                  Originally posted by blackshard View Post

                  Maybe it is the opposite: C is lower level than Rust, at most Rust has to catch up (at most).
                  It depends. Rust can be fairly low-level if it needs to be. Yet, high-level has its advantages as well. The compiler can, ideally, better see your intention and thus provide a more optimized assembly.


                  https://benchmarksgame-team.pages.de...ust-clang.html

                  Comment


                  • #10
                    Originally posted by blackshard View Post
                    C does not handle concurrency in any way, does it?
                    Well yes and thats the problem.

                    Comment

                    Working...
                    X