聊聊多人语音通话的基本原理( 二 )


聊聊多人语音通话的基本原理

文章插图
 
5.音频编码技术
语音编码是一种将语音数字信号压缩的技术 。由于数字化的语音信号在存储、传输上的可靠性、抗干扰能力和保密性都远优于模拟的语音信号,因此,目前几乎在所有的系统中都采用数字化的方式进行语音的存储和传输 。未经过压缩的语音数据因为体积过大,受限于存储设备的容量和传输网络的带宽,不适合直接进行存储和网络传输,音频编码技术应运而生 。音频编码技术可以大大的压缩音频数据的体积,减少了存储消耗的硬件资源与传输占用的带宽和时间,增加了在有限的资源下可以存储和传输的语音数据量 。
根据是否保留原始音频数据的全部信息,音频编码技术通常被分为有损音频编码技术和无损音频编码技术,有损音频编码技术在牺牲部分原始音频数据的情况下可以达到更高的音频数据压缩率,而无损音频编码技术则可以还原出完整的原始音频数据 。
在 Vo IP 技术中,由于网络带宽的限制,往往会使用有损音频编码技术,且这些音频编码算法可以达到的压缩率通常比较高 。此外,由于实时网络传输的不可靠性,使用的音频编码算法需要具备从残损数据中获得接近完整音频数据的功能 。常用的音频编码算法有 G.711、G729、AAC、Speex、Opus 等,这些音频编码算法压缩后的音质与比特率的关系对比如下图所示,延迟与比特率的关系如下图所示:
聊聊多人语音通话的基本原理

文章插图
音频编码算法压缩后的音质与比特率的关系

聊聊多人语音通话的基本原理

文章插图
部分音频编码算法延迟与比特率的关系
如果需要实现多方语音通话功能,对延迟的要求高,由于系统中各成员之间的距离可能较远,整个网络的带宽较小,在保证音频质量的情况下,音频数据码率需要尽可能的低,选择使用 Opus 音频编码算法实现语音数据编解码 。
Opus 是一种有损音频编码算法,包含了 SILK 和 CELT 两种声音编码技术,其开发目的是希望用单一格式包含声音和语音,取代 Speex 和 Vorbis 音频编码算法,且适用于网络上低延迟的实时音频传输 。Opus 可以调节编码比特率,它在较低比特率时使用线性预测编码,在高比特率时使用变换编码,非常适合用于低延迟语音通话的编码 。此外 Opus 也可以透过降低编码比特率,达成更低的算法延迟,最低可以到 5 ms 。
 
6.RTP 实时传输协议
RTP 协议是一种基于 IP 网络传输音视频数据的网络传输协议,它被广泛应用于通信和流媒体应用,例如语音会话、视频会议、网络电视服务等 。它在网络模型中是一个应用层协议,在传输层之上,通常 RTP 协议是基于 UDP 协议的,在一些特殊应用场景之下也可以基于 TCP 协议 。
聊聊多人语音通话的基本原理

文章插图
 
表中几个重要的字段的解释如下:
(1) SN(Sequence Number,序列号):为了解决网络传输时时延抖动的问题,RTP协议使用一个长度为 16 位的序列号来确定数据报的顺序,每个发出的数据报会被标记上连续的序列号,用于接收端对乱序到达的 RTP 数据报进行排序,同时可以用于统计 RTP 传输的丢包情况 。
(2) PT(Payload Type,负载类型):RTP 协议使用 PT 字段来标识 RTP 报文所传输的流媒体数据的类型,常见的数据类型有 AAC、Speex、Opus、H.264 等 。
(3)Timestamp(时间戳):由于时延抖动的存在,目标主机接收到数据报的顺序和时间间隔与发送时的存在偏差,如果每次都立即播放接收到的数据,则播放效果会与我们预期的大不相同 。实际中,接收端通常会设置一个播放时延,时间戳在这个时延区间内的包会被存入缓冲区等待播放,即打上发送时间戳 。
(4) SSRC(Synchronization Source,同步源):RTP 协议在设计之初就考虑到了组播的方式,在进行组播时,IP 地址和端口无法用于确定唯一的一个网络地址,因此 RTP 协议中使用一个长度为 32 位的字段标识 RTP 包来源,它是一个随机数,且能保证其在一个 RTP 会话中的唯一性 。RTP 协议不仅解决了使用 IP 协议进行实时流媒体数据传输时存在的问题,同时也为应用层的流媒体应用程序提供了规范的传输协议,使得开发者不需要重复实现类似的私有协议 。此外,RTP 协议也是一个开源的协议,开发者可以根据各自的应用需求对其进行修改 。


推荐阅读