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.
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.
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.
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!
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 👍
34 Comments
A_Union_of_Kobolds@lemmy.world · 77 pts · 229d
Oh thank god I thought someone wrote about getting ffmpeg pregnant and I was gonna have to give up
gravitas_deficiency@sh.itjust.works · 53 pts · 229d
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 😆
A_Union_of_Kobolds@lemmy.world · 14 pts · 229d
Omg lol wonderful 🤣
onlinepersona@programming.dev · 5 pts · 229d
Kink? Wat?
eth0slash0@sh.itjust.works · 13 pts · 229d
🫃
brucethemoose@lemmy.world · 60 pts · 229d
But why?
Wouldn’t it be better to spend the same effort writing ffmpeg modules and interfaces in Rust?
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 · 46 pts · 229d
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.
bookmeat@lemmynsfw.com · 11 pts · 228d
That's cool, but that doesn't matter. No one is trying to force people to use new, experimental software. Let the hackers hack.
TheSlad@sh.itjust.works · 40 pts · 229d
Someone say mpreg 🫃?
HexesofVexes@lemmy.world · 2 pts · 228d
Testing video should absolutely be https://www.youtube.com/watch?v=ExZEUZsgH3w
AllNewTypeFace@leminal.space · 28 pts · 228d
This and the GIMP is why they shouldn’t let software developers name things.
BB_C@programming.dev · 24 pts · 229d
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/Symphonia
recursive_recursion@piefed.ca · 9 pts · 229d
Unlicensed/missing license👎
gravitas_deficiency@sh.itjust.works · 10 pts · 229d
It’s been flagged
danielquinn@lemmy.ca · 17 pts · 229d
Shame they opted for Apache.
onlinepersona@programming.dev · 25 pts · 229d
Big tech loves Apache and MIT 💕
vas@lemmy.ml · 5 pts · 227d
Here, a person added GPL as a proposed alternative.
danielquinn@lemmy.ca · 4 pts · 227d
Well that's encouraging. Here's hoping they switch.
gravitas_deficiency@sh.itjust.works · -5 pts · 229d
I agree but it’s better than nothing.
MITM0@lemmy.world · 8 pts · 228d
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 · 8 pts · 228d
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 · 1 pts · 227d
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 · -7 pts · 228d
MITM0@lemmy.world · 9 pts · 228d
How can a good language be "corporate encroachment" ? When it's the community/devs that are responsible for using "bad" licences ?
onlinepersona@programming.dev · 7 pts · 229d
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.
FizzyOrange@programming.dev · 5 pts · 229d
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!
alx@piefed.blahaj.zone · 2 pts · 228d
FizzyOrange@programming.dev · 1 pts · 228d
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!
FalschgeldFurkan@lemmy.world · 2 pts · 227d
How come that so many C/C++ apps are being rewritten in Rust? Is it faster/safer, or is it rather a coding exercise?
IMALlama@lemmy.world · 9 pts · 227d
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
FalschgeldFurkan@lemmy.world · 3 pts · 227d
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)
IMALlama@lemmy.world · 4 pts · 226d
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.
FalschgeldFurkan@lemmy.world · 2 pts · 226d
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 👍
BB_C@programming.dev · 2 pts · 226d
How is this literal joke still getting so much engagement?
irelephant@lemmy.dbzer0.com · 1 pts · 227d
We just need to rewrite curl next.