IP通信中音频编解码技术与抗丢包技术概要
此文较长,建议收藏起来看。
一、一个典型的IP通信模型
二、Server2Server技术分类
Server2Server这块也是一个专门的领域,这里只简单分个类。
1、同一国家相同运营商之间:
同一运营商之间也有丢包,在铁通,鹏博士等运营商中尤甚。并且在晚高峰的时候表现更加突出。
2、同一国家不同运营商之间:
在很多时候,由于运营商之间的结算和有限带宽的问题。运营商之间的网络不稳定。
3、不同国家之间:
同一个国家都这么多问题,不同国家的问题回更复杂,在不同的国家要选择好的机房,实时选择实时监控。比如以下地方。以下地区,我们端到端延时平均为157ms。
中美,中欧
东亚:中,日本,韩国,台湾
其他地区:拉丁美洲,印度,菲律宾,泰国,南非,中东
三、Server2Device——Lastmile技术简介
我们在公网做实时音视频服务,丢包对抗是少不了的。
首先我们定义下什么是丢包:没按时到的包就是丢包。一个包应该在某个时间点到,但它晚到了,即使来了但是晚了,也叫丢包。因为播放的这段时间已经过去了,即使放了,体验也不好。从整个网络上看,丢包一定有时限,否则,都通过反复重传方法,一定能送达一个包。
Server到达device这块还可以分以下两种通路。
1、Server经过基站到Device
可以分为以下几种情况:
不同类型的基站:3G/4G,TD和WDCDMA就不一样。
相同类型的基站不同的地点:北京联通推出流量包月下行最高150kbps的服务
相同基站相同地点不同时间:球赛,运动会,热点聚集区附近的基站
不同国家的基站:中国的WCDMA和印度的WCDMA和美国的WCDMA
2、Server经过家用路由器到Device
2.4G路由和5G路由,2.4G路由覆盖面积广,但是2.4G频段很脏,容易干扰和丢包。5G路由相对好些,但是覆盖面积小。并且在公司内部,会有多个路由,很多人连一个路由。竞争严重,有时网络丢包会很高。并且有些路由器是有bug的,比如小米路由的梳状抖动模型。
四、Device技术简介
AVDM,AVPM,AVCM,AVNM
1、AVDM(Audio Video Device Module):
AVDM是主要针对device的播放,录音录像端做处理的模块。不同的平台会有不同的驱动和录音录像需求,比如XP、Vista、win7、win8。我们不能一概而论的统一选择dshow甚至是waveout来播放还是录音。在移动端、iOS、安卓,安卓本身也有java和opensles两种录音方法,并且还有一系列的配置参数。比如用什么样的参数能录立体声,关闭手机自带处理,录高音质声音,延时低等等。和device相关的还有就是硬件能力:GPU、CPU的能力,对于视频而言,不同的CPU能支持怎么样的视频编解码能力输出。
2、AVPM(Audio Video Processing Module)
AVPM在视频上指美颜、降噪。音频的一般前后后处理包括3A引擎、AEC、ANS、AGC、混音、加混响(音乐直播)、去混响(会议模式)。是否应该用GPU,什么情况下应该用GPU。用GPU是为了省电还是运算快?
3、AVCM(Audio Video Coding Module)
编解码器的选择和处理,视频包括是选择VP8、VP9,还是选择264、265,是用硬件还是用软件,是否涉及专利问题。选择硬件会遇到什么问题,选择软件会遇到什么问题,为什么用硬件会遇到很多参数不能配置的问题。是否需要和硬件厂商配合。安卓碎片化导致的硬件支持问题。高通的硬件支持有什么问题,mtk的硬件支持有什么特点。硬件支持是否还要交专利费。
4、AVNM
音视频的JitterBuffer,FEC,PLC,BWE。Jitterbuffer主要是为了对抗网络抖动,对不熟悉Jitterbuffer的人,早期我们经会听到一种理解,jitter为什么不拉大啊?另外jitterbuffer的设计也是要结合更多的输入才能更好发挥作用。
BWE:带宽估计,用于估计网络的带宽,以便实时调整。但是这里会有两种估计模型,基于RTT和基于丢包,如何选择?
以上每个点都能讲或者写很多内容,本文只做简单梳理、点到为止,以后再做专题分析。
五、IP通信的几种结构
1v1的双工通信结构(交互):最简单的一对一通信,要做好也不容易。
MxM的全双工通信结构(交互): 小型会议。(这块要注意,在移动设备上首先要移动设备的尺寸问题,展示方法和技术要求也有不同,比如多人会议时会有多种layout可能,一大N小,平均分屏)。
1xN的单工通信结构(直播)
MxMxN的单双工混合结构(交互直播)
N的短延时方案,随时交互
N的长延时方案,永不交互(9158实际在比较早的时候就实现了这种技术)。
六、音频编解码器选择与丢包对抗方法介绍
前面概述了基本网络模型和一些技术需求点,下面我针对本次重点做个分享:编解码器的选择和抗丢包技术。这两项技术对整个通信网络都有影响,在不同的网络条件下选择方法也不同。但一般来说,正确的选择编解码器和对应的抗丢包技术对Lastmile和端到端的音频质量影响最大。VOIP通信很早就有了,在不同的时代,我们选择了不同的编解码器实现对音频的传输,我们通常会做下面的分类。
1、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中(华为又要收苹果钱了哦)。
2、直播中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。
3、丢包对抗的几种办法
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
PLCPLC的意义在于当FEC和重传之后还无法恢复的时候,通过信号处理的方法对丢失的数据进行补偿。
分类:
插0法:所谓插0法就是在丢包的位置全添0.
预测法,插值法,快慢放(注意,快慢放有副作用,大家不愿意接受这种做法)
基于编解码模型的PLC方法
特点:被动抗丢包。
优点:灵活不占带宽
缺点:根据编解码器的类型,对抗能力有限对低压缩比的编解码器,可以做到比较高的抗丢包效果。对高压缩比的编解码器,一般看丢包能力在5%以下。
高级PLC算法,盲宽带带宽扩展(BWE),就是把8Khz拓展到16Khz。
七、WebRTC
Webrtc的缘来:WebRTC的前身是GIPS,在GIPS被Google收购之后,google选择将GIPS的源代码开源。但是其实不是全部。只能说绝大部分已经开源。
##1、Webrtc适用于什么条件
包装开发,满足1对1,P2P,Iphone 通信,对质量没有啥要求
二次开发,抽取webrtc的好的部分,自己开发,但是工作量很大
##2、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的音频开发工作。
IP通信中音频编解码技术与抗丢包技术概要相关推荐
- 直播带货平台开发如何实现抗丢包技术
无论对于音频编码还是视频编码而言,对于编解码来说,都有不同的直播带货平台开发应用场景.比较大的两个范围,第一种,面向文件直播的编解码器.第二种,面向网络通信的编解码器. 在不同的应用场景下面,编解码器 ...
- 实时音视频聊天技术分享:面向不可靠网络的抗丢包编解码器
本文整理自声网Agora.io编解码算法工匠高泽华在RTC2017实时互联网大会和QCon上海2017上的技术分享.本文仅讨论技术,无关商业因素,请从技术角度理解文中的分享内容即可,如给您带来误导,请 ...
- 对抗弱网下的音视频难题,声网正式开源抗丢包音频编解码器 Agora SOLO!
近些年,比较火的应用场景有这么几类: 游戏,比如多人在线对战游戏.狼人杀等,多人组队,还需要实时语音: 互动直播,比如主播与观众连麦.主播与其他主播进行跨直播间连麦,需要实时的互动: 在线教育,其中有 ...
- LiveVideoStack线上分享第四季(十二):实时音视频抗丢包的实践
12月26日 19:30,LiveVideoStack线上分享第四季,第十二期,我们邀请到了好视通 音视频开发工程师 何永德分享"好视通"如何通过FEC.NACK .带宽自适应等技 ...
- 电脑ping服务器ip显示数据丢失,Win7系统如何测试网络丢包率解决网页显示不全的问题...
Win7系统在上网过程中打开网页经常遇到网页显示不全,或者玩游戏卡顿的现象,但是过一会儿又恢复了.怎么回事呢?可能是因为网络丢包率太高导致的,我们可以Ping一下网络,找到故障原因.那么接下来小编和大 ...
- 从编解码、传输到基础架构 详解Bigo多媒体技术栈
本文来自Bigo多媒体技术团队的投稿,详细介绍了Bigo多媒体技术的前生今世,通过何种技术手段支撑起了BigoLive.Likee和imo三大业务.技术栈具体涉及编解码.传输.全球基础设施架构等三方面 ...
- 视频技术详解:语音编解码技术演进和应用选型
本文来自现网易云音乐音视频实验室负责人刘华平在LiveVideoStackCon 2017大会上的分享,并由LiveVideoStack整理而成.分享中刘华平以时间为主线,讲述了语音编解码技术的演进路 ...
- 语音编解码技术演进和应用选型
本文来自现网易云音乐音视频实验室负责人刘华平在LiveVideoStackCon 2017大会上的分享,并由LiveVideoStack整理而成.分享中刘华平以时间为主线,讲述了语音编解码技术的演进路 ...
- 浅谈视频监控行业编解码技术的发展与应用
本文转自 浙江大华技术股份有限公司产品经理 张龙彪 视频监控技术经过多年的发展,监控画面正经历着从最初的D1标清图像,向4K高清.8K超清时代前进.由于CCD与CMOS技术的发展,前端摄像机的像素越 ...
最新文章
- 前端小项目之在线便利贴
- Linux很有用的根据字符串查找符合条件的命令
- Web前端开发笔记——第二章 HTML语言 第十节 画布标签、音视频标签
- 快速排序详解以及java实现
- 工作62:显示省略号
- postman怎么不登陆使用_最新百度云不限速,免安装、免登陆、不限速,打开网站就能使用...
- 【Spark】Spark基本概念
- 神经网络中常用激活函数总结【Python实现激活函数与导函数,曲线可视化分析】
- php调用empty报错
- A Game of Thrones(109)
- 2021年终总结——脚踏实地,为下一次腾飞积蓄力量
- [技术讨论]关于前几天公布的京东bug上的问题分析
- 什么是边界扫描(boundary scan)?
- 自然语言处理系列五》新词发现与短语提取》短语提取
- ST、SC、FC、LC光纤接头区别?
- WIN10 EXCEL 快捷键
- 安全框架-SpringSecurity
- zbb20180929 zk Zookeeper的功能以及工作原理
- 【STM32F4系列】【HAL库】【自制库】RDA5807M收音机芯片驱动
- 2019/08/09 zookeeper基础概念(01)
热门文章
- Fisher Vector费舍尔向量and FIsher Kernel费舍尔核
- 乐清高考2021成绩查询,2021年乐清高考状元名单公布,乐清文理科状元是谁多少分...
- (19)全民小视频引流脚本模块化开发13-界面构建与功能整合By飞云脚本学院
- 基于表格的CRC校验码实现
- 【AcWing周赛】AcWing第85场周赛
- C#面向对象Chatbot智能版
- 差分方程模型(一):模型介绍与Z变换
- starcraft2 html 资源,最新HTML5版星际争霸完全版源码
- HashMap面试题,看这一篇就够了!
- 大数据技术之Canal入门篇