Honest question. In which scenario do you care so much about the size of the DLL , these days ?

Maybe to encode/decode video on a Mars rover.

Your primary concern is almost certainly power draw, so you're using a hardware encoder. The weight of a few more megabytes ROM would be inconsequential.

I mean the Ingenuity helicopter runs Linux, which seems to suggest that a few megabytes here and there isn't such a big deal; whatever the constraints of mars are, they seem to have a fair amount of onboard storage. I can't imagine that the improved video compression of AV1 compared to Theora or H.264 wouldn't outweigh the cost of that 4MB extra storage space.

That hardware selection was locked-in years ago, I think that's the major hold up with ginny in particular. I don't think even the next helicopter they're building now will be able to get hardware AV1 encoding. Would be moderately funny if they could eek better performance out of ffmpeg with remote updates.

Just FWIW...

* eke out -- extend something by stretching it or using less.

* eek -- a noise of surprise or fear, stereotypically used upon seeing mice.

https://www.dictionary.com/browse/eke--out

Embedded would be my guess.

an embedded machine that 1. has a software decoder, 2. has presumably some ram for that decode and 3. cant afford like 128megs flash on its design for its rom?

Embedded machine with big enough CPU for video encoding, but not having 10-20 MB flash? Doesn't sound too plausible.

Well I'm looking for the same thing, for a lightweight 2D game engine supporting decades old hardware (the game player is 2MB zipped, 1MB for a minimised build). Animations are likely to be low resolution and seconds long, so a huge decoding library would be pointless. Sure, most users don't care about file sizes, but some (including me) still do. Especially for the wasm and Win95 ports.

I considered libtheora, the library size is good but the compression/visual quality is awful compared to the alternatives.

Does that hardware have the CPU power for a recent codec? It doesn't sound like it.

Same use-case, we used to rely on system libraries but the video codec support is all over the place on each platform, and developers would test in their main platform and ship to others without fully testing and have a broken video near the end of their games because WMV runs on Windows but not on macOS, or the audio of the video was a variant of AAC that didn't run in the web port in some places and a bunch of other random differences between platforms to the point the only reliable way was to cut system video libraries and make sure all platforms have the exact same codecd. But then it turns out there isn't something better than Theora or mpg-1 without making the game player have 10x or more in size - the game player is around 3MB unzipped.

This feels like an absurd ask. Who cares how big the codec is? If you watch a 480p video for 10 minutes, won't that have overwhelmingly dwarfed 20MB or whatever of savings?

This feels like a gross gross misoptimization that is actively harmful to 99.999999999% of user experiences.

esp32 with encoded video being streamed out to Wifi?

There's mjpeg for that. Is there any evidence anyone has streamed to such a platform over real video codecs? No there's not. People just make up endless shit to justify anti use cases.

You wont be encoding any video with algorithm more computationally intensive than jpeg on esp32, and even mjpeg will be excruciatingly slow.

mpeg1 seems possible https://github.com/rossumur/espflix

this is decoding

Just because DVDs are several GB doesn't mean it's acceptable for the decoder to be a few hundred MB.

...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.

The size of the codec is so unimportant as to be essentially irrelevant within reason outside of a few extremely niche cases. We care about video file size, we care about subjective quality, we care about power efficiency in compression and decompression, in many applications we care about latency; on all these metrics, modern codecs are stunningly well-optimised. Modern codecs are extremely complex, but that complexity is absolutely necessary for them to perform well on the dimensions that actually matter to users.

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.

> The size of the codec is so unimportant as to be essentially irrelevant within reason outside of a few extremely niche cases.

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.

If you're including a video codec in a phone app, you are almost certainly making a terrible mistake. Android and iOS have very comprehensive media APIs.

VLC is a mistake?

I said almost certainly making a terrible mistake. VLC has an extremely specific niche as "that one media app that plays literally anything in any format ever". You are almost certainly not developing that app. The overwhelming majority of apps have lots of very good reasons to rely on the platform APIs and no good reasons to eschew them.

Is there one codec that's universally available on all supported versions of iOS and all versions of Android with significant use? With an encoder and a decoder? If not, something has to make up the difference, and that something is probably a server that can see all the content.

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.

H.264 and VP8 are available essentially everywhere. Reasonably recent versions of Android and iOS (5.0 and 11, IIRC) include support for H.265 and VP9. The APIs on both platforms make it very easy to query available media formats, including hardware acceleration capabilities. Hardware acceleration is particularly important on mobile for power consumption reasons, so you should use it wherever possible.

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.

> 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.

> Removing support for dead formats is generally a very good idea, particularly in a web browser, because it reduces the attack surface;

This seems unfortunate, surely they could sufficiently sandbox the decoder

They do, but it's defense in depth

Yet websites can run arbitrary JS?

Just because you can't fanthom a legitimate case for needing a small codec lib doesn't mean there isn't one.

Typical engineering myopia.

"I apologize for such a long letter - I didn't have time to write a short one." - Mark Twain, et al.

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?

> Who cares how big the codec is?

Small inefficiencies add up and in the end you have the janky laggy mess that is modern software.

A larger codec doesn't mean it's more inefficient in other areas than a smaller codec. A 400KB codec is not necessarily less laggy or janky than a 4MB codec.

Otherwise, why use a bunch of larger algorithms for map routing when BFS/DFS are so simple and small?

it does contribute to software bloat, I’m always impressed when I install an app and it weighs in at 20MB

How big is the VP8 codec? Did you try building libvpx with --disable-vp9?

Strip out debug symbols if you care about size? There’s no reason either of those libraries should be that large unless you’re including them.

Maybe the best option will be just waiting for h264 patents to expire, just like happened with mp3s a while ago. On that note, does anyone knows when h264 expires? Or it's earlier siblings like avc? It also has the benefit of having vast access to an array of hardware decoders/encoders, although those might have their own can of IP worms.

> does anyone knows when h264 expires

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.

> something else

Isn't AV1 the "preferred" option as a replacement, at least by those who are looking for something high quality and without patents encumbrance?

According to Wikipedia it seems Safari is only now starting to support it, so there's still a large segment of the Apple market lacking support.

The problem is that H.265's patent owners didn't form a single patent pool, so the licensing is a nightmare, with three separate pools, patent holders that never joined a pool, and lots of double-billing all over the place. H.266 isn't much better. So a lot of people just stuck with H.264 as the "good enough" codec as a result. The only people not using it were organizations who couldn't or wouldn't pay for any patented invention (e.g. most of the web standards people, Wikimedia, etc), who stuck with Theora and later VP8.

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.

>So a lot of people just stuck with H.264 as the "good enough" codec as a result. The only people not using it were organizations who couldn't or wouldn't pay for any patented invention (e.g. most of the web standards people, Wikimedia, etc), who stuck with Theora and later VP8.

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.

> Implementations of AV1 in discrete GPUs similarly only landed last year with Nvidia 40 series

NVIDIA has supported AV1 hardware decoding since the 30 series. I believe they were the first to market with it.

Radeon 6000 also supports accelerated av1 decoding. The 7000 series added encoding.

That's the very last patent, and I haven't looked at it in any detail to see whether it might even be relevant to a typical software implementation; a lot of patents are on special optimisations / hardware implementations, so may not be relevant to your use-case.

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.

AVC is not an older sibling, it is H.264, just like H.265 is HEVC.