IP通讯中音频编解码技术与抗丢包技术概要

此文较长，建议收藏起来看。

1、一个典型的IP通讯模型

2、Server2Server技术分类

Server2Server这块也是一个专门的领域，这里只简单分个类。

一、同一国家相同运营商之间：

同一运营商之间也有丢包，在铁通，鹏博士等运营商中尤甚。而且在晚高峰的时候表现更加突出。

二、同一国家不一样运营商之间：

在不少时候，因为运营商之间的结算和有限带宽的问题。运营商之间的网络不稳定。

三、不一样国家之间：

同一个国家都这么多问题，不一样国家的问题回更复杂，在不一样的国家要选择好的机房，实时选择实时监控。好比如下地方。如下地区，咱们端到端延时平均为157ms。

• 中美，中欧

• 东亚：中，日本，韩国，台湾

• 其余地区：拉丁美洲，印度，菲律宾，泰国，南非，中东

3、Server2Device——Lastmile技术简介

咱们在公网作实时音视频服务，丢包对抗是少不了的。

首先咱们定义下什么是丢包：没按时到的包就是丢包。一个包应该在某个时间点到，但它晚到了，即便来了可是晚了，也叫丢包。由于播放的这段时间已通过去了，即便放了，体验也很差。从整个网络上看，丢包必定有时限，不然，都经过反复重传方法，必定能送达一个包。

Server到达device这块还能够分如下两种通路。

一、Server通过基站到Device

能够分为如下几种状况：

• 不一样类型的基站：3G/4G,TD和WDCDMA就不同。

• 相同类型的基站不一样的地点：北京联通推出流量包月下行最高150kbps的服务

• 相同基站相同地点不一样时间：球赛，运动会，热点汇集区附近的基站

• 不一样国家的基站:中国的WCDMA和印度的WCDMA和美国的WCDMA

二、Server通过家用路由器到Device

2.4G路由和5G路由，2.4G路由覆盖面积广，可是2.4G频段很脏，容易干扰和丢包。5G路由相对好些，可是覆盖面积小。而且在公司内部，会有多个路由，不少人连一个路由。竞争严重，有时网络丢包会很高。而且有些路由器是有bug的，好比小米路由的梳状抖动模型。

4、Device技术简介

AVDM，AVPM，AVCM，AVNM

一、AVDM(Audio Video Device Module)：

AVDM是主要针对device的播放，录音录像端作处理的模块。不一样的平台会有不一样的驱动和录音录像需求，好比XP、Vista、win七、win8。咱们不能一律而论的统一选择dshow甚至是waveout来播放仍是录音。在移动端、iOS、安卓，安卓自己也有java和opensles两种录音方法，而且还有一系列的配置参数。好比用什么样的参数能录立体声，关闭手机自带处理，录高音质声音，延时低等等。和device相关的还有就是硬件能力：GPU、CPU的能力，对于视频而言，不一样的CPU能支持怎么样的视频编解码能力输出。

二、AVPM(Audio Video Processing Module)

AVPM在视频上指美颜、降噪。音频的通常先后后处理包括3A引擎、AEC、ANS、AGC、混音、加混响（音乐直播）、去混响（会议模式）。是否应该用GPU，什么状况下应该用GPU。用GPU是为了省电仍是运算快？

三、AVCM(Audio Video Coding Module)

编解码器的选择和处理，视频包括是选择VP八、VP9，仍是选择26四、265，是用硬件仍是用软件，是否涉及专利问题。选择硬件会遇到什么问题，选择软件会遇到什么问题，为何用硬件会遇到不少参数不能配置的问题。是否须要和硬件厂商配合。安卓碎片化致使的硬件支持问题。高通的硬件支持有什么问题，mtk的硬件支持有什么特色。硬件支持是否还要交专利费。

四、AVNM

音视频的JitterBuffer，FEC，PLC，BWE。
Jitterbuffer主要是为了对抗网络抖动，对不熟悉Jitterbuffer的人，早期咱们经会听到一种理解，jitter为何不拉大啊？另外jitterbuffer的设计也是要结合更多的输入才能更好发挥做用。

