Audio Choppy -- Jitterbuffer

最新推荐文章于 2025-05-16 14:16:07 发布

IAmCodingEx

最新推荐文章于 2025-05-16 14:16:07 发布

阅读量162

点赞数 3

文章标签：实时音视频

本文链接：https://blog.csdn.net/weixin_45216705/article/details/145906488

版权

Jitterbuffer

在音视频会议中，抖动缓冲器（jitter buffer）主要用来平滑由于网络抖动带来的音频包延迟或丢失问题，而 audio concealment（音频隐藏或丢包隐藏）就是在这种情况下采取的一种技术手段，用以“填补”因网络问题而缺失的音频数据，从而避免出现明显的音频断裂或杂音。

Audio Concealment

什么是 Audio Concealment？
核心理念：当网络出现抖动或数据包丢失时，音频隐藏技术会利用前一帧或周围的音频信息，通过复制、插值或其他算法来生成替代音频数据。这种做法能够掩盖丢失的数据，使听众感受到连续、平滑的音频播放。
常用方法：
帧复制：直接重复前一帧或几帧音频数据。
插值算法：通过数学模型估算出缺失部分的音频样本。
频谱估计：在频域中重构缺失的音频信息。
如何计算 Audio Concealment？
通常来说，计算音频隐藏效果的方法依赖于统计隐藏过程中的关键指标，例如：

隐藏帧数（Concealed Frames）：在丢包或延迟情况下，通过音频隐藏技术恢复出来的帧数。
总丢失帧数（Total Lost Frames）：原本应接收但由于网络问题而缺失的音频帧总数。
一种常见的计算方法是用恢复出来的帧数与总丢失帧数的比例来表示隐藏效果，比如：

隐藏率
=
隐藏帧数
总丢失帧数
×
100
%
隐藏率= 
总丢失帧数
隐藏帧数

 ×100%
例如，如果在一次会议中一共丢失了 100 帧音频数据，而通过音频隐藏技术成功恢复了 90 帧，则隐藏率就是 90%。这种计算方法可以帮助工程师评估隐藏技术的效果，以及是否需要进一步优化处理算法。

小结
Audio Concealment 是指在抖动缓冲器中，通过特定算法填补丢失的音频数据，以确保音频播放连续平滑。
计算方法 通常是通过统计恢复的隐藏帧数与总丢失帧数的比例来量化隐藏效果，不同系统可能会有细微差别，但基本原理大同小异。

Conclusion:

total concealment time (ms)越小, 丢包越少.
RTPSSRC

RTP 中的 SSRC（同步源标识符）是一个 32 位的标识符，用于唯一标识同一个 RTP 流中的发送者。每个发送端在开始发送数据时，会随机生成一个 SSRC，并在整个会话中保持不变，从而让接收端能够区分来自不同源的音视频数据。简单来说，SSRC 就像是每个发送者的身份证，让接收端可以知道“这是谁发过来的数据”。

关于 jitterbuffer 是否正常 的判断，可以从以下几个方面来观察和分析：

延时和抖动情况

正常情况下，jitterbuffer 会维持一个合理的队列深度，既能缓冲网络波动，又不会引入过多延时。如果你发现延时显著增大或者 jitterbuffer 的队列经常耗尽（下溢）或过满（上溢），可能就需要检查网络状况或缓冲器配置。
丢包隐藏（Audio/Video Concealment）指标

查看系统日志或统计数据，关注隐藏机制的调用次数。较高的隐藏率可能表明网络丢包频繁，或者 jitterbuffer 未能及时填充数据，这时需要分析具体原因。
RTCP 报告数据

利用 RTCP 报告中的指标，比如统计的 jitter 值、延时、丢包率等，来判断当前网络和 jitterbuffer 的状态。如果这些指标偏离正常范围，就可能需要对 jitterbuffer 参数进行调整。
用户体验

观察最终用户端的音视频质量。如果音频出现断裂、杂音或者视频卡顿，可能就是 jitterbuffer 配置或网络状况不理想的信号。
总之，通过上述指标的综合分析，可以较为准确地判断 jitterbuffer 是否正常工作.

Audio Codec

