Announcement

Collapse
No announcement yet.

NihAV Is An Experimental Multimedia Framework Written In Rust

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

  • NihAV Is An Experimental Multimedia Framework Written In Rust

    Phoronix: NihAV Is An Experimental Multimedia Framework Written In Rust

    NihAV is a new open-source, multimedia framework being pursued by FFmpeg/Libav developer Kostya Shishkov...

    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 license this as AGPLv3?

    EDIT: The answer seems to be so that anyone using this to provide services has to disclose the source.
    Last edited by wswartzendruber; 09 August 2020, 12:37 PM.

    Comment


    • #3
      I am a free software enthusiast and lover of open source, but I would much prefer the LGPL, I really dislike the AGPL.

      Comment


      • #4
        That is why you dont have to use it. This is experimental and may lead to something great. Or it may not.

        Chances are that it will remain a playground and the possibility of success is increased if those that utilise it cannot hide their improvements.

        For everyone else there are other frameworks available that they can use, from proprietary to LGPL and other licences.

        Comment


        • #5
          Originally posted by uid313 View Post
          I am a free software enthusiast and lover of open source, but I would much prefer the LGPL, I really dislike the AGPL.
          You mean you can take without giving back? :/

          Comment


          • #6
            There are a few projects already looking into using this. When it gets integrated into rust-av, that might use a different license more in-line with that project's licensing. At least, that's what I get from some comments on licensing in Kostya's blog.

            Comment


            • #7
              NiH is strong with this one.

              Expect this project to die in a few months/years after the developer gets tired of maintaining it.

              And it's unlikely ffmpeg developers will ever migrate to Rust given a ton of effort required and less than obvious benefits, besides, ffmpeg cannot exist without low level assembler code in order to speed up certain functions and this doesn't mesh well with Rust.
              Last edited by birdie; 09 August 2020, 02:17 PM.

              Comment


              • #8
                Originally posted by wswartzendruber View Post
                Why license this as AGPLv3?

                EDIT: The answer seems to be so that anyone using this to provide services has to disclose the source.
                Except that if you don't want to do so in a meaningful sense, there are ways to lawyer around it, like compiling a binary containing nothing but NihAV which communicates with the rest of your program through pipes or loopback sockets.

                People have tried to close that "hole" before, but you run up against the problem that you also make the license unsatisfiable because the resulting license either fails the FSF/OSI/Debian definitions of open-source licensing or is incompatible with the licenses of other processes running on the same host or both.

                Comment


                • #9
                  Originally posted by birdie View Post
                  NiH is strong with this one.

                  Expect this project to die in a few months/years after the developer gets tired of maintaining it.

                  And it's unlikely ffmpeg developers will ever migrate to Rust given a ton of effort required and less than obvious benefits, besides, ffmpeg cannot exist without low level assembler code in order to speed up certain functions and this doesn't mesh well with Rust.
                  Rust has nothing against justifiable assembly language, just as it has nothing against C FFI... heck, it's pretty much required to write crypto you can truly trust to run in constant time. What they do have a problem with is rushing to stabilize a bad design.

                  Just recently, they finally put an inline assembly syntax on the path to stabilization that isn't just "expose LLVM's syntax and hope alternative rust compilers are OK with reimplementing that".

                  (Same reason that the WebKit/Blink WebSQL API didn't go on to become a standard. It would required "Just expose a copy of SQLite to the web" for proper cross-browser compatibility, and web standards aim for multiple independent implementations.)
                  Last edited by ssokolow; 09 August 2020, 02:22 PM.

                  Comment


                  • #10
                    Originally posted by uid313 View Post
                    I am a free software enthusiast and lover of open source, but I would much prefer the LGPL, I really dislike the AGPL.
                    I don't have a dog in this fight, but I'm curious why is AGPL bad?

                    Comment

                    Working...
                    X