Some of the Alliance members want to use it for video chat (e.g. Cisco, Google) or live streaming (e.g. Twitch/Amazon, Google) so it'll get done at some point.

I can see their point (and that of any other content provider) in that context, but I'm sure they do care. It would be fine even if it required a dedicated hardware encoding bloc, but lack of reasonable RT encoding (including low wattage) would create a significant technical impediment to full general adoption, so I can't believe that optimization hasn't been at least somewhat considered. There is of course still plenty of real time streaming that's important, though in those cases reduction in quality would often be an acceptable tradeoff. However, Apple and Google both have a quite reasonable and absolute need for real time (or a close enough cheat), high quality offline encoding on mobile systems within the physical constraints of a handheld form factor. End users will also want to (again, quite reasonably) be able to immediately share what they make without the need for a lengthy reencoding stage or trip through a middleman.

So if there wasn't at least a timeline for 4k+ RT on iPhone or Android devices I can't see how HEVC wouldn't stick around for a very long time. That a live stream has already been demonstrated should mean that this has been considered and they do care though, and thus won't be a problem. Ideally of course at least the high end of current generation devices would be capable of AV1 recording through software updates, which would enable moving on much more rapidly from HEVC. For that at least though I think it'd be an acceptable tradeoff to have those become legacy if that's what it takes to get us into a patent-unencumbered future afterwards. A pity software patents couldn't have just been eliminated entirely but I guess that remains politically infeasible for now.

It's not onetime CPU costs, at least for Google. Netflix and amazon don't process that much video (relatively), so they can afford slow encode times, but youtube gets tons of video uploaded every minute, they want fast and cheap encoding.

For each individual video, it is a onetime CPU cost, but not a onetime bandwidth cost.

For ongoing operation of the platform, at scale, you might argue that it's an ongoing CPU cost as more and more videos are added constantly, but the bandwidth to distribute those videos goes up at an equal rate on average.

I don't know any actual numbers, but it seems very plausible to me that a vast increase in CPU cost for a minor decrease of bandwidth cost could still be a welcome trade-off.

If you're making an argument that availability of CPU power at that scale is a concern, it seems like YouTube has the option of Google's cloud services as an excellent candidate for massive, interruptible compute power.

It's not just bandwidth cost. Google suggests their big win with VP9 deployment is reaching people across the globe with relatively powerful computers but terrible internet connections. By using more powerful compression (paying for it with more computing work at both ends) they can get higher quality video to these users.

And from a blunt business perspective: Higher quality videos = more watch time = platform dominance = more ads viewed.

> vast increase in CPU cost for a minor decrease of bandwidth cost could still be a welcome trade-off

I don't think that this would be true, though. Recall the 80-20 rule. They have to encode (CPU) a lot of videos, which will get very few views (bandwidth).

Not really. It’s the long tail. The most popular videos are (in addition to likely being ultra resolution like vevo media’s) watched many (8-10?) orders of magnitude more times than the least popular videos. Bandwidth matters, cpu doesn’t.

It’s actually the same 80-20 rule. Eighty percent of the costs come fro serving twenty percent of their videos:)