zlacker

Netflix’s AV1 Journey: From Android to TVs and Beyond

submitted by Charle+(OP) on 2025-12-05 00:09:57 | 535 points 276 comments
[view article] [source] [go to bottom]

NOTE: showing posts with links only show all posts
◧◩
9. munifi+P6[view] [source] [discussion] 2025-12-05 01:00:13
>>pbw+76
Just what we need, a new loudness war, but for our eyeballs.

https://en.wikipedia.org/wiki/Loudness_war

◧◩◪
18. JoshTr+N7[view] [source] [discussion] 2025-12-05 01:05:47
>>Elasti+67
> 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 .

◧◩
27. FrostK+v8[view] [source] [discussion] 2025-12-05 01:11:10
>>Eduard+W7
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

◧◩◪
37. snvzz+v9[view] [source] [discussion] 2025-12-05 01:20:00
>>FrostK+v8
Even RISC-V vector assembly[0].

0. https://code.videolan.org/videolan/dav1d/-/issues/435

◧◩◪
39. km3r+ea[view] [source] [discussion] 2025-12-05 01:25:32
>>dehrma+o8
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.

◧◩
44. avidia+Ca[view] [source] [discussion] 2025-12-05 01:29:42
>>ls612+G8
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

◧◩◪◨⬒
48. jshear+5b[view] [source] [discussion] 2025-12-05 01:33:22
>>kevinc+m9
https://en.wikipedia.org/wiki/Versatile_Video_Coding#Hardwar...

Yeah, that's... sparse uptake. A few smart TV SOCs have it, but aside from Intel it seems that none of the major computer or mobile vendors are bothering. AV2 next it is then!

◧◩◪
72. breve+Fi[view] [source] [discussion] 2025-12-05 02:43:42
>>avidia+Ca
> 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...

◧◩◪
73. jiggaw+Qi[view] [source] [discussion] 2025-12-05 02:45:19
>>mtoner+7c
https://xkcd.com/1015/

Now you can be mad about two things nobody else notices.

◧◩◪
106. adgjls+tr[view] [source] [discussion] 2025-12-05 04:26:49
>>7e+Sk
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).

◧◩◪◨
108. lern_t+5s[view] [source] [discussion] 2025-12-05 04:36:07
>>hombre+5f
Android finally addressed this issue with the latest release. https://9to5google.com/2025/12/02/the-top-new-features-andro...
138. _puk+oB[view] [source] 2025-12-05 06:36:58
>>Charle+(OP)
I imagine that's a big part of the drive behind discontinuing Chromecast support..

https://www.androidcentral.com/streaming-tv/chromecast/netfl...

◧◩◪◨⬒⬓
166. close0+QP[view] [source] [discussion] 2025-12-05 08:59:21
>>SG-+wL
Dell and HP are significant in the "devices" world and they just dropped the support for HEVC hardware encoding/decoding [1] to save a few cents per device. You can still pay for the Microsoft add-in that does this. It's not just streaming, your Teams background blur was handled like that.

Eventually people and companies will associate HEVC with "that thing that costs extra to work", and software developers will start targeting AV1/2 so their software performance isn't depending on whether the laptop manufacturer or user paid for the HEVC license.

[1] https://arstechnica.com/gadgets/2025/11/hp-and-dell-disable-...

◧◩◪◨⬒
169. Drybon+BX[view] [source] [discussion] 2025-12-05 09:23:02
>>dd_xpl+Kz
I do a lot of AV1 encoding. Here's a couple of guides for encoding with SVT-AV1 from enthusiast encoding groups:

https://wiki.x266.mov/docs/encoders/SVT-AV1

https://jaded-encoding-thaumaturgy.github.io/JET-guide/maste...

◧◩
196. deanyl+Vq1[view] [source] [discussion] 2025-12-05 12:55:28
>>bofaGu+wa
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
◧◩◪◨
198. windex+5w1[view] [source] [discussion] 2025-12-05 13:26:29
>>usrusr+Dp1
If, by chance, you're not running the latest version RootMyTV [0] may be an option. Or downgrade might still be an option [1].

[0] https://github.com/RootMyTV/RootMyTV.github.io [1] https://github.com/throwaway96/downgr8

◧◩◪
205. cubefo+lF1[view] [source] [discussion] 2025-12-05 14:13:42
>>dehrma+o8
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
◧◩◪◨⬒⬓
208. beala+uG1[view] [source] [discussion] 2025-12-05 14:20:01
>>mort96+Ys1
There’s an infamous case of xerox photocopiers substituting in incorrect characters due to a poorly tuned compression algorithm. No AI necessary.

https://en.wikipedia.org/wiki/JBIG2#:~:text=Character%20subs...

◧◩◪◨⬒⬓
218. amiga3+dU1[view] [source] [discussion] 2025-12-05 15:22:36
>>mort96+Ys1
> And in the case of many others, it makes a very significant difference.

This is very true, but we're talking about an entertainment provider's choice of codec for streaming to millions of subscribers.

A security recording device's choice of codec ought to be very different, perhaps even regulated to exclude codecs which could "hallucinate" high-definition detail not present in the raw camera data, and the limitations of the recording media need to be understood by law enforcement. We've had similar problems since the introduction of tape recorders, VHS and so on, they always need to be worked out. Even the phantom of Helibronn (https://en.wikipedia.org/wiki/Phantom_of_Heilbronn) turned out to be DNA contamination of swabs by someone who worked for the swab manufacturer.

◧◩◪◨⬒
241. cogman+7B2[view] [source] [discussion] 2025-12-05 18:21:57
>>galad8+Br2
It was a presentation on AV1 before it was released. I'll see if I can find it but I'm not holding my breath. It's mostly coming from my own recollection.

Ok, I don't think I'll find it. I think I'm mostly just regurgitating what I remember watching at one of the research symposiums. IDK which one it was unfortunately [1]

[1] https://www.youtube.com/@allianceforopenmedia2446/videos

◧◩◪◨⬒
276. tomhow+d86[view] [source] [discussion] 2025-12-07 02:45:18
>>Verifi+jt5
I don't know where you get the idea that the moderators or the community are such unreasonable tyrants about this!

> people who point out obscure titles are downvoted in most cases, and eventually shadow-banned

Nothing like this happens! Nobody gets banned for pointing out anything about titles. People only get banned ("shadow" or otherwise) for serial abuse or trolling (and only after multiple warnings), or for spamming. Comments only get downvoted if more people disagree than agree with the title suggestion or the way it's suggested. It's no big deal. It's how opinions are expressed and debated on HN.

> The HN post is entitled merely "tunni.gg".

That's Tunnl.gg [1], and it would have been fine for the page's heading to be added to the HN title (that routinely happens when software projects on Github are submitted). It's also not terrible for just the project name to be there, because the name of the project (a variant of the word "Tunnel") hints at what it is. But we're not dogmatic about it, and anybody could have emailed us (hn@ycombinator.com) to suggest a better title we would have given it due consideration and replied appreciatively. We do that multiple times each day.

> You see plenty of similarly and intentionally obscure titles on HN daily. Try calling them out and see what happens.

“Intentionally obscure” isn't the right framing. Maybe we don't always want to clobber people over the head with obviousness. The joy of surprising discovery is an important part of the HN experience.

But the key principles – (a) respecting the original work of the author/publisher and (b) don't mislead or disrespect the HN audience with clickbait or false information – have proven to be the most stable and defensible over time. There's still plenty of room for discernment in the way those principles are applied on a case-by-case basis.

[1] >>46145902

[go to top]