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.
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).
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.
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?