Hacker News Reader

Comment by ksec | Hacker News Reader

Yes. Netflix's library is tiny by comparison. The article made it as if it is huge. It is so small to the point Netflix could afford to re-encode their entire library every few months when they have new and better encoder or quality measurement matrix.

In the end this read like a marketing piece for AccelData.

If there is one thing that Netflix technically excel, it is their 800Gbps Serving Appliance [1] with FreeBSD. ( I cant wait until they do 1.6Tbps )

[1] https://news.ycombinator.com/item?id=32519881

View on HN

> It is so small to the point Netflix could afford to re-encode their entire library every few months when they have new and better encoder or quality measurement matrix.

I wish they did, their current encoding for some shows is absolutely atrocious. I don't know the terminology for what I'm seeing, but for example in Stranger Things, it seems like the brightness and contrast is boosted for every n-th frame. In general, smooth motion seems to get a stuttering quality whenever Netflix touches it. I don't observe this so much with other video sources on the same device...

I regularly have atrocious transient 144p like compression artefacts and lighting absurdities using Netflix both in chrome and via their native h265 app. It is pathetic.

Tangent if they really cared about user experience and Ecology they would implement h265 and h266 support in chromium (aka a mere function call to the embedded ffmpeg). H266 is revolutionary but it's adoption is of zero because of AV1 lobbyists a bit like so called environmentalists once launched a RPG rocket on the superphenix thorium mankind saving reactor.

>H266 is revolutionary but it's adoption is of zero

Adoption on the Web. Most broadcasting companies are getting ready to move to H.266.

I wish we could get a JPEG XL based Video codec.

jpeg-xs?

Good point I hope is true but I was also mostly referring to the inexistant (not even in roadmap) hardware acceleration support.

> I wish we could get a JPEG XL based Video codec. Well i'm curious about that but FLIF, the predecessor (and maybe XL too) is based on MANIAC which is a variation of H264 encoding.. https://en.wikipedia.org/wiki/Free_Lossless_Image_Format#:~:...

>inexistant (not even in roadmap) hardware acceleration support.

Oh they are definitely on the roadmap ( Qualcomm and Mediatek ). I think a lot of people forget there are long lead time in hardware development. Especially with Mobile where energy usage is a key issue. The conformance test of H.266 only finished in mid 2021 if I remember correctly and continued being refined in 2022. If you are going to test your silicon in 2021, your earliest chance of any mobile solution with VVC is going to be 2023.

I would guess both AV1 and VVC lands in Qualcomm SoC in ~2023. MediaTek and Apple coming in 2024.

FFMPEG hasn't even implemented VVC yet, and neither have web browsers, so Netflix can't just make "a mere function call" to get H.266 support.

I'm pretty sure you can do that with Linux. The hypothetical BSD networking advantages seems more and more obscolete to me, missing on most modern advances such as e.g MTCP support https://www.multipath-tcp.org/ It's a basic gradient about human resources.

This switch has throughput of 3.2Tbps and runs linux so evidently doable with hardware offload https://store.nvidia.com/en-us/networking/store/product/MSN2...

Reply on news.ycombinator.com