FFmpeg 7.0 released [LWN.net]

FFmpeg 7.0 released

Posted Apr 5, 2024 14:58 UTC (Fri) by rolexhamster (guest, #158445) [Link] (10 responses)

The most noteworthy changes for most users are a native VVC decoder ...

It can be argued that this is not a useful change, but instead a backwards step.

Why promote the use of the VVC (aka H.266) codec when the AV1 codec is around? VVC doesn't really bring in anything other than making a mess.

VVC is patent encumbered (aka "royalty bearing", aka rent seeking), while AV1 has been explicitly designed as royalty-free.

While I generally applaud the effort put into FFmpeg development, the addition of VVC handling is a misguided decision -- it's ultimately counter-productive, as it hampers the adoption of unencumbered codecs.

FFmpeg 7.0 released

Posted Apr 5, 2024 15:40 UTC (Fri) by koh (subscriber, #101482) [Link]

This is a strange criticisim in light of how FFmpeg sees itself. From its About page:

> FFmpeg is the leading multimedia framework, able to decode, encode, transcode, mux, demux, stream, filter and play pretty much anything that humans and machines have created. It supports the most obscure ancient formats up to the cutting edge. No matter if they were designed by some standards committee, the community or a corporation.

I wonder whether you might be confusing the FFmpeg project with a political advocacy group. I for one do welcome that FFmpeg is as universal as it is and continues to support obscure codecs. Maybe better than absolute statements like "not useful", "misguided decision" or "making a mess" would be a phrase akin "personally, I would like to see all patent encumbered codecs sent to hell", what do you think?

FFmpeg 7.0 released

Posted Apr 5, 2024 16:17 UTC (Fri) by flussence (guest, #85566) [Link] (7 responses)

FFmpeg has a H.266 decoder for the same reason it has a Bink decoder or WMV decoder or RealAudio decoder. For the same reason Linux has an NTFS driver. For the same reason we have software like Pidgin, WINE, yt-dlp, ...

If you surrender the fight against proprietary formats at not even offering their users an escape route, then people will remain wholly dependent on proprietary software to access them. When that proprietary software invokes its DRM suicide pill, all things dependent on it become lost media. We already have a decade of culture lost to SaaS, let's not allow that to be perpetuated.

FFmpeg 7.0 released

Posted Apr 5, 2024 18:56 UTC (Fri) by MarcB (subscriber, #101804) [Link] (6 responses)

> If you surrender the fight against proprietary formats at not even offering their users an escape route, then people will remain wholly dependent on proprietary software to access them

That's not really applicable to VVC. It is an upcoming, struggling standard (the licensing situation is a disaster; the attempts to improve it wrt HVEC failed). I suspect there is no exclusive content in that format, at the moment. Also, the Fraunhofer reference implementation is available under 3-clause BSD.
I'd also assume that CPU implementations of VVC are not that useful, unless you are in a "very cheap electricity vs very expensive or limited data volume" situation. To be an improvement in practice, VVC typically needs a hardware decoder.

Apple appears to have been the hope for VVC, but they finally adopted AV1 in 2023 with the A17 and M3. If the IPhone 16 will not adopt VVC, they likely will never adopt it.
Qualcomm still seems to be pushing it (not surprising, considering their share of the patent pool) while also moving against AV1 with some patent claims (primarily, they tried to get the mandatory patent cross-licensing required by AOMedia overturned. All that they achieved is this statement, AOMedia was required to make: https://aomedia.org/docs/AOM_W3C_Mode_and_the_AOM_Patent_...).

VVC now also is in DVB specs, but there is hardly any decoding hardware (some high-end LG TVs).

FFmpeg 7.0 released

Posted Apr 5, 2024 21:22 UTC (Fri) by roc (subscriber, #30627) [Link] (5 responses)

Decoding VVC makes some sense. Less expensive than encoding, and it means FFmpeg keeps its status as a tool that lets you play any kind of video.

If they add a VVC *encoder*, that would make less sense. Crazy slow and increases the amount of content in a patent-encumbered format.

FFmpeg 7.0 released

Posted Apr 6, 2024 1:35 UTC (Sat) by rolexhamster (guest, #158445) [Link] (1 responses)

If they add a VVC *encoder*, that would make less sense. Crazy slow and increases the amount of content in a patent-encumbered format.

I'd argue that even adding a VVC decoder to FFmpeg doesn't make sense in the current situation.

The mere availability of a VVC decoder is part of a feedback loop that needs to be broken before it has a chance to get started. Availability of a VVC decoder gives (or adds to) reasons for VVC content and VVC encoders to exist.

VVC is evil and anti open-source: is requires royalty payments. With the AV1 codec we have a very strong chance to kill off VVC before it has a chance to grab a foothold. Anything that hampers AV1 adoption (even indirectly) is counter-productive.

Do we really want another repeat of the mess we have with H.264 and H.265?

FFmpeg 7.0 released

Posted Apr 6, 2024 6:32 UTC (Sat) by intelfx (subscriber, #130118) [Link]

> Availability of a VVC decoder gives (or adds to) reasons for VVC content and VVC encoders to exist.

They will have enough of those reasons with or without FFmpeg support.

FFmpeg 7.0 released

Posted Apr 8, 2024 2:16 UTC (Mon) by cypherpunks2 (guest, #152408) [Link] (2 responses)

Encoders are far more complex than decoders. FFmpeg tries to support native decoding and will often write their own decoders, but they link against other libraries for the majority of their encoding. In fact, when they do have native encoding, it's usually inferior to libraries it links against (the native aac encoder is inferior to libfdk_aac, the native opus encoder is much worse than libopus, etc).

FFmpeg will not write a VVC encoder (that would be an insanely complex task, easily 100x harder than writing the decoder), but as soon as MulticoreWare releases x266, they will include the option to link against libx266. There's nothing wrong with that.

FFmpeg 7.0 released

Posted Apr 8, 2024 7:00 UTC (Mon) by epa (subscriber, #39769) [Link] (1 responses)

In principle if you have a decoder you can make an encoder -- by producing random data until you get something that decodes to the original file. That's totally impractical of course. I wonder whether one day AI would be able to help with that? By "evolving" the random data somehow, or by hacking together something that might possibly be an encoder and then "evolving" that using the decoder as a way to keep score. You could do these things without the help of generative AI, they're not new ideas, but they are still totally impractical if you rely on blind natural selection and completely random changes. But if the limited programming skills of ChatGPT, Claude, Devin and the like could be applied to encoding, making small improvements and checking how it matches the decoder on a corpus of typical video files (or even randomly generated test cases)...

FFmpeg 7.0 released

Posted Apr 8, 2024 19:11 UTC (Mon) by cypherpunks2 (guest, #152408) [Link]

These codecs are lossy. Nothing will decode to the original file, and just creating a valid bitstream isn't enough for an encoder to be useful. Encoders are very finely tuned to create a bitstream that gives you a video that is similar to the original. Codecs are defined by their decoders (all compliant decoders will decode the same bitstream to the same output), but the encoders are free to be creative to find new ways to compress input.

Pure end-to-end AI encoders exist but they are very very slow (think 0.0001 fps) and they can only really compete with H.264. Maybe one day in the future they will be more useful but not for a long time. What I think AI will be useful for is finding new non-patented early-exit heuristics. The encoder would not be using AI, but it would be using techniques discovered and fine-tuned with the help of AI. A lot of encoder R&D goes into finding and optimizing these early-exit heuristics (because use of brute force to try all techniques and modes on each portion of the image to find the optimal one every time is impractical. Only something simple like optipng can truly brute force all combinations of settings to shave off a percent or two).

FFmpeg 7.0 released

Posted Apr 8, 2024 2:55 UTC (Mon) by cypherpunks2 (guest, #152408) [Link]

FFmpeg is the swis army knife of multimedia. It would be much better for people to go to an open source GPLed application for all their encoding needs (no matter how proprietary or patent-encumbered) than some proprietary and closed source multimedia suite. If FFmpeg only supported open codecs, it would be a niche tool used by FOSS enthusiasts only and it would not be the behemoth of a tool that it is today.

If you don't like FFmpeg supporting patent-encumbered codecs, you can always build it yourself with the problematic codecs removed. It's just a matter of passing the right options to the configure script.

FFmpeg 7.0 released

Posted Apr 5, 2024 14:59 UTC (Fri) by numgmt (guest, #167446) [Link] (3 responses)

I wonder how much use VVC is getting. The AOM crowd is staying well away from it, obviously. Does Apple include decoders for it? Have any hardware manufacturers created hardware encoders/decoders for it (though it hasn't been long, I wonder if there's any interest)? Interesting to see that very few companies that held patents for H.264 are in Via-La's patent pool: https://www.via-la.com/licensing-2/vvc/vvc-patent-list/

And that there's far fewer of them...though it's still early days. Took the opportunity to check out the H.264 patent pool at Via-La: over 80% of the patents have expired now but there are still hundreds of them left: https://www.via-la.com/licensing-2/avc-h-264/avc-h-264-pa...

I'm more excited about the multi-threaded ffmpeg CLI tool.

FFmpeg 7.0 released

Posted Apr 5, 2024 15:50 UTC (Fri) by MarcB (subscriber, #101804) [Link] (2 responses)

The patent situation is as messed up as with HEVC, potentially even worse. They tried to do better, and form a single pool again (as with AVC), but failed.

I doubt it will ever become relevant on desktop systems. It almost certainly will never be shipped by Linux distributions; there are explicit licensing fees for free (free as in beer) software after a million copies that would also apply to truly free software.

FFmpeg 7.0 released

Posted Apr 5, 2024 18:26 UTC (Fri) by tuna (guest, #44480) [Link]

It will probably be shipped in 20 years when the patents expire.

FFmpeg 7.0 released

Posted Apr 5, 2024 19:41 UTC (Fri) by elenril (subscriber, #165899) [Link]

>It almost certainly will never be shipped by Linux distributions;
At least Debian washed its hands of the patent nonsense over 10 years ago and enables everything in its builds.
That said, times have changed, and decoding "scene" movies on a desktop/laptop is no longer as common a use case as it used to be.

FFmpeg 7.0 released

Posted Apr 5, 2024 16:09 UTC (Fri) by NightMonkey (subscriber, #23051) [Link]

Big congratulations to the FFmpeg devs and contributors!

FFmpeg 7.0 released

Posted Apr 7, 2024 9:58 UTC (Sun) by job (guest, #670) [Link] (3 responses)

Are the forks dead now? It seems the libav.org domain does now resolve anymore.

FFmpeg 7.0 released

Posted Apr 8, 2024 5:28 UTC (Mon) by krashanoff (subscriber, #170424) [Link] (1 responses)

It seems so. Wikipedia now notes it as an “abandoned free software project” (https://en.wikipedia.org/wiki/Libav).

When I checked in 2022, the latest commit to libav’s master branch was authored in 2019, and the most recent release was in 2018.

FFmpeg 7.0 released

Posted Apr 9, 2024 2:34 UTC (Tue) by cypherpunks2 (guest, #152408) [Link]

Yes, libav is long gone. The devs responsible for the fork have all either returned the ffmpeg or quit multimedia altogether.

This is a great explanation of the events: https://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html

FFmpeg 7.0 released

Posted Apr 8, 2024 7:16 UTC (Mon) by andrey.turkin (guest, #89915) [Link]

Well, there is librempeg now. But that is single person rage-quitting FFmpeg in order to make his own, with blackjack and stuff, nothing like libav split was.

FFmpeg 7.0 released

Posted Apr 12, 2024 13:15 UTC (Fri) by marksugrue (guest, #170881) [Link]

Loving the significant speed improvements in v7.0 for CLI transcoding due to multithreading. Tool now better uses CPU resources on a multi-core machine. I noticed, however, that some tasks don't seem to multi-thread - or perhaps I need to alter my command? For example

ffmpeg.exe -stdin -y -loglevel info -i "videofile.mp4" -f rawvideo -s widthxheight -pix_fmt bgr24 -

It works in v7 as before but seems to just use a single core, as before. Is there a way to force multithreading or is this not (yet?) supported for -f rawvideo?