Most devices can indeed most likely handle software decode of more common resolutions, codecs and bitrates. But I'd really hope they'd pick the one that won't s

Most devices can indeed most likely handle software decode of more common resolutions, codecs and bitrates. But I'd really hope they'd pick the one that won't suck up all the battery, so H264. This line of thought is supported by the fact that YouTube still provides an H264 option with most if not all videos. With higher bitrate things, HEVC seems to grow in popularity but even software decode support is not everywhere. Netflix for example requires the installation of HEVC support on Windows to play 4K content. Actually hardware-accelerated video decode is even spottier and more unreliable across most platforms. The JS API for codec support (canPlayType) literally returns "maybe" and "probably". It's quite bad. So far the best compatibility I've seen has been Edge with flags on Windows (MPEG-2, H264, HEVC, AV1, VP8, VP9 with most also supporting accelerated encode). It still fails with some content (Dolby Vision P5 colors are incorrect, HEVC Rext doesn't play - more info about HEVC is available here https://github.com/StaZhu/enable-chromium-hevc-hardware-decoding https://github.com/StaZhu/enable-chromium-hevc-hardware-deco...). Chrome on macOS is a close second in terms of codec support. The worst in terms of HW acceleration being all the browsers on desktop Linux-s, few and fragile combinations that offer limited and janky support. But it's slowly improving. This combined with the not-the-latest hardware many use, means things like VP9 or AV1 tend to stutter. I'd love to see some more generic stats, but considering the APIs aren't sufficient to determine actual support, these might be difficult to gather. But all things considered, I heavily doubt dropping H264 HW decode support was a good idea considering how often its still used.