Gstreamer: RTP-буфер дрожания не работает должным образом с потерей пакетов?

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 медиа. Я создал файл захвата, в котором отсутствует 50 исходных 400 дейтаграмм UDP. Для данного звукового образца (8s долго для моего примера):

[XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX] 

с определенным количеством последовательных потерь пакетов я бы ожидать звуковой сигнал, как это будет выходом («-» обозначает молчание):

[XXXXXXXXXXXXXXXXXXXXXXXX-----XXXXXXXXXXX] 

однако, что на самом деле сохраняется в звуковом файле это (1s короче для моего примера):

[XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX] 

это кажется, что буфер джиттера, важной частью этого приложения является не работает правильно. Может ли это быть несовместимо с/недостатком элемента pcapparse? Не хватает ли ключевой части в конвейере для обеспечения синхронизации времени? Что еще может быть причиной этого?

Answer 1

Проблема может быть решена путем небольшого изменения трубопровода: audiorate элемент должен быть добавлен перед wavenc, что «produces a perfect stream by inserting or dropping samples as needed». Однако это работает, только если audiorate принимает события потери пакетов. Для этого необходимо, чтобы значение do-lost значения gstjitterbuffer было равно true.

Вот исправленный трубопровод:

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

Answer 2

GStreamer может просто использовать буфер дежурного для сглаживания пакетов на пути к (аудио) выходному сигналу. Это не было бы необычным, его минимальное определение дежитеринга.

Это может зайти так далеко, как переупорядочить пакеты не по порядку или удалить дубликаты, но сокрытие пакетов (ваш сценарий) может быть довольно сложным.

Основные реализации просто дублируют последний полученный пакет, в то время как более продвинутая реализация анализирует и восстанавливает тон последних принятых пакетов, чтобы сгладить звук.

Похоже, что производительность вашего приложения будет зависеть от точной реализации скрытия потерь, поэтому даже если GStreamer действительно «что-то», вам может быть сложно определить его влияние на ваши результаты, если вы не понимаете его очень подробно.

Возможно, вы могли бы попробовать pcap с несколькими нестандартными и дублирующимися пакетами и проверить, по крайней мере, перегружает или удаляет их GStreamer, что могло бы помочь выяснить, что происходит.