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 impressive pieces of open-source software and is the underlying infrastructure for a ton of A/V software. It is also, like the Linux kernel, written purely in C and Assembly.
There are a couple reasons for why FFmpeg is a good candidate for this kind of project. The source code is incredibly high quality, being battle-tested and having contributions from the best experts in the area. A/V encoding and decoding is also rigorously described by specification, which is easily consumed by LLMs. The project's nature of being a bunch of codecs bundled together in a convenient interface made it easy to rewrite incrementally. C, being a systems programming language, maps nicely to Rust, and the assembly could be directly ported over.
The major contribution `wedeo` currently has is an implementation of the H.264 decoder, which is around 30,000 lines of code for the scalar Rust implementation. It doesn't support some complex features like interlacing or 10-bit, but it should support 99% of H.264 encoded video.
There has not been any kind of performance optimization done (except porting some assembly over and basic multithreading), so `wedeo` is much slower than FFmpeg. I expect the gap to close somewhat over time, but I doubt that even the most optimized Rust could beat FFmpeg's high quality C and Assembly.
In order to get this project to the point where it can actually play video properly, I have utilized some existing libraries. The intention is for the codebase to be pure Rust, so any functionality which only exists as a non-Rust library will have to be rewritten. `symphonia` is used for audio, `rav1d` and `rav1e` for AV1, and `wgpu` and `winit` for the player.
I have only confirmed that this works on MacOS M-series, so I would welcome testing on other machines.
There is a lot missing from `wedeo`, in particular any video codecs besides H.264 and AV1, as well as H.264 encoding. I will be working on this as a side project, but I would also welcome contributions on these. And if anyone is interested in taking on an active role as maintainer, I'd gladly hand the reins over.
# On AI Slop
Although I can read and write Rust, 100% of the code in `wedeo` is AI-generated and I have not directly reviewed a single line of it, other than asking Claude to fix bugs and explain parts of it. It is intended as an experiment in pure LLM usage.
I'm aware that this community and many other technical spaces online have been overwhelmed by "AI slop", bloated projects that have LOC that run in the tens of thousands, and I can see why many people might interpret `wedeo` that way. However, the amount of code in this project is similar to the equivalent amount in FFmpeg.
I also think that this project is at least interesting in that this has never been attempted before, and I want to see where it can be taken. I think it's at least a better use of tokens than typical AI slop.
Have you taken a look at the various test harnesses for video encoding/decoding, or consider publishing a standalone one yourself? I get a bit-for-bit rewrite can have some advantage but it's hard to know if the AI implementation actually covers all of the edges cases.
> It provides no additional features compared to FFmpeg, and despite incorporating FFmpeg's assembly code, is significantly slower.
What a fantastic use of tokens. The author isn't even reviewing the code so you can't really even call it a study.
Worth mentioning https://github.com/yazaldefilimone/ffmpreg, another rust rewrite of ffmpeg (apparently from scratch, not translated)
A rust rewrite that's GPL and isn't MIT or Apache licensed? I'm shocked.
It’s generated by an AI so the "author" doesn’t care about the license.
It incorporates code directly from FFmpeg and FFmpeg is LGPL.
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 impressive pieces of open-source software and is the underlying infrastructure for a ton of A/V software. It is also, like the Linux kernel, written purely in C and Assembly.
There are a couple reasons for why FFmpeg is a good candidate for this kind of project. The source code is incredibly high quality, being battle-tested and having contributions from the best experts in the area. A/V encoding and decoding is also rigorously described by specification, which is easily consumed by LLMs. The project's nature of being a bunch of codecs bundled together in a convenient interface made it easy to rewrite incrementally. C, being a systems programming language, maps nicely to Rust, and the assembly could be directly ported over.
The major contribution `wedeo` currently has is an implementation of the H.264 decoder, which is around 30,000 lines of code for the scalar Rust implementation. It doesn't support some complex features like interlacing or 10-bit, but it should support 99% of H.264 encoded video.
There has not been any kind of performance optimization done (except porting some assembly over and basic multithreading), so `wedeo` is much slower than FFmpeg. I expect the gap to close somewhat over time, but I doubt that even the most optimized Rust could beat FFmpeg's high quality C and Assembly.
In order to get this project to the point where it can actually play video properly, I have utilized some existing libraries. The intention is for the codebase to be pure Rust, so any functionality which only exists as a non-Rust library will have to be rewritten. `symphonia` is used for audio, `rav1d` and `rav1e` for AV1, and `wgpu` and `winit` for the player.
I have only confirmed that this works on MacOS M-series, so I would welcome testing on other machines.
There is a lot missing from `wedeo`, in particular any video codecs besides H.264 and AV1, as well as H.264 encoding. I will be working on this as a side project, but I would also welcome contributions on these. And if anyone is interested in taking on an active role as maintainer, I'd gladly hand the reins over.
# On AI Slop
Although I can read and write Rust, 100% of the code in `wedeo` is AI-generated and I have not directly reviewed a single line of it, other than asking Claude to fix bugs and explain parts of it. It is intended as an experiment in pure LLM usage.
I'm aware that this community and many other technical spaces online have been overwhelmed by "AI slop", bloated projects that have LOC that run in the tens of thousands, and I can see why many people might interpret `wedeo` that way. However, the amount of code in this project is similar to the equivalent amount in FFmpeg.
I also think that this project is at least interesting in that this has never been attempted before, and I want to see where it can be taken. I think it's at least a better use of tokens than typical AI slop.
Excited to see what the community thinks!
P.S. I just saw [this tweet](https://x.com/FFmpeg/status/2039115531744334180) from FFmpeg. Ironic, but I assure you this is not an April Fools' joke.
> 100% of the code in `wedeo` is AI-generated
Thanks but no thanks
> It is intended as an experiment in pure LLM usage.
Have you taken a look at the various test harnesses for video encoding/decoding, or consider publishing a standalone one yourself? I get a bit-for-bit rewrite can have some advantage but it's hard to know if the AI implementation actually covers all of the edges cases.
Thank you for being up-front in disclaiming that this project is AI-written, both here and in the Github page. I really appreciate the transparency.
What's the unsafe situation like in Wedeo?