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?