BWE：带宽估计，用于估计网络的带宽，以便实时调整。可是这里会有两种估计模型，基于RTT和基于丢包，如何选择？

以上每一个点都能讲或者写不少内容，本文只作简单梳理、点到为止，之后再作专题分析。

5、IP通讯的几种结构

1. 1v1的双工通讯结构（交互）：最简单的一对一通讯，要作好也不容易。

2. MxM的全双工通讯结构（交互）: 小型会议。（这块要注意，在移动设备上首先要移动设备的尺寸问题，展现方法和技术要求也有不一样，好比多人会议时会有多种layout可能，一大N小，平均分屏）。

3. 1xN的单工通讯结构（直播）

4. MxMxN的单双工混合结构（交互直播）

5. N的短延时方案，随时交互

6. N的长延时方案，永不交互（9158实际在比较早的时候就实现了这种技术）。

6、音频编解码器选择与丢包对抗方法介绍

前面概述了基本网络模型和一些技术需求点，下面我针对本次重点作个分享：编解码器的选择和抗丢包技术。这两项技术对整个通讯网络都有影响，在不一样的网络条件下选择方法也不一样。但通常来讲，正确的选择编解码器和对应的抗丢包技术对Lastmile和端到端的音频质量影响最大。VOIP通讯很早就有了，在不一样的时代，咱们选择了不一样的编解码器实现对音频的传输，咱们一般会作下面的分类。

一、VOIP通讯中Codec选择的几个时代。

1）ITU Gxxx时代：G711，G722，G723.1，G729ab等等

G711主要用在移动通讯基站和基站之间的包交换网络中，而且在有些提供VOIP服务的监控摄像头上使用。64kbps，8khz压缩。

G722系列包括G722,G722.1,G722.2。是针对WB，16khz和SWB 32khz的压缩算法。比较著名的是G722.1 也就是Polycom的Siren Codec，他的特色语音编解码为数很少的频域编码框架，不只对语音支持比较好，对音乐支持也还能够。在Polycom的VOIP设备中一般支持该编解码器。

G722.2就是AMR-WB+，是32khz语音编解码器，同时支持音乐编码，是AMR-WB的超宽带版本，可是因为他前向兼容AMR系列的框架，内核选择了CELP编解内核，对音乐编码有先天的问题

2）AMRNB/WB，Speex，ILBC/ISAC，SILK时代

AMR系列：做为8kbps~12kbps的语音编解码器，在一段时间内，质量是不错的，毕竟他是WCDMA和TDCDMA标准选择的语音编解码器。也经过3GPP标准开源。在有一段时间Yy语音和QTalk，微信语音留言都使用了AMR编解码器。可是他的问题是，有专利费，固定比特率。抗丢包性能通常。

• Speex：Speex是由Jean Marc Valin（也是CELT的主要发明人）开发的编解码器，特色是免专利费，开源。支持宽带超宽带。缺点是这个编解码器多是为了避开专利，而且受限于不少因素，编码质量并很差。不管是窄带宽带超宽带，对抗丢包，质量都很通常。可是这也是站在今天的角度看当时的技术，而且在当时可以提供免专利费的全频带，低速率（16kbps左右）语音编解码器确实没有，能够说，Speex填补了空白。而且Speex有一个显著特色是，Speex实际上不是一个编解码器，是一个音频处理集。包括AGC，AEC，ANS。能够完整的应用在一个VOIP通讯系统中，而且他的AEC的自适应滤波部分作的至关不错，在PC上能够拿来使用。

