One of my favorite pieces of software. FFmpeg has done so much for my career. Happy to see it still going strong.
FFmpeg 9.0
21–30 of 107 posts
Re: FFmpeg 9.0
#22Changelog: - Extend AMF Color Converter (vf_vpp_amf) HDR capabilities - LCEVC track muxing support in MP4 muxer - Playdate video encoder and muxer - Add v360_vulkan filter - HE-AAC 960 decoding (DAB+) - transpose_cuda filter - Add AMF Frame Rate Converter (vf_frc_amf) filter - SMPTE 2094-50 metadata support and passthrough - ProRes RAW VideoToolbox hwaccel - APV Vulkan hwaccel - Animated WebP decoder - Animated WebP…
[dead]
Re: FFmpeg 9.0
#23Earlier quoted context omitted.
I'm curious if they used LLMs to do the tedious work of porting the (de/en)coders to different architectures, and how useful they are here.
Seems like Yes. https://nitter.net/FFmpeg/status/2084084810813743614 "Thank you @ClaudeDevs and @AnthropicAI for supporting FFmpeg through the Claude for Open Source program! So far, Claude has helped find missing backports for the upcoming 9.0 release." Although i was under the impression that they ususally preferred hand optimized assembly. Not sure what their LLM/AI contribution policy looks like compared to other…
> Although i was under the impression that they usually preferred hand optimized assembly.
Using LLMs/agents to do gap analysis and fill boilerplate doesn't rule out also reviewing the output and hand-optimising. That is how the tools should be used (if you aren't being a luddite like me and not using them at all) rather than click-and-hope vibe-coding.
Re: FFmpeg 9.0
#24Ffmpeg has patented codes and is GPLv3, what gives?
Re: FFmpeg 9.0
#25Do I understand right that the last version (v8) was released 8 years ago? So this breaks a long hiatus?
FFMpeg 8.0 came out August 22nd, 2025
8.1 came out 4 months ago on March 16th, 2026
Maybe you're thinking of VLC which has been stuck with a stable v3 release for almost a decade while work on v4 continue?
Re: FFmpeg 9.0
#26Do I understand right that the last version (v8) was released 8 years ago? So this breaks a long hiatus?
Re: FFmpeg 9.0
#27Earlier quoted context omitted.
Seems like Yes. https://nitter.net/FFmpeg/status/2084084810813743614 "Thank you @ClaudeDevs and @AnthropicAI for supporting FFmpeg through the Claude for Open Source program! So far, Claude has helped find missing backports for the upcoming 9.0 release." Although i was under the impression that they ususally preferred hand optimized assembly. Not sure what their LLM/AI contribution policy looks like compared to other…
> Although i was under the impression that they usually preferred hand optimized assembly. Using LLMs/agents to do gap analysis and fill boilerplate doesn't rule out also reviewing the output and hand-optimising. That is how the tools should be used (if you aren't being a luddite like me and not using them at all) rather than click-and-hope vibe-coding.
And as a ffmpeg user with some old/weird hardware, I would much prefer click-and-hope support to no support at all. Ideally they’d have the resources for a real live human to hand-code assembly for every codec for every platform, but that’s probably not realistic. I’ll take what I can get and dust off my assembly skills if a click-and-hope implementation is close but not quite enough.
Re: FFmpeg 9.0
#28Seems Michael Niedermayer wrote that manually, without AI. Good for him. :P
ffmpeg is great, I think nobody disputes this. I use it in two ways mostly:
1) one, via mpv, and 2) two, as conversion tool primarily
ffmpeg also has many really powerful filters, but these are very confusing to use IMO and not elegant at all. I'd wish we could use some kind of simple meta-language or so, in part similar to virtualdub/avisynth (not necessarily suggesting the same API or DSL here, but just the main idea to think of multimedia data as tangible to manipulation as if it were an object oriented system or datastream system; every time I have to use ffmpeg's filter system, I ask myself if nobody designs any of this ...).
Re: FFmpeg 9.0
#29Earlier quoted context omitted.
> Although i was under the impression that they usually preferred hand optimized assembly. Using LLMs/agents to do gap analysis and fill boilerplate doesn't rule out also reviewing the output and hand-optimising. That is how the tools should be used (if you aren't being a luddite like me and not using them at all) rather than click-and-hope vibe-coding.
And as a ffmpeg user with some old/weird hardware, I would much prefer click-and-hope support to no support at all. Ideally they’d have the resources for a real live human to hand-code assembly for every codec for every platform, but that’s probably not realistic. I’ll take what I can get and dust off my assembly skills if a click-and-hope implementation is close but not quite enough.
Makes sense.
The problem I see is that LLM use deters many potential contributors. I understand that in your use case this is not an issue since you prefer working code over theoretical contributors (as said makes a lot of sense), but I am noticing this in many projects that transitioned hard into an AI dependency. It puts a barrier to some people. If 99% of a project's contributions are via AI, is that project still alive?
Re: FFmpeg 9.0
#30Earlier quoted context omitted.
I'm curious if they used LLMs to do the tedious work of porting the (de/en)coders to different architectures, and how useful they are here.
In FFmpeg's twitter page it says that several of their developers got six free months of Claude Max 20x plan through Anthropic's Claude for Open Source Program, and that it was used, so far, to help find missing backports for this 9.0 release.
Sounds like advertisement though.