This and the GIMP is why they shouldn’t let software developers name things.
How is this literal joke still getting so much engagement?
How come that so many C/C++ apps are being rewritten in Rust? Is it faster/safer, or is it rather a coding exercise?
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.
Thanks for explaining, didn’t know that part about memory safety. I agree, for new apps it makes more sense to pick Rust over C/C++ (unless maybe if you’re a C veteran). However, if it’s just as fast as C/C++, wouldn’t it make sense to leave existing C/C++ apps as they are (as long as you don’t want to add new functions)? Not judging, just genuinely curious (especially since Rust hat stirred up some drama among Linux maintainers, from what I have heard)
There’s not a great answer to your question and the ‘right’ choice is going to be situational. The reason to migrate to Rust is simple: fewer possible bugs should reduce maintenance costs. Whether or not migrating functionality between languages makes sense is another can of worms. Is there enough documentation to avoid the nuanced edge cases that are handled by the current solution’s code? Is this a simple port, does it only need interface compatibility, or should a larger area of code be modified? If the code is shared how does the rest of the team feel about the potential language?
I do not know what happened re: drama among Linux maintainers but I seen rumblings about it on Lemmy.
Huh, so it’s not something simple I have missed regarding why so much software is being rewritten in Rust… I see that appearing so often, so I thought there was maybe a bigger reason I’m not seeing. Anyways, thanks again, appreciate the explanations 👍
Oh thank god I thought someone wrote about getting ffmpeg pregnant and I was gonna have to give up
The name is absolutely hilarious, I agree.
It’s made even better by the fact that the author evidently hadn’t heard of the kink aspect of the name until they posted it on Reddit 😆
Omg lol wonderful 🤣
Kink? Wat?
🫃
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.
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.
Someone say mpreg 🫃?
Testing video should absolutely be https://www.youtube.com/watch?v=ExZEUZsgH3w
An actually serious project that is not at the “joke” stage. Zero LLM use too:
https://nihav.org/For audio at least, people should be aware of:
https://github.com/pdeljanov/SymphoniaWe just need to rewrite curl next.
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 ?
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.
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.
Yup. Rust is corporate encroachment in diaguise of memory “safety”
Rust (the language) has good ideas. Rust (the community) is pure cancer concentrate
How can a good language be “corporate encroachment” ? When it’s the community/devs that are responsible for using “bad” licences ?
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.
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!
Also you have to change the name! why is that? (i’m aware of what mpreg means)
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!
Unlicensed/missing license👎
Shame they opted for Apache.
Here, a person added GPL as a proposed alternative.
Well that’s encouraging. Here’s hoping they switch.
Big tech loves Apache and MIT 💕
I agree but it’s better than nothing.
they out here plagiarising @ffmpreg@hexbear.net smh
