实时音视频技术解析

实时音视频技术解析

编者按：音视频技术的历史可能要追溯到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-time Network模型。而1对多模式是一个分发树模型，各个客户端节点需要就近接入离自己最近的server服务器，然后在server与server构建一个实时通信网络。P2P前向收敛技术

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

图3：P2P多路径传输示意图proxy传输技术

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

图4：proxy传输模式示意图分段计算