gstreamer udp Потоковая передача идет медленно - PullRequest
Новая
       33

gstreamer udp Потоковая передача идет медленно

8 голосов
/ 28 июня 2011

Я работаю над приложением видеочата, и у меня возникают проблемы с потоковой передачей UDP по сравнению с TCP.

Когда я использую приведенные ниже конвейеры, видеопотоки приемлемо.(Само приложение написано на python, но конвейеры в основном такие, как показано ниже) 

sender: 

gst-launch-0.10 v4l2src ! video/x-raw-yuv,width=320,height=240 ! 
    theoraenc ! oggmux ! tcpclientsink host=nnn.nnn.nnn.nnn port = 5000

receiver: 

gst-launch-0.10 tcpserversrc host=nnn.nnn.nnn.nnn port=5000 
    ! decodebin ! xvimagesink

Однако, поскольку это приложение должно работать через / через NAT, мне требуется потоковая передача UDP.Когда я переключаю tcpserversrc на «udpsrc port = 5000», а tcpclientsink на «udpsink host = nnn.nnn.nnn.nnnn port = 5000», производительность падает до точки, где принимающий компьютер получает один кадр каждые 5 секундили так.(Это происходит, даже если оба потока выполняются на одном и том же компьютере)

Отправляющий конвейер генерирует следующее (один раз): 

WARNING: from element /GstPipeline:pipeline0/GstUDPSink:udpsink0: 
    Internal data flow problem.
    Additional debug info:
    gstbasesink.c(3492): gst_base_sink_chain_unlocked (): /GstPipeline:pipeline0
    /GstUDPSink:udpsink0:
    Received buffer without a new-segment. Assuming timestamps start from 0.

... и приемный конвейер генерирует (каждые 20секунд или около того): 

WARNING: from element /GstPipeline:pipeline0/GstXvImageSink:xvimagesink0: 
    A lot of buffers are being dropped.
    Additional debug info:
    gstbasesink.c(2739): gst_base_sink_is_too_late (): /GstPipeline:pipeline0
    /GstXvImageSink:xvimagesink0:
    There may be a timestamping problem, or this computer is too slow.

Я прочитал документы и справочные страницы, поиграв с различными параметрами в udpsink, все безрезультатно.Может ли кто-нибудь направить меня к (несомненно, очевидной) вещи, которую я совершенно не понимаю?Заранее спасибо:)

Ответы [ 3 ]

7 голосов
/ 20 ноября 2011

У меня была такая же проблема. Попробуйте установить 

sync=false

на tcpclientsink и xvimagesink

4 голосов
/ 15 июля 2012

У меня была похожая проблема.Мне удалось решить эту проблему, изменив две вещи (1) Как упомянул Fuxi sync = false и (2) Добавление заглавных букв на стороне декодирования для соответствия конвейеру кодирования.Например, в вашем случае что-то вроде gst-launch-0.10 tcpserversrc host=127.0.0.1 port=5000 ! decodebin ! video/x-raw-yuv,width=320,height=240 ! ffmpegcolorspace ! xvimagesink sync=false должно работать (у меня работает).Я бы порекомендовал вам также установить частоту кадров в обоих (сервер / клиент) конвейерах. Сначала я запускаю конвейер декодирования (сервер), а затем конвейер кодирования (клиент), иначе OFCOURSE не удается.

Обновление: Добавление очередь между соответствующими элементами декодирования спасли мой хвост много раз.например gst-launch-0.10 tcpserversrc host=127.0.0.1 port=5000 ! queue ! decodebin ! queue ! video/x-raw-yuv,width=320,height=240 ! ffmpegcolorspace ! xvimagesink sync=false.Точно так же videorate помог мне в некоторых ситуациях.

0 голосов
/ 11 марта 2014

Я использую эту команду, и она работает как шарм.

на стороне сервера: 

gst-launch v4l2src device=/dev/video1 ! ffenc_mpeg4 ! rtpmp4vpay send-config=true ! udpsink host=127.0.0.1 port=5000

Клиентская сторона: 

gst-launch udpsrc uri=udp://127.0.0.1:5000 caps="application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)MP4V-ES, profile-level-id=(string)1, config=(string)000001b001000001b58913000001000000012000c48d88007d0a041e1463000001b24c61766335322e3132332e30, payload=(int)96, ssrc=(uint)298758266, clock-base=(uint)3097828288, seqnum-base=(uint)63478" ! rtpmp4vdepay ! ffdec_mpeg4 ! autovideosink
...