> It provides no additional features compared to FFmpeg, and despite incorporating FFmpeg's assembly code, is significantly slower.
These things may not be true in the future. I just meant to describe the current state of the project. With Rust being a modern language and the repository being AI-optimized, I wouldn't be surprised if it grew to have more features. And I hope that Rust can close the gap on performance, it would be a great testament to Rust's usefulness for high performance software.
After playing around with Claude Code for a bit, rewriting some Python tooling in Rust to great effect, I was interested in pushing the boundaries of what LLMs could do in terms of rewriting projects in Rust. The result is `wedeo`. For those unfamiliar, [FFmpeg]( https://www.ffmpeg.org/ ) is "a complete, cross-platform solution to record, convert and stream audio and video". It is one of the most powerful and impress…
FFMPEG is a media processing framework. Of course, it is normally built with the many encoders, decoders and filters that do the actual media processing work. Those components are separate open source projects. The performance critical part of FFMPEG is in the component encoders, decoders and filters, not the framework that sets up the media processing graph, gets it running and monitors it. It could be useful or interesting to have a Rust port of FFMPEG (for developers who might want to contribute new features). I wouldn't bother trying to port component encoders, decoders or filters from C to Rust. There is no need, and no benefit. They are mostly older and stable. Rust will never be faster than C, even if you link all the hand-optimized assembly code.
The challenge of maintaining a Rust fork of FFMPEG will be to stay current with changes to FFMPEG. LLMs are very good at converting from one language to another, so it might be feasible, especially if you can automate it. But I would definitely stick to using Rust only for the top layer of FFMPEG.
It’s generated by an AI so the "author" doesn’t care about the license.
I don’t know if I would say I don’t “care” about the license. I want to respect the FFmpeg license, and considering that my project is a straight ripoff, it would be dishonest to not have the same license. Whether AI-generated code can even be legally licensed or copyrighted is a separate question that hasn’t been decided by courts. I’ll happily comply with whatever experts recommend.
Good answer. Asking an AI coding agent to port a C codebase to Rust is clearly and obviously creating a derivative work. You need to follow the terms of the LGPL license, and your Rust fork of FFMPEG must be licensed as LGPL. Videolan holds the copyright to FFMPEG, and that includes derivative works. LGPL allows you to do exactly what you're doing.
Note that if you convert x264, x265 or any of the other GPL v2 libraries, your Rust version of those libraries will be GPL v2. When builds of FFMPEG are created with GPL v2 libraries, the entire build becomes GPL v2 (which has a more restrictive copyleft provision than LGPL).
Worth mentioning https://github.com/yazaldefilimone/ffmpreg , another rust rewrite of ffmpeg (apparently from scratch, not translated)
Why even keep working on this by hand for months when an AI can just write it fully featured in a week?
Because it can't. I'm aware of only two projects that have attempted this.
1. Anthropic's C compiler. This is a buggy, unoptimized, unwieldy mess. One that can compile the Linux kernel, which is no mean feat. But it is not "fully featured." And it had an incredible array of tests to start with.
2. Cursor's web browser. This is, flatly, a trainwreck. It's built on top of massive dependencies that do incredible amounts of heavy lifting despite claims to the contrary, and never seems to have ever produced a successful build.
Worth mentioning https://github.com/yazaldefilimone/ffmpreg , another rust rewrite of ffmpeg (apparently from scratch, not translated)
Why even keep working on this by hand for months when an AI can just write it fully featured in a week?
To be clear, `wedeo` took a few weeks to get to this point, and it is by no means fully featured. Even with LLMs, it will take a few months to reach that point with me as the sole human contributor.
Why even keep working on this by hand for months when an AI can just write it fully featured in a week?
Because it can't. I'm aware of only two projects that have attempted this. 1. Anthropic's C compiler. This is a buggy, unoptimized, unwieldy mess. One that can compile the Linux kernel, which is no mean feat. But it is not "fully featured." And it had an incredible array of tests to start with. 2. Cursor's web browser. This is, flatly, a trainwreck. It's built on top of massive dependencies that do incredible amounts…
The tests are the real clincher here. That’s the main reason that this project has made so much progress: the FATE suite highlights specific bugs to fix and tracks regressions.
As for optimization, that seems to be more of a question of effort than whether it’s possible. I was able to take down the performance gap on Rust vs C (without Assembly) from 10x to 1.5x through detailed profiling and iterative improvements with Claude.
It also looks like the Anthropic C compiler was built from scratch. By contrast, `wedeo` was directly based on FFmpeg’s existing code. Going by spec and test suite only would have taken a lot longer, and the quality would have been significantly lower.
I don’t know if I would say I don’t “care” about the license. I want to respect the FFmpeg license, and considering that my project is a straight ripoff, it would be dishonest to not have the same license. Whether AI-generated code can even be legally licensed or copyrighted is a separate question that hasn’t been decided by courts. I’ll happily comply with whatever experts recommend.
Good answer. Asking an AI coding agent to port a C codebase to Rust is clearly and obviously creating a derivative work. You need to follow the terms of the LGPL license, and your Rust fork of FFMPEG must be licensed as LGPL. Videolan holds the copyright to FFMPEG, and that includes derivative works. LGPL allows you to do exactly what you're doing. Note that if you convert x264, x265 or any of the other GPL v2 librar…
Good to know! I have licensed as LGPL so I think that covers it. Rewriting x264 and x265 are in scope so I’ll keep that in mind. I will design the application as well so that those can easily be excluded from compilation to get a pure LGPL build.
After playing around with Claude Code for a bit, rewriting some Python tooling in Rust to great effect, I was interested in pushing the boundaries of what LLMs could do in terms of rewriting projects in Rust. The result is `wedeo`. For those unfamiliar, [FFmpeg]( https://www.ffmpeg.org/ ) is "a complete, cross-platform solution to record, convert and stream audio and video". It is one of the most powerful and impress…
FFMPEG is a media processing framework. Of course, it is normally built with the many encoders, decoders and filters that do the actual media processing work. Those components are separate open source projects. The performance critical part of FFMPEG is in the component encoders, decoders and filters, not the framework that sets up the media processing graph, gets it running and monitors it. It could be useful or int…
I don’t really think there’s any actual benefit to `wedeo` existing, beyond the novelty of having pure Rust media processing software and perhaps being easier to use as a library. Like I said, this is mostly an experiment in LLM’s ability to rewrite software in Rust. FFmpeg is one of the most high quality pieces of open source software out there, I seriously doubt that LLMs on their own could eclipse it, even with all of Rust’s benefits. So I definitely understand what you’re saying but it’s not really my motivation.
As for the updating, this is something that I’ve been considering but it’s obviously not in scope until `wedeo` is fully featured. But yes, this is something that LLMs should be able to do quite easily, it could even trigger on every commit.
FFMPEG is a media processing framework. Of course, it is normally built with the many encoders, decoders and filters that do the actual media processing work. Those components are separate open source projects. The performance critical part of FFMPEG is in the component encoders, decoders and filters, not the framework that sets up the media processing graph, gets it running and monitors it. It could be useful or int…
I don’t really think there’s any actual benefit to `wedeo` existing, beyond the novelty of having pure Rust media processing software and perhaps being easier to use as a library. Like I said, this is mostly an experiment in LLM’s ability to rewrite software in Rust. FFmpeg is one of the most high quality pieces of open source software out there, I seriously doubt that LLMs on their own could eclipse it, even with al…
The benefit is that you and other Rust developers could potentially implement improvements to FFMPEG. Again, if you stick to porting only the top layer of FFMPEG - the media processing framework with the CLI - you can still keep the rest as C and link it all together in a build. Your Rust version (and any improvements implemented by other Rust developers who contribute to wedeo) can easily be converted back to C so that patches could be offered back upstream to the main FFMPEG project.