Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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%.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: