本文来自快手科技算法科学家，快手传输算法团队负责人周超博士在LiveVideoStackCon 2020线上峰会的分享，介绍了快手基于流式直播多码率的实践与优化，以及LAS (Live Adaptive Streaming)标准的架构、原理、自适应算法与未来规划。
近日，快手正式对外发布基于流式的直播多码率自适应标准LAS（Live Adaptive Streaming），用于提供低延迟、平滑、流畅的直播多码率体验。据悉，快手同时开源了LAS的端到端解决方案，包括服务端、客户端、业界领先的多码率自适应算法等，帮助业界实现零门槛接入和使用LAS。
直播清晰度对用户的体验至关重要，通过提升视频的码率、分辨率，能够确保视频清晰度显著提升。快手用户规模大、分布广泛，用户间网络差异性大，单一的视频质量（码率、分辨率）或固定的档位下发策略难以适应不同的网络需求。
2019年底数据显示，快手的直播DAU超过了1亿，快手的游戏直播日活用户数达到5100万，游戏直播是众多直播场景中比较特殊的一个例子。相对于传统直播（秀场类），因为游戏画面的复杂性，游戏直播对码率的需求更高。这也是催生快手做直播多码率的一大动机：单一的码率很难满足不同用户的网络条件。
直播技术的痛点和行业解决思路
站在用户的角度，直播体验面临的最大痛点可以分为三类：卡顿、模糊、延迟大。
对于这些问题，单独优化某一个指标并不难，难点在于彼此之间互相制约。例如通过降低码率能降低卡顿率，提升观看直播的流畅度，但降低码率损失了清晰度的体验，会引起直播画面模糊。此外，延迟对于直播体验也至关重要，例如秀场的互动直播，主播能及时响应粉丝的评论或送礼等行为，都能极大的改善用户体验。而延迟越低，客户端缓存的数据也越少，对网络抖动的抗性也越差，从而增加了卡顿的风险。
目前的直播架构主要分为两类，一类是是基于流式架构，例如HTTP-FLV、WebRTC等。这类基于流式的直播架构，可以实现帧级传输，从而获得低延迟的直播体验。此外，对于这些架构和协议，CDN支持好，易部署，并且被长时间大规模的商用验证过，稳定性高。其缺点是不支持多码率，无法根据用户的网络动态自适应选择最佳的码率档位。
多码率自适应是在抖动网络下保证观看流畅度最有效的手段之一。目前多码率自适应方案，主要包括MPEG-DASH和HLS，并且这二者都是基于分片传输的。在最初设计时，也主要用于点播场景，延迟问题考虑得相对较少，直接用于直播场景时容易引起延迟过大，影响直播体验。目前国内暂无大规模的使用DASH或HLS进行直播，实际大规模使用时，其稳定性也有待考量。虽然目前MPEG-DASH和HLS都在讨论低延迟方案，例如LHLS，但这些方案还没完全标准化，离落地尚需时日。
鱼和熊掌兼得的自研思路
已有的解决方案或多或少的存在一些瑕疵，难以满足快手的业务需求。因此，我们选择自研之路，设计了一套基于流式的直播多码率自适应方案，其目标是在支持直播码率自适应的同时，实现流式直播的低延迟。
总体而言，快手的直播多码率解决方案包含两大特性：一是基于流式传输，从而保证低延时；二是支持多码率，从而依据每个用户的网络状态，自适应选择最佳的视频清晰度。该方案需要解决的三个核心问题为：When——什么时候切换码率；Which——切换到哪一档；How——在流式传输下，如何实现无缝切换。
快手直播的系统架构如上图所示，主播推流到快手自建源站，源站负责收流、转码后，由CDN回源拉取不同码率档位的视频流，进而依据用户的请求，将合适的视频流分发给用户。在基于流式的直播多码率架构下，对转码、CDN和播放器需要有一些规范的要求。
对于转码，不同于MPEG-DASH或HLS，我们的方案不需要进行切片操作，只需要在转码时保证不同的转码流的I帧的pts严格对齐。因为在做码率切换时，需要依据I帧的pts进行对齐，否则，在解码渲染时可能会出现跳帧的现象。
对于CDN，也是多码率服务端的核心逻辑，主要包括以下功能的支持：
缓存：传统CDN的缓存使用字节数（Bytes），在多码率场景下，对于不同的视频码率，相同字节数所对应的时长不一样，而多码率的操作都是基于时间的，因此，我们要求存储单位统一为时间。这个时间长度的计算，可以依据视频，也可以依据音频 ，详细的实现可以参考我们的标准文档。
拉流：CDN需要支持三种拉流模式，即默认位置拉流（传统拉流）、绝对位置拉流（明确吐流位置）、相对位置拉流（设置吐流时长）。
在具体实现时，考虑迟到视频帧的解码参考关系，CDN在吐流时，需要从关键帧开始，具体分为三种情况：
- 默认位置拉流，一般发生在启播时，依据默认长度计算当前期望的绝对位置，找到最近的I帧开始吐流。
- 绝对位置拉流，一般发生在码率切换时，需要找到pts不大于绝对位置的I帧开始吐流，避免渲染跳变。
- 相对位置拉流，一般发生在启播时，根据相对位置计算绝对位置，再找到最近的I帧开始吐流。
上图是基于流式的直播多码率自适应的流程示意图。在启播时，采用相对位置拉流的模式，默认拉取高清档位的视频流。此时，可以结合业务的需求，通过合理的设置相对位置来控制直播延迟。在直播过程中，当因为网络等原因导致需要从高清流切换到标清流，从而保证播放的流畅性时，可以采用绝对位置的拉流方式。具体过程为：首先断开高清流，然后播放器依据当前的状态，得到期望吐流的绝对位置 ，比发送绝对位置的拉流请求。通过I帧的pts严格对齐，保证了无缝切换。
基于流式传输的架构保证了低延迟的效果，直播的流畅度和清晰度，则需要通过多码率自适应算法来实现。为了平衡这一对矛盾的目标，我们采用基于buffer的模式，背后的出发点在于当buffer数据较多时，意味着带宽没有被充分利用起来，需要切换到更高档位以获得更高的清晰度，反之亦然。此外，频繁的码率切换，对用户的主观体验也不友好，因此，我们还需要考虑码率切换的平滑性。
这里值得强调一点的是，整个建模过程都依赖与网络带宽的估计。在基于分片的多码率框架下，每个分片独立下载，其平均下载速度可以近似作为当前带宽的均值。然而，在基于流式传输的过程中，源数据实时产生，观测到的下载速度近似等于请求的视频流的码率，难以反应真实的带宽。在我们的方案中，带宽通过实时收集固定时间间隔的微粒度下载速度采样点并滤波来获得。
在实际求解时，除了考虑当前时刻的决策外，还需要考虑当前的决策对未来的影响，从而达到全局最优。经过一些矩阵的巧妙设计，极大简化了求解过程，也方便了工程实现。算法的具体实现已开源。
LAS标准发布期待行业伙伴参与共建
快手直播多码率的解决方案方案从开始调研，实现再到全量，经历了方案和架构选择、工程实现、算法优化等诸多问题，目前已经在快手直播业务实现全量，并且取得了很不错的收益。我们将整套方案重新梳理并形成标准文档LAS（Live Adaptive Streaming），将这些经验分享出来，希望能为大家带来一些帮助。LAS标准主要内容包括以下几个方面：
- 媒体呈现描述：描述了基于流式的直播多码率自适应标准的基本语义元素
- LAS请求描述：描述了基于流式的直播多码率自适应标准，不同场景下请求的生成方式
- LAS服务描述：描述了基于流式的直播多码率自适应标准，服务端/云端支持的处理逻辑
- LAS客户端描述：LAS客户端的具体实现，不作为LAS标准的范畴。LAS仅给出推荐的实现架构与自适应算法策略
详细的文档、架构、部署方式、测试数据等，可以参考LAS的官方网站（https://las-tech.org.cn），这里不再赘述。
最后，我们还与HLS做了详细的测试对比，包括不同的网络环境、不同的GOP大小、不同的延迟模式等。其中，LAS不同的延时模式，通过启播拉流时，采用相对位置拉流并设定不同的相对位置来实现。详细的测试数据可以参考LAS的官网。
LAS基于流式架构，实现帧级传输，与HLS等基于分片的多码率架构相比，能显著降低延迟。在自适应算法上，与分片传输的策略相比，基于流式的传输逻辑会一定程度增加自适应算法的难度（例如在流式传输中，因为源数据实时产生，观测到的平均带宽值近似等于当前请求的视频码率，无法反应真实的带宽），但流式架构更加灵活，并且能显著降低分片架构中存在的传输ON-OFF现象，从而降低了码率切换过于频繁的问题。上图展示的LAS与HLS对比各项指标的平均结果，可以看出，与HLS相比，LAS能在获得更低的卡顿率、更高的码率和更低的延迟，从而为用户提供更低延迟，更流畅、更清晰的直播体验。
LAS已经开源，涵盖服务端、客户端和自适应算法。目前，阿里云、腾讯云、百度云、金山云、网宿云等云厂商均支持LAS，企业可直接接入使用。此外，业内知名开源流媒体服务器SRS也已支持LAS，基于SRS 4.0及更高版本，企业客户也可搭建自己的LAS服务端以满足个性化的需求。在客户端，我们已经开源了LAS Web的实现，包括协议、架构和自适应算法。
未来，LAS还将进一步优化升级，主要包括以下几个方面：
- 跨平台：未来我们希望可以实现跨平台的支持，例如移动端的支持和开源。
- 多协议：在协议层面，目前开源的版本是基于HTTP-FLV的实现，未来希望可以支持更多协议，例如WebRTC、QUIC等。
- 全链路：LAS目前主要是针对拉流端的多码率自适应方案，未来希望涵盖推流、转码，打造一套全链路的解决方案。
- 自适应算法：自适应算法是LAS高效性的保障。我们有完善的测试环境，AB系统。
最后，欢迎业界同行加入LAS，共同完善LAS标准和LAS开源社区。
