gstreamer udp Streaming is slow

Question

I'm working on a videochat application and am having trouble with UDP streaming vs TCP.

When I use the pipelines below, the video streams acceptably. (The application itself is in python, but the pipelines are essentially as below)

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

However, since this app is to perform across/through NAT, I require UDP streaming. When I switch the tcpserversrc to a "udpsrc port=5000" and the tcpclientsink to a "udpsink host = nnn.nnn.nnn.nnnn port=5000", performance plummets to the point where the receiving computer gets one single frame every 5 seconds or so. (This occurs even when both streams are executed on the same machine)

The sending pipeline generates the following (once):

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.

...and the receiving pipeline generates (every 20 seconds or so):

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.

I've read docs and manpages, fiddled with various parameters to the udpsink, all to no good effect. Can anyone direct me to the (no doubt obvious) thing that I'm completely not getting? Thanks in advance :)

score 10 · Answer 1 · answered Nov 20 '11 at 00:05

10

I had the same problem. Try setting

sync=false

on tcpclientsink and xvimagesink

answered Nov 20 '11 at 00:05

Fuxi

5,298
3
25
35

3

It works! thank you. btw, what does `sync=false` even do? – Sadegh Dec 02 '15 at 06:29
With `sync=false` you disable clock sync the of the output sink. I also do not know what I'm saying :) – Melroy van den Berg Dec 02 '18 at 21:23

enthusiasticgeek · Answer 2 · 2013-03-18T18:46:52.897

I had a similar problem. I managed to solve it by changing two things (1) As Fuxi mentioned sync = false and (2) Adding caps at the decoding side to match the encoding pipeline. For e.g. in your case something like 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 should work (It works for me). I would recommend you set the frame rate in both (server/client) the pipelines as well. I start the decoding pipeline first (server) and then the encoding pipeline (client) otherwise OFCOURSE it fails.

Update: Adding queue between the appropriate decoding elements have saved my tail numerous times. e.g. 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. Similarly videorate has helped me in some situations.

score -1 · Answer 3 · answered Mar 10 '14 at 22:29

i am using this command and it working like a charm.

server side:

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

Client side:

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

gstreamer udp Streaming is slow

3 Answers3