Hacker News Reader

Comment by apocalyptic0n3 | Hacker News Reader

No word on what their encoding toolset is. That's been the limiting factor with widespread adoption thus far; it just takes too much CPU and too much time to encode as AV1 vs 264, 265, or VP9

View on HN

> No word on what their encoding toolset is.

They're using ST-AV1[1], the encoder they've collaborated with Intel on.[2][3]

[1] https://github.com/OpenVisualCloud/SVT-AV1

[2] https://newsroom.intel.com/news/intel-netflix-deliver-av1-sc...

[3] https://netflixtechblog.com/introducing-svt-av1-a-scalable-o...

So SVT-AV1 now does 20% better than VP9?

Edit: They did mention the 20% is from AV1-libaom compression efficiency as measured against VP9-libvpx. So not SVT-AV1.

They cite AV1-libaom for the 20% efficiency improvement over VP9, but I didn't take that to mean that they're using the reference encoder in production. Do you happen to know for sure?

For Netflix this likely doesn't matter. While Youtube deals with 300+ hours of content uploaded every minute that it has to encode, Netflix only has to encode ~100 titles per month. Even if it takes a month to encode 1 of these, it's still easily doable for Netflix.

Perhaps they're only AV1-ing a blockbuster per week, say.

Yes and no. It's a cost-benefit deal. Just because they _can_ (and they surely can), doesn't mean it is cost beneficial to do so now. It takes CPU time (and therefore money) for each encode they do. If one takes much more resources to do, it may not be beneficial to do so yet. I originally posted my comment wondering if there had been some encoder breakthrough that I had missed that had made AV1 a viable option finally. Looks like there was, but it's still not nearly as good as it needs to be fore widespread adoption (looks like it's still 30x slower than a comparable HEVC or VP9 encode). So I guess it comes down to: are they saving enough on downstream bandwidth to balance out the CPU time for the encode? Releasing it would suggest yes, or they see some benefit to pushing the standard into the mainstream now rather than in six months regardless of the cost to them.

savings on bandwidth will make up for it

Almost like Netflix has data analysts and experts in the field who have already calculated the cost benefits based on internal metrics unavailable to us and chosen to implement it...

> doesn't mean it is cost beneficial to do so now

But they are using AV1 now i.e. you should presume NetFlix have judged that the benefits outweigh the costs (unless you have other relevant information to share).

I would argue that since the CPU is a one time cost but the bandwidth benefit is recurring and not just for the company but for the customers as well especially on mobile the calculation is rather easy.

That kind of CPU load is a drop in the bucket for Netflix.

Yup. Run it during off peak with extra hardware. EZ.

Yeah this seems like a good job for AWS spot or the like. If it costs $.01/minute of video, probably worth it even if only a few hundred people watch the title.

Does Netflix encode realtime? I would think they would encode all of the possible data rates exactly once, then stream off disk. I would think realtime encoding would add a significant cost per client.

* Disclaimer: I know nothing of AV1.

They encode once then stream off disk.

No, they don't have much time constraint on encoding. But the bill still matters; if AV1 costs $$$$$ to encode because you need so many servers it's a bad situation.

I remember an article on video encoding where Netflix had approached some people basically with the question "what if we didn't care about encoding times?" Netflix doesn't want to was money, but encoding cost might not be something that they want to optimize against other things. For example, let's say that you have an episode of a TV show. Netflix is going to transfer that file 10M times. If that file is 2GB, that's 19PB by my math. I know that they aren't paying AWS's exorbitant transfer fees, but it can still add up to a lot of money. $200,000 at a cent per GB, $20,000 at a tenth of a cent per GB. On top of that, more CDN storage, more servers needed to transfer additional data, etc. There are certainly costs. How much would it cost to encode things? Let's say that AV1 can be encoded at 1/10th real-time on a 16-v-core box (which seems reasonable given https://medium.com/@ewoutterhoeven/av1-is-ready-for-prime-ti...). That's $7.60 on Google Cloud for an hour-long show (I know they use AWS, but this is just representative pricing).

Let's say that AV1 reduces file sizes by 40% (compared to H.264), saving them 0.8GB per stream. Let's say that only 10% of users have AV1 capability. And let's say that they only pay a tenth of a cent per GB for bandwidth. They're still saving 800,000 GB of bandwidth or $800. Of course, there are also going to be other savings like electricity since transferring smaller files means needing fewer servers (servers have network cards that get saturated whether in their data center or CDN).

At Google, encoding costs can be big since a lot of YouTube videos aren't watched a lot. With Netflix, the library is a lot smaller and more popular. Netflix is up to around 170M customers. Each of those customers might have a few household members watching something popular (and maybe re-watching those things). Even encoding something very slowly ends up not costing that much money.

But it's also about the customer experience. Mobile companies throttle video services. I believe Google started using VP8 so that T-Mobile customers could see 720p video without paying extra for HD video. When downloading files for offline usage on a plane, the size is going to matter both in terms of the time it takes to download and the storage used on your device which is limited.

Even if bandwidth only costs Netflix a hundredth of a cent per GB, the compute needed for AV1 just doesn't seem to matter given the way Netflix's business works.

Agreed completely with this - there are second order effects to this as well on the customer side.

A smaller file for the same quality means that customers need less bandwidth to stream a show, improving their experience and decreasing buffer times, etc. This might not be as relevant in the USA as other places, but I'm sure there are a significant number of customers and potential customers that this will make a difference with.

With an encode-once stream-many setup, it's likely quite worth it for Netflix to pay whatever upfront transcoding cost if the resulting file is advantageous in any way.

Independent of network cards, TLS using AES-GCM will cost one cycle per byte.

>"what if we didn't care about encoding times?"

Yeah, I can already see it. AV5 with 3 months of encoding time on a 128 core EPYC for a 90 minute movie.

Theoretically yes, but the hardware cost of encoding their microscopic, in streaming terms, number of videos would have to be absurd to even come close to the savings they get from lowering their bandwidth by 20%.

Reply on news.ycombinator.com