本文是来自Video @Scale 2019的演讲，演讲者是来自Youtube的工程师Steven Robertson，演讲主要内容是AV1在Youtube的部署情况。

AV1部署在Youtube之后已经累计服务了超过五十亿小时，并且其使用预期将会猛增到1080p内容的1QPS（每秒点击量，换算下来为每天超过80k次访问），将要覆盖Youtube视频观看中的很大一部分，承担一部分流量。

但是Youtube对AV1的使用还没有完全调整到最优，他们目前关注的重心是部署的规模，也就是保证在未来5到8年内，AV1作为主导的codec，具有广泛的软硬件支持，可以编解码各种不同的格式。

这其中一个重要的影响因素就在于，虽然AV1的上线产生了很多积极的表现，但是在台式机上表现平平。VP9上线之后是因其出众的稳定性而获得认可，但是AV1表现一般。

另一个因素是台式机通常拥有足够的带宽来传输用户想要的高质量，但Youtube的主要增长平台是移动平台。移动平台情况下，在相同质量下降低码率更能满足用户需求。

下面演讲者从客户角度谈AV1部署的历史。AV1是Youtube大规模部署的第三个codec，一个经验是人们需要尝试它，因此youtube设置了TestTube作为用户的尝试入口。AV1还经历了根据未来的使用进行重运行。

在性能方面，youtube使用了混合格式，也就是部分分辨率使用VP9，部分使用AV1。具体实现使用了web中的SourceBuffer.changeType()，浏览器将会自动切换解码器。此处演讲者提到了播放器设置中的一个trick，用来提升切换codec时的表现。下面是混合格式阈值的确定，从480p开始。实验过程中演讲者发现老机器解码AV1非常差，原因部分是因为其支持的cpu指令集太少。这促使其使用dav1d这个解码器来取代libaom，因为dav1d更快，并且含有使用更老的cpu指令集编写的汇编优化代码。

然后演讲者介绍了他们确定切换分辨率的两个判据，一个是丢帧，另一个是non-networkrebuffer。后者是浏览器发生等待事件的明确标志，或者是在媒体有超过5秒的缓存时无法推进现在时间的标志。判断丢帧是比较麻烦的，各种浏览器和网络状况复杂，但是在一些情况下丢帧可以作为判据。最终他们确定了一个判据，是每5秒采样，计算丢帧率，在超过阈值连续3次后进行降低质量操作。他们还发现高丢帧不一定会伴随non-network rebuffer，比如有时可能由于一些原因收不到帧，这些没收到的帧不会被计算在丢帧中。所以不仅要考虑丢帧，还需要考虑那些性能相关的没收到的帧。

下面演讲者介绍了媒体容量。理想的媒体容量可以直接指导分辨率的使用，但是媒体容量也依赖于浏览器的丢帧。youtube致力于利用AV1的播放数据帮助浏览器厂商进行这些性能测试，从而让多方受益，最终达到浏览器能自主获得cpu能力及网络状况，从而在减少失败尝试下选择合适的分辨率。目前youtube会根据用户终端cpu的核心数选择AV1播放的分辨率，具体是小于4核用360p，4核用720p，大于4核用1080p。

接下来演讲者介绍了AV1的可变参考帧结构这一特性对解码播放的影响。他展示了VP9和AV1解码一帧的时间分布，发现两者都有起伏，av1解码一帧的时间起伏尤其大。他表示这会使浏览器受到各种线程问题的困扰，因此需要妥善优化解码顺序以及浏览器的多线程安排，以提升性能。

AV1在移动设备上具有更广泛的市场，因为在同样质量下码率更低，而移动用户通常比台式机用户更加被数据流量所限制。youtube会对用户对视频质量的要求进行建模，从而有针对性的选择给他们的视频分辨率，防止用户因用掉了过多流量而停止观看。考虑AV1在移动平台的部署，一个重大问题就是codec切换，现在没有一个自然的解决办法来处理这个问题，只能是强行切换，从而产生一个播放的停顿。即使如此，影响也不大，因为据统计，移动平台上只有2%的视频在起始时小于等于480p而结束时大于等于720p。移动平台上还有一个问题是速度与节能的选择，dav1d这个解码器注重速度，但同时消耗的cpu资源和cache资源比较多，从而会更快的消耗电量。youtube呼吁社区以及自身去设计一个比较节能的解码配置，从而适合移动市场的需要。