6月21日，快手正式对外发布基于流式的直播多码率自适应标准LAS（Live Adaptive Streaming），用于提供低延迟、平滑、流畅的直播多码率体验。LAS的端到端解决方案同时开源，包括服务端、客户端、业界领先的多码率自适应算法等，从而帮助业界实现零门槛接入和使用LAS。
图：《搏击俱乐部》
采访专家：周超博士，毕业于北京大学，曾任职于华为2012实验室。现任快手科技算法科学家，快手传输算法团队负责人。主要研究方向包括多媒体处理与通信、流媒体传输优化等，发表论文40+，申请专利50+，曾获得2012年IEEE VCIP Best Student Paper Award和2015年IEEE VCIP Best Paper Award。
1
做追求极致的选择
最开始考虑多码率自适应大概是18年下半年。当时团队的人很少，大家都在集中精力做KTP（Kuaishou Transport Protocol快手传输协议），优化上行的体验，包括直播推流、短视频发布、以及RTC等。但当时快手的直播业务发展非常快，随着王者荣耀、吃鸡这些爆款游戏的推出，游戏直播的规模急剧增长。
游戏直播画面复杂，对清晰度的要求很高，直播推流码率是快手APP直播场景的好几倍，卡顿情况严重。这时候，降低卡顿成为很明确的需求，大家第一反应就是要做直播多码率，但是具体怎么做，面临着选型的问题。
当时有两条路：
图：《绅士们》
一是“拿来主义”，采用DASH或HLS这类国际标准协议。优点是部署简单，很快就能在线上看见效果。缺点也很显著，这类基于分片的方案延迟大，例如采用HLS，至少需要3个片段，再考虑到推流、转码、服务端和客户端的处理逻辑等因素，端到端的延迟预计4个片段左右。而当时快手的GOP是4秒，那么延迟基本就是15秒往上了，这显然不是用户能接受的。
二是“造轮子”，自研一套低延迟的直播多码率方案。自研的优点很明显，无论是架构还是算法，都可以结合业务的需求做深度优化。缺点也很突出，从零到一面临着很多的不确定性。此外，快手的直播主要依靠第三方云厂商进行分发，采用自研的方案，意味着所有CDN厂商需要配合做定制化的开发。
自研私有方案我们是有经验的，KTP就是私有方案，当时也面临过同样的选择。现成的方案，例如直播可以采用RTMP，PK/连麦等RTC业务可以采用WebRTC。然而，众所周知，RTMP虽然简单易接入，CDN支持好，但是由于底层采用TCP，很难做深入的优化。
此外，直播和PK/连麦采用不同的协议，会存在互相干扰和竞争的情况。因此，尽管自研会面临着很多的不确定，包括协议、算法、源站等等，经过反复斟酌与权衡，为了把传输做到极致，我们依然选择了自研的KTP。目前KTP已全面用于快手的各种业务，取得了非常不错的效果，这为团队自研多码率方案提供了很强的信心。
选择自研，并且能做成，是需要一定的认知和信念的。
图：《绅士们》
首先要评估自己的能力，能不能比现成的方案做得更好，要对相关的技术有非常深刻和全面的理解，以及对自己团队能力有足够的认知。快手音视频技术团队都是行业里的佼佼者，技术能力上绝对不会有问题。
另外很关键的是信念，做自研的时候会去想：“有必要为了一点点收益投入那么大么？”“已有的方案简单快捷，凑合一下不也可以么？”
快手是一家“追求极致”的公司，对技术人来说，追求“极致”的技术就是我们的使命。在明确市场已有解决方案存在严重问题的情况下，只为了工作简便就“凑合”一下的选择是我们心理上不能接受的。可以预见的是，随着快手业务的飞速发展，这种“凑合”未来也将成为我们前行的障碍。
2
成功的秘籍是不放弃
毫无悬念的，我们再次走上了自研之路。项目初期内部做了很明确的分工，例如各家CDN厂商的排期、转码模版的设计、客户端和播放器的适配、自适应算法的设计等等。
当时大家对项目整体比较乐观，预计3～5个月就可以上线，其中最担忧的是CDN厂商，因为需要CDN厂商配合做定制开发，担心对方配合度不高。事实证明是我们多虑了，CDN厂商了解基本信息后都非常认可这套架构，并给予高度配合，甚至有的CDN厂商承诺一个月就可以联调上线。于是，我们就很愉快的开工啦。
大约4个月左右，我们完成了所有的开发与联调工作，开始灰度与AB测试。大家都期待着数据给我们一个大大的惊喜，然而惊喜没有，惊吓倒是不小，无论是卡顿率等QoS数据，还是时长等QoE数据，都显著负向，一时间大家都傻眼了。我的第一反应是是不是多码率自适应算法设计的不够合理？
图：《搏击俱乐部》
毕竟算法是影响多码率效果的核心因素。我在北大读博的研究课题之一就是多码率算法，无论是标准制定还是学术论文，无论是系统搭建还是工程落地，都有比较丰富的经验，对这个领域也有很深刻的理解，在反复检查算法的逻辑和实现后，基本排除了算法的因素。
到底为什么数据会负向，等待我们的是漫长的基于数据驱动的优化过程。不断的加埋点，AB测试、数据分析与优化、加埋点、AB测试、数据分析与优化……一路逢山开路，遇水架桥，发现和解决了各类问题。
有的是我们低估了整个系统的复杂度，例如我们只是给了CDN厂商一个简单的需求文档，但是各家CDN厂商都有自己的层级逻辑和回源架构，功能上很容易支持，不过效果却和传统的HTTP-FLV有比较大的差异；例如回源机制、冷流的处理、吐流规则、域名更换等等。于是团队和各家CDN厂商一起一点点迭代优化，直到能和传统的非多码率架构的性能完全对齐。
还有的问题是内部沟通不够充分导致的。整个项目涉及到的团队非常多，例如客户端、播放器、算法等等，很多细节没有达成一致，比如上报的口径不一致，导致统计数据的偏差；播放器的逻辑与算法适配不够精细，例如播放器的很多操作都是基于音频，而算法的输入则主要参考视频；卡顿事件没告知算法，因为一旦发生卡顿播放器会等缓存积累到一定程度再继续播放，如果算法不知道卡顿这个事件，单纯的看见缓存数据很多，就会误以为网络很好……
类似的例子特别多，现在回头来看感觉这些问题解决起来都很简单。但是在实际过程中，最大的难点是发现问题，明确问题所在。
图：《搏击俱乐部》
一个小插曲，记得当时数据负向排查几个月依然没有拿到收益时，这个项目一度变成了烫手山芋，陷入让人无从下手的胶着状态，不得不被“搁置”。但是这个事情总得有始有终，在停滞了一段时间后，我硬着头皮重新梳理了整个方案，把每个环节的核心开发人员拉到一起，逐个细节去核对预期的需求和具体的实现。
一点点核对数据细节，而不只看最终的结论。同时叫停了每周的汇报，我们一直在通过AB测试和数据找问题，但是状态一直不变，无形中会给同事更大的压力。
经过深入艰难的分析与优化，在去年10月份左右，我们基本把问题全部解决，并在游戏场景取得了很好的效果，卡顿率得到显著的降低，用户时长等QoE也有不错的收益，这时大家才真的松了口气。
看到游戏的收益后，快手APP就在考虑，是不是也可以采用这套架构，提升站内直播的体验。有了前面的丰富经验，在快手APP上，我们从播放器和算法适配，到灰度、AB，再到最后全量，只花了大概一个月左右的时间。目前，这套架构也已全面用于快手的各直播业务 。
3
先行者要把肩膀贡献出来
自研多码率在快手全面落地取得不错的收益，获得了公司的内部肯定，似乎可以暂时画上一个句号，但是总感觉差口气。
在和部门负责人于冰老师的探讨中，我们在想目前市面上没有适合直播的多码率标准方案，而我们踩过那么多坑，终于搞出了这套每天有上亿快手用户在使用的方案，是不是可以考虑将方案标准化甚至开源贡献给业界呢？
图：《搏击俱乐部》
这个想法立马就得到了大家的认可，记得之前我们第一次对外公开KTP的时候，就有很多的同行问过我们，期望我们将KTP开源。但KTP涉及到公司内部的太多技术和业务，一时难以解耦，暂时无法开源。
直播多码率方案，也许是我们为业界作贡献的一个很好的机会。有了想法以后，说干就干，我立刻着手标准文档的撰写和开源的事情，并正式命名为LAS。
LAS基于流式架构，实现帧级传输，与MPEG-DASH/HLS等基于分片的多码率架构相比，能显著降低延迟。在自适应算法上，与分片传输的策略相比，基于流式的传输逻辑会一定程度增加自适应算法的难度（例如在流式传输中，因为源数据实时产生，观测到的平均带宽值近似等于当前请求的视频码率，无法反应真实的带宽），但流式架构更加灵活，并且能显著降低分片架构中存在的传输ON-OFF现象，从而降低了码率切换过于频繁的问题。
与HLS测试对比也验证了LAS的高效性，LAS能极大的降低卡顿率和延迟，同时获得更高的清晰度（平均码率），详细数据可以参考LAS测试报告。
做标准与开源，经常会被问到的是“对外开放技术，会不会让别人快速追上甚至超过你们”。这种情况的确可能存在，正所谓“如果我看得更远一点的话，是因为我站在巨人的肩膀上”，我们不是什么巨人，但是至少可以帮助其他企业少走很多弯路。
至于超过我们，我觉得这也是一种好事，说明LAS还有很大的优化空间。作为一个技术人，如果一直担心“别人偷了你的技术”，在某种程度上也是对自己技术不够自信的表现。无论是学术科研，还是工程技术，开放心态，多多交流，于人于己都是有好处的。
“某个项目一旦用了开源模式，就能获得迅速而持久的进步。一旦开源，就能同时拥有许多团队并驾齐驱地投入工作，很多问题都能快速地迎刃而解，这和关起门来开发不可同日而语。”
图：《绅士们》
我们发布和开源LAS，除了把自己的技术经验贡献给业界，也非常希望业界同行一起参与进来。目前，百度、阿里、腾讯、网宿、金山等厂商都参与了LAS的共建，在云端保证了LAS的服务。
此外，业内知名开源流媒体服务器SRS也已支持LAS，基于SRS 4.0及更高版本，企业客户也可搭建自己的LAS服务端以满足个性化的需求。在客户端，我们已经开源了LAS Web的实现，包括协议、架构和自适应算法。
LAS1.0的发布只是开源的第一步，希望起到抛砖引玉的作用，集中业界的智慧，进一步将LAS完善，例如移动端方案、WebRTC和QUIC等协议的支持等，最终打造一套可以真正解决直播传输场景下各种复杂问题的标准化方案，服务全球相关行业开发者，帮助大家站在更高的起点上完成相关研究，实现更高的技术突破。
标签：码率,快手,CDN,算法,直播,LAS,周超 From： https://blog.51cto.com/u_13530535/6477505