默认
打赏 发表评论 9
想开发IM:买成品怕坑?租第3方怕贵?找开源自已撸?尽量别走弯路了... 找站长给点建议
即时通讯音视频开发(八):常见的实时语音通讯编码标准
阅读(150202) | 评论(9 收藏4 淘帖1
微信扫一扫关注!

前言


即时通讯应用中的实时音视频技术,几乎是IM开发中的最后一道高墙。原因在于:实时音视频技术 = 音视频处理技术 + 网络传输技术 的横向技术应用集合体,而公共互联网不是为了实时通信设计的。有关实时音视频开发时的技术难题请参见《音视频云声网Agora:从demo到实用,中间还差1万个WebRTC》:http://www.52im.net/article-119-1.html

本文是一篇讲述常用的实用音频通讯编码标准的文章。

系列文章


本文是系列文章中的第8篇,本系列文章的大纲如下:


内容概述


视频通讯过程是视频和音频的实时双向完整通讯过程。在这个过程中我们为了获得高清晰视频图像,有时却忽略了另外一个重要的过程——音频通讯过程。如果我们在观看高清晰视频图像的时候,不能得到一个更清晰、连续的音频效果。那么这个过程实际上就没有任何意义,所以其重要性甚至超过视频。

在传统的视频会议系统、即时通讯聊天系统中音频技术发展极其缓慢,原因在于目前应用于视频通讯的音频编解码压缩标准都是为了保持传输时的低带宽占用和较高的编解码效率,从而将音频信号的采样频率、采样精度和采样范围指标做了极大的降低,使得所能提供的音频清晰度和还原性都有很大程度上的衰减。与用于存储和回放非实时压缩协议的标准(如OGG、MP3等)相比,音频的保真度非常低。这样就在某种程度上对现场声音的还原达不到要求。

目前传统视频通讯过程中主要采用的是G.711、G.722、G.721、G.728等音频标准,音频宽度仅有50Hz-7KHz单声道,而人耳所能感知的自然界的频响能力可以达到20Hz-20KHz,因此,在对现场环境音的还原过程中过多的音频信息的丢失造成了无法真实表现现场情况。所以在高清晰视频通讯过程中我们势必要有一种相辅助的音频处理方式解决此问题。使整个高清晰通讯过程更去近于完美。

目前国际上对音频处理技术上标准较多,在对下一代实时交互音频处理上可以采用MPEG-1 Layer 2或AAC系列音频,对选用标准的原则是,音频频响范围要达到22KHz,这样就几乎可以覆盖了人耳听觉的全部范围,甚至在高频方面还有所超越,能够使现场音频得到真实自然的还原,并且在还原时可以采用双声道立体声回放,使整个视频通讯的声音有更强的临近感,达到CD级音质。同时在对链路带宽的适应和编解码效率上达到最佳。

以下是各种音频编码标准的说明。

实时音频通讯编码标准:G.711


类型:Audio
制定者:ITU-T
所需频宽:64Kbps
特性:算法复杂度小,音质一般
优点:算法复杂度低,压缩比小(CD音质>400kbps),编解码延时最短(相对其它技术)
缺点:占用的带宽较高
备注:70年代CCITT公布的G.711 64kb/s脉冲编码调制PCM。

实时音频通讯编码标准:G.721


制定者:ITU-T
所需带宽:32Kbps
音频频宽:3.4KHZ
特性:相对于PCMA和PCMU,其压缩比较高,可以提供2:1的压缩比。
优点:压缩比大
缺点:声音质量一般
备注:子带ADPCM(SB-ADPCM)技术。G.721标准是一个代码转换系统。它使用ADPCM转换技术,实现64 kb/s A律或μ律PCM速率和32 kb/s速率之间的相互转换。

实时音频通讯编码标准:G.722


制定者:ITU-T
所需带宽:64Kbps
音频宽度:7KHZ
特性:G722能提供高保真的语音质量
优点:音质好
缺点:带宽要求高
备注:子带ADPCM(SB-ADPCM)技术

实时音频通讯编码标准:G.722.1


制定者:ITU-T
所需带宽:32Kbps/24Kbps
音频宽度:7KHZ
特性:可实现比G.722 编解码器更低的比特率以及更大的压缩。目标是以大约一半的比特率实现  G.722 大致相当的质量。
优点:音质好
缺点:带宽要求高
备注:目前大多用于电视会议系统。

实时音频通讯编码标准:G.721附录C


制定者:ITU-T
所需带宽:48Kbps/32Kbps/4Kbps
音频宽度:14KHZ
特性:采用自Polycom 的Siren™14 专利算法,与早先的宽频带音频技术相比具有突破性的优势,提供了低时延的14 kHz 超宽频带音频,而码率不到MPEG4 AAC-LD 替代编解码器的一半,同时要求的运算能力仅为十分之一到二十分之一,这样就留出了更多的处理器周期来提高视频质量或者运行因特网应用程序,并且移动设备上的电池续航时间也可延长。
优点:音质更为清晰,几乎可与CD 音质媲美,在视频会议等应用中可以降低听者的疲劳程度。
缺点:是Polycom的专利技术。
备注:目前大多用于电视会议系统

实时音频通讯编码标准:G.723(低码率语音编码算法)


制定者:ITU-T
所需带宽:5.3Kbps/6.3Kbps
音频宽度:3.4KHZ
特性:语音质量接近良,带宽要求低,高效实现,便于多路扩展,可利用C5402片内16kRAM实现53coder。达到ITU-TG723要求的语音质量,性能稳定。可用于IP电话语音信源编码或高效语音压缩存储。
优点:码率低,带宽要求较小。并达到ITU-TG723要求的语音质量,性能稳定。
缺点:声音质量一般
备注:G.723语音编码器是一种用于多媒体通信,编码速率为5.3kbits/s和6.3kbit/s的双码率编码方案。G.723标准是国际电信联盟(ITU)制定的多媒体通信标准中的一个组成部分,可以应用于IP电话等系统中。其中,5.3kbits/s码率编码器采用多脉冲最大似然量化技术(MP-MLQ),6.3kbits/s码率编码器采用代数码激励线性预测技术。

实时音频通讯编码标准:G.723.1(双速率语音编码算法)


制定者:ITU-T
所需带宽:5.3Kbps(29)
音频宽度:3.4KHZ
特性:能够对音乐和其他音频信号进行压缩和解压缩,但它对语音信号来说是最优的。G.723.1采用了执行不连续传输的静音压缩,这就意味着在静音期间的比特流中加入了人为的噪声。除了预留带宽之外,这种技术使发信机的调制解调器保持连续工作,并且避免了载波信号的时通时断。
优点:码率低,带宽要求较小。并达到ITU-TG723要求的语音质量,性能稳定,避免了载波信号的时通时断。
缺点:语音质量一般
备注:G.723.1算法是ITU-T建议的应用于低速率多媒体服务中语音或其它音频信号的压缩算法,其目标应用系统包括H.323、H.324等多媒体通信系统 。目前该算法已成为IP电话系统中的必选算法之一。

实时音频通讯编码标准:G.728


制定者:ITU-T
所需带宽:16Kbps/8Kbps
音频宽度:3.4KHZ
特性:用于IP电话、卫星通信、语音存储等多个领域。G.728是一种低时延编码器,但它比其它的编码器都复杂,这是因为在编码器中必须重复做50阶LPC分析。G.728还采用了自适应后置滤波器来提高其性能。
优点:后向自适应,采用自适应后置滤波器来提高其性能
缺点:比其它的编码器都复杂
备注:G.728 16kb/s短延时码本激励线性预测编码(LD-CELP)。1996年ITU公布了G.728 8kb/s的CS-ACELP算法,可以用于IP电话、卫星通信、语音存储等多个领域。16 kbps G.728低时延码激励线性预测。

G.728是低比特线性预测合成分析编码器(G.729和G.723.1)和后向ADPCM编码器的混合体。G.728是LD-CELP编码器,它一次只处理5个样点。对于低速率(56~128 kbps)的综合业务数字网(ISDN)可视电话,G.728是一种建议采用的语音编码器。由于其后向自适应特性,因此G.728是一种低时延编码器,但它比其它的编码器都复杂,这是因为在编码器中必须重复做50阶LPC分析。G.728还采用了自适应后置滤波器来提高其性能。

实时音频通讯编码标准:G.729


制定者:ITU-T
所需带宽:8Kbps
音频宽度:3.4KHZ
特性:在良好的信道条件下要达到长话质量,在有随机比特误码、发生帧丢失和多次转接等情况下要有很好的稳健性等。这种语音压缩算法可以应用在很广泛的领域中,包括IP电话、无线通信、数字卫星系统和数字专用线路。

G.729算法采用“共轭结构代数码本激励线性预测编码方案”(CS-ACELP)算法。这种算法综合了波形编码和参数编码的优点,以自适应预测编码技术为基础,采用了矢量量化、合成分析和感觉加权等技术。

G.729编码器是为低时延应用设计的,它的帧长只有10ms,处理时延也是10ms,再加上5ms的前视,这就使得G.729产生的点到点的时延为25ms,比特率为8 kbps。
优点:语音质量良,应用领域很广泛,采用了矢量量化、合成分析和感觉加权,提供了对帧丢失和分组丢失的隐藏处理机制。
缺点:在处理随机比特错误方面性能不好。
备注:国际电信联盟(ITU-T)于1995年11月正式通过了G.729。ITU-T建议G.729也被称作“共轭结构代数码本激励线性预测编码方案”(CS-ACELP),它是当前较新的一种语音压缩标准。G.729是由美国、法国、日本和加拿大的几家著名国际电信实体联合开发的。

实时音频通讯编码标准:G.729A


制定者:ITU-T
所需带宽:8Kbps(34.4)
音频宽度:3.4KHZ
特性:复杂性较G.729低,性能较G.729差。
优点:语音质量良,降低了计算的复杂度以便于实时实现,提供了对帧丢失和分组丢失的隐藏处理机制
缺点:性能较G.729差
备注:96年ITU-T又制定了G.729的简化方案G.729A,主要降低了计算的复杂度以便于实时实现,因此目前使用的都是G.729A。

实时音频通讯编码标准:MPEG-1 audio layer 1


制定者:MPEG
所需带宽:384kbps(压缩4倍)
音频宽度:
特性:编码简单,用于数字盒式录音磁带,2声道,VCD中使用的音频压缩方案就是MPEG-1层Ⅰ。
优点:压缩方式相对时域压缩技术而言要复杂得多,同时编码效率、声音质量也大幅提高,编码延时相应增加。可以达到“完全透明”的声音质量(EBU音质标准)
缺点:频宽要求较高
备注:MPEG-1声音压缩编码是国际上第一个高保真声音数据压缩的国际标准,它分为三个层次:
--层1(Layer 1):编码简单,用于数字盒式录音磁带
--层2(Layer 2):算法复杂度中等,用于数字音频广播(DAB)和VCD等
--层3(Layer 3):编码复杂,用于互联网上的高质量声音的传输,如MP3音乐压缩10倍

实时音频通讯编码标准:MPEG-1 audio layer 2,即MP2


制定者:MPEG
所需带宽:256~192kbps(压缩6~8倍)
音频宽度:
特性:算法复杂度中等,用于数字音频广播(DAB)和VCD等,2声道,而MUSICAM由于其适当的复杂程度和优秀的声音质量,在数字演播室、DAB、DVB等数字节目的制作、交换、存储、传送中得到广泛应用。
优点:压缩方式相对时域压缩技术而言要复杂得多,同时编码效率、声音质量也大幅提高,编码延时相应增加。可以达到“完全透明”的声音质量(EBU音质标准)
缺点:无记录
备注:同MPEG-1 audio layer 1

实时音频通讯编码标准:MPEG-1 audio layer 3(MP3)


制定者:MPEG
所需带宽:128~112kbps(压缩10~12倍)
音频宽度:无记录
特性:编码复杂,用于互联网上的高质量声音的传输,如MP3音乐压缩10倍,2声道。MP3是在综合MUSICAM和ASPEC的优点的基础上提出的混合压缩技术,在当时的技术条件下,MP3的复杂度显得相对较高,编码不利于实时,但由于MP3在低码率条件下高水准的声音质量,使得它成为软解压及网络广播的宠儿。
优点:压缩比高,适合用于互联网上的传播
缺点:MP3在128KBitrate及以下时,会出现明显的高频丢失
备注:同MPEG-1 audio layer 1

实时音频通讯编码标准:MPEG-2 audio layer


制定者:MPEG
所需带宽:与MPEG-1层1,层2,层3相同
音频宽度:无记录
特性:MPEG-2的声音压缩编码采用与MPEG-1声音相同的编译码器,层1, 层2和层3的结构也相同,但它能支持5.1声道和7.1声道的环绕立体声。
优点:支持5.1声道和7.1声道的环绕立体声
缺点: 无记录
备注:MPEG-2的声音压缩编码采用与MPEG-1声音相同的编译码器,层1, 层2和层3的结构也相同,但它能支持5.1声道和7.1声道的环绕立体声。

实时音频通讯编码标准:AAC-LD (Advanced Audio Coding,先进音频编码)


制定者:MPEG
所需带宽:48-64 kbps
音频宽度:22KHZ
特性:提供高质量的低延时的音频编码标准,以其20ms的算法延时提供更高的比特率和各种声音信号的高质量音频。
缺点:无记录
备注:超宽带编解码器技术支持高达48KHz采样率的语音传输,与传统的窄带与宽带语音编解码器相比大幅提高了音质。该技术可提供接近CD音质的音频,数据速率高达48–64kbps,不仅提高了IP语音与视频应用的清晰度,而且支持电话音乐传输功能。高清语音通道支持更高的采样率,配合音频编解码器的高保真音效,显著丰富并扩展了频谱两端的音质范围,有效改善了语音回响性能,提高了清晰度。

附录:更多实时音视频技术文章


[1] 开源实时音视频技术WebRTC的文章:
开源实时音视频技术WebRTC的现状
简述开源实时音视频技术WebRTC的优缺点
访谈WebRTC标准之父:WebRTC的过去、现在和未来
良心分享:WebRTC 零基础开发者教程(中文)[附件下载]
WebRTC实时音视频技术的整体架构介绍
新手入门:到底什么是WebRTC服务器,以及它是如何联接通话的?
WebRTC实时音视频技术基础:基本架构和协议栈
浅谈开发实时视频直播平台的技术要点
[观点] WebRTC应该选择H.264视频编码的四大理由
基于开源WebRTC开发实时音视频靠谱吗?第3方SDK有哪些?
开源实时音视频技术WebRTC中RTP/RTCP数据传输协议的应用
简述实时音视频聊天中端到端加密(E2EE)的工作原理
实时通信RTC技术栈之:视频编解码
开源实时音视频技术WebRTC在Windows下的简明编译教程
网页端实时音视频技术WebRTC:看起来很美,但离生产应用还有多少坑要填?
了不起的WebRTC:生态日趋完善,或将实时音视频技术白菜化
腾讯技术分享:微信小程序音视频与WebRTC互通的技术思路和实践
融云技术分享:基于WebRTC的实时音视频首帧显示时间优化实践
>> 更多同类文章 ……

[2] 实时音视频开发的其它精华资料:
实时语音聊天中的音频处理与编码压缩技术简述
网易视频云技术分享:音频处理与压缩技术快速入门
学习RFC3550:RTP/RTCP实时传输协议基础知识
基于RTMP数据传输协议的实时流媒体技术研究(论文全文)
声网架构师谈实时音视频云的实现难点(视频采访)
浅谈开发实时视频直播平台的技术要点
还在靠“喂喂喂”测试实时语音通话质量?本文教你科学的评测方法!
实现延迟低于500毫秒的1080P实时音视频直播的实践分享
移动端实时视频直播技术实践:如何做到实时秒开、流畅不卡
如何用最简单的方法测试你的实时音视频方案
技术揭秘:支持百万级粉丝互动的Facebook实时视频直播
简述实时音视频聊天中端到端加密(E2EE)的工作原理
移动端实时音视频直播技术详解(一):开篇
移动端实时音视频直播技术详解(二):采集
移动端实时音视频直播技术详解(三):处理
移动端实时音视频直播技术详解(四):编码和封装
移动端实时音视频直播技术详解(五):推流和传输
移动端实时音视频直播技术详解(六):延迟优化
理论联系实际:实现一个简单地基于HTML5的实时视频直播
IM实时音视频聊天时的回声消除技术详解
浅谈实时音视频直播中直接影响用户体验的几项关键技术指标
如何优化传输机制来实现实时音视频的超低延迟?
首次披露:快手是如何做到百万观众同场看直播仍能秒开且不卡顿的?
Android直播入门实践:动手搭建一套简单的直播系统
网易云信实时视频直播在TCP数据传输层的一些优化思路
实时音视频聊天技术分享:面向不可靠网络的抗丢包编解码器
P2P技术如何将实时视频直播带宽降低75%?
专访微信视频技术负责人:微信实时视频聊天技术的演进
腾讯音视频实验室:使用AI黑科技实现超低码率的高清实时视频聊天
微信团队分享:微信每日亿次实时音视频聊天背后的技术解密
近期大热的实时直播答题系统的实现思路与技术难点分享
福利贴:最全实时音视频开发要用到的开源工程汇总
七牛云技术分享:使用QUIC协议实现实时视频直播0卡顿!
实时音视频聊天中超低延迟架构的思考与技术实践
理解实时音视频聊天中的延时问题一篇就够
实时视频直播客户端技术盘点:Native、HTML5、WebRTC、微信小程序
写给小白的实时音视频技术入门提纲
微信多媒体团队访谈:音视频开发的学习、微信的音视频技术和挑战等
腾讯技术分享:微信小程序音视频技术背后的故事
微信多媒体团队梁俊斌访谈:聊一聊我所了解的音视频技术
新浪微博技术分享:微博短视频服务的优化实践之路
实时音频的混音在视频直播应用中的技术原理和实践总结
以网游服务端的网络接入层设计为例,理解实时通信的技术挑战
腾讯技术分享:微信小程序音视频与WebRTC互通的技术思路和实践
新浪微博技术分享:微博实时直播答题的百万高并发架构实践
技术干货:实时视频直播首屏耗时400ms内的优化实践
爱奇艺技术分享:轻松诙谐,讲解视频编解码技术的过去、现在和将来
零基础入门:实时音视频技术基础知识全面盘点
实时音视频面视必备:快速掌握11个视频技术相关的基础概念
淘宝直播技术干货:高清、低延时的实时视频直播技术解密
>> 更多同类文章 ……

(原文链接:点此进入

即时通讯网 - 即时通讯开发者社区! 来源: - 即时通讯开发者社区!

本帖已收录至以下技术专辑

推荐方案
评论 9
引用:文件助手 发表于 2021-02-13 17:54
文中 "dvanced Audio Coding" 前面少了一个字母 A

已修订,看的太仔细了。。
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部