• ILBC和ISAC：ILBC编解码器是GIPS（WebRTC前身）第一个开源出来的编解码器。8khz，13.3kbps。窄带编解码器。他的特色是，抗丢包性好。信源编码的基础是去冗余，信道编码的基础是加冗余。去冗余的弊端就是抗丢包差，因此ILBC反其道行之，减小帧间冗余的压缩，增长每一个帧独立性，使得当发生丢包的时候，丢包对抗效果好。ILBC在部分呼叫中心公司有普遍应用。ISAC是在GIPS被收购以后伴随WebRTC开源的编解码器，他的特色是支持16khz，24khz，32khz。支持带宽估计（这是不少语音编解码器不具有的）。而且他不是基于CELP框架，使用了频域编码框架+格型编码+算数编码的框架。具备必定特殊性。ISAC继承了ILBC的抗丢包优势，可是缺点也至关突出，因为用了频域编码器，高频语音编码效果很差，听起来有金属音，PESQ-WB MOS分低。

• SILK：SILK面世时代比较晚，是以上编解码器中最晚开发一个编解码器。他的发明人是Ken Vos，也是ILBC，ISAC的主要开发者。Ken VOS在离开GIPS以后去了高通，为高通开发了一个宽带编解码器。而后到Skype为Skype开发SILK。Skpye有一段时间也是使用GIPS的方案，用ILBC和ISAC。后面本身开发Codec，他们第一个本身的Codec是VSOPC(好像，这里缺一个wiki的连接)。可是质量不好，用户抱怨。故请来了Vos开发SILK。Vos又在Skpye尝试新框架，Vos的SILK使用了预测加噪声整形的混合框架（第一使用相似框架的是Broadcom的BV16，BV32编解码器）。使用STP+LTP+STNS+LTNS两层后反馈嵌套（BV16和BV32是一个前馈+一个后馈，这里差图和wiki连接）。而且引入Delay Decision量化搜索方法，使得标量量化具备矢量量化的性能指标。能够说SILK的质量是很是好的一个编解码器。（这里差一个表），不管主观仍是客观。虽然他充分挖掘相关性，但因为作到极致和很是完美，使得在丢包对抗上有必定帮助。而且他开发了RED辅助编码算法，提升他的抗丢包能力。

我我的，是很是推荐初级和中级算法工程师仔细阅读SILK编解码器，代码质量好（EE工程师中少见），而且用了不少基础算法，不少小技巧，甚至包括自动控制理论。对提高本身的能力颇有帮助。

3）Opus/EVS时代

Opus在2012年横空出世，按照官网的说法，opus比HEAAC好，并给了一些demo。但事实真的是这样吗，Opus是由SILK+CELT混合的编码器，学术上的叫法叫作USAC，Unify Speech and Audio Coding。这点，EVS也是。意思是不区分音乐语音的编解码器。这个编解码器内有个一Music detector去判断当前帧是语音仍是音乐，语音选择语言框架编码，音乐选择音乐框架编码（注意目前尚未统一框架，缘由是框架通常是人体生理模拟，由于人有两个声学器官，嘴和耳朵，因此语音是针对声带，口腔，鼻腔见面，音乐是根据人耳朵结构的时间掩蔽，频域掩蔽，双耳暗示效益编码）。因此，Opus适合电台这种音乐语音混合编码器。可是因为Opus的音乐编码CELT的质量并不突出，因此Opus在双声道低速率（24kbps~32kbps左右）效果并不突出。在网站上的demo缺乏钢琴，爵士，摇滚的demo。更可能是流行音乐和民谣。高频份量相对弱些。但若是使用Opus有如下要注意事情，音频码率高些，不要限制编码器的模式。另外高通宣称有OPUS专利，来自大神Ken VOS。
EVS 主要是VoiceAge公司，Dolby公司，Fraunhofer，华为（北京苗磊兄弟，羡慕大家）联合开发的USAC编码器（这里面也有故事，和技术无关，我就不八卦了），低速率音乐编码器质量很好，源自dolby和Fraunhofer的HEAACv2技术。可是问题是，目前没有高效的嵌入式系统可用的编码器，不支持双声道，专利费不便宜哦。主要计划用在将来的VoLTE中（华为又要收苹果钱了哦）。

二、直播中Codec选择

