AV1 is a codec, not an implementation. Its competition is the upcoming H.266. VP9's competition was H.265, and libvpx-vp9's competition was x265.

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.

No, VP9's competition is HEVC/H.265, VP9 ties for efficiency and wins on practical deployment on open platforms. AV1 is competing with all of these codecs, at every resolution, and at every complexity point, but especially with HEVC's successor planned for 2021.

This. Even if it takes another year to optimise its encoder and develop hardware acceleration, AV1 will be in the market for two years before MPEG's 2021 forecast.

HEVC's successor will need to be materially superior AND have compelling and final patent licensing terms in order to be remotely viable.

>materially superior

To AV2, that is. I don't expect this to stop at AV1.

As compressing more gets harder and harder, a significant enough improvement to tempt people into using a royalty-encumbered codec is unlikely to happen ever again.

Nobody's competition is x265 (HEVC) until its patent licensing situation is clarified.

Of the streaming services that currently do 4k or HDR, only YouTube isn't using HEVC.

Actually thinking about it again, I guess most 4k porn probably isn't HEVC, though for other reasons I suspect. But Netflix, Amazon, etc. all kept distributing HEVC when the licensing situation was even worse than it is now.

Not in terms of price. HEVC can cost more than $1 per unit. To high for things like rpi.

The Raspberry Pi Foundation has previously supported MPEG-2 and VC-1 hardware-based decoding by selling additional licenses in their online store [1][2]. By making the licenses optional they didn't need to increase the cost of all Raspberry Pi devices unnecessarily.

There isn't any reason they couldn't do the same for HEVC or H.266 as long as the hardware support was there.

[1] http://www.raspberrypi.com/mpeg-2-license-key/

[2] http://www.raspberrypi.com/vc-1-license-key/

> There isn't any reason they couldn't do the same for HEVC

The practical problem with HEVC licensing is that it's complex and uncertain. There are three separate patent pools (MPEG LA, HEVC Advance, and Velos Media) and there are other licensors who aren't in any patent pool. The licensing situation is so bad that Leonardo Chiariglione, founder and chairman of MPEG, calls HEVC an "unusable modern standard":

http://blog.chiariglione.org/a-crisis-the-causes-and-a-solut...

A while back the x265 team pleaded with the industry to sort out the HEVC licensing problems, but that never happened:

http://x265.org/proposal-accelerate-hevc-adoption/

HEVC licensing may be too risky for the Raspberry Pi Foundation. It's simpler to use H.264 and VP9 today and to look to AV1 for the future.

> There are three separate patent pools (MPEG LA, HEVC Advance, and Velos Media)

Four pools — also Technicolor.

Thee gpu/video block hasn't been updated since RPi 1, I wonder what their plan is.

To the extent that is true it seems like x265 already lost the fight for Facebook's usecase of web video before they even ran the software.