enable-chromium-hevc-hardware-decoding VS SubKt

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-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.

> The 'right' solution would be to just use system codecs for everything. Many apps need good implementations of image codecs. They just need to be implemented once by the OS vendor (or the toolkit on Linux).

Windows has done this and is still doing this, but the decade-long track history so far is that this does not work well. It can work, in a very limited scope and if you have a lot of influence.

Sure, it's really nice if an 8K@60Hz HDR HEVC video plays perfectly straight in your browser or desktop app, but more often than not, it just won't. You don't have the right browser, the extension installed (due to license agreements), good enough graphics drivers or someone has forgotten a flag yet again.

And we haven't even gotten to the immense amount of variation each codec introduces or the potential attack surface.

How shit the situation is with just HEVC (and thus also basically HEIC): https://github.com/StaZhu/enable-chromium-hevc-hardware-deco...

> Just file a bug against your OS.

In the end that "just" carries a lot of burden, it can't be the users reporting these issues.

It's just way easier to leech off of ffmpeg and similar, and let it deal with all the formats. Instead of hoping that maybe you can leverage what the OS gives you, that it works and works correctly in all your edge-cases.

Though not everything is that gloomy, there are Vulkan extensions that might (in the future) simplify cross-platform image and video decoding (and HW acceleration).

I think there are a few patches that can enable HEVC hardware decoding with chromium. Though I am a firefox user so I didn't test whether these patches works or not. https://github.com/StaZhu/enable-chromium-hevc-hardware-deco...

This'll be long-winded excitement to talk about the weird little community, but I think a lot of that depends on the circles you run in and the content you consume.

There is surely a lot of low-effort GUI handbrake encodes online. But most of the """well-respected""" piracy groups put a surprising amount of effort into filtering and such to correct artifacts, both due to the compression and due to the source material itself.

A lot of these people are using tools like VapourSynth with a variety of scripts they've put together and x264 or x265 directly rather than ffmpeg. You can see a couple of guides written about some of the processes they perform:

- <https://silentaperture.gitlab.io/mdbook-guide/introduction.h...> (all video content)

- <https://guide.encode.moe> (anime-focused)

And some links to the kinds of filtering code pirates write for movies/tv/anime:

- <https://git.concertos.live/OpusGang/EncodeScripts> (MANY VapourSynth and AviSynth scripts for both live-action content and anime)

- <https://github.com/Beatrice-Raws/encode-scripts>

And while not directly related to the encoding side of things, but if any of that is interesting, in addition to the encoding side of things, pirate fansubs also get pretty complex, particularly for anime since, unlike the unstyled SRT subs most people come across for foreign movies online, anime fansubs tend to use ASS [1] subtitles with lots of styling to accomplish things like cleanly replacing Japanese text in a letter someone is reading or adding non-distracting subtitles for background text (e.g., signs on buildings, etc).

To do a lot of that, though, these subtitles often pack fonts into the video container to allow the media player to render things as expected without resorting to "hardsubbing" (i.e., pre-rendering the subtitles into the video itself)—which is one of many reasons container formats like Matroska (MKV) is so popular in those communities.

An interesting thing to see come out of that is that I have noticed some fansubbing groups move to proper build tools, like Gradle, to automate portions of their workflows. As an example, SubKt, a Gradle plugin, allows them to essentially have CI/CD for their subtitling projects by doing integrity checks on the fonts, linting the subtitles/fonts to ensure the selected fonts actually have glyphs for all the text, templating and merging so that different team members can work on things like the script/timing while another does styling, and then packaging and publishing tasks to bundle everything up into an MKV at the end and upload the result to torrent sites.

If any of that is interesting, here are some links to SubKt + some real-world finished projects making use of it:

- <https://github.com/Myaamori/SubKt>