Not a Lex Friedman fan, but I highly recommend the recent podcast he did with two leading engineers (and founder) from the ffmpeg project: https://www.youtube.com/watch?v=nepKKz-MzFM
In a world full of endless AI slop, it is refreshing to see that there are still folks out there hand-rolling assembler code to squeeze out another 5% efficiency.
Seems 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 ...).
ffmpeg's filter system is what you get when you design a meta-language for it.
It's also not that bad once you take a bit of time to learn it - it's just a textual encoding of a graph where each node is a filter with a number of properties.
Only slightly broken already. Dont remember the details, but Gemini could not this to work just by reading the manual. https://github.com/timonoko/Skipperi
I 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.
You could, but there's two big reasons why this isn't useful:
1. The translation system would still have to implement the underlying ideas. For example, your spec might explain "key frames are made by doing a wavelet transform ABC, dropping frequency XYZ, applying Heuristic Alpha and then doing LZ encoding on the result" or something like that. You still need implementations of those specific operations. Having to explain all that stuff in the spec would mean each english language doc would be book length tretsie on encoding. As a result, you don't really gain much by doing this kind of meta-explaination.
2. Video encoding/decoding is something where optimization is extremely important. Writing code that is specific to a single purpose is generally going to be faster than generic code that could be applied to any theoretical format. For example, by knowing the exact size of a transformation matrix, you can decide whether to build a lookup table or calculate on the fly - you can use hardware level features that require knowing exact sizes at build-time etc.
For 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.
Bless everyone who has the patience to deal with all the crazy crap audio video etc codecs and stuff throws out there and they figure out ways to put it into a free tool suite.
24 comments
[ 2.6 ms ] story [ 19.3 ms ] thread- 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 demuxer
- Remove CELT decoding support (doesn't affect Opus CELT)
- Remove ogg/celt parsing
- Bitstream filter to split Dolby Vision multi-layer HEVC
- Add AMF hardware memory mapping support.
- ONNX Runtime DNN backend with GPU execution provider support
- Remove deprecated NVENC options and support for pre-11.1 SDK versions
Hah! Useful for me today, to get rid of some hacks. Good stuff FFmpeg. It truly continues to be a pillar supporting the world in so many ways.
I guess I am the only one excited to see this.
In a world full of endless AI slop, it is refreshing to see that there are still folks out there hand-rolling assembler code to squeeze out another 5% efficiency.
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 ...).
It's also not that bad once you take a bit of time to learn it - it's just a textual encoding of a graph where each node is a filter with a number of properties.
1. The translation system would still have to implement the underlying ideas. For example, your spec might explain "key frames are made by doing a wavelet transform ABC, dropping frequency XYZ, applying Heuristic Alpha and then doing LZ encoding on the result" or something like that. You still need implementations of those specific operations. Having to explain all that stuff in the spec would mean each english language doc would be book length tretsie on encoding. As a result, you don't really gain much by doing this kind of meta-explaination.
2. Video encoding/decoding is something where optimization is extremely important. Writing code that is specific to a single purpose is generally going to be faster than generic code that could be applied to any theoretical format. For example, by knowing the exact size of a transformation matrix, you can decide whether to build a lookup table or calculate on the fly - you can use hardware level features that require knowing exact sizes at build-time etc.
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.
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.
[https://youtu.be/9kaIXkImCAM]