For an enormous project like this, it is probably more reasonable to just use the latest version of C, and turn on lots of linters and sanitizers. You could also use one of the various strict subsets of C that is oriented for safety.
Might as well tell people to rewrite WebKit or Linux in Rust. There are projects that aim at building browsers or kernels in Rust, but the man-millennia of effort put into the existing projects means catching up is no small feat.
Even the coreutils rewrite has taken like a decade and isn't done. And that is a small and well-defined goal by comparison.
What other big projects like Chromium and Android are doing is writing new code in Rust and investing in interop with the existing C and C++ code, along with fuzzing and sanitizing.
You're not wrong. Media codecs are a good attack vector. However, it's not so simple. You need hand crafted SIMD to reach desired performance. That is a whole area of specialized theory and research. I think it should be done, but who is going to fund it?
It would involve unsafe rust anyway, which does sequester but not eliminate the concern. I think it would be difficult to make a case that this effort is worthwhile.
You don't necessarily need all the code to be fast. I think writing correctness validators in a memory-safe language would go a long way toward securing media formats. Run the validator on all untrusted media to confirm it strictly conforms to the specification before playing it in the fast-but-unsafe player. This should make things a lot more difficult for attackers. As a bonus, it would be a useful debugging tool for encoders.
Serious question, let's say you had a ton of money and wanted to get this done, is there physically enough available Rust talent (at market rates) in the world today to port ffmpeg to rust in any reasonable amount of time? My understanding is that it's one of the biggest open source projects in terms of LoC, development hours needed to both create and maintain, and number of former and active developers working on the project.
If it doesn’t support the formats, it’s not a replacement for ffmpeg. It’s a competitor with fewer capabilities. I’m sure people will flock to that just for the excuse of saying they are using a rust library.
> If it doesn’t support the formats, it’s not a replacement for ffmpeg.
That's dumb. Like saying a car isn't a replacement for a horse because it can't jump over hedges. Most people do not care about the obscure formats at all.
> I’m sure people will flock to that just for the excuse of saying they are using a rust library.
Well, for not having to worry about trivial security bugs, yes I suspect they would flock to it! Especially for server side video processing.
> That's dumb. Like saying a car isn't a replacement for a horse because it can't jump over hedges.
A car is not a replacement for a horse, it's a replacement for what was the most common use case of the horse, getting from A->B in a developed environment. There are still (limited) applications where a horse is the best or only transportation option.
A pocket knife is not a replacement for a multitool, even if the multitool blade gets used more than any other feature. People use multitools because they want something that can solve multiple problems with a single tool. The greatest feature and the reason people reach for ffmpeg is that it's extremely versatile. If you get rid of that versatility, it's not a replacement for ffmpeg.
You can't win by inventing your own overly narrow definition of what "replacement" means. Under your definition nothing is a replacement for anything, which is clearly idiotic.
He didn't invent his own definition. A drop-in replacement does the exact same thing, as what it would replace in the exact same way.
You however don't seem to understand _why_ backwards compatibility is important, and i would absolutely hate to interface with whatever mess of a software you write.
> But something doesn't have to be backwards compatible to be a "replacement".
Yes it does. Especially when it's the size of projects like ffmpeg. Just because you replaced c++ with rust in your tiny hobby projects doesn't mean you have the experience, nor the qualifications to say what it entails what it takes to do it at this scale.
You are getting very very confused. Let me simplify it for you.
1. It is desirable for replacements to be drop-in replacements. But it isn't a strict requirement. It is possible to replace something with something else even if it requires some work to do that replacement.
Cars did replace horses for transport. That is fact. They were not a drop-in replacement. Roads had to be built. People had to learn to drive.
The fact that they were not a drop-in replacement for horses does not mean that they were not a replacement. That's simply not what the word "replacement" means in English.
2. You seem to be confusing the size of ffmpeg itself, with the difficulty of replacing it. That's not how programs work. The thing that matters is the size of the interface of the program, which isn't the same as the size of the program itself.
For example if you are using ffmpeg on a web server to compress or convert videos to a standard format, you might be running a single ffmpeg command, and replacing it with some other system would literally be a matter of changing the command. It doesn't matter that ffmpeg itself is a huge program.
I hope that helps you understand a bit better. Good luck learning about computers - keep at it and you will get there eventually!
There's plenty of talented developers out there that are currently working in another language, but could relatively quickly learn the required Rust skills to go work on such a project. Domain knowledge (codecs, video/audio processing, etc) is probably a bigger problem.
It will possibly kill lots of community contributions. Currently its easy to add missing features to things like filters.
Who is going to do that in rust? I'm yet to see a practicing rust programmer IRL.
To be fair, ffmpeg is highly modular, some parts of it are probably already in Rust. I feel like rewriting certain extremely high-use libraries like libx264 could be done if like, 5 really productive Rust engineers with codec experience took it on for 12 months.
I’m not saying it’s needed, just that ffmpeg is the kind of thing that could be rewritten gradually if there was interest and a lot of dedicated talent.
You are getting down voted, but you aren't really wrong, there have been 142 vulnerabilities[1] in ffmpeg since 2018, 3 in this year so far. The attack surface is huge, with mostly memory corruption issues being found.
Not sure rust is the answer or what else could be done, but we shouldn't pretend it isn't an issue.
So they found and fixed 142 vulnerabilities in the last 3 years and folks are advocating for them to abandon all that good work and build a new framework from scratch which reintroduces tons more bugs that are completely undiscovered. Seems like an insane path to stability to me.
You are missing the point. Nearly 100% of those bugs are due to the fact that it is written in a memory unsafe language, FFmpeg is 23 years old and we still find memory corruption bugs in it every few months. That's why people are saying to perhaps use a memory safe language instead, I don't understand why people give this such a hostile response, it has been widely accepted that C is dangerous and can not ever be made safe, to suggest anything different is denying reality.
A lot of it is written in ASM for performance reasons.
Besides that, there's always a bunch of "this should be rewritten completely in <hot new language>" as if it's trivial to rewrite software like this from scratch but nobody ever steps up and does it, I wonder why that is?
This is creating bad incentives - now the billions of dollars relying on that have no interest in fixing the issue and they'll do the same for other projects.
It's very good that ffmpeg gets support and the sovereign tech fund is a good idea but for me it again just highlights how perverted the incentives to support open source are.
Millions of dollars are extracted by using ffmpeg from a lot of corporations, yet the German taxpayer pays for maintenance.
before any of us bein patting ourselves on the back, It's prolly best to acknowledge that without Frances copyright laws this project along with many others would've been killed by lawyers.
> before any of us bein patting ourselves on the back, It's prolly best to acknowledge that without Frances copyright laws this project along with many others would've been killed by lawyers.
How are French copyright laws responsible for this?
This is great news, but simultaneously disappointing that it is necessary. FFmpeg underpins tens of billions of dollars in value for the companies that use it, yet the support from the community is proportionally minuscule.
It's weird when you consider how much money corporations waste on complete bs that they can't set aside a tiny amount to support the software they use.
For the same reason that they hire cleaners to clean the windows of their buildings and pay people to check cables in their data centers. To make sure that their business isn't going to fall apart.
It's necessary because anytime there's talk about the original authors of open source software making money rather than big corps everyone starts frothing at the mouth and forking things to protect the leeches.
54 comments
[ 935 ms ] story [ 2038 ms ] threadi see some generic posts about how ffmpeg is written in C and Assembly and will not be re-written in C++, but nothing about Rust.
Might as well tell people to rewrite WebKit or Linux in Rust. There are projects that aim at building browsers or kernels in Rust, but the man-millennia of effort put into the existing projects means catching up is no small feat.
Even the coreutils rewrite has taken like a decade and isn't done. And that is a small and well-defined goal by comparison.
;-)
It would still cost a lot though.
That's dumb. Like saying a car isn't a replacement for a horse because it can't jump over hedges. Most people do not care about the obscure formats at all.
> I’m sure people will flock to that just for the excuse of saying they are using a rust library.
Well, for not having to worry about trivial security bugs, yes I suspect they would flock to it! Especially for server side video processing.
A car is not a replacement for a horse, it's a replacement for what was the most common use case of the horse, getting from A->B in a developed environment. There are still (limited) applications where a horse is the best or only transportation option.
A pocket knife is not a replacement for a multitool, even if the multitool blade gets used more than any other feature. People use multitools because they want something that can solve multiple problems with a single tool. The greatest feature and the reason people reach for ffmpeg is that it's extremely versatile. If you get rid of that versatility, it's not a replacement for ffmpeg.
You however don't seem to understand _why_ backwards compatibility is important, and i would absolutely hate to interface with whatever mess of a software you write.
I agree, but do you see "drop-in" anywhere in my comments?
> You however don't seem to understand _why_ backwards compatibility is important
I completely understand why backwards compatibility is important. But something doesn't have to be backwards compatible to be a "replacement".
I have replaced C++ with Rust in my hobby projects.
Yes it does. Especially when it's the size of projects like ffmpeg. Just because you replaced c++ with rust in your tiny hobby projects doesn't mean you have the experience, nor the qualifications to say what it entails what it takes to do it at this scale.
You come across as extremely unexperienced.
1. It is desirable for replacements to be drop-in replacements. But it isn't a strict requirement. It is possible to replace something with something else even if it requires some work to do that replacement.
Cars did replace horses for transport. That is fact. They were not a drop-in replacement. Roads had to be built. People had to learn to drive.
The fact that they were not a drop-in replacement for horses does not mean that they were not a replacement. That's simply not what the word "replacement" means in English.
2. You seem to be confusing the size of ffmpeg itself, with the difficulty of replacing it. That's not how programs work. The thing that matters is the size of the interface of the program, which isn't the same as the size of the program itself.
For example if you are using ffmpeg on a web server to compress or convert videos to a standard format, you might be running a single ffmpeg command, and replacing it with some other system would literally be a matter of changing the command. It doesn't matter that ffmpeg itself is a huge program.
I hope that helps you understand a bit better. Good luck learning about computers - keep at it and you will get there eventually!
What exactly does a complete rewrite of FFmpeg achieve given the absolutely monstrous complexity involved?
I’m not saying it’s needed, just that ffmpeg is the kind of thing that could be rewritten gradually if there was interest and a lot of dedicated talent.
Not sure rust is the answer or what else could be done, but we shouldn't pretend it isn't an issue.
[1] https://stack.watch/product/ffmpeg/ffmpeg/
Besides that, there's always a bunch of "this should be rewritten completely in <hot new language>" as if it's trivial to rewrite software like this from scratch but nobody ever steps up and does it, I wonder why that is?
ffmpeg is one of these "Too Important to Fail" libraries.
I'll lay odds that billions of dollars rely on it, and it's an open-source tool.
Millions of dollars are extracted by using ffmpeg from a lot of corporations, yet the German taxpayer pays for maintenance.
How are French copyright laws responsible for this?
So weird, it sounds like a conspiracy theory.