@Mina @KDWang @chris_e_simpson @rugkThis comment was more or less a joke, but okay, if there are those who take my words seriously, I'll make a longer writeup.
Technically yes, they are open, but Google controls the reference implementation. If you come up with your own implementation and they want it gone — they will accomplish it easily, they'll just start changing theirs breaking compatibility and you won't be able to keep up with them — you simply don't have their manpower.
If you start extending your implementation, no one will use it as the one used in Chrome doesn't support that.
So it's open in words only, de-facto they have complete control over it, you can't compare it to ARPA stuff — it's nothing close to that. US military can't exercise such control over the protocols we use today.
Their efficiency is also debatable: WebP offers about 10% better compression on average — it's not a game changer, hardly enough to justify new codec to be supported in every browser. Imagine yourself developing a completely new browser today, if everyone uses WebP, you will have to support it too. And you have two ways: implementing it from the ground up spending developer-hours on that or you can rely on Google's implementation — last week a vulnerability has been discovered in their implementation that was rated high severity even by Mozilla. Now we take a step back to the fact that it only offers a marginal advantage compression-wise over existing codecs and now supporting it doesn't seem reasonable at all 🤷
I think the sole purpose of its existence is making developing new browsers harder. KHTML, predecessor to WebKit has been developed by KDE project. Is something like that possible today? I don't think so — modern web browsers are too complex and adding more to that complexity strengthens our reliance on Chrome with Firefox and its derivatives being the sole alternative. Well, Safari too, but it's only available on Apple's platforms.
Of course 10% compression gain is still reasonable if you're Google as you serve petabytes of data — for everyone else it simply doesn't make sense, no one else has such numbers to justify implementing new codec for such a marginal gain.
All in all, WebP is beneficial for Google and no one else.
WebM is only a container, I don't think it's necessary either, but being relatively easy to implement, I don't have anything against it. Let us talk about VP9 though — everything said about WebP above still holds and more: I've seen videos on YouTube for which VP9 stream size was bigger than H264 in side-by-side comparison of equally specced streams: YT format 248 vs 137. So it's not even always better — not in all use cases. Even on Google's own YouTube! And yet, that is the codec they want you to use, it's used by default and, sorry, I don't have any examples at hand, but there are videos for which VP9 stream is available, but AV1 stream (codec also often associated with Google, but over which they have much less control) of same resolution and framerate isn't — and I think it's being done on purpose!
Of course, I might be biased here — I most probably am, as there are few things that I hate more than Google, but I'm not completely unreasonable and I believe that most of codecs and technologies related to web and developed by Google or in cooperation with Google are open on paper only and exist for the sole purpose of market lock-in. And I strongly encourage everyone not to use any of them: be it WebP, Brotli, VP9, QUIC-HTTP/2 or HTTP/3.
#Google #Web #WebP@m0xee @FalconMarkSix