音视频抗丢包技术综述，面向不可靠传输网络的抗丢包编解码器

本文整理自高泽华 声网Agora.io 编解码算法工匠，在RTC2017实时互联网大会和QCon上海2017上的技术分享。

欢迎访问 RTC 开发者社区，与更多开发者交流经验，参与更多技术活动。

不管对于音频编码仍是视频编码而言，对于编解码来讲，都有不一样的应用场景。比较大的两个范围，第一种，面向文件直播的编解码器。第二种，面向网络通讯的编解码器。

在不一样的应用场景下面，编解码器的选择彻底不同。举个例子，面向直播的时候，延时比较长、丢一些包、网络带宽跳动等，是不须要考虑。能够在离线的时候，充分的利用CPU的能力去编，能够固定I帧的间隔、固定I帧的大小，甚至多个B帧均可以。码率也能够是固定的，这对于录文件和录视频没有问题。

可是若是面向实时网络通讯这样恐怕不太好，由于网络是瞬变，并且网络状态通常来讲都是会伴随着丢包这样的状态，这个时候就不适合使用，好比说使用固定的I帧间隔，若是I帧丢了就要使用I帧重传。还有就是也不能使用固定的码率，由于码率也是瞬变的。

因此在面向于网络通讯的编解码器中，编解码器选择和直播的编解码器的选择差异比较大。好比有人提出在网络通讯中硬件压缩是否能够，其实因为不一样的厂商对硬件压缩的支持是不同的，硬件压缩的迭代不同，编码支持也不太同样。有的硬件版本也不能产生可变I帧大小，或者码率是固定的，若是码率不固定就会自动重启硬件的编解码器。我说的都是一些个例，并不表明全部编解码器都是这样。我想强调的是，编解码器面向直播和网络通讯是不同的，我今天想说的是面向不可靠传输网络的抗丢包编解码器。

首先咱们来思考一下抗丢包的重要性。在2017年，有几类应用是比较火的，第一类在大学校园最火的游戏应该是王者荣耀和狼人杀，王者荣耀10人组队实时厮杀，还有语音。狼人杀提供实时视频。第二类就是互动直播，主播端把通讯直播流发到观众端，同时也能够把观众端拉上麦，实现主播和观众的互动。我记得沪江的技术负责人吴海滨曾经提出，“在当前互动网络教育中最难解决的问题仍是实时性，就是老师跟学生怎么可以更好的互动”。互动直播，在当前网络下给技术提了更高的要求，要求可以在低延时下提供高质量的通讯品质。包交换的网络中，要想实现低延时和提升包质量，若是承载信息的包没有按时到达，接收质量不会好。

既然丢包是低延时和高质量的一个拦路虎，咱们来看一下当前的网络状态是否是有那么多丢包。咱们提到丢包的时候首先要想到一点，丢包的定义是什么？其实对于通讯来讲丢包并不意味着真正的包丢了，我我的理解“只要包没有按时到达都叫丢包”。好比第一个包没有来，第二个包已经到了，此时第二个包发出去了，那么第一个包再来对我没有任何的帮助，实时通讯不可能重来。

对于通讯系统而言，上图是一个基本的通讯系统，一个APP经过4G和WIFI，再经过公有云实现通讯。你们可能会讲了，已经4G、5G，是否是带宽足够大，不须要考虑丢包的问题了呢？

不彻底是那样。举个例子，咱们看一下上图这个包的到达通路，手机和Pad通讯，假如说Pad经过4G到达公有云，再经过WIFI发回给手机端。在这个通路中有三段网络，也就是有三段可能会产生丢包的地方。第一段是公有云之间，由于公有云之间也会有不少路由的转换。第二是4G或者WIFI到APP端，第三段就是，还有就是APP，device自己。

先来说第一段，在公有云上咱们都会建一些服务器。即便是在同一个运营商下，早上八点、中午12点到晚上8点，网络情况都不同，一般来讲晚上8点网络高峰期，这个时候网络传输很是上不稳定，在服务器和服务器之间常常容易产生丢包。第二是不一样的运营商之间，好比电信和联通之间，当联通向电信传输数据时，因为两个运营商出口带宽结算问题，不在高峰期均可能不太稳定。还有一个问题就是，小运营商，好比教育网，机房的状态不是一直稳定的，可能会产生丢包。

