实时音视频技术解析

实时音视频技术解析编者按：音视频技术的历史可能要追溯到19世纪末——特斯拉与爱迪生的伟大时代。直到今天，他们的发明依然伴随我们生活的每时每刻。2018年音视频技术将有哪些突破?来自学霸君的资深架构师袁荣喜从编解码器、客户端、传输网络、动态缓冲区以及媒体处理技术几个方面解析实时音视频技术。展望2018，区块链、AI、WebRTC、AV1将成为关键词。

实时音视频技术是源于早期的VoIP通信，随着后来互联网的发展进程，这项技术2003年被Skype引入到PC桌面系统，开启了整个实时音视频技术新纪元。经过15年的进化，基于PC上的实时音视频技术日渐成熟，也涌现了像WebRTC这样的开源项目。但随着近几年移动互联网和4G的兴起，实时音视频领域有了更广泛的应用，引来了新的技术难题和挑战。经过2016年直播大战后，音视频应用得到了用户的认可，直接促成了2017年实时音视频应用的大爆发，在娱乐方面出现了像狼人杀、陌生人视频社交、在线抓娃娃等风口;在协作应用领域出现了Slack和Zoom等多人远程协作应用;在行业应用上也有很大的突破，例如像VIPKID、学霸君1V1等强劲的在线教育产品。在苹果8月份宣布新一代iOS浏览器Safari支持WebRTC后，实时音视频技术成为了时下热门技术体系。

但实时音视频相关技术门槛非常高，很多细节并不为人所知，其中涉及到平台硬件、编解码、网络传输、服务并发、数字信号处理、在线学习等。虽然技术体系繁多，但总体上归纳两类：1对1模式和会议模式。我从这两个分类对实时音视频相关技术做简单介绍，主要有以下几方面：编解码器客户端上传实时传输网络动态缓冲区媒体处理技术编解码器

谈到视频编码器，就会想到MPEG4、H.264、H.265、WMA等等，但不是所有的视频编码器都可以用来作为实时视频的编码器，因为实时视频编码器需要考虑两个因素：编码计算量和码率带宽，实时视频会运行在移动端上，需要保证实时性就需要编码足够快，码率尽量小。基于这个原因现阶段一般认为H.264是最佳的实时视频编码器，而且各个移动平台也支持它的硬编码技术。H.264/AVC

H.264是由ITU和MPEG两个组织共同提出的标准，整个编码器包括帧内预测编码、帧间预测编码、运动估计、熵编码等过程，支持分层编码技术(SVC)。单帧720P分辨率一般PC上的平均编码延迟10毫秒左右，码率范围1200~2400kpbs，同等视频质量压缩率是MPEG4的2倍，H.264也提供VBR、ABR、CBR、CQ等多种编码模式，各个移动平台兼容性好。VP8/VP9

除H.264以外，适合用于实时视频的编码器还有Google提供的VP8，VP8采用了H.264相似的编码技术，计算复杂度和H.264相当，不支持SVC，相同视频质量的压缩率比H.264要小一点，不支持B帧。而后Google又在VP8的基础上研发了VP9，官方号称VP9在相同视频质量下压缩率是VP8的2倍，对标的对手是H.265，VP9已经嵌入到WebRTC当中，但VP9编码时CPU计算量比较大，对于VP9用于实时视频我个人持保留意见。不管是VP8还是VP9硬编方式只有Android支持，iOS和其他的移动平台并不支持。音频编码器

实时音视频除了视频编码器以外还需要音频编码器，音频编码器只需要考虑编码延迟和丢包容忍度，所以一般的MP3、AAC、OGG都不太适合作为实时音频编码器。从现在市场上来使用来看，Skype研发的Opus已经成为实时音频主流的编码器。Opus优点众多，编码计算量小、编码延迟20ms、窄带编码-silk、宽带编码器CELT、自带网络自适应编码等。

图1：语音编码器编码延迟与码率对比客户端推流实时音视频系统都是一个客户端到其他一个或者多个客户端的通信行为，这就意味着需要将客户端编码后的音视频数据传输到其他客户端上，一般做法是先将数据实时上传到服务器上，服务器再进行转发到其他客户端，客户端这个上传音视频数据行为称为推流。这个过程会受到客户端网络的影响，例如：Wi-Fi信号衰减、4G弱网、拥挤的宽带网络等。为了应对这个问题，实时音视频系统会设计一个基于拥塞控制和QoS策略的推流模块。拥塞控制因为客户端有可能在弱网环境下进行推流，音视频数据如果某一时刻发多了，就会引起网络拥塞或者延迟，如果发少了，可能视频的清晰不好。在实时音视频传输过程会设计一个自动适应本地网络变化的拥塞控制算法，像QUIC中的BBR、WebRTC中GCC和通用的RUDP。思路是通过UDP协议反馈的丢包和网络延

迟(RTT)来计算当前网络的变化和最大瞬时吞吐量，根据这几个值调整上层的视频编码器的码率、视频分辨率等，从而达到适应当前网络状态的目的。QoS策略

