Wow. To me, the big news here is that ~30% of devices now support AV1 hardware decoding. The article lists a bunch of examples of devices that have gained it in the past few years. I had no idea it was getting that popular -- fantastic news!
So now that h.264, h.265, and AV1 seem to be the three major codecs with hardware support, I wonder what will be the next one?
> To me, the big news here is that ~30% of devices now support AV1 hardware decoding
Where did it say that?
> AV1 powers approximately 30% of all Netflix viewing
Is admittedly a bit non-specific, it could be interpreted as 30% of users or 30% of hours-of-video-streamed, which are very different metrics. If 5% of your users are using AV1, but that 5% watches far above the average, you can have a minority userbase with an outsized representation in hours viewed.
I'm not saying that's the case, just giving an example of how it doesn't necessarily translate to 30% of devices using Netflix supporting AV1.
Also, the blog post identifies that there is an effective/efficient software decoder, which allows people without hardware acceleration to still view AV1 media in some cases (the case they defined was Android based phones). So that kinda complicates what "X% of devices support AV1 playback," as it doesn't necessarily mean they have hardware decoding.
AV1 was specifically designed to be friendly for a hardware decoder and that decision makes it friendly to software decoding. This happened because AOMedia got hardware manufacturers on the board pretty early on and took their feedback seriously.
VP8/9 took a long time to get decent hardware decoding and part of the reason for that was because the stream was more complex than the AV1 stream.
“30% of viewing” I think clearly means either time played or items played. I’ve never worked with a data team that would possibly write that and mean users.
If it was a stat about users they’d say “of users”, “of members”, “of active watchers”, or similar. If they wanted to be ambiguous they’d say “has reached 30% adoption” or something.
H266/VVC has a five year head-start over AV2, so probably that first unless hardware vendors decide to skip it entirely. The final AV2 spec is due this year, so any day now, but it'll take a while to make it's way into hardware.
> So now that h.264, h.265, and AV1 seem to be the three major codecs with hardware support, I wonder what will be the next one?
Hopefully, we can just stay on AV1 for a long while. I don't feel any need to obsolete all the hardware that's now finally getting hardware decoding support for AV1.
They mentioned they delivered a software decoder on android first, then they also targeted web browsers (presumably through wasm). So out of these 30%, a good chunk of it is software not hardware.
That being said, it's a pretty compelling argument for phone and tv manufacturers to get their act together, as Apple has already done.
I'm not too surprised. It's similar to the metric that "XX% of Internet is on IPv6" -- it's almost entirely driven by mobile devices, specifically phones. As soon as both mainstream Android and iPhones support it, the adoption of AV1 should be very 'easy'.
(And yes, even for something like Netflix lots of people consume it with phones.)
Not trolling, but I'd bet something that's augmented with generative AI. Not to the level of describing scenes with words, but context-aware interpolation.
I don't want my video decoder inventing details which aren't there. I much rather want obvious compression artifacts than a codec where the "compression artifacts" look like perfectly realistic, high-quality hallucinated details.
We already have some of the stepping stones for this. But honestly much better for upscaling poor quality streams vs just gives things a weird feeling when it is a better quality stream.
Neural codecs are indeed the future of audio and video compression. A lot of people / organizations are working on them and they are close to being practical. E.g. https://arxiv.org/abs/2502.20762
>So now that h.264, h.265, and AV1 seem to be the three major codecs with hardware support
That'd be h264 (associated patents expired in most of the world), vp9 and av1.
h265 aka HEVC is less common due to dodgy, abusive licensing. Some vendors even disable it with drivers despite hardware support because it is nothing but legal trouble.
I'm running an LG initially released in 2013 and the only thing I'm not happy with is that about a year ago Netflix ended their app for that hardware generation (likely for phasing out whatever codec it used). Now I'm running that unit behind an Amazon fire stick and the user experience is so much worse.
(that LG was a "smart" TV from before they started enshittifying, such a delight - had to use and set up a recent LG once on a family visit and it was even worse than the fire stick, omg, so much worse!)
Two years ago I bought a Snapdragon 8+ Gen 1 phone (TSMC 4nm, with 12 GB LPDDR RAM, 256 GB NAND flash, and a 200 megapixel camera). It still feels pretty modern but it has no AV1 support.
because device makers will not care for the DRM, but will care for the hardware decoder they need to decide to put into their devices to decode netflix videos. By ensuring this video codec is open, it benefits everybody else now, as this same device will now be able to hardware decode _more_ videos from different video providers, as well as make more video providers choose AV1.
> AV1 streaming sessions achieve VMAF scores¹ that are 4.3 points higher than AVC and 0.9 points higher than HEVC sessions. At the same time, AV1 sessions use one-third less bandwidth than both AVC and HEVC, resulting in 45% fewer buffering interruptions.
Just thought I'd extract the part I found interesting as a performance engineer.
This VMAF comparison is to be taken with a grain of salt. Netflix' primary goal was to reduce the bitrate consumption, as can be seen, while roughly keeping the same nominal quality of the stream. This means that, ignoring all other factors and limitations of H.264 with higher resolutions, VMAF scores for all their streaming sessions should roughly be the same, or in a comparable range, because that's what they're optimizing for. (See the Dynamic Optimizer Framework they have publicly posted a few years ago.)
I had forgotten about the film-grain extraction, which is a clever approach to a huge problem for compression.
But... did I miss it, or was there no mention of any tool to specify grain parameters up front? If you're shooting "clean" digital footage and you decide in post that you want to add grain, how do you convey the grain parameters to the encoder?
It would degrade your work and defeat some of the purpose of this clever scheme if you had to add fake grain to your original footage, feed the grainy footage to the encoder to have it analyzed for its characteristics and stripped out (inevitably degrading real image details at least a bit), and then have the grain re-added on delivery.
So you need a way to specify grain characteristics to the encoder directly, so clean footage can be delivered without degradation and grain applied to it upon rendering at the client.
Actual film grain (i.e., photochemical) is arguably a valid source of information. You can frame it as noise, but does provide additional information content that our visual system can work with.
Removing real film grain from content and then recreating it parametrically on the other side is not the same thing as directly encoding it. You are killing a lot of information. It is really hard to quantify exactly how we perceive this sort of information so it's easy to evade the consequences of screwing with it. Selling the Netflix board on an extra X megabits/s per streamer to keep genuine film grain that only 1% of the customers will notice is a non-starter.
You just add it to your original footage, and accept whatever quality degradation that grain inherently provides.
Any movie or TV show is ultimately going to be streamed in lots of different formats. And when grain is added, it's often on a per-shot basis, not uniformly. E.g. flashback scenes will have more grain. Or darker scenes will have more grain added to emulate film.
Trying to tie it to the particular codec would be a crazy headache. For a solo project it could be doable but I can't ever imagine a streamer building a source material pipeline that would handle that.
Mmmm, no, because if the delivery conduit uses AV1, you can optimize for it and realize better quality by avoiding the whole degrading round of grain analysis and stripping.
"I can't ever imagine a streamer building a source material pipeline that would handle that."
That's exactly what the article describes, though. It's already built, and Netflix is championing this delivery mechanism. Netflix is also famous for dictating technical requirements for source material. Why would they not want the director to be able to provide a delivery-ready master that skips the whole grain-analysis/grain-removal step and provides the best possible image quality?
Presumably the grain extraction/re-adding mechanism described here handles variable grain throughout the program. I don't know why you'd assume that it doesn't. If it didn't, you'd wind up with a single grain level for the entire movie; an entirely unacceptable result for the very reason you mention.
This scheme loses a major opportunity for new productions unless the director can provide a clean master and an accompanying "grain track." Call it a GDL: grain decision list.
This would also be future-proof; if a new codec is devised that also supports this grain layer, the parameters could be translated from the previous master into the new codec. I wish Netflix could go back and remove the hideous soft-focus filtration from The West Wing, but nope; that's baked into the footage forever.
There's an HDR war brewing on TikTok and other social apps. A fraction of posts that use HDR are just massively brighter than the rest; the whole video shines like a flashlight. The apps are eventually going to have to detect HDR abuse.
I know how bad the support for HDR is on computers (particularly Windows and cheap monitors), so I avoid consuming HDR content on them.
But I just purchased a new iPhone 17 Pro, and I was very surprised at how these HDR videos on social media still look like shit on apps like Instagram.
And even worse, the HDR video I shoot with my iPhone looks like shit even when playing it back on the same phone! After a few trials I had to just turn it off in the Camera app.
I wonder if it fundamentally only really makes sense for film, video games, etc. where a person will actually tune the range per scene. Plus, only when played on half decent monitors that don’t just squash BT.2020 so they can say HDR on the brochure.
The HDR implementation in Windows 11 is fine. And it's not even that bad in 11 in terms of titles and content officially supporting HDR. Most of the ideas that it's "bad" comes from the "cheap monitor" part, not windows.
I have zero issues and only an exceptional image on W11 with a PG32UQX.
The only time I shoot HDR on anything is because I plan on crushing the shadows/raising highlights after the fact. S curves all the way. Get all the dynamic range you can and then dial in the look. Otherwise it just looks like a flat washed out mess most of the time
What if they did HDR for audio? So an audio file can tell your speakers to output at 300% of the normal max volume, even more than what compression can do.
This is one of the reasons I don't like HDR support "by default".
HDR is meant to be so much more intense, it should really be limited to things like immersive full-screen long-form-ish content. It's for movies, TV shows, etc.
It's not what I want for non-immersive videos you scroll through, ads, etc. I'd be happy if it were disabled by the OS whenever not in full screen mode. Unless you're building a video editor or something.
Sounds like they need something akin to audio volume normalization but for video. You can go bright, but only in moderation, otherwise your whole video gets dimmed down until the average is reasonable.
Every phone has it, it’s called “power save mode” on most devices and provides additional advantages like preventing apps from doing too much stuff in the background. =)
HDR has a slight purpose, but the way it was rolled out was so disrespectful that I just want it permanently gone everywhere. Even the rare times it's used in a non-abusive way, it can hurt your eyes or make things display weirdly.
That's true on the web, as well; HDR images on web pages have this problem.
It's not obvious whether there's any automated way to reliably detect the difference between "use of HDR" and "abuse of HDR". But you could probably catch the most egregious cases, like "every single pixel in the video has brightness above 80%".
Funnily enough HDR already has to detect this problem, because most HDR monitors literally do not have the power circuitry or cooling to deliver a complete white screen at maximum brightness.
My idea is: for each frame, grayscale the image, then count what percentage of the screen is above the standard white level. If more than 20% of the image is >SDR white level, then tone-map the whole video to the SDR white point.
> Wouldn't that just hurt the person posting it since I'd skip over a bright video?
Sure, in the same way that advertising should never work since people would just skip over a banner ad. In an ideal world, everyone would uniformly go "nope"; in our world, it's very much analogous to the https://en.wikipedia.org/wiki/Loudness_war .
sounds like every fad that came before it where it was over used by all of the people copying with no understanding of what it is or why. remember all of the HDR still images that pushed everything to look post-apocalyptic? remember all of the people pushing washed out videos because they didn't know how to grade the images recorded in log and it became a "thing"?
eventually, it'll wear itself out just like every other over use of the new
I would love to know who the hell thought adding "brighter than white" range to HDR was a good idea. Or, even worse, who the hell at Apple thought implementing that should happen by way of locking UI to the standard range. Even if you have a properly mastered HDR video (or image), and you've got your brightness set to where it doesn't hurt to look at, it still makes all the UI surrounding that image look grey. If I'm only supposed to watch HDR in fullscreen, where there's no surrounding UI, then maybe you should tone-map to SDR until I fullscreen the damn video?
Yup, totally agreed. I said the same thing in another comment -- HDR should be reserved only for full-screen stuff where you want to be immersed in it, like movies and TV shows.
Unless you're using a video editor or something, everything should just be SDR when it's within a user interface.
HDR videos on social media look terrible because the UI isn’t in HDR while the video isn’t. So you have this insanely bright video that more or less ignores your brightness settings, and then dim icons on top of it that almost look incomplete or fuzzy cause of their surroundings. It looks bizarre and terrible.
It's good if you have black text on white background, since your app can have good contrast without searing your eyes. People started switching to dark themes to avoid having their eyeballs seared monitors with the brightness high.
For things filmed with HDR in mind it's a benefit. Bummer things always get taken to the extreme.
Not sure how it works on Android, but it's such amateur UX on Apple's part.
99.9% of people expect HDR content to get capped / tone-mapped to their display's brightness setting.
That way, HDR content is just magically better. I think this is already how HDR works on non-HDR displays?
For the 0.01% of people who want something different, it should be a toggle.
Unfortunately I think this is either (A) amateur enshittification like with their keyboards 10 years ago, or (B) Apple specifically likes how it works since it forces you to see their "XDR tech" even though it's a horrible experience day to day.
Netflix has been the worst performing and lowest quality video stream of any of the streaming services. Fuzzy video, lots of visual noise and artifacts. Just plan bad and this is on the 4k plan on 1GB fiber on a 4k Apple TV. I can literally tell when someone is watching Netflix without knowing because it looks like shit.
It's not AV1's fault though, I'm pretty sure it's that they cheap out on the bitrate. Apple is among the highest bitrates (other than Sony's weird hardware locked streaming service).
I actually blamed AV1 for the macro-blocking and generally awful experience of watching horror films on Netflix for a long time. Then I realized other sources using AV1 were better.
If you press ctl-alt-shift-d while the video is playing you'll note that most of the time that the bitrate is appallingly low, and also that Netflix plays their own original content using higher bitrate HEVC rather than AV1.
That's because they actually want it to look good. For partner content they often default back to lower bitrate AV1, because they just don't care.
This is actually their DRM speaking. If you watch it on a Linux device or basically anything that isn’t a smart TV on the latest OS, they limit you to a 720p low bitrate stream, even if you pay for 4k. (See Louis Rossman’s video on the topic)
Have same experience as OP on newest ATV 4k.
Good it's not only me who wonders how is it possible that they describe such great approaches to encoding, but final result is just so bad.
Good that the OCAs really work and are very inspiring in content delivery domain.
I also find Netflix video quality shockingly bad and oddly inconsistent. I think they just don’t prioritize video quality in the same way as say apple or Disney does.
I was able to improve things somewhat by going to https://www.netflix.com/settings/playback/<myprofileid> and changing "Data usage per screen" from Auto to High
I cancelled Netflix for this exact reason. 4K Netflix looks worse than 720 YouTube, yet I pay(paid) for Netflix 4K, and at roughly 2x what I paid for Netflix when it launched. It's genuinely a disgrace how they can even claim with a straight face that you're actually watching 4K. The last price rise was the tipping point and I tapped out after 11 years.
Probably some function of your location to data centers. I find hbo max to be aysmal these days. But I've learned to just stop caring about this stuff since no one else in my life does
I'm surprised AV1 usage is only at 30%. Is AV1 so demanding that Netflix clients without AV1 hardware acceleration capabilities would be overwhelmed by it?
Thanks to libdav1d's [1] lovingly hand crafted SIMD ASM instructions it's actually possible to reasonably playback AV1 without hardware acceleration, but basically yes: From Snapdragon 8 onwards, Google Tensor G3 onwards, NVIDIA RTX 3000 series onwards. All relatively new .
There are a lot of 10 year old TVs/fire sticks still in use that have a CPU that maxes out running the UI and rely exclusively on hardware decoding for all codecs (e.g. they couldn't hardware decode h264 either). Image a super budget phone from ~2012 and you'll have some idea the hardware capability we're dealing with.
Compression gains will mostly be for the benefit of the streaming platform’s bills/infra unless you’re trying to stream 4K 60fps on hotel wifi (or if you can’t decode last-gen codecs on hardware either ). Apparently streaming platforms still favor user experience enough to not heat their rooms for no observable improvement. Also a TV CPU can barely decode a PNG still in software - video decoding of any kind is simply impossible.
I'd love to watch Netflix AV1 streams but they just straight up don't serve it to my smart TV or my Windows computers despite hardware acceleration support.
The only way I can get them to serve me an AV1 stream is if I block "protected content IDs" through browser site settings. Otherwise they're giving me an H.264 stream... It's really silly, to say the least
If you are on a mobile device, decoding without hardware assistance might not overwhelm the processors directly, but it might drain your battery unnecessarily fast?
I'm a hobbiest video encoder (mostly I like to experiment in backing up my DVD collection), and I recently switched to using AV1 over HEVC.
I've found the ratio of a fixed quality vs CPU load to be better, and I've found it is reasonably good at retaining detail over smoothing things out when compared to HEVC. And the ability to add generated "pseudo grain" works pretty well to give the perception of detail. The performance of GPU encoders (while still not good enough fory maybe stringent standards) is better.
AV1 is not new anymore and I think most of the modern devices are supporting them natively. Some devices like Apple even have a dedicated AV1 HW-accelerator. Netflix has pushing AV1 for a while now so I thought that the adoption rate should be like 50%, but it seems like AV1 requires better hardware and newer software which a lot of people don't have.
Dont forget that people also view Netflix on TV’s, and a large number of physical TV’s were made before AV1 was specced. So 30% overall may also mean 70% on modern devices.
Uh what. (Embedded) hardware lasts a long time (and it should!). TV's around the globe are not all built after 2018. H264 is still the gold standard if you want to be sure a random device has hardware acceleration.
I make use of this by taking a USB hard drive with me on trips. Random TV's rarely have issue with my H264 catalogue. It'll be a while before I look at AV1 for this. Sure, I wish I could benefit faster, but I don't want people to throw out perfectly good hardware either!
There are other possible explanations, e.g. AVC and HEVC are set to the same bitrate, so AVC streams lose quality, while AV1 targets HEVC's quality. Or they compare AV1 traffic to the sum of all mixed H.26x traffic. Or the rates vary in more complex ways and that's an (over)simplified summary for the purpose of the post.
Netflix developed VMAF, so they're definitely aware of the complexity of matching quality across codecs and bitrates.
I have no doubt they know what they are doing. But it's a srange metric no matter how you slice it. Why compare AV1's bandwith to the average of h.264 and h.265, and without any more details about resolution or compression ratio? Reading between the lines, it sounds like they use AV1 for low bandwidth and h.265 for high bandwidth and h.264 as a fallback. If that is the case, why bring up this strange average bandwidth comparison?
I doubt that. Netflix has an app on TVs as old as 8-10 years now. SoCs in such TVs aren't enough to decode AV1. They're stuck with H.264 for a long time.
Weirdly, Netflix on my Samsung TV it's been a few months it's using only H264. Not AV1. When they first launched AV1, it worked there...
Honestly not complaining, because they were using AV1 with 800-900~kbps for 1080p content, which is clearly not enough compared to their 6Mbps h.264 bitrate.
On a related note, why are release groups not putting out AV1 WEB-DLs? Most 4K stuff is h265 now but if AV1 is supplied without re-encoding surely that would be better?
I looked into this before, and the short answer is that release groups would be allowed to release in AV1, but the market seems to prefer H264 and H265 because of compatibility and release speed. Encoding AV1 to an archival quality takes too long, reduces playback compatibility, and doesn't save that much space.
There also are no scene rules for AV1, only for H265 [1]
AV1 is the king of ultra-low bitrates, but as you go higher — and not even that much higher — HEVC becomes just as good, if not more. Publicly-available AV1 encoders (still) have a tendency to over-flatten anything that is low-contrast enough, while x265 is much better at preserving visual energy.
This problem is only just now starting to get solved in SVT-AV1 with the addition of community-created psychovisual optimizations... features that x264 had over 15 years ago!
> Encoding AV1 to an archival quality takes too long
With the SVT-AV1 encoder you can achieve better quality in less time versus the x265 encoder. You just have to use the right presets. See the encoding results section:
Player compatibility. Netflix can use AV1 and send it to the devices that support it while sending H265 to those that don't. A release group puts out AV1 and a good chunk of users start avoiding their releases because they can't figure out why it doesn't play (or plays poorly).
h.264 has near-universal device support and almost no playback issues at the expensive of slightly larger file sizes. h.265 and av1 give you 10-bit 4K but playback on even modest laptops can become choppy or produce render artifacts. I tried all three, desperately wanting av1 to win but Jellyfin on a small streaming server just couldn't keep up.
I'm not in the scene anymore, but for my own personal encoding, at higher quality settings, AV1 (rav1e or SVT; AOM was crazy slow) doesn't significantly beat out x265 for most sources.
FGS makes a huge difference at moderately high bitrates for movies that are very grainy, but many people seem to really not want it for HQ sources (see sibling comments). With FGS off, it's hard to find any sources that benefit at bitrates that you will torrent rather than stream.
Bigger PT sites with strict rules do not allow it yet and are actively discussing/debating it.Netflix Web-DLs being AV1 is definitely pushing that. The codec has to be a select-able option during upload.
Everyone is affected by that mess, did you miss the recent news about Dell and HP dropping HEVC support in hardware they have already shipped? Encoders might not care about legal purity of the encoding process, but they do have to care about how it's going to be decoded. I like using proper software to view my videos, but it's a rarity afaik.
I've seen some on private sites. My guess is they are not popular enough yet. Or pirates are using specific hardware to bypass Widevine encryption (like an Nvidia Shield and burning keys periodically) that doesn't easily get the AV1 streams.
I wish everyone knew the difference between patents and copyright.
You can download an open source HEVC codec, and use it for all they care according to their copyright. But! You also owe MPEG-LA 0.2 USD if you want to use it, not to mention an undisclosed sum to actors like HEVC Advance and all the other patent owners I don't remember, because they have their own terms, and it's not their problem that you compiled an open source implementation.
VP9 is more on the level of H265 really. VVC/H266 is closer to AV1. It's not an exact comparison but it is close. The licensing is just awful for VVC similar to HEVC and now that AV1 has proved itself everyone is pivoting away from VVC/h266 especially on the consumer side. Pretty much all VVC adoption is entirely internal (studios, set top boxes, etc) and it is not used by any major consumer streaming service afaik.
> At Netflix, our top priority is delivering the best possible entertainment experience to our members.
I dont think that is true of any streamers. Otherwise they wouldnt provide the UI equivalent of a shopping centre that tries to get you lost and unable to find your way out.
Compression is great and all, but Netflix is overdoing it and their content looks like an over-sharpened mess with lego blocks in high intensity scenes. And no, it's not my connection, Apple TV does it far better and so does Prime.
It's really sad that most people never get to experience a good 4K Blu-ray, where the grain is actually part of the image as mastered and there's enough bitrate to not rely on sharpening.
Am I the only one that thought this is an old article by the title? AV1 is now 10 years old and AV2 has been announced for year-end release few months ago. If anything the news is that AV1 powers only 30% by now. At least HEVC, released about the same time, has gotten quite popular in warez scene (movies/TV/anime) for small encodes, whereas AV1 releases are still considered a rarity. (Though to be fair 30% Netflix & YT means AV1 usage in total is much higher.) Will've expected a royalty-free codec to've been embraced more but seems its difficulty for long time to be played on low power devices hindered its adoption.
Something doesn’t quite add up to me. The post says “AV1 powers approximately 30% of all Netflix viewing”. Impressive, but I’m wondering why it isn’t higher? I’m guessing most devices should support AV1 software decoders. 88% of devices in certified in the last 4 years support AV1, all browsers support AV1 software decoding, Netflix apps on Android (since 2021) and iOS (since 2023) obviously do.
So why isn’t it AV1 higher? The post doesn’t say, so we can only speculate. It feels like they’re preferring hardware decoding to software decoding, even if it’s an older codec. If this is true, it would make sense - it’s better for the client’s power and battery consumption.
But then why start work on AV2 before AV1 has even reached a majority of devices? I’m sure they have the answer but they’re not sharing here.
Smart TVs, TV sticks, and a lot of mobile devices will not be capable of decoding AV1 in software in realtime, given their low-spec CPUs. I imagine that Netflix is only serving AV1 to devices with hardware decoding support.
I understand that sometimes the HN titles get edited to be less descriptive and more generic in order to match the actual article title.
What’s the logic with changing the title here from the actual article title it was originally submitted with “AV1 — Now Powering 30% of Netflix Streaming” to the generic and not at all representative title it currently has “AV1: a modern open codec”? That is neither the article title nor representative of the article content.
We generally try to remove numbers from titles, because numbers tend to make a title more baity than it would otherwise be, and quite often (e.g., when reporting benchmark test results) a number is cherry-picked or dialed up for maximum baitiness. In this case, the number isn't exaggerated, but any number tends to grab the eye more than words, so it's just our convention to remove number-based titles where we can.
The thing with this title is that the number isn't primarily what the article is about, and in fact it under-sells what the article really is, which is a quite-interesting narrative of Netflix's journey from H.264/AVC, to the initial adoption of AV1 on Android in 2020, to where it is now: 30% adoption across the board.
When we assess that an article's original title is baity or misleading, we try to find a subtitle or a verbatim sentence in the article that is sufficiently representative of the content.
The title I chose is a subtitle, but I didn't take enough care to ensure it was adequately representative. I've now chosen a different subtitle which I do think is the most accurate representation of what the whole article is about.
AV1 is fine as-is. Plenty of technical titles on HN would need to be googled if you didn't know it. Even in yours, HDR10+ "could be anything if you don't know it". Play this game if you want, but it's unwindable. The only people who care about AV1 already know what it is.
If there really was a “mania for obscurity in titles” we’d see a lot more complaints than we do.
Our title policy is pretty simple and attuned for maximum respect to the post’s author/publisher and the HN audience.
We primarily just want to retain the title that was chosen by the author/publisher, because it’s their work and they are entitled to have such an important part of their work preserved.
The only caveat is that if the title is baity or misleading, we’ll edit it, but only enough that it’s no longer baity or misleading. That’s because clickbait and misleading titles are disrespectful to the audience.
Any time you see a title that doesn’t conform to these principles, you’re welcome to email us and ask us to review it. Several helpful HN users do this routinely.
I really like moderation on HN in general, but honestly this inconsistent policy of editorializing titles is bad. There were plenty of times where submitter editorialized titles (e.g GitHub code dumps of some project) were changed back to useless and vague (without context) original titles.
And now HN administration tend to editorialize in their own way.
For me that’s a FU moment that reminds me ‘TF am I doing here?’ I genuinely see this resource as a censoring plus advertising (both for YC, obviously) platform, where there are generic things, but also things someone doesn’t want you to read or know. The titles are constantly being changed to gibberish like right here, the adequate comments or posts are being dead, yet the absolutely irrelevant or offensive things, can stay not touched. Etc.
Also, it’s not the whole picture. AV1 is open because it didn’t have the good stuff (newly patented things) and as such I also wouldn’t say it’s the most modern.
AV1 has plenty of good stuff. AOM (the agency that developed AV1) has a patent pool https://www.stout.com/en/insights/article/sj17-the-alliance-... comprising of video hardware/software patents from Netflix, Google, Nvidia, Arm, Intel, Microsoft, Amazon and a bunch of other companies. AV1 has a bunch of patents covering it, but also has a guarantee that you're allowed to use those patents as you see fit (as long as you don't sue AOM members for violating media patents).
AV1 definitely is missing some techniques patented by h264 and h265, but AV2 is coming around now that all the h264 innovations are patent free (and now that there's been another decade of research into new cutting edge techniques for it).
Just because something is patented doesn't necessarily mean its good. I think head to head comparisons matter more. (Admittedly i dont know how av1 holds up)
IIRC, there's a time/recency factor. If we assume that most people don't browse /newest (without commenting on should, I suspect this is true), then that seems like a reasonable way to help surface things; enough upvotes to indicate interest means a story gets a chance at the front page.
Wow. To me, the big news here is that ~30% of devices now support AV1 hardware decoding. The article lists a bunch of examples of devices that have gained it in the past few years. I had no idea it was getting that popular -- fantastic news!
So now that h.264, h.265, and AV1 seem to be the three major codecs with hardware support, I wonder what will be the next one?
> To me, the big news here is that ~30% of devices now support AV1 hardware decoding
Where did it say that?
> AV1 powers approximately 30% of all Netflix viewing
Is admittedly a bit non-specific, it could be interpreted as 30% of users or 30% of hours-of-video-streamed, which are very different metrics. If 5% of your users are using AV1, but that 5% watches far above the average, you can have a minority userbase with an outsized representation in hours viewed.
I'm not saying that's the case, just giving an example of how it doesn't necessarily translate to 30% of devices using Netflix supporting AV1.
Also, the blog post identifies that there is an effective/efficient software decoder, which allows people without hardware acceleration to still view AV1 media in some cases (the case they defined was Android based phones). So that kinda complicates what "X% of devices support AV1 playback," as it doesn't necessarily mean they have hardware decoding.
That was one of the best decisions of AOMedia.
AV1 was specifically designed to be friendly for a hardware decoder and that decision makes it friendly to software decoding. This happened because AOMedia got hardware manufacturers on the board pretty early on and took their feedback seriously.
VP8/9 took a long time to get decent hardware decoding and part of the reason for that was because the stream was more complex than the AV1 stream.
4 replies →
“30% of viewing” I think clearly means either time played or items played. I’ve never worked with a data team that would possibly write that and mean users.
If it was a stat about users they’d say “of users”, “of members”, “of active watchers”, or similar. If they wanted to be ambiguous they’d say “has reached 30% adoption” or something.
2 replies →
In either case, it is still big news.
> So now that h.264, h.265, and AV1 seem to be the three major codecs with hardware support, I wonder what will be the next one?
Hopefully AV2.
H266/VVC has a five year head-start over AV2, so probably that first unless hardware vendors decide to skip it entirely. The final AV2 spec is due this year, so any day now, but it'll take a while to make it's way into hardware.
15 replies →
> So now that h.264, h.265, and AV1 seem to be the three major codecs with hardware support, I wonder what will be the next one?
Hopefully, we can just stay on AV1 for a long while. I don't feel any need to obsolete all the hardware that's now finally getting hardware decoding support for AV1.
That's not at all how I read it.
They mentioned they delivered a software decoder on android first, then they also targeted web browsers (presumably through wasm). So out of these 30%, a good chunk of it is software not hardware.
That being said, it's a pretty compelling argument for phone and tv manufacturers to get their act together, as Apple has already done.
I'm not too surprised. It's similar to the metric that "XX% of Internet is on IPv6" -- it's almost entirely driven by mobile devices, specifically phones. As soon as both mainstream Android and iPhones support it, the adoption of AV1 should be very 'easy'.
(And yes, even for something like Netflix lots of people consume it with phones.)
Not trolling, but I'd bet something that's augmented with generative AI. Not to the level of describing scenes with words, but context-aware interpolation.
I don't want my video decoder inventing details which aren't there. I much rather want obvious compression artifacts than a codec where the "compression artifacts" look like perfectly realistic, high-quality hallucinated details.
11 replies →
AI embeddings can be seen as a very advanced form of lossy compression
https://blogs.nvidia.com/blog/rtx-video-super-resolution/
We already have some of the stepping stones for this. But honestly much better for upscaling poor quality streams vs just gives things a weird feeling when it is a better quality stream.
Neural codecs are indeed the future of audio and video compression. A lot of people / organizations are working on them and they are close to being practical. E.g. https://arxiv.org/abs/2502.20762
for sure. macroblock hinting seems like a good place for research.
how does that mean "~30% of devices now support AV1 hardware encoding"? I'm guessing you meant hardware decoding???
Whoops, thanks. Fixed.
>So now that h.264, h.265, and AV1 seem to be the three major codecs with hardware support
That'd be h264 (associated patents expired in most of the world), vp9 and av1.
h265 aka HEVC is less common due to dodgy, abusive licensing. Some vendors even disable it with drivers despite hardware support because it is nothing but legal trouble.
I have the feeling that H265 is more prevalent than VP9
I mean... I bought a Samsung TV in 2020, and it already supported AV1 HW decoding.
2020 feels close, but that's 5 years.
Is that supposed to be long-lived for a TV?
I'm running an LG initially released in 2013 and the only thing I'm not happy with is that about a year ago Netflix ended their app for that hardware generation (likely for phasing out whatever codec it used). Now I'm running that unit behind an Amazon fire stick and the user experience is so much worse.
(that LG was a "smart" TV from before they started enshittifying, such a delight - had to use and set up a recent LG once on a family visit and it was even worse than the fire stick, omg, so much worse!)
3 replies →
Two years ago I bought a Snapdragon 8+ Gen 1 phone (TSMC 4nm, with 12 GB LPDDR RAM, 256 GB NAND flash, and a 200 megapixel camera). It still feels pretty modern but it has no AV1 support.
Amazing. Proprietary video codecs need to not be the default and this is huge validation for AV1 as a production-ready codec.
Why does it matter if Netflix is using an open standard if every video they stream is wrapped in proprietary closed DRM?
because device makers will not care for the DRM, but will care for the hardware decoder they need to decide to put into their devices to decode netflix videos. By ensuring this video codec is open, it benefits everybody else now, as this same device will now be able to hardware decode _more_ videos from different video providers, as well as make more video providers choose AV1.
Basically, a network effect for an open codec.
6 replies →
> Why does it matter if Netflix is using an open standard if every video they stream is wrapped in proprietary closed DRM?
I am not sure if this is a serious question, but I'll bite in case it is.
Without DRM Netflix's business would not exist. Nobody would license them any content if it was going to be streamed without a DRM.
8 replies →
> AV1 streaming sessions achieve VMAF scores¹ that are 4.3 points higher than AVC and 0.9 points higher than HEVC sessions. At the same time, AV1 sessions use one-third less bandwidth than both AVC and HEVC, resulting in 45% fewer buffering interruptions.
Just thought I'd extract the part I found interesting as a performance engineer.
This VMAF comparison is to be taken with a grain of salt. Netflix' primary goal was to reduce the bitrate consumption, as can be seen, while roughly keeping the same nominal quality of the stream. This means that, ignoring all other factors and limitations of H.264 with higher resolutions, VMAF scores for all their streaming sessions should roughly be the same, or in a comparable range, because that's what they're optimizing for. (See the Dynamic Optimizer Framework they have publicly posted a few years ago.)
Still impressive numbers, of course.
I had forgotten about the film-grain extraction, which is a clever approach to a huge problem for compression.
But... did I miss it, or was there no mention of any tool to specify grain parameters up front? If you're shooting "clean" digital footage and you decide in post that you want to add grain, how do you convey the grain parameters to the encoder?
It would degrade your work and defeat some of the purpose of this clever scheme if you had to add fake grain to your original footage, feed the grainy footage to the encoder to have it analyzed for its characteristics and stripped out (inevitably degrading real image details at least a bit), and then have the grain re-added on delivery.
So you need a way to specify grain characteristics to the encoder directly, so clean footage can be delivered without degradation and grain applied to it upon rendering at the client.
Actual film grain (i.e., photochemical) is arguably a valid source of information. You can frame it as noise, but does provide additional information content that our visual system can work with.
Removing real film grain from content and then recreating it parametrically on the other side is not the same thing as directly encoding it. You are killing a lot of information. It is really hard to quantify exactly how we perceive this sort of information so it's easy to evade the consequences of screwing with it. Selling the Netflix board on an extra X megabits/s per streamer to keep genuine film grain that only 1% of the customers will notice is a non-starter.
You just add it to your original footage, and accept whatever quality degradation that grain inherently provides.
Any movie or TV show is ultimately going to be streamed in lots of different formats. And when grain is added, it's often on a per-shot basis, not uniformly. E.g. flashback scenes will have more grain. Or darker scenes will have more grain added to emulate film.
Trying to tie it to the particular codec would be a crazy headache. For a solo project it could be doable but I can't ever imagine a streamer building a source material pipeline that would handle that.
Mmmm, no, because if the delivery conduit uses AV1, you can optimize for it and realize better quality by avoiding the whole degrading round of grain analysis and stripping.
"I can't ever imagine a streamer building a source material pipeline that would handle that."
That's exactly what the article describes, though. It's already built, and Netflix is championing this delivery mechanism. Netflix is also famous for dictating technical requirements for source material. Why would they not want the director to be able to provide a delivery-ready master that skips the whole grain-analysis/grain-removal step and provides the best possible image quality?
Presumably the grain extraction/re-adding mechanism described here handles variable grain throughout the program. I don't know why you'd assume that it doesn't. If it didn't, you'd wind up with a single grain level for the entire movie; an entirely unacceptable result for the very reason you mention.
This scheme loses a major opportunity for new productions unless the director can provide a clean master and an accompanying "grain track." Call it a GDL: grain decision list.
This would also be future-proof; if a new codec is devised that also supports this grain layer, the parameters could be translated from the previous master into the new codec. I wish Netflix could go back and remove the hideous soft-focus filtration from The West Wing, but nope; that's baked into the footage forever.
2 replies →
There's an HDR war brewing on TikTok and other social apps. A fraction of posts that use HDR are just massively brighter than the rest; the whole video shines like a flashlight. The apps are eventually going to have to detect HDR abuse.
The whole HDR scene still feels like a mess.
I know how bad the support for HDR is on computers (particularly Windows and cheap monitors), so I avoid consuming HDR content on them.
But I just purchased a new iPhone 17 Pro, and I was very surprised at how these HDR videos on social media still look like shit on apps like Instagram.
And even worse, the HDR video I shoot with my iPhone looks like shit even when playing it back on the same phone! After a few trials I had to just turn it off in the Camera app.
I wonder if it fundamentally only really makes sense for film, video games, etc. where a person will actually tune the range per scene. Plus, only when played on half decent monitors that don’t just squash BT.2020 so they can say HDR on the brochure.
1 reply →
The HDR implementation in Windows 11 is fine. And it's not even that bad in 11 in terms of titles and content officially supporting HDR. Most of the ideas that it's "bad" comes from the "cheap monitor" part, not windows.
I have zero issues and only an exceptional image on W11 with a PG32UQX.
3 replies →
The only time I shoot HDR on anything is because I plan on crushing the shadows/raising highlights after the fact. S curves all the way. Get all the dynamic range you can and then dial in the look. Otherwise it just looks like a flat washed out mess most of the time
Just what we need, a new loudness war, but for our eyeballs.
https://en.wikipedia.org/wiki/Loudness_war
What if they did HDR for audio? So an audio file can tell your speakers to output at 300% of the normal max volume, even more than what compression can do.
1 reply →
Interestingly, the loudness war was essentially fixed by the streaming services. They were in a similar situation as Tik Tok is now.
6 replies →
This is one of the reasons I don't like HDR support "by default".
HDR is meant to be so much more intense, it should really be limited to things like immersive full-screen long-form-ish content. It's for movies, TV shows, etc.
It's not what I want for non-immersive videos you scroll through, ads, etc. I'd be happy if it were disabled by the OS whenever not in full screen mode. Unless you're building a video editor or something.
Or a photo viewer, which isn't necessarily running in fullscreen.
Sounds like they need something akin to audio volume normalization but for video. You can go bright, but only in moderation, otherwise your whole video gets dimmed down until the average is reasonable.
Actually I don’t even agree with that. I don’t want to be flash banged.
I was about to write that. The algorithm need to be chosen, what is mostly used for audio gain normalization? Rolling average?
[dead]
> The apps are eventually going to have to detect HDR abuse
The latest android release has a setting that is the HDR version of “volume leveling”.
My phone has this cool feature where it doesn't support HDR.
Every phone has it, it’s called “power save mode” on most devices and provides additional advantages like preventing apps from doing too much stuff in the background. =)
HDR has a slight purpose, but the way it was rolled out was so disrespectful that I just want it permanently gone everywhere. Even the rare times it's used in a non-abusive way, it can hurt your eyes or make things display weirdly.
That's true on the web, as well; HDR images on web pages have this problem.
It's not obvious whether there's any automated way to reliably detect the difference between "use of HDR" and "abuse of HDR". But you could probably catch the most egregious cases, like "every single pixel in the video has brightness above 80%".
Funnily enough HDR already has to detect this problem, because most HDR monitors literally do not have the power circuitry or cooling to deliver a complete white screen at maximum brightness.
My idea is: for each frame, grayscale the image, then count what percentage of the screen is above the standard white level. If more than 20% of the image is >SDR white level, then tone-map the whole video to the SDR white point.
2 replies →
> It's not obvious whether there's any automated way to reliably detect the difference between "use of HDR" and "abuse of HDR".
That sounds like a job our new AI overlords could probably handle. (But that might be overkill.)
Can someone explain what the war is about?
Like HDR abuse makes it sound bad, because the video is bright? Wouldn't that just hurt the person posting it since I'd skip over a bright video?
Sorry if I'm phrasing this all wrong, don't really use TikTok
> Wouldn't that just hurt the person posting it since I'd skip over a bright video?
Sure, in the same way that advertising should never work since people would just skip over a banner ad. In an ideal world, everyone would uniformly go "nope"; in our world, it's very much analogous to the https://en.wikipedia.org/wiki/Loudness_war .
Not everything that glitters (or blinds) is gold.
sounds like every fad that came before it where it was over used by all of the people copying with no understanding of what it is or why. remember all of the HDR still images that pushed everything to look post-apocalyptic? remember all of the people pushing washed out videos because they didn't know how to grade the images recorded in log and it became a "thing"?
eventually, it'll wear itself out just like every other over use of the new
I would love to know who the hell thought adding "brighter than white" range to HDR was a good idea. Or, even worse, who the hell at Apple thought implementing that should happen by way of locking UI to the standard range. Even if you have a properly mastered HDR video (or image), and you've got your brightness set to where it doesn't hurt to look at, it still makes all the UI surrounding that image look grey. If I'm only supposed to watch HDR in fullscreen, where there's no surrounding UI, then maybe you should tone-map to SDR until I fullscreen the damn video?
Yup, totally agreed. I said the same thing in another comment -- HDR should be reserved only for full-screen stuff where you want to be immersed in it, like movies and TV shows.
Unless you're using a video editor or something, everything should just be SDR when it's within a user interface.
HDR videos on social media look terrible because the UI isn’t in HDR while the video isn’t. So you have this insanely bright video that more or less ignores your brightness settings, and then dim icons on top of it that almost look incomplete or fuzzy cause of their surroundings. It looks bizarre and terrible.
The alternative is even worse, where the whole UI is blinding you. Plus, that level of brightness isn't meant to be sustained.
The solution is for social media to be SDR, not for the UI to be HDR.
2 replies →
It's good if you have black text on white background, since your app can have good contrast without searing your eyes. People started switching to dark themes to avoid having their eyeballs seared monitors with the brightness high.
For things filmed with HDR in mind it's a benefit. Bummer things always get taken to the extreme.
1 reply →
Not sure how it works on Android, but it's such amateur UX on Apple's part.
99.9% of people expect HDR content to get capped / tone-mapped to their display's brightness setting.
That way, HDR content is just magically better. I think this is already how HDR works on non-HDR displays?
For the 0.01% of people who want something different, it should be a toggle.
Unfortunately I think this is either (A) amateur enshittification like with their keyboards 10 years ago, or (B) Apple specifically likes how it works since it forces you to see their "XDR tech" even though it's a horrible experience day to day.
2 replies →
But isn't it the point? Try looking at a light bulb; everything around it is so much less bright.
OTOH pointing a flaslight at your face is at least impolite. I would put a dark filter on top of HDR vdeos until a video is clicked for watching.
2 replies →
Netflix has been the worst performing and lowest quality video stream of any of the streaming services. Fuzzy video, lots of visual noise and artifacts. Just plan bad and this is on the 4k plan on 1GB fiber on a 4k Apple TV. I can literally tell when someone is watching Netflix without knowing because it looks like shit.
It's not AV1's fault though, I'm pretty sure it's that they cheap out on the bitrate. Apple is among the highest bitrates (other than Sony's weird hardware locked streaming service).
I actually blamed AV1 for the macro-blocking and generally awful experience of watching horror films on Netflix for a long time. Then I realized other sources using AV1 were better.
If you press ctl-alt-shift-d while the video is playing you'll note that most of the time that the bitrate is appallingly low, and also that Netflix plays their own original content using higher bitrate HEVC rather than AV1.
That's because they actually want it to look good. For partner content they often default back to lower bitrate AV1, because they just don't care.
This is actually their DRM speaking. If you watch it on a Linux device or basically anything that isn’t a smart TV on the latest OS, they limit you to a 720p low bitrate stream, even if you pay for 4k. (See Louis Rossman’s video on the topic)
OP said they're using an Apple TV, which most definitely supports the 4K DRM.
1 reply →
Have same experience as OP on newest ATV 4k. Good it's not only me who wonders how is it possible that they describe such great approaches to encoding, but final result is just so bad.
Good that the OCAs really work and are very inspiring in content delivery domain.
Yep, and they also silently downgrade resolution and audio channels on an ever changing and hidden list of browsers/OS/device overtime.
Meanwhile pirated movies are in Blu-ray quality, with all audio and language options you can dream of.
I also find Netflix video quality shockingly bad and oddly inconsistent. I think they just don’t prioritize video quality in the same way as say apple or Disney does.
I was able to improve things somewhat by going to https://www.netflix.com/settings/playback/<myprofileid> and changing "Data usage per screen" from Auto to High
I cancelled Netflix for this exact reason. 4K Netflix looks worse than 720 YouTube, yet I pay(paid) for Netflix 4K, and at roughly 2x what I paid for Netflix when it launched. It's genuinely a disgrace how they can even claim with a straight face that you're actually watching 4K. The last price rise was the tipping point and I tapped out after 11 years.
Netflix on Apple TV has an issue if "Match Content" is "off" where it will constantly downgrade the video stream to a lower bitrate unnecessarily.
Even fixing that issue the video quality is never great compared to other services.
Probably some function of your location to data centers. I find hbo max to be aysmal these days. But I've learned to just stop caring about this stuff since no one else in my life does
https://xkcd.com/1015/
Now you can be mad about two things nobody else notices.
Oddly enough, I observe something to the opposite effect.
I wonder if it has more to do with proximity to edge delivery nodes than anything else.
I'm surprised AV1 usage is only at 30%. Is AV1 so demanding that Netflix clients without AV1 hardware acceleration capabilities would be overwhelmed by it?
Thanks to libdav1d's [1] lovingly hand crafted SIMD ASM instructions it's actually possible to reasonably playback AV1 without hardware acceleration, but basically yes: From Snapdragon 8 onwards, Google Tensor G3 onwards, NVIDIA RTX 3000 series onwards. All relatively new .
[1] https://code.videolan.org/videolan/dav1d
It's possible without specific hardware acceleration, but murderous for mobile devices.
Even RISC-V vector assembly[0].
0. https://code.videolan.org/videolan/dav1d/-/issues/435
There are a lot of 10 year old TVs/fire sticks still in use that have a CPU that maxes out running the UI and rely exclusively on hardware decoding for all codecs (e.g. they couldn't hardware decode h264 either). Image a super budget phone from ~2012 and you'll have some idea the hardware capability we're dealing with.
Compression gains will mostly be for the benefit of the streaming platform’s bills/infra unless you’re trying to stream 4K 60fps on hotel wifi (or if you can’t decode last-gen codecs on hardware either ). Apparently streaming platforms still favor user experience enough to not heat their rooms for no observable improvement. Also a TV CPU can barely decode a PNG still in software - video decoding of any kind is simply impossible.
> Apparently streaming platforms still favor user experience enough to not heat their rooms for no observable improvement
It’s more like “why does Netflix kill my battery within an hour when I used to be able to play for 20”
I'd love to watch Netflix AV1 streams but they just straight up don't serve it to my smart TV or my Windows computers despite hardware acceleration support.
The only way I can get them to serve me an AV1 stream is if I block "protected content IDs" through browser site settings. Otherwise they're giving me an H.264 stream... It's really silly, to say the least
If you are on a mobile device, decoding without hardware assistance might not overwhelm the processors directly, but it might drain your battery unnecessarily fast?
Absolutely. Playing back any video codec is a terrible experience without acceleration.
tv manufacturers don't want high end chips for their tv sets... hardware decoding is just a way to make cheaper chips for tvs.
They would be served h.265
I'm a hobbiest video encoder (mostly I like to experiment in backing up my DVD collection), and I recently switched to using AV1 over HEVC.
I've found the ratio of a fixed quality vs CPU load to be better, and I've found it is reasonably good at retaining detail over smoothing things out when compared to HEVC. And the ability to add generated "pseudo grain" works pretty well to give the perception of detail. The performance of GPU encoders (while still not good enough fory maybe stringent standards) is better.
AV1 is not new anymore and I think most of the modern devices are supporting them natively. Some devices like Apple even have a dedicated AV1 HW-accelerator. Netflix has pushing AV1 for a while now so I thought that the adoption rate should be like 50%, but it seems like AV1 requires better hardware and newer software which a lot of people don't have.
Dont forget that people also view Netflix on TV’s, and a large number of physical TV’s were made before AV1 was specced. So 30% overall may also mean 70% on modern devices.
> AV1 is not new anymore
Uh what. (Embedded) hardware lasts a long time (and it should!). TV's around the globe are not all built after 2018. H264 is still the gold standard if you want to be sure a random device has hardware acceleration.
I make use of this by taking a USB hard drive with me on trips. Random TV's rarely have issue with my H264 catalogue. It'll be a while before I look at AV1 for this. Sure, I wish I could benefit faster, but I don't want people to throw out perfectly good hardware either!
This is really cool. Props to the team that created AV1. Very impressive
>AV1 sessions use one-third less bandwidth than both AVC and HEVC
Sounds like they set HEVC to higher quality then? Otherwise how could it be the same as AVC?
There are other possible explanations, e.g. AVC and HEVC are set to the same bitrate, so AVC streams lose quality, while AV1 targets HEVC's quality. Or they compare AV1 traffic to the sum of all mixed H.26x traffic. Or the rates vary in more complex ways and that's an (over)simplified summary for the purpose of the post.
Netflix developed VMAF, so they're definitely aware of the complexity of matching quality across codecs and bitrates.
I have no doubt they know what they are doing. But it's a srange metric no matter how you slice it. Why compare AV1's bandwith to the average of h.264 and h.265, and without any more details about resolution or compression ratio? Reading between the lines, it sounds like they use AV1 for low bandwidth and h.265 for high bandwidth and h.264 as a fallback. If that is the case, why bring up this strange average bandwidth comparison?
1 reply →
definitely reads like "you're holding it wrong" to me as well
I imagine that's a big part of the drive behind discontinuing Chromecast support..
https://www.androidcentral.com/streaming-tv/chromecast/netfl...
I doubt that. Netflix has an app on TVs as old as 8-10 years now. SoCs in such TVs aren't enough to decode AV1. They're stuck with H.264 for a long time.
Nah, that's more "we can't get ad injection working on the old Chromecast client" because it still works on early Chromecasts for ad-free plans.
Weirdly, Netflix on my Samsung TV it's been a few months it's using only H264. Not AV1. When they first launched AV1, it worked there...
Honestly not complaining, because they were using AV1 with 800-900~kbps for 1080p content, which is clearly not enough compared to their 6Mbps h.264 bitrate.
they may have determined the decoding of av1 was too poor or that software decoding av1 wasn't a good idea.
On a related note, why are release groups not putting out AV1 WEB-DLs? Most 4K stuff is h265 now but if AV1 is supplied without re-encoding surely that would be better?
I looked into this before, and the short answer is that release groups would be allowed to release in AV1, but the market seems to prefer H264 and H265 because of compatibility and release speed. Encoding AV1 to an archival quality takes too long, reduces playback compatibility, and doesn't save that much space.
There also are no scene rules for AV1, only for H265 [1]
[1] https://scenerules.org/html/2020_X265.html
AV1 is the king of ultra-low bitrates, but as you go higher — and not even that much higher — HEVC becomes just as good, if not more. Publicly-available AV1 encoders (still) have a tendency to over-flatten anything that is low-contrast enough, while x265 is much better at preserving visual energy.
This problem is only just now starting to get solved in SVT-AV1 with the addition of community-created psychovisual optimizations... features that x264 had over 15 years ago!
I'm surprised it took so long for CRF to dethrone 2-pass. We used to use 2-pass primarily so that files could be made to fit on CDs.
> Encoding AV1 to an archival quality takes too long
With the SVT-AV1 encoder you can achieve better quality in less time versus the x265 encoder. You just have to use the right presets. See the encoding results section:
https://www.spiedigitallibrary.org/conference-proceedings-of...
2 replies →
Yeah I’m talking about web-dl though not a rip so there is no encoding necessary.
Player compatibility. Netflix can use AV1 and send it to the devices that support it while sending H265 to those that don't. A release group puts out AV1 and a good chunk of users start avoiding their releases because they can't figure out why it doesn't play (or plays poorly).
h.264 has near-universal device support and almost no playback issues at the expensive of slightly larger file sizes. h.265 and av1 give you 10-bit 4K but playback on even modest laptops can become choppy or produce render artifacts. I tried all three, desperately wanting av1 to win but Jellyfin on a small streaming server just couldn't keep up.
I'm not in the scene anymore, but for my own personal encoding, at higher quality settings, AV1 (rav1e or SVT; AOM was crazy slow) doesn't significantly beat out x265 for most sources.
FGS makes a huge difference at moderately high bitrates for movies that are very grainy, but many people seem to really not want it for HQ sources (see sibling comments). With FGS off, it's hard to find any sources that benefit at bitrates that you will torrent rather than stream.
Smaller PT sites usually allow it
Bigger PT sites with strict rules do not allow it yet and are actively discussing/debating it.Netflix Web-DLs being AV1 is definitely pushing that. The codec has to be a select-able option during upload.
Because pirates are unaffected by the patent situation with H.265.
Everyone is affected by that mess, did you miss the recent news about Dell and HP dropping HEVC support in hardware they have already shipped? Encoders might not care about legal purity of the encoding process, but they do have to care about how it's going to be decoded. I like using proper software to view my videos, but it's a rarity afaik.
But isn’t AV1 just better than h.265 now regardless of the patents? The only downside is limited compatibility.
15 replies →
I've seen some on private sites. My guess is they are not popular enough yet. Or pirates are using specific hardware to bypass Widevine encryption (like an Nvidia Shield and burning keys periodically) that doesn't easily get the AV1 streams.
I'm seeing releases pop up on Pirate Bay with AV1 this year.
Worth a note, H.264 High Profile is patent free in most countries and soon be patent free too in US.
Isn't AV1 on the level of H.265? And are H.265 and the future H.266(will face the upcoming av2) free of charge forever and wherever like av[12]?
They could do the Big Tech way: make it all 'free' for a good while, estinguish/calm down any serious competition, then make them not 'free' anymore.
In the end, you cannot trust them.
Absolutely not.
I wish everyone knew the difference between patents and copyright.
You can download an open source HEVC codec, and use it for all they care according to their copyright. But! You also owe MPEG-LA 0.2 USD if you want to use it, not to mention an undisclosed sum to actors like HEVC Advance and all the other patent owners I don't remember, because they have their own terms, and it's not their problem that you compiled an open source implementation.
VP9 is more on the level of H265 really. VVC/H266 is closer to AV1. It's not an exact comparison but it is close. The licensing is just awful for VVC similar to HEVC and now that AV1 has proved itself everyone is pivoting away from VVC/h266 especially on the consumer side. Pretty much all VVC adoption is entirely internal (studios, set top boxes, etc) and it is not used by any major consumer streaming service afaik.
For a second there I wasn't looking very close and I thought it said that 30% of Netflix was running on .AVI files
This is a great result from Google, Netflix, Cisco, etc.
> At Netflix, our top priority is delivering the best possible entertainment experience to our members.
I dont think that is true of any streamers. Otherwise they wouldnt provide the UI equivalent of a shopping centre that tries to get you lost and unable to find your way out.
Or compression that makes a streamed 4K video look worse than a 1080p video played locally.
Compression is great and all, but Netflix is overdoing it and their content looks like an over-sharpened mess with lego blocks in high intensity scenes. And no, it's not my connection, Apple TV does it far better and so does Prime.
It's really sad that most people never get to experience a good 4K Blu-ray, where the grain is actually part of the image as mastered and there's enough bitrate to not rely on sharpening.
The one big hardware deficiency of my Nvidia Shield TV is its lack of YouTube AV1 support.
Am I the only one that thought this is an old article by the title? AV1 is now 10 years old and AV2 has been announced for year-end release few months ago. If anything the news is that AV1 powers only 30% by now. At least HEVC, released about the same time, has gotten quite popular in warez scene (movies/TV/anime) for small encodes, whereas AV1 releases are still considered a rarity. (Though to be fair 30% Netflix & YT means AV1 usage in total is much higher.) Will've expected a royalty-free codec to've been embraced more but seems its difficulty for long time to be played on low power devices hindered its adoption.
Something doesn’t quite add up to me. The post says “AV1 powers approximately 30% of all Netflix viewing”. Impressive, but I’m wondering why it isn’t higher? I’m guessing most devices should support AV1 software decoders. 88% of devices in certified in the last 4 years support AV1, all browsers support AV1 software decoding, Netflix apps on Android (since 2021) and iOS (since 2023) obviously do.
So why isn’t it AV1 higher? The post doesn’t say, so we can only speculate. It feels like they’re preferring hardware decoding to software decoding, even if it’s an older codec. If this is true, it would make sense - it’s better for the client’s power and battery consumption.
But then why start work on AV2 before AV1 has even reached a majority of devices? I’m sure they have the answer but they’re not sharing here.
Smart TVs, TV sticks, and a lot of mobile devices will not be capable of decoding AV1 in software in realtime, given their low-spec CPUs. I imagine that Netflix is only serving AV1 to devices with hardware decoding support.
Qualcomm seems to be lagging behind and doesn't have AV1 decoder except in high end SoCs.
I understand that sometimes the HN titles get edited to be less descriptive and more generic in order to match the actual article title.
What’s the logic with changing the title here from the actual article title it was originally submitted with “AV1 — Now Powering 30% of Netflix Streaming” to the generic and not at all representative title it currently has “AV1: a modern open codec”? That is neither the article title nor representative of the article content.
OK guys, my screwup.
We generally try to remove numbers from titles, because numbers tend to make a title more baity than it would otherwise be, and quite often (e.g., when reporting benchmark test results) a number is cherry-picked or dialed up for maximum baitiness. In this case, the number isn't exaggerated, but any number tends to grab the eye more than words, so it's just our convention to remove number-based titles where we can.
The thing with this title is that the number isn't primarily what the article is about, and in fact it under-sells what the article really is, which is a quite-interesting narrative of Netflix's journey from H.264/AVC, to the initial adoption of AV1 on Android in 2020, to where it is now: 30% adoption across the board.
When we assess that an article's original title is baity or misleading, we try to find a subtitle or a verbatim sentence in the article that is sufficiently representative of the content.
The title I chose is a subtitle, but I didn't take enough care to ensure it was adequately representative. I've now chosen a different subtitle which I do think is the most accurate representation of what the whole article is about.
Though in the original title AV1 could be anything if you don't know it's a codec. How about:
"AV1 open video codec now powers 30% of Netflix viewing, adds HDR10+ and film grain synthesis"
AV1 is fine as-is. Plenty of technical titles on HN would need to be googled if you didn't know it. Even in yours, HDR10+ "could be anything if you don't know it". Play this game if you want, but it's unwindable. The only people who care about AV1 already know what it is.
3 replies →
> Though in the original title AV1 could be anything if you don't know it's a codec.
I'm not trying to be elitist, but this is "Hacker News", not CNN or BBC. It should be safe to assume some level of computer literacy.
1 reply →
The article barely mentioned “open”, and certainly gave no insight as to what “open” actually means wrt AV1.
Amen. The mania for obscurity in titles here is infuriating. This one is actually replete with information compared to many you see on the front page.
If there really was a “mania for obscurity in titles” we’d see a lot more complaints than we do.
Our title policy is pretty simple and attuned for maximum respect to the post’s author/publisher and the HN audience.
We primarily just want to retain the title that was chosen by the author/publisher, because it’s their work and they are entitled to have such an important part of their work preserved.
The only caveat is that if the title is baity or misleading, we’ll edit it, but only enough that it’s no longer baity or misleading. That’s because clickbait and misleading titles are disrespectful to the audience.
Any time you see a title that doesn’t conform to these principles, you’re welcome to email us and ask us to review it. Several helpful HN users do this routinely.
hacker news loves low information click bait titles. The shorter and more vague the better.
It is usually Dang using his judgment.
I really like moderation on HN in general, but honestly this inconsistent policy of editorializing titles is bad. There were plenty of times where submitter editorialized titles (e.g GitHub code dumps of some project) were changed back to useless and vague (without context) original titles.
And now HN administration tend to editorialize in their own way.
For me that’s a FU moment that reminds me ‘TF am I doing here?’ I genuinely see this resource as a censoring plus advertising (both for YC, obviously) platform, where there are generic things, but also things someone doesn’t want you to read or know. The titles are constantly being changed to gibberish like right here, the adequate comments or posts are being dead, yet the absolutely irrelevant or offensive things, can stay not touched. Etc.
Also, it’s not the whole picture. AV1 is open because it didn’t have the good stuff (newly patented things) and as such I also wouldn’t say it’s the most modern.
AV1 has plenty of good stuff. AOM (the agency that developed AV1) has a patent pool https://www.stout.com/en/insights/article/sj17-the-alliance-... comprising of video hardware/software patents from Netflix, Google, Nvidia, Arm, Intel, Microsoft, Amazon and a bunch of other companies. AV1 has a bunch of patents covering it, but also has a guarantee that you're allowed to use those patents as you see fit (as long as you don't sue AOM members for violating media patents).
AV1 definitely is missing some techniques patented by h264 and h265, but AV2 is coming around now that all the h264 innovations are patent free (and now that there's been another decade of research into new cutting edge techniques for it).
Just because something is patented doesn't necessarily mean its good. I think head to head comparisons matter more. (Admittedly i dont know how av1 holds up)
1 reply →
[dead]
[dead]
[dead]
[dead]
[dead]
Is it me or this post has LLM vibes?
Top post without a single comment and only 29 points. Clearly my mental model of how posts bubble to the top is broken.
IIRC, there's a time/recency factor. If we assume that most people don't browse /newest (without commenting on should, I suspect this is true), then that seems like a reasonable way to help surface things; enough upvotes to indicate interest means a story gets a chance at the front page.