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).
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.
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.
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.
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.
Grokipedia is impressive. All edits to the original Wikipedia article are shown, along with source links for the edit. All anyone has to do is to look at a wikipedia article and the Grokipedia article side by side to see that Grok is usually able to make significant improvements to articles, adding important context, improving explanations and removing bias. Don't knock it 'til you've tried it. If you haven't tried it because of a hatred of Elon Musk... well... who's the biased one?
It's always healthy to be skeptical, but we know that on the whole, sunlight is healthy for humans. People who get more sun exposure live longer (even though they have a higher incidence of melanoma). We know that it's more than just the Vitamin D that is produce when our skin is exposed to sun. There are numerous studies showing the benefits of sunshine, so the next question is "what is the mechanism for sunshine to improve human health?". One theory is that it stimulates the production of intra-cellular melatonin. A seminal paper on this topic is "Melatonin and the Optics of the Human Body".... http://sininenankka.dy.fi/~sami/kielletyt_uutiset/melatonin_...
Some factors controlled for: smoking, history of antidiabetic meds, history of CVD meds, weight/height/BMI, level of exercise, income, alcohol consumption, N pregnancies.
I think these factors pretty well correlate with "health" (however you'd measure actually that).
> Despite having adjusted for several potential confounders, the major shortcoming of this study is the inability to distinguish between the consequences of an unhealthy lifestyle and of avoidance of sun exposure.
Take depression for example. None of the factors you mentioned would control for it and depression is often not diagnosed, especially early on.
Agreed, and you already addressed this with your sibling comment. I just thought it was an amusing counterpoint to "healthy people go outside more than sick people".
Most people are deficient in iodine. We don't eat a lot of iodine rich foods, and commercial farming techniques have depleted soils of many minerals and elements. Tissues in the body that should be absorbing and storing iodine, which is an essential element for thyroid hormone, will preferentially store bromine. Bromine has also been used to make flame retardant fabrics, carpet, furniture, etc. Avoid it.
> Bromine has also been used to make flame retardant fabrics, carpet, furniture, etc.
While this argument feels right, chemically it makes no sense. You can do this with any element. It’s the same as saying you shouldn’t drink water because it has hydrogen and oxygen which are used as rocket fuel.
No, it's not the same. Molecules act very differently than the individual elements that make the molecule. Water does not behave similarly to hydrogen or oxygen, and humans aren't plants, which can break water into component elements.
What happens to the bromine when humans ingest brominated vegetable oil? Something very different than what happens when we ingest water, which always stays stable as a water molecule.
As someone who started and ran a very successful open source project, I feel his pain. You get a large following of adopters, some of whom feel entitled to demand features or priority for bug fixes even though they aren't contributing anything to the project. If they don't get what they want, they start bad-mouthing you in order to bring more pressure. After about 6 months of observing this, I finally had a good discussion with my brilliant Principal Architect, who helped me respond as follows...
If you would like a new feature or bug fix, you have the following options;
1 - Improve the code yourself.
2 - Pay someone to improve the code.
3 - Ask nicely, and wait patiently. Or,
4 - Openly criticize the project leads.
If it were me, I wouldn't choose option 4. But that's just me.
Once I posted this to the main forum thread where people discussed the project, most of the participants rallied to support me, and peer pressured in the discussion threads helped keep open source entitlement to a minimum.
For context, this rant was inspired by someone who complained that "1. Improve the code yourself" was prohibitively slow and even if you did solve the problem there could be a months/years-long turnaround only for it to be declined:
I don't think they're wrong that it's not a great way to work for the contributor and I can see why they'd want to write this gist in frustration. They're obviously being mostly fair to the people involved, but think that the process is just tedious and bad for contributors.
So I think you're off base; you're not in fact talking about the same issue here and Hickey is addressing real contributors who are trying to improve the code.
reply