自适应比特率流媒体与CDN性能

本篇是来自Seattle Video Tech 2019年3月的演讲，演讲者是来自Brightcove的研究员Yuriy Reznik，主题是“自适应比特率流媒体与CDN性能”。

Y. Reznik首先介绍了流媒体的历史，然后他介绍了没有CDN的原始架构：一台server负责了几乎所有工作（基于UDP传输），这导致整个系统不是可扩展的。

随后发展了基于HTTP的ABR流媒体，一个常规的HTTP server替代了原先的streaming server，扩展性和分发都交给了CDN。这样做的合理性是当内容很热门的时候，会保持在CDN的cache，不需要向源站获取。并且，由于CDN距离用户终端更近，会有更好的网络连接。

但是，这样做也会有以下的问题：

1. ABR流媒体生成了同一内容的不同码率分辨率的版本，它们会互相竞争CDN cache的空间，增加了CDN cache未命中的概率；

2. 现代的OTT流媒体往往会同时使用数种流媒体技术以适应不同的设备，如HLS、DASH、Smooth等，它们也会相互竞争；

3. 不同的codec对同一内容的表示也会相互竞争。

基本上，流媒体希望各类技术、版本越多越好，而CDN则希望越少越好。

那么，我们应该cache哪些内容到CDN？如果我们对同一内容有两个版本，哪个应该被cache？

总体上，最热门的内容应该被cache，经过CDN cache miss概率的数学推导得到：同一内容有两个版本的表示时，CDN cache miss的概率与容量C无关，只与两个版本被请求的概率有关，等概率时CDN效率最低，越不对称效率越高。

这个推导可以有以下应用：

应用1：什么时候部署HEVC是有意义的？（部署前后达到相同的CDN cache miss概率）

经过数学建模并且结合之前推导的CDN cache miss概率可以得到CDN cache miss关于码率节省率和设备支持率的关系。

数学结果表明：码率节省50%的时候，设备支持率需要超过82%，部署HEVC才有意义。

同样，我们可以计算CDN流量的变化和总体的花费，数学结果表明当HEVC码率节省25%的时候，需要33%以上的设备支持率。

应用2：什么时候部署CMAF是有意义的？

因为CMAF的初始部署需要与传统的HLS+DASH部署共存，所以我们需要对比HLS+DASH+CMAF和HLS+DASH的效率。

数学结果表明，当75%使用HLS，25%使用DASH，CMAF的设备支持率达到0.8的时候，部署CMAF有意义。

最后，在QA环节Y. Reznik谈到CMAF的设备支持情况：大多数Apple的产品可以支持，在chrome中也有支持，不过不清楚稳定性如何，Android平台上还需要支持。

附上演讲视频：