第二段是4G或WIFI到终端，这一块也并非很是可靠。若是两台设备连着是不一样的基站互相通讯，基站之间可能产生一个转化和丢包的问题。虽然链接了骨干网，可是因为骨干网不一样的运营商差别，会产生丢包。在同一个运营商之间，不一样的地区，网络状态也是不同的。举个例子，在今天的会场，虽然我以为这附近4G是蛮不错的，可是在2000人大型的会场都在使用联通4G的时候，实际上共享网络的状态是比较差的。这就是所谓的共享网络带来的问题。

当咱们在不一样的国家链接网络的时候，好比印度、美国，不一样的国家网络状态也不一样，因此咱们在作网络策略的时候实际上都不能一律而论。

除此以外还有WIFI。若是你们作过实时通讯的话，都会有一个感受，有些时候4G比WIFI更稳定。由于WIFI其实是很是不稳定的系统，若是你们在公司连WIFI的话，公司可能会存在数十台路由器，路由器之间有频率干扰。另外，即时是上千块钱的路由器，可支持链接人数最多也就是三四十人。超过这个限制，即便是连上了也会主动丢包。因此，并非4G和WIFI带宽足够高就没有丢包的问题。

再提出一个很是现实的现状，运营商都在推行VoLTE，还有一个新词叫VoWiFi。这是数字电话在产生的一个变革，把电路交换过渡到分组交换，在分组交换下全部的通讯都是经过包来传递，而不是固定的链路。以前的通话，我一旦拨通这个电话，链路就保持下来，无论有没有用、用多少，链路都是存在，因此效果都比较好。可是在分组交换网络下，数据都是以包的形式传递，不说话的时候不发包，或者发包比较少，码率也会比较低。可是运营商提出VoLTE和VoWiFi已经好久了，实际上咱们只有少许状况会使用VoLTE，当网络很差时，都会回落到电路交换进行通话。运营商本身的4G网络质量就很差，更不用说咱们在上面作端到端视频的通讯。

既然丢包问题这么常见，咱们有哪些办法？一般有这四种方案：FEC、PLC、ARC、ARQ，还有一个是编码器。ARC和ARQ分别是自动码率控制和自动请求重传，都是针对网络状态进行调整的策略，可是它们俩应用的场景不同。对于音频来讲，不管是语音仍是音乐，码率一般需求比较低，尤为是语音，此时ARC的应用场景并非特别大。好比，要传一个16kbps的语音，在当今的网络状态下问题不大。要传一个128kbps的音乐就稍微有一点问题。要传一个400-800kbps的视频问题就会比较多了。因此ARC是一种针对当前网络状态进行估计，而且回传回来主动进行码率调整的策略。

ARQ，自动请求重传，当网络延时比较低的时候，咱们能够经过重传的方法来实现抗丢包。这种方案有两种策略：第一种，发出一个包，只要在规定的时间没有响应，就再发一个包；第二种，发出一个包会等它的请求，若是它的请求到了就给它一个重传包。可是这种技术的使用前提是端到端的网络延时比较短，若是延时比较长，好比延时200-400毫秒，用重传请求的方法，网络传输的延时会更长。

PLC是一个彻底后端的抗丢包方法，有最简单的插值法、过采样法、还有WebRTC比较流行的拉伸和缩短法。WebRTC的这种方法效果不是很好，由于拉长或缩短会改变声音的频率，会产生奇怪的声音，或者改变语速。插值法采用的策略是，第一个包到了，第二个包丢了，第三个包到了，能够经过差值来实现。通常的PLC，能够对抗5%的丢包，再高了就效果很差。

我想重点讲的是FEC，这是一个很大的话题。FEC能够分为两大类：基于信源和基于信道。信源FEC是，包能够多发几遍，对于音频来讲一秒能够发50个包，信源FEC就发两倍100个包，一样大小多发一遍，来实现抗丢包。基于信道的抗丢包是，好比当前的丢包率25%，咱们能够加50%的抗丢包。那么原始有4个包，通过处理生成6个包，这6个包到达任意的4个包，均可以实现准确解码。

