audio - Gstreamer:RTP jitter buffer 在丢包时无法正常工作？

Question

对于 VoIP 语音质量监控应用程序，我需要将传入的 RTP 音频流与引用信号进行比较。对于信号比较本身，我使用预先存在的专用工具。对于其他部分(抓包除外)，Gstreamer 库似乎是一个不错的选择。我使用以下管道来模拟一个基本的 VoIP 客户端:

filesrc location=foobar.pcap ! pcapparse ! "application/x-rtp, payload=0, clock-rate=8000"
  ! gstrtpjitterbuffer ! rtppcmudepay ! mulawdec ! audioconvert
  ! audioresample ! wavenc ! filesink location=foobar.wav

pcap 文件包含单个 RTP 媒体流。我制作了一个缺少原始 400 个 UDP 数据报中的 50 个的捕获文件。对于给定的音频样本(我的示例为 8 秒):

[XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX]

有一定数量的连续丢包，我希望输出这样的音频信号(' - ' 表示静音):

[XXXXXXXXXXXXXXXXXXXXXXXX-----XXXXXXXXXXX]

然而，实际保存在音频文件中的是这个(对于我的例子来说更短 1s):

[XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX]

似乎此应用程序的关键部分 jitter buffer 工作不正常。这可能是与 pcapparse 的不兼容/缺点吗？元素？我是否遗漏了管道中的关键部分以确保时间同步？还有什么可能导致这种情况？

Answer 1

GStreamer 可能只使用去 jitter buffer 来平滑通往(音频)输出的数据包。这并不罕见，它是去抖动的最低限度的定义。

它可能会重新排序无序的数据包或删除重复项，但数据包丢失隐藏(您的场景)可能非常复杂。

基本实现只是复制最后接收到的数据包，而更高级的实现分析和重建最后接收到的数据包的音调以平滑音频。

听起来您的应用程序性能将取决于丢失隐藏的确切实现，因此即使 GStreamer 确实做了“某事”，除非您非常详细地了解它，否则您可能很难量化其对结果的影响。

也许您可以尝试使用带有几个乱序和重复数据包的 pcap 并检查 GStreamer 是否至少重新排序/删除它们，这将在某种程度上澄清正在发生的事情。