gstreamer udp Streaming is slow - streaming

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 :)

Answer 1

I had the same problem.
Try setting
sync=false
on tcpclientsink and xvimagesink

Answer 2

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.

Answer 3

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