The exact correspondence between the VPx-es and the MPEG codecs is not that relevant, because old codecs don't go away when new ones come out. In fact, hardware decoders are irrevocably baked into devices where consumption happens, so anything H.264 or newer becomes difficult to displace -- like Google's ham-fisted push [1] for VP8 and VP9 on YouTube for their own benefit, burning through people's batteries in software instead of serving H.264.

But I'd argue that the MPEG codecs roughly slot in between each tier of VP8, VP9, and AV1, because the MPEG codecs are tremendously flexible (as can be seen in Netflix's tests [2]), have dozens of competing encoders of different qualities, and dozens of profiles that constrain or unlock advanced features. So in a way, it can be simultaneously true that AV1's competition is both H.265 and whatever comes after H.265.

[1] https://news.ycombinator.com/item?id=13230676 [2] https://medium.com/netflix-techblog/more-efficient-mobile-en...

VP9 had more browser support than H.265, the codec it competed against. It was Apple's hamfisted attempt to hinder royalty free codecs for the web (among other web standards) that gave some users a bad battery experience. https://ngcodec.com/news/2017/10/21/why-we-are-supporting-vp...

That Google didn't force VP8 over H.264 is what led to the unfortunate situation with Firefox needing to ship a binary blob. I'm happy that Google stuck to its guns in the next round.

How is serving better quality with less bandwidth "ham fisted"? Both Netflix and Google says the codec is better. If anyone was ham fisted it was Apple who fought to stop free codecs'.

He explained that in the same sentence. An imperceptible quality improvement is not worth an order of magnitude increase in CPU usage, and the network savings aren’t enough to make up for dropped frames on hardware which is more than a year old.

Netflix says VP9 is 20% worse than 265... so what are you referring to?

Care to spell this out in more detail for those of us who don't know the relation between x265/h265/codec vs implementation/etc.?

You use x26* to encode h26*.

The correction is correct, albeit a bit pedantic, given the point of GPs comment.

It's the difference between a file format and a library used to write the format.

(but that explanation also glosses over the fact that containers are something else entirely... "data format" may be better than "file format" here)

Codecs are almost like programming languages. They are highly modular and flexible.

Implementations and encoders actually use algorithms to turn the media into something that is compatible with a codec.

That's interesting.

But how can an implementation be compatible with a codec, if a codec is not set in the stone -- i.e. if there are different versions of a codec?

It may help to think about video codecs as standards on how to decode images from a series of bits, not on how to encode them. Decoding is deterministic, encoding is not. You have to consider that these encoders are lossy, i.e. while encoding they modify the information so that it is more easily compressible. Different encoders will do different choices and produce different result while using the same bitrate.

Obviously encoders are constrained by the fact that they must produce a series of bits that can be decoded according to a certain standard, so a new video format can enable encoders to compress information more efficiently (i.e. less perceptual loss of quality at the same bitrate).

That makes it clear, thanks!

Codec refers to the implementation.

Thanks. You are correct. I should have said video coding format.

Very pedantic. The competition is between real encoders not potential encoders.

Actually AV1, H.265, and VP9 are coding formats, while AOM AV1 reference software, x265, and libvpx-vp9 are codecs... while were being pedantic.

we're

That's also unlikely to be true. We saw both VP9 and AV1 come out within h.265's lifecycle (with at least 2 more years to go until the next spec is ready). Chances are there will be an AV2 coming out around the same time of h.266 release.

But either way, the whole industry has already backed an open and royalty-free codec. The release of h.266 (if that's what they're calling it) will be pointless because it's highly unlikely anyone will adopt it. They may as well release it as open source if they did the work anyway.