信源FEC中，若是采用多发包的方式，会产生新的问题，好比要传输的是16kpbs的语音，丢包时，是发32kpbs的语音，两个16kpbs的都发过去。仍是把它拆成两个8kpbs再发？各有优劣。若是使用两个8kpbs，降低了音质来换取抗丢包性。若是选择32kpbs，保持音质，以前16kpbs下网络丢包假如是10%，带宽变成32kpbs后，丢包状况也会不一样。因此，Opus和Silk的编码器提出一种新方法，采用了降低码率的作法，相似于两个8kbps。在16kbps的音频流中，有4kbps的小包来对前一帧补偿。一旦大的包丢了，就使用小包来进行恢复，可是带来的问题是音频质量降低了。FEC是一种很好的抗丢包方法，可是它的问题是有可能会浪费带宽。使用FEC以后，确实能提升包的到达率，能在有限的延时下把通讯的质量提升。

咱们来看一下FEC的流程。先发出了三个包，从device1发了3个包到device2，packet2丢了，那么此时的丢包率是33%。device2会发一个lossinfo给device1，告诉它丢包率是33%。而后，device1接着发新的包，此时会发双倍，两个packet4，两个packet5。packet4发生丢包，就会被另外一个packet4补偿回来了。这是典型的FEC的流程，但有几个问题：

• loss info自己也可能会丢丢失
• loss info没丢失，但从device 2 到device 1会有延时
• 丢包估计可能不许。丢包率33%，若是扩大窗口多是25%
• 虽然是33%的抗丢包，发冗余包时只能多发一倍，没有办法准确的发33%
• 只丢了packet4，但packet5也发了两遍，这浪费了带宽，没有意义的

若是是多方通讯， device2丢包率33%，可是device3和device4不丢包怎么办？若是全部device都多发了一倍的包，并且码率不上升，确实device2的抗丢包性好了，可是牺牲了device3和device4的质量。若是把码率扩大一倍，全部device的质量都好了，可是浪费了一倍的带宽。

基于这种现状和当前的不少学术研究，咱们提出了一种新的思路：结合信源和信道编码的特色，利用充分包交换网络的特性，基于此，研发出了声网新的编解码器——Agora SOLO™。从通讯原理来讲，信源编码是尽量去追求高压缩比，去冗余。而信道编码是追求强纠错，靠加冗余来实现纠错。Agora SOLO™就是把加冗余和减冗余结合起来，不重要的地方减冗余，重要的地方加冗余。

咱们以上图为例，来看一下Agora SOLO™的抗丢包特色。对全部的接收端，咱们默认都发了这些包。可是，咱们会把包分红两块，一个是packet 1，一个是packet 1’。若是只收到其中一个包，那么就实现一个有限失真的恢复，质量相对稍差。若是packet 2和packet 2’都收到了，那么就两个包合起来，实现一个高质量的解码。也就是说，Agora SOLO™默认就不须要等待对当前网络丢包状态的统计，只须要直接把抗丢包作到编解码内部。这样作的好处是，首先实现了更低的延时，由于它不须要估计信道的状态，直接把包发出去就好。第二是更高质量，收到一个包时质量达到的普通编解码器水平，收到两个包达到高质量编解码水平。第三，这是面向多人环境的。不一样人下行网络不同，丢包不同。第四，策略更简化，使用Agora SOLO™几乎能够不须要再作策略调整。

上图我用ITU NTT的中文测试序列跑的测试结果。我稍微介绍一下，ITU的NTT是标准的编解码器测试序列，里面有26国语言，我这里面只拿出了中文部分。除了荷兰语和俄罗斯语之外，中文是比较难编。由于中文除了通常语言外还有四声。看图第一列，是只收到8kbps的packet1， PESQ的平均分是3.52分。若是只收到packet2，它分数是3.51分。若是packet1和packet2都收到，16kbps时，分数是3.95分。以上是窄带的分数。宽带下的分数，是3.58分，满分是4.5分。这个测试结果能够清晰的看到，只收到1个包时是有限失真的。当两个包都收到时，质量会明显提高。

接下来，咱们来与其它编码器进行比较。上图一个中文的女声序列在不一样的编解码器的比较。第一列是不一样的丢包率，后面各列是不一样编解码器在不一样丢包率下的分数。能够看到在丢包率25%时，Agora SOLO™整整比其它编解码器高出1分。

最后，再来回顾一下Agora SOLO™抗丢包的特色。咱们能够再也不关心网络丢包状态，默认发两个包。若是只收到一个就是有限失真，收到两个就是高质量的恢复。