从2016开始，腾讯启动将传统的音视频解决方案逐步部署在腾讯云上，从传统的FFmpeg、OBS、RTMP开始提供了第一代直播服务。随后演进到以QUIC与HLS低延迟直播。最后在网络拥塞算法与Codec层面做进一步调优，进一步提升复杂场景下用户的QoE体验。本文根据腾讯视频云终端研发总经理常青在LiveVideoStack2019北京音视频技术大会上的分享整理而成。
文 / 常青
整理 / LiveVideoStack
大家好，我是腾讯视频云终端研发负责人常青，本次分享的主题和内容是关于腾讯音视频终端这些年来的进化演化以及在客户方面的实践应用，所以“进化”也是本次分享的主题词，说到进化大家可能首先联想到的是达尔文的进化论，因此我会先以一段故事来引出之后的内容。
达尔文在刚刚公布进化论的一段时间，在当时的社会引起了轩然大波，尤其是在“神创论”占据主流思想的情况下，很多名流都更愿意相信人是神创造出来的，并且举了很多反例来挑战达尔文。比如有人就提出：像人眼如此复杂的器官是如何进化出来呢？受限于当时人类的认知，达尔文本人也未必能够回答的清楚，但随着科技的进步以及科学的验证已经可以尝试的去解答这样的问题。
1. 简介
地球上生物的进化首先是由单细胞生物进化为多细胞生物，多细胞生物（浮游生物）在某些特定条件下发生基因突变形成感光细胞，可以在感应光线变化的同时驱动鞭毛避开海面周围的紫外线。感光细胞聚集成细胞群并形成凹陷，使得此时浮游生物不仅可以感受到光线强弱，甚至可以感受到光线的方向。之后凹陷越来越大，逐步加深形成带孔眼球，但成像效果并不好，此时的眼球已经可以通过空隙收缩完成“小孔成像”，但光线进入量有所减少。之后通过角膜覆盖和产生晶状体完成光线进入量和成像效果增加，逐步形成一个简单的生物版照相机。
2. LiteAVSDK技术演进之路
2.1 LiteAVSDK技术架构图
回到本次分享的主角LiteAV音视频框架，它是腾讯云线上音视频产品的总框架。称为LiteAV也是在开发之初对它的愿景，希望它能做到很轻、很小、很简单，而在四年的发展历程中，它也像我们刚才提到的眼睛一样，从一个小小的感光细胞开始，不断进化，最终形成了一个功能强大的音视频产品。。它的设计思路是采用统一的架构，包括统一的底层框架、一系列可复用的音视频模块和工作组，最后再加上网络协议就可以包装出一系列基础性的功能，包括直播的推流和拉流、小程序音视频方案、短视频、播放器以及融合音视频解决方案的TRTC都是基于这一整套的框架去实现，所以目前整个腾讯音视频的产品线都逐渐使用这套整体框架提供服务。
2.2 Step1：始于播放器，自研播放引擎
时间跳转到2016年，腾讯开始从传统的音视频解决方案转到云上的音视频解决方案。在开发初期，团队的立足点是最先解决播放问题，当时云上的客户推流大多采用OBS的解决方案，但在播放中被诟病最多的是播放卡顿和延迟不可控等问题，因此腾讯开始从这个角度思考如何去解决，在调研中我们发现绝大多数客户播放器的解决方案都是基于FFmpeg，FFmpeg的解码能力非常强，但在网络层设计之初是用于本地文件播放以及远程点播文件，缓存机制为“下载-积攒-播放”，由此产生了延迟不可控的问题，因此我们决定在播放器上做文章。
腾讯在很多年前就开始做音视频方面的产品，QQ 和 微信的视频通话中有很多技术都可以直接搬过来用，比如延时控制、语音声学变化以及人声和背景声的分离等技术等，同时还可以针对客户的诉求和场景，做一些针对直播场景下音画同步的逻辑，最终构建出一套自研播放引擎，它最大的优势则是在延迟控制方面做得很好。
比如相对于常规播放器，观看直播的观众之间进度是不同的——有些观众与主播的时差是三秒，而有些则达到五秒以上，这样的延迟在诸如答题直播场景中无法满足用户需求，而LiteAV在当时可以很好解决这个问题。
2.3 Step2：QUIC协议优化助力推流加速
在播放器方面有成绩之后，下半年腾讯云将目光投向了推流部分，推流方面的难点相比播放还要更大。由于RTMP协议太过标准，以至于没有太多发挥的空间，RTMP是基于TCP的解决方案，所以有些主播家里网络出现问题时，就会导致推流质量很差，从而影响到观看质量。既然TCP不可靠，我们就换成谷歌的QUIC协议，QUIC协议是使用UDP去实现TCP的方案，在质量和效果上都要好很多。
QUIC技术是七层协议，对外接口都是HTTP这样的请求/响应，RTMP推流是通过流式把数据发送到服务器上，因此首先需要解决的问题就是把七层协议改成四层。除此之外，把QUIC全部打包进SDK会使App体积要增加一、两倍，因此需要对QUIC协议进行裁剪，在保持主流程不变的情况下对关键部件进行替换，甚至采用HOOK和一些伪实现的方式来尽可能将体积压在1M以内，这是团队在2016年下半年做一件很重要的事情。整个完成之后推流质量相较于友商有很大提升，而且服务端有很多GPN加速节点去配合，加上QQ、微信积攒了大量的动态路由数据，因此可以找到最合适的加速节点，保证推流质量。
2.4 Step3：直播 连麦，低延迟链路优化
在推拉流协议都做了优化之后，我们在“最后一公里”的问题上已经有了一些进展，接下来，我们开始将目光投向“延时”这个老大难问题。上[青1] 图是腾讯云的直播架构，主播通过RTMP协议推流到服务器上，服务器通过转码集群——由于RTMP协议秒开效果太差，所以会优先转码成FLV和适合网页播放的HLS格式，有些高清码流也会转码为不同分辨率的流，这些数据经过CDN强大的扩散集群，最后到达每个观众。这样的操作延迟很多都在2-3秒以上，如果码率过高延迟会达到4-5秒甚至更高。
我们发现整个直播场景下关于延时存在很大问题，因此通过大幅降低延迟通过取消转码和CDN扩散集群，直接用腾讯的骨干网资源，每个主播/观众到云上节点中间最不确定的部分用QUIC加速，可以把延迟缩短到500ms以内，而线上的平均数据还要更低。
在此基础上，当主播之间延迟都很低的情况下，我们就可以把双向的通话拉起，这其中需要解决的不仅仅是网络上的问题，还要做一些声音上的处理，比如回声的抵消、降噪以及声音的自动增益，完成声音处理之后，一个简单的直播连麦方案就创造出来了。
前面提到的这些技术，在腾讯云LiteAVSDK 的 TXLivePusher 和 TXLivePlayer 组件中都已经提供，并且为很多的腾讯云客户提供着稳定的服务，事实上，它是如此的简单和高效，以至于微信的小程序也成为了我们的一个很重要的“客户”和“partner”。上[青2] 图中小程序API有两个标签——<live-pusher>和<live-player>，都是基于LiteAVSDK实现的。通过与微信的合作也实现了很多轻量级的诉求，比如用户并不想安装App时就可以使用小程序唤醒来完成诉求。除此之外，现在的新零售、保险理赔、政务庭审以及在线问诊场景，目前BMW的在线销售场景可以实现导购员直接带着用户看车，用户可以在家里指示导购员将镜头对着用户需要观看的部分。
2.5 Step4：视频特效编辑系统构建
2017年下半年短视频市场非常火爆，因此我们没有继续在网络上投入更多精力，而是将重心放在视频特效编辑系统上。这套视频特效编辑系统框架除了很多“积木”（模块）的堆积，还做了编辑引擎类的构建，像抖音里的“动感光波”、“时光倒流”等特效就是通过SDK中编辑子引擎来实现和构建的。整体效果，不仅是在录制中的变速、多段的播放，还包括视频在处理过程中的特效加持，甚至连足够商业化的UI界面，在整个系统中都是一气合成的。
2.6 Step5：弱网优化与无线网络的新挑战
2018年直播场景更多强调互动和低延时，互动不仅体现在弹幕和礼物系统，更多扩展到连麦K歌、聊天和游戏中，传统直播的标准方案在应对这些需求时也显得有些吃力。
腾讯云团队在将之前的技术应用于新的直播场景时，发现关于弱网优化的技术仍旧固有在ARQ、FEC和拥塞控制。ARQ和TCP的思路很像，但不同的是在传输过程中出现丢包时，丢掉哪一个包就需要重新请求这个数据包，没有出现则就此放过。FEC技术则采用了生物界里面繁衍下一代常用的“光撒种”的策略，通过增加荣誉的信息来减少丢包带来的影响，比如原始图像有五个数据包从发送方通过网络传输到接收方，发送方将数据包传到网络之前会通过冗余算法加一些冗余，把五个数据包变成六个、七个甚至更多，这些冗余数据包的作用是在网络传输过程中一旦出现丢包，就会通过冗余数据包尽快恢复出丢失数据包，然后再通过解码显示图像。FEC技术看似很好，但实际代价却很大：首先FEC算法计算量会很大。其次，FEC技术在现实中表现得并不高效，即使较好的FEC算法也只能以30%的冗余解决10%的数据丢失问题。当然，除了ARQ 和 FEC，还有一个常用思路就是通过拥塞控制应对网络情况的变化：在带宽非常充裕时可以随意挥霍，但在带宽非常紧张时，整体会通过控制编码器减少发送数据量，让编码器适应带宽。
最近几年网络环境的改变除了带宽的提升，还有从有线网络到无线网络的切换。无线网络（802.11）具有一个特点，在共享一个热点的状态下，终端相互之间会抢资源，这是因为无线网络下的通讯是排它的，资源的分配很大程度上由使用量和分配算法决定，这就造成了很大的不确定性。物理网络虽然不方便，但是稳定而且抗干扰能力强，所以不管是好是坏，网络质量都更像一个稳重的lady，不会动不动就跟你“闹情绪”。相比之下，无线网络更像是一个年青爱撒娇的girl，这一段时间WiFi信号满格，但只是因为你的手机转动了一下方向，或者在客厅和卧室里来回走了几步，网络质量就可以随着信号强度一起泛起“轩然大波”。在这种情况下协议理念需要作出变革，不止关注网络层的恢复率和能力，更多应该关注上层音视频处理的容错性。
2.7 Step6：提升编解码器容错能力，建立基于云端决策的调控系统
2018年下半年腾讯云团队开始专注基于Codec的卡顿优化和基于云端决策的调控系统。比如在现在编码时就不能再像直播一样采取标准参考关系：假设一秒的画面15帧，在最开始编一个关键帧（I帧），再编一系列的非关键帧/参考帧（P帧），每一个P帧参考前面一帧来把变化的部分编进去，编码部分预测的越准，编码算法越强，所得的视频越小。但如果简单采取上面这种标准参考关系，当其中一个P帧丢失后，后面所有的帧都无法解开，造成这段影像卡顿。如果在编码时多考虑容错性，相应来说在解码端的容错性也会更强，表现在播放画面中也只卡顿一下，对于一秒钟20帧的影像相当于卡了50毫秒，用户在观看时几乎不会感知，这对于观看体验会有不小的提升。
同样的思路也可以用在声音上。人声是通过声带振动发出声音，对声音容错性的要求会更加苛刻，但声带的振动本身是物理振动，如果声音信号切的非常细——比如20毫秒一个，会发现其中存在很多规律，如果只是简单丢掉一两个数据包，是可以通过预测来填补，这也是最简单的音视频丢包异常处理。
视频和音频可以接受一定程度丢包的前提下，网络层相对就不用照顾所有的数据，整个音视频体系就可以不再局限于原来在有线网络积累的思路，而是更多关注最终的收益和效果，比如下图中橙色部分的实际恢复率、失败反馈和无参考评分，综合这些信息交给云端完备的统计分析系统和决策系统，就可以通过实时调控甚至迭代版本去优化网络的拥塞算法和发送策略，这样一系列的改变来提升产品的体验和效果。
所以像腾讯的TRTC和目前做的比较优秀的音视频系统，都是体积化去优化的过程。首先它有最基础的线路质量要求，仅靠三四台服务器想要撑起全国各处无缝低延迟连接都是不可能的，线路质量主要依靠于全国各地机房布点以及骨干网专线的打通，都是好的音视频解决方案的基础，有了这样的基础设施建设才有软件方面的加分项。同时要有比较基础的理论体系支撑，比如FEC、ARQ和QUIC这些基础算法支撑，但要想做好产品体验更多的是靠一系列的工程和细分领域上的优化。
2.8 Now
腾讯云在2019年上半年开始打造一些新的玩法，比如低延时大房间的解决方案。之前讲到直播CDN的方案是流式从左到右非常清晰的链路，逐级将信号放大，但是在TRTC这种混合方案中，链路就没办法做到像CDN那样清晰，更多是靠强大的音视频节点（腾讯内部称为接口机），通讯链路重拾了UDP协议，对于要求低延时和互动性高的使用场景会用UDP方案和很强大的接口去做，而对于低延时、高并发观看场景则会使用对并发能力支持更强的代理机来做。最后这套服务还可以通过旁路集群与标准的直播CDN进行打通，同时能支持对直播CDN的结合，这样一套复合解决方案能够越来越多的满足解决不同场景下的不同需求。
目前很多客户在使用音视频场景解决方案时，逐渐开始追求更高的互动性和更低的延时。以陌陌举例，在交友方面涉及到各种各样的玩法，以互动性来说就包括多人聊天/PK和KTV聊天室，这样的使用场景对延时的要求非常高，这样的产品想要真正落地需要大量的优化，因此，我们今年上半年也在功能、流畅度、延时和转推效果方面做了大量的努力。
也有很多应用场景对于玩法花样没有太多的要求，只是需要有很高的视频通话质量，比如VIPKID，在教育方面表现为很多海外老师对中国学生进行视频教学，这部分的视频卡顿率都是可以度量和统计的，有一些参考评分，比如视频渲染帧间隔不能超过200ms、视频清晰度评分、POLQA分、端到端延时以及全年不可用时间<10分钟，这就可以在客户和我们之间画出一条“红线”，只要逾越这条红线就要出局。如果可以满足要求，那就可以成为服务提供商。
线路质量有海外专线支撑，但专线在一些特殊情况下也会出问题，所以要有多条V**线路备份，再包括光纤断了之后需要多集群分布式容灾。在声音流畅度方面，教育领域对音质的要求近两年也在不断提升，尤其不仅局限于英语教学，在声乐教学场景中对于声音传输中钢琴的音色也提出了很高的要求。关于弱网抗性中首帧加载速度以及对端质量决策和视频丢帧预测，这其中都有很多规律可循。在网络策略上全局的动态路由表，这其中有很多事情都可以落地。
总的来说，在很多客户诉求随着市场竞争的加剧，用户需求的提升，不断地追求质量的精益求精，在此期间腾讯云也在不断地完善音视频体系。
LiveVideoStackCon 2019深圳招募讲师
12月13-14日，LiveVideoStackCon将首次来到深圳，将全球前沿多媒体技术实践与深圳本地产业结合，触发技术与商业灵感。欢迎将你的技术实践、踩坑与填坑经历、技术与商业创业的思考分享出来，独乐不如众乐。请将个人资料和话题信息邮件到 speaker@livevideostack.com 或点击【阅读原文】了解成为LiveVideoStackCon讲师的权益与义务，我们会在48小时内回复。
LiveVideoStack正在招募编辑/记者/运营，与全球顶尖多媒体技术专家和LiveVideoStack年轻的伙伴一起，推动多媒体技术生态发展。同时，也欢迎你利用业余时间、远程参与内容生产。了解岗位信息请在BOSS直聘上搜索“LiveVideoStack”，或通过微信“Tony_Bao_”与主编包研交流。
