I tried to use VP9 in the past but it's like 20-40MBs a dll. The lowest I could find was dav1d and it's still around 4MB for the library dll and encoding AV1 and getting good compression rate was not trivial.
I was wondering about this too. https://www.osnews.com/story/24954/us-patent-expiration-for-... seems to think 12/2027.
Would it be surprising if H.264 was replaced by something else by that point? We have multiple subsequent standards, and it seems like everyone producing or providing content would want improved codecs by then.
Isn't AV1 the "preferred" option as a replacement, at least by those who are looking for something high quality and without patents encumbrance?
AV1 (itself derived from the On2 VP8 and VP9 formats) is supposed to be the answer to H.265's patent shenanigans, but support is very slow to manifest. Like, Apple only added it to the iPhone 15 - as in, the one that just came out a month ago. Implementations of AV1 in discrete GPUs similarly only landed last year with Nvidia 40 series, Intel Arc, and Radeon 7000 series cards.
h.265 is very popular in the piracy scene, since you can get a file size about half that needed for equivalent-quality h.264. Of course, being pirates, they don't worry about patents. And since decoders are freely downloadable for players like VLC, there's no good reason not to use it.
NVIDIA has supported AV1 hardware decoding since the 30 series. I believe they were the first to market with it.
It's also noteworthy that of the full list of H.264 patents here:
https://scratchpad.fandom.com/wiki/MPEG_patent_lists
...the majority of them have already expired. IANAL but since the original H.264 spec became public 20 years ago, everything in it should be usable as prior art.
Also, all existing MPEG-4 part 2 (infamous DivX etc.) patents and anything older, e.g. H.263, MPEG-1/2 and H.261, have certainly expired by now.
* eke out -- extend something by stretching it or using less.
* eek -- a noise of surprise or fear, stereotypically used upon seeing mice.
I considered libtheora, the library size is good but the compression/visual quality is awful compared to the alternatives.
This feels like a gross gross misoptimization that is actively harmful to 99.999999999% of user experiences.
...and in fact it doesn't need to be, as I can say so from having written an MPEG-2 (+MPEG-1) decoder myself, whose binary turned out to be less than 16KB.
When one hears about a codec being dozens of MB, the natural instinct should be "for what?" and not "who cares?" The latter attitude is responsible for why software has gotten so much more inefficient, and serves only to line the pockets of hardware manufacturers.
Nobody uses Theora, because it's a bad codec. It was worse than H.264 back in 2009 and it hasn't been updated since. Removing support for dead formats is generally a very good idea, particularly in a web browser, because it reduces the attack surface; we have recently seen a number of major vulnerabilities caused by archaic, neglected file formats and codecs that provided almost no value to users.
Codec size matters if you're going to include the codec in a phone app, which is a huge niche.
You can try to rely on system codecs, but then you're at the mercy of system codec availability and system codec security.
Is it space efficient? (Compared to whatever you're prepared to license and run on the cpu) Not shipping a codec to save app size but sending larger media doesn't help the user much.
Are all implementations secure? If you have to predecode to verify the file won't trigger buffer overruns etc, you've written half of a safe decoder, and maybe you should just include the rest of the owl. Media decoding is a bountiful area of security vulnerabilities... which brings risks to both using the system apis and using your own, but at least you have some control over your own.
If any app developer believes that they are better able to implement a secure codec than Apple or Google, I have a bridge to sell them.
Google isn't the only one providing system codecs on Android phones.
This seems unfortunate, surely they could sufficiently sandbox the decoder
Typical engineering myopia.
A codec bloated by megabytes to me is a little too close to a web site bloated by megabytes. It works...but isn't it also a little embarrassing?
Small inefficiencies add up and in the end you have the janky laggy mess that is modern software.
Otherwise, why use a bunch of larger algorithms for map routing when BFS/DFS are so simple and small?