Live data from Hacker News

Google added HEVC support in Chrome

bitmovin.com

181–190 of 225 posts

Re: Google added HEVC support in Chrome

#181

Earlier quoted context omitted.

I think it's remarkable that the pirate scene has barely touched VP9 or AV1. We discussed this 2.5 years ago, nothing really has changed except there's more H.265 than before. https://news.ycombinator.com/item?id=19362098

Pirates don't care about codec licences the same way they don't care about the copyright of the content they pirate. Therefore they will always pick the codec which is easiest to target, has hardware for encoding and decoding readily available. Most either watch content on PCs, smart TVs, nvidia shield / firestick and almost none of those have av1 hardware support (maybe PCs but only recently).

Pirates also work directly with video files. Each file has one bitrate and one codec, and needs to work as universally as possible. There are sometimes two or more versions of the same video available that use different bitrates or codecs, but each added version has a cost in clutter (they typically show up as separate entries in the UI), disk space (relatively expensive when it’s people’s personal disks) and P2P swarm availability (critical if using P2P), so you won’t see too many. In contrast, just about any streaming service will have several different encodes for each video, automatically selecting one based on bandwidth and codec availability. That makes it relatively easy to adopt new codecs, since users who can’t decide them can just get a different encode.

However, pirates do care about file size and quality, as demonstrated by the adoption of 10-bit H.265. So AV1 should be coming, eventually.

Re: Google added HEVC support in Chrome

#182
post #175
post #167

Earlier quoted context omitted.

If Apple can stop using it to not proliferate it switching to AV1 by default and aren't doing it, then you can say they are part of the problem due to their size. I.e. if you meant that Google went out of the way to enable it in Chrome because Apple users produce so much content with it (because of Apple), then Apple are causing a problem. Compare it to someone who makes products that dump toxic waste in the environm…

Presumably heif and/or hevc had an advantage when Apple adopted them as the default formats. Given they’re primarily on mobile devices it’s reasonable to assume there is hardware support. So switching to something else means battery life impact on everything else. What you are saying, is that because Google didn’t support a standard format that has been around, and in wide spread use, for years Apple should make all…

Today AV1 can be supported in hardware and is supported in all recent or upcoming SOCs and GPUs. So Apple have no excuse not to do it when they are even pouring tons of money into making and refreshing their own chips.

Re: Google added HEVC support in Chrome

#183
post #15

Every new software and hardware is moving towards the royalty free, agile and efficient AV1 codec. But out of nowhere and 9 years after its release, they add support to the mother of all royalties HEVC codec. Probably had some kind of deal to benefit their android partner Samsung, since they own pretty much most of HEVC patents. https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#P...

I'll consider AV1 a real codec when TV and movie torrents are encoded with it.

Re: Google added HEVC support in Chrome

#184
post #10

On one hand, that's great for anyone watching HEVC content in Chrome. On the other, I'd prefer to not see further adoption of HEVC and instead see increased deployment of VP9 and AV1 wherever possible. Let MPEG-LA and the other HEVC patent pools+holders... well I'll leave the rest to your imagination. Future looking, no one should even touch VVC/H.266. Unfortunately the above rant does not address the gap in hardware…

I just want the best codec, and I am willing to a pay a dollar for it.

For Video, H.266 / VVC is just technically superior in every single way. For Images, JPEG Xl is the best for 95%+ of use cases. For audio, we have a AAC-LC, literally as ubiquitous as MP3, true patent free, and at 128+kbps, 95% of cases as good as the state of the audio codec.

And yet we end up in a world where the only accepted choice is AV1 for video, AVIF for images and Opus for Audio.

Re: Google added HEVC support in Chrome

#185
post #56
post #53

Earlier quoted context omitted.

Did you tried to encode anything with av1? Even with a high end CPU it's just not feasible, I tried with ffmpeg and it was encoding a single digit fps per seconds. A video of just 10min would take many hours, on the other end h265 encoding is slow but doable. Edit: just retried on my laptop: 0.6fps with a 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz Using the lastest version of ffmpeg with the sample from the wiki:…