G.711 (u-law / a-law)

特点：属于无损压缩的编解码器，工作在 64 kbps，延时低，音质非常接近原始语音。
适用场合：广泛用于传统电话网络、IP 电话和呼叫中心。通常 u-law 主要在北美和日本使用，而 a-law 则在欧洲及其他地区更为常见。
ILBC (Internet Low Bitrate Codec)

特点：设计时考虑了网络丢包的情况，即使在数据包丢失或网络抖动时也能保持语音的可理解性，工作比特率通常在15-32 kbps左右。
适用场合：非常适合用于VoIP应用，尤其在网络环境不稳定或者带宽有限的情况下能提供相对稳定的语音质量。
OPUS

特点：极具灵活性，支持从 6 kbps 到 510 kbps 的可变比特率，能在低延时的同时兼顾语音和音乐的编码，提供高质量的音频传输。
适用场合：被广泛应用于现代实时通信，如 WebRTC、在线会议、流媒体以及各类音频聊天应用，是当前非常热门的音频编解码器之一。
G.722

特点：一种宽带编解码器，相对于传统的窄带语音提供更清晰、更自然的音频效果，通常工作在 64 kbps 或更高。
适用场合：适合需要高质量语音的场景，如会议电话、视频会议和高质量VoIP通信等。
G.729

特点：以8 kbps的低比特率工作，采用有损压缩方式，能在较低带宽条件下传输语音，但相对牺牲了一些音质。
适用场合：特别适合带宽受限的网络环境，如移动网络或远程会议，能在有限带宽下保持语音通信的流畅性。
G.722.1

特点：基于G.722的宽带编解码器，提供了更高的压缩效率，同时保持较高的音频质量。
适用场合：常见于视频会议和高质量VoIP系统中，在音质与带宽之间取得了不错的平衡。
总结一下：

如果你追求最高音质且网络带宽充足，G.711和OPUS都是非常好的选择；
若网络环境较差或带宽有限，G.729和ILBC会更加适用；
对于要求高音质同时需要宽带效果的场景，G.722和G.722.1能提供更出色的体验。

Codec document

下面为你整理了每个编码器的官方原文文档链接（PDF 格式），供你参考：

G.711 (u-law / a-law)
ITU-T Recommendation G.711
链接：https://www.itu.int/rec/T-REC-G.711/en
（页面中一般提供 PDF 下载选项）

G.722
ITU-T Recommendation G.722
链接：https://www.itu.int/rec/T-REC-G.722/en

G.729
ITU-T Recommendation G.729
链接：https://www.itu.int/rec/T-REC-G.729/en

G.722.1
ITU-T Recommendation G.722.1
链接：https://www.itu.int/rec/T-REC-G.722.1/en

iLBC
IETF RFC 3951 – “iLBC: A Low-Delay Voice Codec”
PDF 版链接：https://tools.ietf.org/pdf/rfc3951.pdf

Opus
IETF RFC 6716 – “Opus: A Versatile Audio Codec”
PDF 版链接：https://tools.ietf.org/pdf/rfc6716.pdf

RTT 指的是“Round Trip Time”，也就是往返时延，衡量的是一个数据包从源头发送到目的地，再从目的地返回到源头所需的总时间。这项指标对于实时通信（如语音和视频会议）至关重要，因为它直接影响到交互的实时性和用户体验。

正常范围
局域网（LAN）环境下，由于物理距离短，RTT 往往低至几毫秒甚至更低。
互联网环境中，一般来说：
理想状态：RTT 在 20 毫秒到 50 毫秒之间，非常适合实时通信。
可接受范围：RTT 在 50 毫秒到 150 毫秒之间，大部分实时应用仍能正常工作，但会有轻微延时。
边缘情况：RTT 超过 150 毫秒时，可能会对语音或视频交互产生明显影响；超过 300 毫秒时，用户体验可能会大幅下降，交互变得不流畅。
需要注意的是，RTT 受到网络拥堵、路由选择、物理距离等多种因素的影响，因此在不同场景下“正常”范围可能有所不同。总体来说，为了确保音视频会议的流畅性，建议尽量保持 RTT 在 150 毫秒以下哦！