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.
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...
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.
The correction is correct, albeit a bit pedantic, given the point of GPs comment.
Implementations and encoders actually use algorithms to turn the media into something that is compatible with a codec.
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?
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).
(but that explanation also glosses over the fact that containers are something else entirely... "data format" may be better than "file format" here)
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.