• IMALlama@lemmy.world
      link
      fedilink
      arrow-up
      2
      ·
      1 hour ago

      Rust is spiritually fairly close to C/C++, but with modern convenances like memory safety and ease of concurrency. It compiles somewhat slower but it’s compiler errors are more friendly IMO. Rust can be as fast as C++, is also cross platform (eg windows/Linux/Mac) and scales up/down from IoT device level to desktop to seerver applications. If you’re going to be writing a lower level app Rust is a good language to look at, but you can also write GUI applications in Rust too.

      Here’s a decent overview

  • brucethemoose@lemmy.world
    link
    fedilink
    arrow-up
    55
    arrow-down
    1
    ·
    edit-2
    2 days ago

    But why?

    Wouldn’t it be better to spend the same effort writing ffmpeg modules and interfaces in Rust?

    keeping external dependencies to a minimum

    This is… concerning, too.

    Media processing code is difficult. It’s not even a pure coding problem, and often involves human perception, extensive, expensive experimentation and esoteric, buggy hardware APIs . Hence the whole point of ffmpeg is basically integration of external libraries, with immense amounts of labor already put into each.

    There are some Rust libraries they could pull in though. I guess it’d be reasonable to focus on newer formats/codecs that have Rust implementations already, and let ffmpeg handle weird legacy formats.

  • GissaMittJobb@lemmy.ml
    link
    fedilink
    arrow-up
    42
    arrow-down
    1
    ·
    2 days ago

    Seems quite inadvisable unless backed by the larger video community, which in turn I think will be unlikely.

    Do not underestimate how incredibly load-bearing ffmpeg is to all of video technology, and do not underestimate the crazy shit going on inside it. It’s a remarkable piece of technology.

  • ZeroOne@lemmy.world
    link
    fedilink
    arrow-up
    6
    arrow-down
    5
    ·
    1 day ago

    I am worried, that a crap ton of rust rewrites are in MIT or APACHE.

    Like why not use GPL ? Is there something sinister going on & it’s going to give the Bryan Lunduke types so much effective ammunition.

    Or am I just over-reacting ?

    On another note are there any video games made in Rustlang ?

    • daniskarma@lemmy.dbzer0.com
      link
      fedilink
      arrow-up
      7
      ·
      1 day ago

      My guest would be that open licenses are just more common overall nowadays, so any new development is more likely to have them.

      I don’t think is just rust related.

      • The_Decryptor@aussie.zone
        link
        fedilink
        English
        arrow-up
        1
        ·
        2 hours ago

        Rust has no stable inter-module ABI, so everything has to be statically linked together. And because of how “viral” the GPL/LGPL are a single dependency with that license turns the entire project into a GPL licenced one.

        So the community mostly picks permissive licenses that don’t do that, and that inertia ends up applying to the binaries as well for no real good reason. Especially when there’s options like e.g. MPL.

    • vivendi@programming.dev
      link
      fedilink
      English
      arrow-up
      6
      arrow-down
      10
      ·
      edit-2
      1 day ago

      Yup. Rust is corporate encroachment in diaguise of memory “safety”

      Rust (the language) has good ideas. Rust (the community) is pure cancer concentrate

      • ZeroOne@lemmy.world
        link
        fedilink
        arrow-up
        8
        ·
        1 day ago

        How can a good language be “corporate encroachment” ? When it’s the community/devs that are responsible for using “bad” licences ?

  • FizzyOrange@programming.dev
    link
    fedilink
    arrow-up
    5
    arrow-down
    1
    ·
    2 days ago

    I mean, it would be great if this succeeded… ffmpeg is nice and all but its interface is clearly terrible and there’s absolutely no way it is remotely secure. Anyone that uses it on a server basically has to run it in its own VM, or a severely locked down sandbox.

    But good luck supporting all the codecs people expect. I’m not even talking the obscure ones ffmpeg supports; just the ones “normal” people use will be a life’s work.

    Also you have to change the name!

      • FizzyOrange@programming.dev
        link
        fedilink
        arrow-up
        1
        ·
        18 hours ago

        It’s just not a very good name. Awkward even without the mpreg/preg thing. Steps on ffmpeg’s toes too much. Just pick something unique. Videoh. Muxy. Movrify. Flippityflop, whatever. I thought about those names for literally 10 seconds. You can definitely do better than ffmpreg if you think harder!

  • onlinepersona@programming.dev
    link
    fedilink
    English
    arrow-up
    8
    arrow-down
    2
    ·
    2 days ago

    Good luck. Isn’t a lot of ffmpeg in assembly? I wonder how that will be handled. If faster code can be compiled that’d be crazy.