FFmpeg 7.0 Released With Native VVC Decoding & Multi-Threaded CLI

[pWe00Iri3e7Z9lHOX2Qx]

Several reasons, none of them are because there are any proven patent claims to x264.

1. There had been claims made against x264, obviously without any success. So some people were scared off
2. Cisco is part of the MPEG LA and guarantees for no claims being made against OpenH264. The Videolan project can't give any such guarantees
3. x264 is GPL 2+, which does make some people uncomfortable because of GPL's viral nature. Only since 2010 it's also allowed to have it under a proprietary license. OpenH264 is under a simplified BSD license
4. OpenH264 first and foremost was made for Firefox for real time encoding for WebRTC. x264 wasn't able to handle this
5. especially the people at Fedora are ridiculously paranoid. To an extent that they removed support for h264 hardware codecs just a few years back, after having them for god knows how many years, just like pretty much every distro and no claims ever being made.

Repeating the same thing over and over again doesn't make it true. It doesn't even make logical sense that creating an open source encoder or decoder for a patent encumbered codec would magically make the codec not patent encumbered. I'm pretty sure the Director of Global Licensing for the MPEG LA knows what he is talking about, but I have a feeling you'll just move the goal posts again.

https://lwn.net/Articles/371751/

I read through the FAQ and can't find out if Free and Open Source
developers and products need to license the MPEG-LA patents for
MPEG-4 Visual. It was alleged (http://lwn.net/Articles/370985/)
in a comment that royalties are only necessary for products sold,
not for free products. Is this correct? Could you please comment
on the licensing options for Free (e.g. GPL) and open source
implementations of MPEG-4 Visual, specifically h.264? What about
downstream users/developers/distributors of Free and open source
software?
I'll post your reply to the above comment list when I've received it.
Thank you very much,



==========REPLY==========
Subject: RE: Free and Open Source implementations of MPEG-4 Visual?
Dear Joseph,
Thank you for your message. We appreciate you contacting MPEG LA
regarding our Licenses and I will be happy to assist you.


By way of background, I would like to point out that the Licenses
offered by MPEG LA are provided as a convenience and an alternative to
negotiating direct licenses with many individual patent owners. While
MPEG LA offers the Licenses to the marketplace, it is the patent owners
participating in our Licenses (not MPEG LA) who establish the License
terms and royalty rates.


Our MPEG-4 Visual Patent Portfolio License includes 29 patent owners
contributing more than 900 patents that are essential for use of the
MPEG-4 Visual (Part 2) Standard. Our AVC Patent Portfolio License
includes 25 patent owners contributing more than 1,000 patents that are
essential for use of AVC/H.264 Standard ("MPEG-4 Part 10").


Under the Licenses, coverage is provided and rights are granted for (a)
manufacturers to make and sell MPEG-4 Visual/AVC Products and (b) for
such MPEG-4 Visual/AVC Products to be used to deliver MPEG-4 Visual/AVC
Video content. The Licenses were set up this way so as to apportion the
royalty at points in the product/service chain where value is received,
and also to not place the full royalty burden on one party in the chain
(e.g., an encoder maker).


In response to your specific question, under the Licenses royalties are
paid on all MPEG-4 Visual/AVC products of like functionality, and the
Licenses do not make any distinction for products offered for free
(whether open source or otherwise). But, I do note that the Licenses
addresses this issue by including annual minimum thresholds below which
no royalties are payable in order to encourage adoption and minimize the
impact on lower volume users. In addition, the Licenses also include
maximum annual royalty caps to provide more cost predictability for
larger volume users.


I would also like to mention that while our Licenses are not concluded
by End Users, anyone in the product chain has liability if an end
product is unlicensed. Therefore, a royalty paid for an end product by
the end product supplier would render the product licensed in the hands
of the End User, but where a royalty has not been paid, such a product
remains unlicensed and any downstream users/distributors would have
liability.


Therefore, we suggest that all End Users deal with products only from
licensed suppliers. In that regard, we maintain lists of Licensees in
Good Standing to each of our Licenses at http://www.mpegla.com.
I hope this explanation is helpful. If you have further questions or
would like additional information, please feel free to contact me
directly.


Best regards,


Allen


Allen Harkness
Director, Global Licensing
MPEG LA

[Quackdoc]

Lots of great goodies here

• IAMF for immersive audio, an alternative to dolby and dts
• D3D12VA will help windows users, I presume mostly game engines will make use of this, and probably some video players
• VVC shame about the patent situation, it's rough. don't forget folk that FFMPEG disregards patent situation for licencing, it may be GPL compatible for some countries, but not others.
• bsf for input is nice for a lot of things
• ffplay with libplacebo is nice for a lot of things, will let users trial encode settings for things like tonemapping before encoding
• android URI support is probably minor for a lot of people, but I can see a couple things making use of this, possibly MPV Android
• filmgrain synth is majorly nice. It saves a lot of space while being quite pleasing to look at.
• Dolby Vision in AV1 is afaik unofficial so don't expect it to work everywhere.
• HDR10 passthrough is nice for obvious reasons

[Quackdoc]

Holy crap that's impressive. I hope kdenline can now use all 16+16 cores on high end ryzens.

multithreading is for CLI, Video editors wont be effected by this, whether they thread well or not for anything but encoding is up to the editor. Note that encoding is the hardest cpu intensive part for most editors that have GPU accelerated compositing.

The only thing a video editor can really do to make encoding thread better is by chunking it and encoding chunks in parallel, much like the av1an encoding tool.

Depends on what you're doing. Your typical video encoding process can't be parallelized that much if the processes themselves aren't. One example: encoding AV1 with the aom encoder is single threaded, while SVT-AV1 is designed to be multithreaded. So only if you actually have tasks that don't require any serialization you'll see any improvements.

aom isn't single threaded, but granted it can feel like it at times, it sure aint as good as svtav1, I find it sits happily at 2-3 threads, and anything beyond 4 threads useless

[Artim]

ffmpeg has got a huge number of optional dependencies. Even when you have all of them properly installed, there are still a huge number of configure flags to wade through. Luckily though we don't live in an LFS world and every major distro has competent build systems made specifically for complex projects just like ffmpeg. It really is a matter of familiarity and proficiency, once you've done something so many times it begins to feel natural and you just get used to it and it becomes easy.

You don't need to lecture me. Just read back what the original point was

[Artim]

Not an opinion:

https://patents.google.com/patent/US20050238100A1/en

https://patents.google.com/patent/CN103227925A/en

https://patents.google.com/patent/US5650860

https://patents.google.com/patent/US11451840B2/en

https://patents.google.com/patent/US...n+optimization

It's still just your opinoin that x264 actually infringes any patents.

[Artim]

Copyright, patents, and trademarks are completely independent systems. x264 is good on the copyright front, but not the patent front.

(Originally, copyright was for books and maps and patents were for machine designs. The overlap happened when copyright lobbyists and patent lobbyists both convinced the U.S. government that their scopes should be expanded to cover software, but they're still independent systems.)

Basically, you can legally redistribute the plans for "the x264 machine" (the source code) but, because the "mechanical mechanisms it incorporates" (the ones listed by sophisticles) are patented, you need a license to legally be able to manufacture physical machines from those plans... given the nature of open-source software, that means "you'd better have a license if you do anything where the MPEG-LA will notice".

That's actually sort of the original vision for patents. Inventors are incentivized to make their trade secrets public for anyone to read in exchange for a time-limited monopoly where even people who come up with the same thing independently still have to pay them to use it.

Sure, that must be the reason why everyone except a few distros run by paranoids ships x264 binaries, yet nobody sued them. You can bet your ass, if MPEG LA can make money out of anything, they will try. See Broadcom vs Netflix and dozens of other examples.

[Artim]

Repeating the same thing over and over again doesn't make it true. It doesn't even make logical sense that creating an open source encoder or decoder for a patent encumbered codec would magically make the codec not patent encumbered. I'm pretty sure the Director of Global Licensing for the MPEG LA knows what he is talking about, but I have a feeling you'll just move the goal posts again.

https://lwn.net/Articles/371751/

It's absolutely irrelevant what the patent pool itself wants to be true. Of course they'll tell you that you need to pay, whether that's true or not. Especially the MPEG LA is that desperate. That doesn't prove any truth to it. On the opposite, they disprove themselves. Otherwise they would have made sure long ago that anybody shipping binaries for x264 or x265 is paying the royalties. I don't know of a single distro paying these. And so doesn't the videolan team, while shipping the VLC player including x264 and x265.

[Artim]

aom isn't single threaded, but granted it can feel like it at times, it sure aint as good as svtav1, I find it sits happily at 2-3 threads, and anything beyond 4 threads useless

True, in a quick test I actually didn't see any single threaded ones, they are just poorly multi-threaded

[williamthrilliam]

And still no proper AC-4 audio support.

[ssokolow]

Sure, that must be the reason why everyone except a few distros run by paranoids ships x264 binaries, yet nobody sued them. You can bet your ass, if MPEG LA can make money out of anything, they will try. See Broadcom vs Netflix and dozens of other examples.

It's because MPEG-LA has decided to take a "Microsoft turns a blind eye to most Windows piracy for 'opium for China' reasons" or "WinRAR's perpetual free trial" strategy. Make it the end-user's responsibility to pay for licensing for open-source implementations, and get the individuals hooked on it to build up network effects that force valuable corporate users to use H.264, which are much more cost-effective to send legal threats to.