[jeroenhd]

That's very strange. Is this a versioning problem (i.e. Catalina not being supported anymore?) or is there some kind of hardware restriction?

From what I can find, Catalina should still be supported for more than a year from now, right?

Edit: well, that's bizarre. Caniuse.com [0] lists the same restriction, WebP is only available from Big Sur onwards. And then people wonder why nobody likes developing for Safari.

[0]: https://www.caniuse.com/?search=webp

[giantrobot]

Safari uses AVFoundation and ImageIO for handling video and image data respectively. These frameworks are tied to OS releases. This ends up meaning the latest Safari on an older OS might not handle some formats/codecs.

So Safari gets free accelerated handling of new formats and codecs but only when the underlying OS supports them.

[SahAssar]

For media formats the support is often dependent on the OS. It's been that way forever (ask anyone deploying video in early html5 and getting it to work cross-os and cross-platform). I guess it's more expected with videos, but images are (usually) handled the same.

[jeroenhd]

Maybe with hardware decoding, but software decoding is often done in browsers when hardware support is not available.

I suppose Apple doesn't want to include a software fallback for platforms where hardware isn't available to discourage developers from using the format. It's not like Apple would need to write any complicated decoding algorithms when there's already an open source implementation that's free to use.

[SahAssar]

H264 didn't work in FF on MacOS and Linux (but it still worked on windows) until v34 (and it only started working because Cisco donated a license), Ogg Vorbis only works on MacOS 11.3 or later in safari (and it also depends on which container you use), HEVC in IE/EdgeHTML depended on hardware (with no fallback to software whatsoever), AV1 in FF65 only worked on Windows, AV1 in FF66 only worked on Windows and MacOS, chrome on android 2.3 required you to specify a m4v without mime-type, but doing it with mime-type worked fine on desktop chrome.

I'm just saying it's not unprecedented to have the same browser version supporting different audio/video/image formats depending on OS or hardware.

For image formats it's not as usual, but if someone is making a site only supporting webp then I'd assume they'd look up some support matrixes beforehand.

[jeroenhd]

That's because of the licensing issues, especially H.265/HEIF. AV1 has barely any hardware support and software decoding is terrible for performance, so while many browsers can easily build in support, it's not really worth it to enable it by default.

VP9 and WebP patents are all granted freely by Google. WebP images aren't as terrible for power consumption even in software because the browser doesn't decode 60 of them every second.

[SahAssar]

Regardless of that it's not uncommon to have the same browser version support different media codecs/formats.

Regarding the examples, when it comes to Ogg Vorbis there is no issue with software decoding (it's software everywhere), AV1 was granted software decode support on some OS'es but not others in the exact same browser, version and hardware (and IIRC it's the encoding perf that is especially bad for AV1, not decoding) and the chrome on android issue also shows how legal or hardware issues are not the only things limiting what is available (it can also be bugs that just stay around).

All I'm saying is that testing for browser version A is not a surefire test. Either check the support or test on browser A version B on OS C version D on hardware E (for each of the A/B/C/D/E variants) or just stick with what works across the board. Either way you probably won't end up shipping a site with only webp support.