[dead]
FFmpeg 9.0
51–60 of 107 posts
Re: FFmpeg 9.0
#52Earlier quoted context omitted.
I recommend watching the Lex Fridman interview with Jean-Baptiste Kempf and Kieran Kunhya. Amazing work on and amazing project.
Though there is one part I didn’t understand in that interview. They were complaining of being overwhelmed by AI submitted bug reports (fair), including for obscure codecs that must have been used by a couple of users at most. And therefore implying that securing those codecs is low priority/important. I don’t understand that. To me the severity has nothing to do with how popular is a code path, but whether that code…
That sounds nice in theory, but it seems obvious to me there is a major discrepancy between who is burdened with this responsibility, and who benefits from the result. Given many of these contributors are unpaid volunteers, maybe the infrastructure provider needs to secure FFmpeg in another way, for example by restricting codecs or by running it in a container?
Re: FFmpeg 9.0
#53Earlier quoted context omitted.
Though there is one part I didn’t understand in that interview. They were complaining of being overwhelmed by AI submitted bug reports (fair), including for obscure codecs that must have been used by a couple of users at most. And therefore implying that securing those codecs is low priority/important. I don’t understand that. To me the severity has nothing to do with how popular is a code path, but whether that code…
That sounds nice in theory, but it seems obvious to me there is a major discrepancy between who is burdened with this responsibility, and who benefits from the result. Given many of these contributors are unpaid volunteers, maybe the infrastructure provider needs to secure FFmpeg in another way, for example by restricting codecs or by running it in a container?
The creator of borg and k8s of course already run such tools for untrusted inputs in containers, but there is also an endless stream of container escapes.
Re: FFmpeg 9.0
#54For those interested in the work being done, with a bit more details that just the Changelog, I wrote a longer blogpost about the work here: https://jbkempf.com/blog/2026/ffmpeg-9.0/
More details about the ongoing work on Swscale rewrite, on the various Vulkan changes, the assembly detailed and a bit of statistics about this release.
Re: FFmpeg 9.0
#55Watching ffmpeg go from a niche tool for web back ends to what it is now has been incredible.
It's still very niche though, I bet not a single youtuber or OF-girl known they use it
> I bet not a single youtuber
I know this is hyperbole to make a point even this is ridiculous. A lot of YouTubers mess around with their audio/video files, and am sure they have heard of ffmpeg.
Re: FFmpeg 9.0
#56Changelog: - 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…
> - ONNX Runtime DNN backend with GPU execution provider support Oh, wonder what fancy new things this will enable. Any examples in the wild already perhaps?
Well, not that important to me since we already had that in Vapoursynth.
Re: FFmpeg 9.0
#57Earlier quoted context omitted.
I recommend watching the Lex Fridman interview with Jean-Baptiste Kempf and Kieran Kunhya. Amazing work on and amazing project.
Though there is one part I didn’t understand in that interview. They were complaining of being overwhelmed by AI submitted bug reports (fair), including for obscure codecs that must have been used by a couple of users at most. And therefore implying that securing those codecs is low priority/important. I don’t understand that. To me the severity has nothing to do with how popular is a code path, but whether that code…
It's all about time in the day, my friend. Do you want to secure a feature used by 100% of your users or 0.01% of your users? Which has a better ROI?
Re: FFmpeg 9.0
#58I still hope a future FFmpeg release will make Intel QSV encoding available on Windows laptops where the manufacturer disabled this capability from the ACPI tables. The only way to use it on these laptops is currently FFmpeg on Linux.
[dead]
Re: FFmpeg 9.0
#59It is interesting, that changes from 8.0 to 8.1 is more substantial than from 8.1 to 9.0.
I don't say it to mean "they did less work," no, what his interesting to me is choice of major version bump instead of minor one.
Re: FFmpeg 9.0
#60Earlier quoted context omitted.
Though there is one part I didn’t understand in that interview. They were complaining of being overwhelmed by AI submitted bug reports (fair), including for obscure codecs that must have been used by a couple of users at most. And therefore implying that securing those codecs is low priority/important. I don’t understand that. To me the severity has nothing to do with how popular is a code path, but whether that code…
It's all about time in the day, my friend. Do you want to secure a feature used by 100% of your users or 0.01% of your users? Which has a better ROI?
Given that it is easy to feed FFMPEG arbitrary input to exploit any vulnerability, popular codecs are very likely to be already secure enough, while unpopular ones are far more dangerous and deserve more attention. It can be assumed that an attacker would target the worst, easiest to exploit codec they can find in the whole of FFMPEG.