Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


I think the biggest reason is lack of hardware decoding, Lots of people have a device that can hardware decode H.265, which is extremely important for 4k content, my x230 really struggled with software 4k decoding of H.265, so I assume the same issue will happen with VP9 and AV1 especially with higher res content.


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 <4K HEVC encodes at all, except in edge cases like when a streaming platform releases a new show in HEVC-only), so individual encoders and groups aren't always free to use whatever codecs they please.

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!)


Thank you for all these details! You confirm my suspicion, which is that the pirate scene has a lot of really valuable knowledge built up from years of using codecs in a very practical way.


ffmpeg supports libaom, svt-av1 and rav1e. It's simply a matter of compiling it in. (Arch for example does by default)


ffmpeg can also be built to link to libaom, and my package manager (Macports) does this by default. (Likewise, I think ffmpeg has its own H.264 and H.265 implementations, but also links to libx264 and libx265.) Does it really matter what ffmpeg's built-in implementation is like?


ffmpeg h265 implementation lacks support for alpha channel, and that is really important.


Piracy is predicated on a rejection of intellectual property rights. So it's not clear why they would care who owns a codec.


I remember maybe ten years ago "real" pirates (from "the scene") thought that everything needed to be in rar format, and anything else was considered "p2p" and not as pure. They were also late with h264 and used xvid for far too long.


File size capped at 700mb to fit on cd's, bitrate be damned.


Jeez, I remember most pirated video was using xvid, what a dark time that was.


xvid in 8 .part files you download separately from putlocker or megaupload, each is zipped with a password you have to find on a phpBB-based forum




Consider applying for YC's Winter 2027 batch! Applications are open till November 2.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: