> I just checked the Google homepage, and even the New Year's Eve Google Doodle currently being shown is a good ol' GIF, rather than a modern format such as WebP. And this is with me using a desktop Chrome browser that definitively supports WebP.

new-years-eve-2018-4995722058399744.2-law.gif

299 972 bytes

new-years-eve-2018-4995722058399744.2-law.webp

293 636 bytes

new-years-eve-2018-4995722058399744.2-law.apng

251 516 bytes

Interesting...

Meanwhile using ffmpeg's default settings it's 63k as h.264 and 45k as h.265.

Starting a video in most browsers is pretty expensive (it usually loads up various GPU features for hardware video decoding).

On some old and buggy machines, that might cause the browser to crash too.

Not something Google wants to risk for a doodle - that's why all non-trivial doodles require a click to load.

> Starting a video in most browsers is pretty expensive (it usually loads up various GPU features for hardware video decoding).

OTOH it might be cheaper (relatively) on phones as they can offload the work to hardware components and ramp CPU down (or avoid ramping it up).

But that is lossy compression.

It doesn't matter. It will look the same.

chroma subsampling, shallow gradients, ringing, the lack of transparency are all quite visible issues when trying to encode cartoons, pixel graphics or screen captures with the standard profiles of lossy video codecs.

I used gif2webp -q 100 -m 6 -mt "new-years-eve-2018-4995722058399744.2-law.gif" -o out.webp

with the resulting out.webp being 285 932 bytes, so it seems apng does a very good job here, unless I'm using suboptimal options for webp.

I don't like WebP because it's either it or HW accelerated browsing - latter I like a tad more because it saves me a bit of battery juice on my laptop.

HEIF (based on HEVC and support on MacOS/iOS + Android + Windows) is already way better than JPEG. It also provides HW acceleration.

HEIF is made by MPEG. HEIG is extensible (see AVIF fusing the AV1 royalty-free codec). Also an application format (MIAF) will ensure interoperability.

While waiting for native browser support, some js implementation would do the job.

What else?

Isn't it a patented algorithm? So it is practically useless.

I agree with you but hey JPEG also had its own patent issues (https://en.wikipedia.org/wiki/JPEG#Patent_issues).

> HEIF (based on HEVC and support on MacOS/iOS + Android + Windows) is already way better than JPEG. It also provides HW acceleration.

Formats do not provide HW acceleration, implementations do. And so far there is zero HW accelerated HEIF implementations for the web.

> And so far there is zero HW accelerated HEIF implementations for the web.

You sure of that? Apple[1] and Qualcomm[2] might argue otherwise.

[1] https://developer.apple.com/videos/play/wwdc2017/513/

[2] https://techreport.com/news/34306/qualcomm-snapdragon-855-sp...

I don't know who downvoted you but you're correct. The point is that most devices embed an HEVC hardware decoder.

There's the same problem with Google insisting on VP8/9 for YouTube in Chrome. If your Mac only supports h.264 in hardware you'll get better battery life in Safari.

They also try it in Firefox but fortunately you can disable webm/webp in about:config and get better battery life and image quality.

There's a Chrome extension that forces YouTube to stream h.264

https://chrome.google.com/webstore/detail/h264ify/aleakchihd...

Obviously it is a problem with Apple, not Google. People should just push it more to do the job.

I don't think Google are free of responsibility. They are prioritising their lower bandwidth over the user's better power usage.

Apple has a bigger share of the blame. They purposely ignore any codec that is outside of their favorites, even if the hardware they ship does support it (i.e. Intel) or doesn't need any hardware support (Vorbis, Flac). On the other hand, they are quick to support any codec, that is problematic to implement elsewhere.