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

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

3 голосов
/ 03 января 2011

Для приложения мониторинга качества речи 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. Для данного аудиосэмпла (в моем примере это 8 секунд): 

[XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX]

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

[XXXXXXXXXXXXXXXXXXXXXXXX-----XXXXXXXXXXX]

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

[XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX]

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

Ответы [ 2 ]

2 голосов
/ 13 января 2011

Проблема может быть решена путем небольшого изменения конвейера: Элемент audiorate необходимо добавить до wavenc, чтобы " создавал идеальный поток, вставляя или отбрасывая образцы по мере необходимости ". Однако это работает, только если 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
2 голосов
/ 11 января 2011

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

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

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

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

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

...