Try compiling ffmpeg with `--enable-librav1e` and use the `rav1e` encoder implementation. It's supposed to be the fastest software encoder, though of course it can still quite slow depending on the settings. If you have a newish Intel CPU they're supposed to have good AV1 hardware encoding support. See SVT-AV1. (which ffmpeg also supports: https://trac.ffmpeg.org/wiki/Encode/AV1#SVT-AV1 )

But does that get the same quality? All the codec performance comparisons I've seen have totally ignored the video quality, making the utterly meaningless.

Re: Google added HEVC support in Chrome

#186
post #184
post #10

On one hand, that's great for anyone watching HEVC content in Chrome. On the other, I'd prefer to not see further adoption of HEVC and instead see increased deployment of VP9 and AV1 wherever possible. Let MPEG-LA and the other HEVC patent pools+holders... well I'll leave the rest to your imagination. Future looking, no one should even touch VVC/H.266. Unfortunately the above rant does not address the gap in hardware…

I just want the best codec, and I am willing to a pay a dollar for it. For Video, H.266 / VVC is just technically superior in every single way. For Images, JPEG Xl is the best for 95%+ of use cases. For audio, we have a AAC-LC, literally as ubiquitous as MP3, true patent free, and at 128+kbps, 95% of cases as good as the state of the audio codec. And yet we end up in a world where the only accepted choice is AV1 for…

For audio there's also OGG Vorbis, which is open-source and royalty-free and superior to MP3 at comparable bitrates.

EDIT: looks like opus is actually the successor to Vorbis.

Re: Google added HEVC support in Chrome

#187
post #184
post #10

On one hand, that's great for anyone watching HEVC content in Chrome. On the other, I'd prefer to not see further adoption of HEVC and instead see increased deployment of VP9 and AV1 wherever possible. Let MPEG-LA and the other HEVC patent pools+holders... well I'll leave the rest to your imagination. Future looking, no one should even touch VVC/H.266. Unfortunately the above rant does not address the gap in hardware…

I just want the best codec, and I am willing to a pay a dollar for it. For Video, H.266 / VVC is just technically superior in every single way. For Images, JPEG Xl is the best for 95%+ of use cases. For audio, we have a AAC-LC, literally as ubiquitous as MP3, true patent free, and at 128+kbps, 95% of cases as good as the state of the audio codec. And yet we end up in a world where the only accepted choice is AV1 for…

While I agree with the rest, I must say that in one point you are wrong. Opus is better than AAC-LC. It spans a much wider spectrum of bitrates and it sounds good¹ at any of those. On top Opus is open source which AAC-LC is not afaik.

--- ¹ good is subjective, I earn my money as a freelance audio engineer, so I should have the ears to notice anything wrong with it.

Re: Google added HEVC support in Chrome

#188

Earlier quoted context omitted.

> True, HEVC doesn't support Box level encryption like MP4 does I’m not sure why you’re comparing a codec to a container format?

Based on the Quicktime File Format, MP4 is most usually only a container these days. Moving Pictures Experts Group developed the MPEG-4 standard with many parts[1] including a codec called MPEG-4 aka MP4V or just MP4, which was still popular for SD video encoding only a few years ago, though not exclusively, and it is still available to encode video in Apple Quicktime (MPEG-4 Basic, MPEG-4 Advanced), ffmpeg, HandBrak…

Noone calls MPEG-4 Part 2 "MP4". Usually it's MPEG-4 Video, MPEG-4 ASP, or (when using that encoder) Xvid.

Re: Google added HEVC support in Chrome

#189

Earlier quoted context omitted.

".mp4" is just a file extension, the source of the colloquial name for the container. But both the container and the codec are named MPEG-4 and both are colloquially called "MP4." "Box level" is apparently referring to types of cryptography, "S-boxes are non-linear transformations of a few input bits that provide confusion and P-boxes simply shuffle the input bits around to provide diffusion"[1] The basic function of…

different box

What other "box level encryption" is there?

Re: Google added HEVC support in Chrome

#190
post #123

Earlier quoted context omitted.

I think it's remarkable that the pirate scene has barely touched VP9 or AV1. We discussed this 2.5 years ago, nothing really has changed except there's more H.265 than before. https://news.ycombinator.com/item?id=19362098

Probably all comes down to ffmpeg not supporting av1 well. Pretty much everyone uses ffmpeg or a wrapper around ffmpeg like handbrake to encode. And my understanding is that ffmpeg implements an old and very slow and partially broken version of av1.

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. The scripts themselves are typically Python, but often rely on loads of native modules. You can see a couple of guides 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) [2].

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>

- https://github.com/Kaleido-subs/Joshiraku>

Regarding 'why' AV1 and other codecs like VP8/VP9 or VVC haven't really been used:

1. Many of the private trackers have fairly strict rules in terms of standards (e.g., due to lack of hardware support, perceived differences in quality, etc., many don't allow 2. Many seem to find x264 easier to tune for certain types of media than x265, and even more so compared to AV1 and others.

3. Many seem to believe that insert codec tends to produce worse results in certain circumstances or for certain content, so they will stick with x265 (or even x264 for the same reasons)

4. Many find that, to truly achieve the same picture quality produced by x265, compression ratios often end up much worse than people claim, and thus the significant slow-down in encoding speed and loss of hardware support is not worth the minor reductions in size.

#4 is likely the most common reason, as it was/is the same with those who prefer x264 over x265; HEVC video is definitely not "half the size" if you want it to look comparably good. And so, especially in the past with older hardware, it simply wasn't worth the tradeoffs; it's worth remembering that, in the case of piracy groups which distribute over P2P networks, no one is paying AWS and co. exorbitant amounts of money per terabyte of data transferred.

These sites run off of 'free' bandwidth provided by users and cheap unmetered servers from companies like Hetzner, OVH, LeaseWeb, etc -- saving 10-30% in bandwidth often is not worth it at the expense of doubling your encode times (or significantly worse than doubling, in the case of AV1 and VVC) and alienating the people watching on older hardware.

EDIT:

Also, I figured it'd be worth noting as well that RE: my points on encoding speeds and such, while hardware decoding may help adoption in the piracy communities, I don't foresee hardware-accelerated AV1/VVC encoding making much of a difference in the near future; even today, virtually none of these groups use solutions like NVENC for HEVC due to the fact that the software HEVC encoders produce better results (so pirates that encode such content typically have just come to accept the slower encodes now that good CPU compute is much cheaper than in the past).

---

[1]: https://en.wikipedia.org/wiki/SubStation_Alpha>

[2]: https://streamable.com/d21iq> (this is genuinely a toggleable subtitle and not something baked into the video!)

Post reply on HN