On one hand, that's great for anyone watching HEVC content in Chrome.
<rant>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.</rant>
Unfortunately the above rant does not address the gap in hardware support between HEVC and AV1 for efficient accelerated decoding. Codec support is a difficult game to balance. I'm hopeful that by the time AVC/H.264's patent pools fully expire later this decade we'll all have moved on to newer and better (non-royalty patent-unencumbered) things.
It's ironic, not one week ago there were a bunch of complaints on this site saying that Google was abusing their position of power (controlling YouTube, Chrome, Android TV, etc) by pushing AV1. Now they bring HEVC support to Chrome and the top comment is another complaint!
(That said, I agree with you. I think a codec being royalty free is a very good reason to prefer it to other codecs.)
Personally, I have no idea why people are so upset about WebM and AV1 and etc. Like sure, they're not necessarily God's gift to AV, but they're reasonable enough, and patent unencumbered. Google may be awful, but that doesn't mean the incentives can't align. I can tell you that my incentives are perpendicularly aligned with MPEG-LA's in this situation, so...
Hostages? I'd say Google is better than most regarding data portability, assuming that's what you're referring to, offering 'takeout' for just about everything.
The comment was about the internet "hivemind"; no need to be pedantic about it.
Keep in mind that upwards of 95% of people will read comments but not post any themselves (and to address an obvious retort, sure, it'll be a different 95% for each submission). So the general "tone" of the comments absolutely impacts public perception, especially now that practically no-one consumes straight-news without social media commentary.
Redditors use identical arguments: "we're different people!" when their website is the most groupthink-y of all.
Threads are groupthink, but subreddits with diverse topics are less groupthink than you'd think. Different user groups turn out for different headlines, at different times, etc.
TBF they can be abusing their position + helping other companies abuse their position as well.
Just reading about the historical context of AV1 it all feels like huge dirty lawyer battles involving troves of money thrown around, with the user as a hostage indirectly footing the bill in the end so we can't just ignore all the drama.
I would want to side with Google on the open side they seem to be championing, but there's no way it doesn't come with huge side effects that we will pay sooner or later.
All to say, it's looks like a complicated enough matter that opinions will be devised and all options might not be great, some just being more acceptable than others.
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:
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:
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).
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 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?
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.
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: ffmpeg -i input.mp4 -c:v libaom-av1 -crf 30 -b:v 0 av1_test.mkv
It's that slow that I don't even get the file size to change on disk, still 0 I guess the ffmpeg encoded buffer is still too small to be flushed out after a minute.
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.
I don't think there are CPUs with integrated GPUs from Intel that do AV1 encoding yet. Raptor Lake launched on October 20, 2022, and while RL will decode AV1, it won't encode it.
The Intel Arc cards will encode AV1.
The next generation of Intel CPUs with integrated GPUs are supposed to have AV1 encode. Maybe a year or two away?
Intel CPUs don't have AV1 hardware encoding support quite yet. Their latest 13th gen CPUs have AV1 hardware decoding support though. The recent performance improvements[1][2] are for software encoding.
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.
For what it's worth, Intel & Netflix's AV1 encoder SVT-AV1 is extremely fast -- it changed my mind about what encoder rates are possible with AV1, to the point that I'm very happy with realtime CPU encoding.
This was also true of H.265 in its early days before there was widespread support. I once had to wrangle a few workstations to act as a renderfarm overnight in order to transcode a couple hours of footage by the next morning having not been aware that we were dealing with H.265 until the day before it had to be done.
But also yes, as others are pointing out, this is a problem rapidly being addressed and is not atypical for new media formats.
I'm able to encode using av1an (which I believe still uses ffmpeg as its backend) at 3440x1440@30Hz with 10bit color using a mid/high-range AMD 3800X processor.
I'm not sure what might be wrong on your end, but it sounds like ffmpeg's default configs might not be well-optimized yet if you can't encode in real time.
With the correct encoder and settings, it can be faster to encode than x265, for any given "efficiency" that x265 can achieve. Of course, the efficiency can be pushed higher than that, too, still with a reasonable encoding time.
exactly. vp9 isn't actually that good. It's clearly worse than hevc. AV1 is better, but there's limited hardware encoding/decoding support. The result is exactly as expected.
> does not address the gap in hardware support between HEVC and AV1 for efficient accelerated decoding
I'm rooting for AV1 just the same as everyone else, but it's still nowhere close to HEVC in terms of hardware support, or even general quality/efficiency. It's just going to take some more time.
Add the hardware support, then we can talk about dropping the proprietary ones. There's no way the costs of royalties, no matter how they indirectly affect me as a user, outweigh the cost of my CPU chugging to handle unoptimized video.
Surely that depends - is this a bunch of generic and vague detail-less patents, or do they provide the actual information required to implement the thing it purports to describe.
The core problem with “software patents” in the US sense is that the patent office appear to grant them by default if they are vague, only accepts specific types of pre-existing evidence that they are not new or novel, and once a patent is granted makes it as hard and expensive as possible to challenge the granted patents, and doesn’t allow you to recover costs if you are sued for a patent that is eventually revoked.
All of those thing mean that the specifics of us patent law remain BS, but at the same time I think that everyone on HN does believe that IP should exist, and people should have rights to what they create.
You can't patent "pure math" but given that describes literally anything that it is possible to do on a computer, including simulating a physical device, we know that there is an intrinsic point where things go from "math" to something patentable.
The rationale for "you can't patent maths" is basically "you can't patent a fact".
Blanket anti-software patent people take a maximalist position: if it's a step of instructions it is maths, so should not be patentable. I think that is absolute nonsense, and it is an explicit statement that if you ever come up with anything idea, no matter how much it cost you to invent it, or develop it, it has zero value - because apparently the hard part of complex and new technology is writing code, not developing the technology in the first place. It also means you get some absurd results: the same invention would be patentable if you made a mechanical implementation, a purely electronic one, probably an ASIC, but probably not if it was an ASIC executing instructions from a builtin ROM. Because suddenly it becomes "math".
As I said originally, the problem is not patenting "software", it's that the idiocy of the US patent office means that you can make a patent document that has no information that can be used to implement the patent, and thus the patents are inherently open to abuse.
The core problem with software (and worse, process) patents is that they let you patent an idea, rather than an actual implementation of an idea, which is what physical object patents are required to do. The whole reason patents are public is so that the public can look at a patent, and use that document to implement the idea being patented, but if all you've done is patent the idea then all the public can do is see that you had an idea but didn't know how to actually build it (which is what patents are _meant_ to be for).
> It also means you get some absurd results: the same invention would be patentable if you made a mechanical implementation, a purely electronic one, probably an ASIC, but probably not if it was an ASIC executing instructions from a builtin ROM. Because suddenly it becomes "math".
Why is that absurd? Here's my attempt to describe a maximalist position: If the machine actually does something then you get a valid patent for the real world. But the patent won't apply to simulations of the real world. So it doesn't really matter whether it's "patentable" or not. We could give patents to both variants, but if someone is only interested in the data the machine outputs, they can run a simulated version without violating either patent.
> it is an explicit statement that if you ever come up with anything idea, no matter how much it cost you to invent it, or develop it, it has zero value - because apparently the hard part of complex and new technology is writing code, not developing the technology in the first place
Math takes tons of effort too! Deep complicated proofs are no more "just a fact" than compression schemes are "just a fact".
> The core problem with software (and worse, process) patents is that they let you patent an idea, rather than an actual implementation of an idea
I worry that there's no good way to make a thorough guideline for what counts as idea and what counts as implementation for things that are code-based.
Though in the strictest sense you could just rely on copyright for implementations and toss out patents entirely.
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.
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.
is it possible to implement generic/unencumbered blocks at the HW level and then string them together at the SW or firmware layer? how much efficiency do you lose? if you can move all the patentable stuff into SW then we can do the same thing we all did with mp3 patents: i.e. ignore them (see: LAME).
tell that to every Linux user who was doing anything with mp3's before the patents expired just a couple years ago. i'm pretty sure even the Windows version of Audacity -- a tool with over 100 million downloads -- integrated with it. are you claiming the LAME approach wasn't successful? or that its success was a fluke, context-dependent, or for some other reason is a bad analogue?
I'm not sure how you think for-profit companies like Mozilla, Google or Apple would get away with shipping 'ha ha I tricked you!' patent circumventions to a billion people. It's not like Audacity.
Keep in mind that Firefox AFAIK still relies on OS codecs for h264 because shipping it themselves is such a difficult proposition due to patents. And on Windows, if you want native HEVC or AV1 playback you have to buy it from the store, it doesn't ship with the OS.
maybe i misunderstood, then. i thought that HEVC licensing was paid for by the hardware vendor, and hence acted as a broad tax even if you’re not using HEVC, or using GPUs in a HPC context, etc (and unnecessarily raises the barrier of entry to new HW vendors, etc). but if Windows users are individually paying those licenses, that’s probably not the case.
i guess the worry then is that HEVC crowds out AV1/others, and this Chrome change is setting the stage for it to become a broad tax on video? i could buy that angle.
There was a recent kerfuffle about Fedora removing support for hardware accelerated H.265 from their distribution of mesa because of threat of patent litigation. See https://www.phoronix.com/news/Fedora-Disable-Bad-VA-API. That would also seem to suggest that the OS has to pay royalties if it uses hardware acceleration. It seems pretty strange to me that the OS/library/driver has to pay royalties just to expose access to hardware, which is where the patented technology actually exists. But I also don't understand how a video codec can be patented in the first place. ¯\_(ツ)_/¯ IANAL.
Yeah downloading an OS that couldn't play MP3's by default, and required you to jump through hoops to let it play them, because said distro was avoiding law suits, Just like how Audacity didn't ship with LAME, but required you to supply your own dll. Yes patents had zero effect on the User experience.
yes. of course patents impact UX. if patents didn’t make things more difficult for engineers, then they’d be worthless, and in open source that burden on the devs gets passed through to the users.
a reasonable person might conclude that patents are a bad thing as a result. like it or not, HEVC is patented and that’s not changing anytime soon: but do we decide to develop tools around it, or banish it?
that any users actually went through the awful UX of downloading codecs is some evidence that mp3 support was valuable to them. is this still the case, today with HEVC, or not?
if the argument was really as simple as “HEVC is bad UX”, we wouldn’t have this discussion: nobody would use something with bad UX if they didn’t feel compelled to for some other reason. why anyone would feel compelled to, is the more interesting discussion.
LAME is a really great example of why patents exist: the need to avoid the mp3 patents resulted in the development of technology that was superior to that covered by the mp3 patents. Do people really think LAME would have been developed if people were just reimplementing the existing mp3 encoder?
This is wrong in so many ways I'm not sure where to start. LAME was covered by the patents, so your whole idea is backwards and even if it weren't it's not supported by any evidence - there's just no relationship between patentability and how many encoders get implemented independently or not.
AV1 would be ideal to support. It is resource intensive for software, but with M2 MacBook Pros, for example and upcoming iPhone A17 processors, the AV1 decompression and compression codecs could be put in the hardware.
AV1 reputedly is 30% more efficient than HEVC, important for a number of cases, such as more efficient use of bandwidth over cellular. For FaceTime over cellular Apple today uses the HEVC codecs if available on source and destination phones.
My guess is that the next shot is with a TSMC N3E chip, which _may_ debut with iPhone 15 Pro. There's been conflicting reports if N3E will be ready when Apple needs it - September 2023 if it's for iPhone 15.
N3E based M3 Macbook Pro with hardware raytracing and hardware accelerated AV1 decode/encode would be nice.
<rant>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.</rant>
Unfortunately the above rant does not address the gap in hardware support between HEVC and AV1 for efficient accelerated decoding. Codec support is a difficult game to balance. I'm hopeful that by the time AVC/H.264's patent pools fully expire later this decade we'll all have moved on to newer and better (non-royalty patent-unencumbered) things.