There are a couple of things that make Netflix somewhat unique.

1) They have a fairly limited catalog (contrast with the constant ingestion of new content by Youtube, for example)

2) The cheapest way for them to ensure they have sufficient capacity to handle peak loads leaves them with a lot of extra compute during non-peak times. That excess compute is essentially free.

>That excess compute is essentially free.

Since they host on AWS, wouldn't they just scale down during non-peak times and save money?

They do, but as any large AWS customer you want to reserve a lot of capacity, so that it's there when you need it and also it's a lot cheaper than spot usage. So, scaling down below the reserved capacity doesn't save you much if anything.

The AWS-hosted part is not the CDN afaik, which will probably make up the vast majority of their infrastructure.

Speaking as an ISP: Netflix traffic comes from the Netflix ASN and peering session. Their globally distributed CDN/caching/video file storage servers are not on AWS to the best of my knowledge. Netflix traffic does not come from our peering with Amazon's ASN.

If you're talking about OpenConnect, then I think they are really geared to just be a CDN and not much else.

Netflix has an internal spot market for compute, letting them use their reserved instances somewhat optimally.

For what it's worth, I don't know what YouTube's actual constraints look like, but it doesn't seem implausible that they might still be open to reencoding their top 10k video. After a billion views, you might get some substantial savings.

EDIT: After all, they did implement VP8/9 ;)

Re #1: It's not catalog size that matters; it's more like revenue per minute of video, or views per minute of video

Re #2: This is a fairly standard batch-vs-online compute mix tradeoff faced by large enterprises.

It's not bandwidth savings. It's growing the user base. There are lots of people on low bandwidth connections. Maybe now they don't find Netflix watchable, because the video quality is to crappy. But if you can fit higher quality video into the same bandwidth, they'd become users.

I agree with your overall point though, that at some point the extra cost for encode isn't worth it.

Netflix is in fact working very hard to optimize the quality per bandwidth at low bitrates. Megha Manohara from Netflix had a conference talk about it last year:

https://www.youtube.com/watch?v=S9E9xUbcYAM

Their goal is to have video of acceptable quality at 250 kbit/s, which makes Netflix an option for a lot more people worldwide.

That's part of it, but I think you'd be astonished at how much IP transit can end up costing when you're distributing high-quality video. It's pretty staggering how much bandwidth can cost. I would not be surprised in the slightest if at least 1/4 of Netflix's total engineering spend is on network transit, so any savings that are per-video can have a huge impact.

Source: I work at a company that distributes a lot of high-quality video :)

Exactly this. I don't know how many times this need to be repeated. If your original encoding cost were 1 Million, 5x or even 10x is only 9 million more. At 100x that is 99 million. 1000x is a billion. Are you really willing to spend a billion on a codec that saves you 50% transfer and a fee million of royalty cost?

Especially when Netflix already has the Open Alliance in many ISP DC. Bandwidth cost saving are much less that most estimate.

However I do understand her point, she should ask I give you 100x complexity headroom, can you get me 80% reduction in bitrate compare to HEVC.

Lowering bandwidth requirements not only lowers bandwidth bills, but also opens new markets. You suddenly have subscribers that you otherwise woudn't have. There's a long tail of people with slow connections.