sharifhsn

The Internet relies on physical infrastructure managed by sovereign nations and multinational corporations, it would never be free from those constraints. Until we reach post-scarcity utopia and harmony between all of humanity—ironically, something that could be enabled by AI—the Internet will never be "free".

The difference between using general knowledge and summaries and doing code-for-code rewrites cannot be understated. When creating `wedeo`, despite DIRECTLY reviewing FFmpeg's code, Claude would frequently make mistakes that would have to be fixed. I would constantly have it go and refer back to the ground truth FFmpeg source implementation. It did eventually work, but only after several rounds of reviews, and often dead-end investigations. Being able to directly inspect (and in some cases modify for extra debug output) FFmpeg at any given time was invaluable, and I doubt any rewrite would succeed without having that.

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.

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.

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.

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.

For the purposes of debugging, assembly is machine code, just with some nice constructs to make it easier to read. Transpiling between assembly and machine code is mostly a find-and-replace exercise, not like the advanced reasoning involved in proper compilation.

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.

You don’t have to like it but you have to admit that it’s pretty impressive to pass the entire FATE test suite with purely AI-generated code. I honestly didn’t think it would be possible when I first started this.

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.

I found this project, but I’m not surprised that it doesn’t have much progress. Doing this kind of Rust rewrite is an absolutely gargantuan undertaking that I don’t think it would be feasible without AI. It’s not as if FFmpeg is some crufty, slow code that would seriously benefit from it.

I suppose “review” is misleading, since I’m not actually reading the code, I’m simply asking Claude to explain what the code is doing. I’ll change that so it’s expressly clear that none of this code is actually human-reviewed.

It’s used for multithreading and also for assembly loading. It’s not checked by anything other than Claude itself, so that would definitely be a strong candidate for manual review. I did have Claude ingest Rust Atomics & Locks by Mara Bos to help guide the implementation for concurrency, at least.

I’m using FFmpeg’s own FATE suite, which is intended to poke at those edge cases, as well as JVT vectors. I’d love to get a more robust set of weird files similar to what symphonia has, though, so if anyone has any resources I’d appreciate it.

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.

It’s playing stupid to pretend that the theft of a hardly used handle has anything to do with an actual user account. I’m sure if @hac had a presence online, their handle wouldn’t have been sold from under them.

Your bot messed up and posted twice in the same thread.

Government can subsidize the poor. Remember Obamaphones? Just expand that idea.

I hope you feel the same way every time you eat beef.

Gemini has this feature but it’s opt-in.

Good to know. Thanks.

I’m not finding a single article with a good summary, but you can find coverage on Bloomberg of all the twists and turns. FX markets are complicated, so you’ll need to do some research on how they operate as well. It’s not too hard to plug the keywords and concepts from these articles into AI and get a reasonably good background, though.

You can start here: https://www.bloomberg.com/news/articles/2024-12-02/yen-carry...

Takaichi is much more popular than Truss was, and Japan is in a much better situation right now than post-Brexit post-COVID UK. And absolutely nobody is seeking a better relationship with the US right now other than satisfying short-term needs. Japan is not in a good spot long term (population slowdown, debt, slow economy) but there’s no reason to panic right now.

I spoke with a silver expert a week ago before the crash and he said half the flow is speculative, structural flow will remain. Looks like he was right.

It is most certainly LLM generated. Nobody but an AI prompted with “connect the unwind of the yen carry trade with Trump’s threats to acquire Greenland” would have ever written something like that.

My guess is that she did a lot of research on the topic with AI then created this article partially with AI generated text.

Also, while I’m not an expert on Japan, I’ve been following Gearoid Reidy’s commentary on Takaichi and the new Japanese economy and I think the fears expressed are significantly overblown. But this is also characteristic of many other market participants so I wouldn’t categorize this as something obviously wrong, just a disagreement.

Speaking as a quant that has followed this story closely for months (and was educated about the yen carry trade in my degree), this narrative is somewhat wrong and also very obviously LLM slop.

It is true that the yen carry trade is currently being unwound and that it has significant implications for nearly all holders of treasuries. But claiming that ALL of the recent volatility is due to this one event is ludicrous. There are some blatant falsities, like saying that gold and silver are historically uncorrelated??? And it’s clear that the author has a bias against the financial establishment (“monopoly money”), coloring the output.

That said, there are legitimately interesting bits here I didn’t know about, like the Japanese institutional liquidation of US treasuries. I would not repeat this information to others without fact checking it, but if accurately described it’s an important space to watch. It’s not surprising that the LLM would get some things right, of course.

One big problem with this article is the clear prompt given to connect x current event to the yen carry trade, like Warsh’s nomination and the Greenland nonsense. This creates a lot of noise. It’s basically the LLM looking for a pattern between these things instead of identifying a structural flow. It might not even be wrong, but it’s horribly biased towards finding a fake pattern, so I would never trust it.

For the tech heads in HN that are excited to see a Justine Tunney post: don’t go crazy. If you’re really interested in learning about the unwinding of the yen carry trade, there’s plenty of information from actual experts to read about, not this slop.

Because those criticisms misses the forest for the trees. You might as well complain about the pollution caused by the Industrial Revolution. AI doesn’t use nearly as much as water as even a small amount of beef production. And we have cheap ways of producing electricity, we just need to overhaul our infrastructure and regulations.

The more interesting questions are about psychology, productivity, intelligence, AGI risk, etc. Resource constraints can be solved, but we’re wrestling with societal constraints. Industrialization created modernism, we could see a similar movement in reaction to AI.

The “fancy math” associated with quant usually refers to pricing derivatives like options.

The thing is that there isn’t really strong institutional demand for exotic derivatives, people are happy using existing methods and just applying those to current markets.

The other type of fancy math has to do with deriving alpha, which is also not that complex, from a statistics perspective you’re mostly using linear regression or other basic forms of regression.

The hard part of quant is implementation, making sure your data is right, hunting through poorly understood markets, and managing risks carefully and understanding them.

There’s also ML but that’s equally complex in quant as it is anywhere else.

This is a miscommunication between the values of “shipping” which optimizes for fastest time to delivery and “correctness” which optimizes for the quality of the code.

Rust makes it easy to write correct software quickly, but it’s slower for writing incorrect software that still works for an MVP. You can get away with writing incorrect concurrent programs in other languages… for a while. And sometimes that’s what business requires.

I actually wish “rewrite in Rust” was a more significant target in the Rust space. Acknowledging that while Rust is not great for prototyping, the correctness/performance advantages it provides justifies a rewrite for the long-term maintenance of software—provided that the tools exist to ease that migration.