воспроизведение потокового mp3 через RTP с использованием gtreamer - PullRequest
1 голос
/ 30 сентября 2010

Я работаю с gstreamer, в основном играю с функциями воспроизведения музыки.

В настоящее время я пытаюсь использовать RTP для отправки потоков mp3 по нашей локальной сети, но безуспешно до сих пор.

На стороне отправителя я использую следующий конвейер:

gst-launch -v filesrc location =. / My_music_file.mp3! ffdemux_mp3! rtpmpapay! порт udpsink = 6969 хост = 192.168.0.200

На стороне получателя я использую следующий конвейер:

gst-launch -v udpsrc port = 6969 caps = "application / x-rtp, media = (string) audio, тактовая частота = (int) 90000, encoding-name = (string) MPA, payload = (int ) 96, ssrc = (guint) 1951256090, base-base = (guint) 1711290778, seqnum-base = (guint) 24773 "! rtpmpadepay! flump3dec! pulsesink

По-видимому, ошибки нет, поскольку вывод со стороны приемника:

Установка конвейера на PAUSED ...

Трубопровод работает и PREROLL не нужен ...

Настройка конвейера на PLAYING ...

Новые часы: GstSystemClock

... Но звук слышен странно, как если бы он воспроизводился слишком быстро.

Я проверил, что аудио работает, воспроизводя mp3 файлы локально. Я также проверил rtp путем потоковой передачи файлов wav / µLaw. Все это хорошо работает.

Я также пытался столкнуться с проблемой другими способами, например, я использовал следующий конвейер, который хорошо работает с кодеком audiotestsrc / amrnb:

gst-launch имя gstrtpbin = rtpbin audiotestsrc! Amrnbenc! rtpamrpay! rtpbin.send_rtp_sink_0 rtpbin.send_rtp_src_0! udpsink host = 192.168.0.200 port = 5002 rtpbin.send_rtcp_src_0! порт udpsink = 5003 хост = 192.168.0.200 sync = false async = false порт udpsrc = 5005! rtpbin.recv_rtcp_sink_1

Но при использовании того же конвейера с lame, снова на стороне получателя нет ошибки, но есть "слишком быстрый" вывод:

Отправитель: gst-launch имя gstrtpbin = rtpbin audiotestsrc! lamemp3enc! rtpmpapay! rtpbin.send_rtp_sink_0 rtpbin.send_rtp_src_0! udpsink host = 192.168.0.200 port = 5002 rtpbin.send_rtcp_src_0! порт udpsink = 5003 хост = 192.168.0.200 sync = false async = false порт udpsrc = 5005! rtpbin.recv_rtcp_sink_1

Получатель: gst-launch -v udpsrc port = 5002 caps = "application / x-rtp, media = (string) audio, тактовая частота = (int) 90000, encoding-name = (string) MPA, payload = (int) 96" ! rtpmpadepay! flump3dec! pulsesink

Может кто-нибудь иметь представление о том, что не так с моими конвейерами?

Большое спасибо за вашу поддержку,

Jorge

1 Ответ

1 голос
/ 04 октября 2010

Для тех, кто интересуется этой темой, у меня есть частичный ответ на эту проблему.

В FATC это декодер Fluendo, который теряет хорошие mp3-кадры, приходящие из RTP-депея.

Когда я использую mad декодер, я могу получать и слышать весь поток.

Вот конвейеры, которые я использую для потоковой передачи mp3 по RTP:

Отправитель: gst-launch -v filesrc location=. / my_file.mp3!ffdemux_mp3!rtpmpapay!порт udpsink = 6969 хост = 192.168.0.200

Получатель: gst-launch -v порт udpsrc = 6969 заглавных букв = "application / x-rtp, media = (string) audio, тактовая частота = (int) 90000, имя-кодировки = (строка) MPA, полезная нагрузка = (int) 96 "!rtpmpadepay!без ума !pulsesink

Проблема была отправлена ​​в команду fluendo.

Надеюсь, эта помощь.

...