1）AAC系列与Opus
没什么好说的，音乐电台能够选择Opus，主流的仍是AAC，注意，建议立体声使用HE-AACv2，单声道选择HE-AACv1。而不是通常的AAC。HE-AACv1 = AAC + SBR,HE-AACv2 = HE-AACv1+ PS.
AAC的合理编解码质量是在双声道64kbps~128kbps（商用编解码器和标准参考代码是不同质量的，请区分）。HE-AACv1的合理编解码器区间是双声道40kbps~64kbps。HE-AACv2的合理编解码器区间是双声道24kbps到48kbps。

三、丢包对抗的几种办法

1）重传：

传统物理信道传输中，不管是802.11仍是3g/4g标准，自己就包含物理层重传机制，在IP信道中，重传也是很是有效的方法。
优势：节省带宽，按需重传。
约束条件，RTT时间短

2）FEC：

FEC有不少种，主要特色是主动抗丢包，经过增长冗余数据实现抗丢包效果。缺点是浪费带宽。通常的说，只有在丢包大于10%的时候才使用FEC。FEC技术有如下分类方法。

• 不分级的FEC

• 信源FEC

• Inband FEC

• Outband FEC

• 信道FEC

• Read SolomonCode

• DigitalFountain Code

• 分级的FEC

• PLC
  PLC的意义在于当FEC和重传以后还没法恢复的时候，经过信号处理的方法对丢失的数据进行补偿。

分类：

• 插0法：所谓插0法就是在丢包的位置全添0.

• 预测法，插值法，快慢放（注意，快慢放有反作用，你们不肯意接受这种作法）

• 基于编解码模型的PLC方法

  • 特色：被动抗丢包。

  • 优势：灵活不占带宽

  • 缺点：根据编解码器的类型，对抗能力有限
    对低压缩比的编解码器，能够作到比较高的抗丢包效果。对高压缩比的编解码器，通常看丢包能力在5%如下。

• 高级PLC算法，盲宽带带宽扩展(BWE)，就是把8Khz拓展到16Khz。

7、WebRTC

Webrtc的缘来：WebRTC的前身是GIPS，在GIPS被Google收购以后，google选择将GIPS的源代码开源。可是其实不是所有。只能说绝大部分已经开源。
##一、Webrtc适用于什么条件
包装开发，知足1对1，P2P，Iphone 通讯，对质量没有啥要求
二次开发，抽取webrtc的好的部分，本身开发，可是工做量很大
##二、Webrtc的问题

1）P2P的问题

WebRTC使用的是P2P的方法进行网络传输，并宣称保密性好。P2P在通讯中Skype使用的比较早，有人曾经在网上分析过Skype全球有21个节点。其他都用P2P传输。可是这个前提是当时Skype大部分是基于PC+LAN/WIFI网络。适用于一对一通讯，容易穿透，用户流量没限制，CPU稳定。而在Skype向手机普及，在无线网上提供VOIP服务的时候，增长了大量服务器路由。
缺点：占用别人流量，不适合在多人通讯中，要求网络稳定。
优势：适用于demo。

2）Lastmile的问题

在lastmile对抗上，webrtc的对抗过于死板，缺乏对现网的监控与反馈，虽然在webrtc内部有大量的不错的算法，可是缺乏有机适用，好比，有些参数仍是针对有线网设计的参数。

3）Device 的回声消除

安卓的碎片化，和回声消除的固有特色使得WebRTC在移动端没法知足让全部机型都处理的很好。

4）若是你想用webrtc开发你要作什么

架设服务器，监控，运维，客服。

Lastmile网络对抗，本身作策略AVNM，前面描述了不少种网络状态，要靠单一的方法是没法知足全面作好，须要复杂的数据挖掘，分析，整理再反馈网络策略参数调整才能够完成。
端的AV-D/C/P/-M算法，本身要作AV的硬件机型配置，选择和改进。须要在安卓机型作大量的回声消除算法改进。

【本文做者】高泽华，11年音乐语音编解码学习经验。理解几十种音频编解码标准。前后在中磊电子、士兰微电子、虹软科技主导音频项目。任职YY期间负责语音音频技术工做。对音频算法在芯片设计、嵌入式系统、桌面软件。在互联网应用和专利分析方面有多年研发经验和积累。目前负责声网Agora.io的音频开发工做。