Как справиться с перекосом часов в потоковом аудио

Проблема :

  1. Его потоковое аудио-видео в прямом эфире через сеть Wi-Fi + udp.
  2. Поток: Mpeg2Ts
  3. Платформа проигрывателя: gstreamer.
  4. Pipeline Appsrc ----> tsdemuxer -----> аудио-очередь----> декодер faad---> alsasink-----> видео-очередь-> vpudecoder ----> videosink
  5. Аудиоустройство настроено на обработку 48000 выборок в секунду.
  6. Часы отправителя быстрее, чем часы получателя, и я получаю эту информацию, отслеживая значение pcr, поступающее в системные часы потока и получателя. Через 1 час разница между часами отправителя и получателя составляет 8 секунд.
  7. Таким образом, проблема заключается в том, что отправитель отправляет больше выборок за одну секунду по отношению к часам получателя, поскольку эта задержка между отправителем и получателем продолжает увеличиваться со временем.

person Ashutosh Pandey    schedule 29.12.2014    source источник


Ответы (1)


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

Чтобы решить вашу проблему увеличения задержки между отправителем и получателем, вам нужно будет правильно отмечать время ввода вместо того, чтобы полагаться на отметки времени внутри потока TS (которые основаны на часах отправителя и, следовательно, неверны на вашей стороне). Для этого уже может быть достаточно использовать достаточно свежую версию GStreamer и установить do-timestamp=true и format=time в файле appsrc.

person Sebastian Dröge    schedule 29.12.2014
comment
Я не могу использовать последнюю версию gstreamer. В настоящее время я использую gstreamer-0.10.36. В Demuxer (tsdemuxer) gstreamer использовал алгоритм для обработки перекоса часов. Алгоритм требует временной метки получения пакетов rtp, содержащих информацию pcr. Используя значения PCR (эталонные часы программы) отправителя и получателя значения пакета, он вычисляет разницу между часами отправителя и часами получателя. Diff = (PCR-PACKET-RECV-TIME-N - PCR-PACKET-RECV-TIME-1) - (PCR-VALUE-N - PCR-VALUE-1). - person Ashutosh Pandey; 29.12.2014
comment
В зависимости от diff он вычисляет среднее значение перекоса и обновляет PTS (временную метку представления) каждого пакета для часов получателя. Теперь, согласно этой логике, воспроизведение видео не имеет дрейфа, но воспроизведение аудио дрейфует с течением времени. Так что в основном я сталкиваюсь с проблемой синхронизации аудио-видео. - person Ashutosh Pandey; 29.12.2014
comment
Если это RTP, почему вы просто не используете udpsrc и rtpbin? Как вы получаете пакеты RTP в свое приложение? Чтобы сохранить синхронизацию аудио/видео, вам необходимо убедиться, что аудио и видео, которые связаны друг с другом, имеют одинаковое время воспроизведения. - person Sebastian Dröge; 30.12.2014