客户端推流除了需要考虑网络上传能力以外，还需要考虑客户端的计算能力。如果在5年前的安卓机上去编码一个分辨率为640P的高清视频流，那这个过程必然会产生延迟甚至无法工作。为此需要针对各个终端的计算能力设计一个QoS策略，不同计算能力的终端采用不同的视频编码器、分辨率、音频处理算法等，这个QoS策略会配合拥塞控制做一个状态不可逆的查找过程，直到找到最合适的QoS策略位置，图2是一个实时音频的QoS策略迁移过程实例。

图2：实时语音的QoS状态迁移传输路径技术在前面我们对实时音视频归纳为：1V1模式和1对多模式，这两种模式其实传输路径设计是不一样的。1V1模式主要是怎么通过路由路径优化手段达到两点之间最优，这方面Skype首先提出基于P2P的Real-timeNetwork模型。而1对多模式是一个分发树模型，各个客户端节点需要就近接入离自己最近的server服务器，然后在server与server构建一个实时通信网络。P2P前向收敛技术

对于1V1模式的实时音视频通信，很多时候我们以为两点之间直连是延迟最小质量最好的通信链路，其实不是。整个骨干网的结构并不是网状，而是树状的，这个从同城网通电信之间互联的质量可以得出结论，如果涉及到国际之间互联更是复杂无比。一个好的1V1实时音视频系统会设计一个对等多点智能路由的传输算法，就是通过多节点之间的动态计算延迟、丢包等网络状态来进行路径选择，这是个下一跳原则的选择算法，只要保证每个节点自己发送包的下一跳的延迟和丢包最小，那么整个传输路径就是最小最优，一般TTL小于4。寻找下一跳的过程是一个P2P节点前向收敛技术，它需要一个函数f(x)来做收敛。图3是一个传统1V1和基于P2Prelay的1V1对比示意图。

图3：P2P多路径传输示意图proxy传输技术对于1对多模式的实时音视频通信，需要一个中心server来控制状态和分发流数据，但参与通信的节点不都是对中心server网络友好，有可能某些节点连不上中心server或者丢包延迟很大，无法达到实时通信目标需求。所以一般会引入就近proxy机制来优化传输网络，客户端节点通过连接距离最近的proxy到中心server。这种方式不仅仅可以优化网络，还可以起到保护中心server的作用。

图4：proxy传输模式示意图分段计算不管是P2Prelay模式的1v1，还是就近proxy的1V多模式，在数据传输过程会做各种传输补偿来应对丢包，例如：FEC、ARQ等，如果进行ARQ还需要对重传的数据做临时保存。这里遵循的是分段计算的原则，这个原则大致是：每一段网络上一跳节点必须独立计算到下一跳节点之间的丢包、延迟，并将接收到数据cache在内存中，根据这段网络的状态启用对应的FEC、ARQ和路由选择策略，不影响其他分段传输策略。

图5：分段计算与网络节点示意图WebRTC网关在实时音视频系统中需要在Web上进行实时通信，各个浏览器都已支持WebRTC，所以WebRTC是Web上实时音视频通信的首选。但WebRTC是基于浏览器的客户端点对点系统，并没有定义多路通信标准和服务中转标准，不管是1V1模式还是1对多模式，需要引入WebRTC网关来接入自定义的实时系统。网关负责将WebRTC的SDP、ICE、STUN/TURN、RTP/RTCP翻译成自定义系统中的对应协议消息，实现无缝对接WebRTC。WebRTC很多类似的开源网关，例如：licode、janus等。动态缓冲区

在实时视频的播放端会有一个自动动态伸缩的JitterBuffer来缓冲网络上来的媒体数据，为什么要这个JitterBuffer呢?因为TCP/IP网络是一个不可靠的传输网络，音视频数据经IP网络传输时会产生延迟、丢包、抖动和乱序，JitterBuffer可以通过缓冲延迟播放来解决抖动乱序的问题。但JitterBuffer如果缓冲时间太长，会引起不必要的延迟，如果缓冲时间太短，容易引起音视频卡顿和抖动。所以JitterBuffer在工作的时候会根据网络报文的抖动时间最大方差来动态确定缓冲时间，这样能在延迟和流畅性之间取得一个平衡。

JitterBuffer除了缓冲解决抖动和乱序的问题以外，为了延迟和流畅性之间的制约关系，它还需要实现快播和慢播技术，当JitterBuffer中数据时间长度小于确定的抖动时间，需要进行慢播，让抖动缓冲区数据时间和抖动时间齐平，防止卡顿，当JitterBuffer中的数据时间长度大于确定的抖动时间，需要进行快播，接近抖动时间，防止累计延迟。媒体处理回声消除

在实时音视频系统中，回声消除是一个难点，尽管WebRTC提供了开源的回声消除模块，但在移动端和一些特殊的场景表现不佳。专业的实时音视频系统会进行回声消除的优化。回声消除的原理描述很简单，就是将扬声器播放的声音波形