<div dir="ltr"><div><div>Hi Henry.<br><br></div>I have had similar problems with both Raspberry Pi and Raspberry Pi 2. The problem is more significant on Raspberry Pi than the Raspberry Pi 2. The problem mostly disappear when the stream is a video stream with moving video. You start to notice when the video is mostly still and really become noticeable when the video contains a full screen complicated still image.<br><br></div>To identify the problem I tried many different settings for x264enc without much effect. I then simultaneously <br><div> viewed the stream on a regular laptop and saw no of the artifacts you describe, but kept seeing them on the Pi. So the stream is okay, but shows artifacts on the Raspberry Pi. I then inspected RTP sequence number on the Pi, as received over the net, but saw no real drops. Nevertheless since the Pi 2 was doing better than the Pi, I suspected somehow it dropped some packets somewhere in the decoding. I tried adding more buffering to the pipeline on the Pi without any real effect. Eventually I looked at the systems UDP receive buffer size.<br><br></div><div>You can inspect the systems UDP receive buffer by using the following command on the RaspPi:<br><br><div style="margin-left:40px">sudo sysctl net.core.rmem_max<br></div><br></div><div>Now when I enlarged the buffer size by a factor 8, 16 or 32, the problem dissapeared. You can enlarge the buffer size by executing the following command:<br><br><div style="margin-left:40px">sudo sysctl -w net.core.rmem_max=1310720<br></div><br></div><div>If the problem persist, try doubling the buffer size etc.<br><br></div><div>To cure it permanently, you need add the command (without the sudo) to the /etc/rc.local file (Raspian distro).<br></div><div>Now that cured the problem with Raspberry Pi for me, but it could be interesting to find out why the fix is necessary when you stream video with a complicated still image. If you look at the output from x264enc streaming a still image, you will see very low bandwidth (no real changes) until it needs to send an I-frame. Because it has used very little bw up until then, it uses a lot of bytes for the I-frame and you will see a very significant spike of bytes to transport over the network. Somehow this apparently fills the UDP receive buffer on the Raspberry Pi beyond the point where packets are dropped. You could also say, that your udpsrc pipeline on the Raspberry Pi does not read the packets fast enough from the UDP socket.<br><br></div><div>Okay, admittedly my theory isn't completely waterproof, there are some holes you can punch in it, but I believe there might be a minor problem with the udpsrc problem of gstreamer where it does not read the UDP packets of a <u>complete frame fast enough</u> under certain conditions. Enlarging the systems UDP receive buffer can compensate for this, but maybe the GStreamer devs need to revisit the udpsrc code to see if it can read a complete frame faster.<br><br></div><div>Best regards<br> <br></div><div>Peter Maersk-Moller<br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jan 16, 2016 at 7:38 AM, henryco <span dir="ltr"><<a href="mailto:fhenryco@yahoo.fr" target="_blank">fhenryco@yahoo.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
I'm trying to stream the whole desktop screen from a PC to a raspberry pi<br>
with the following pipelines and everything is fine except for a rapid<br>
stuterring every several seconds : from a few seconds when something changes<br>
on the screen, to more than 10 seconds when it's static. I have tried<br>
various combinations involving  sync=false on both ends, use-damage=0,<br>
rtpjitterbuffer ... but with no success so far<br>
<br>
sender side:<br>
<br>
gst-launch-1.0 -v ximagesrc use-damage=true ! queue  ! videoconvert  !<br>
videoscale ! "video/x-raw,framerate=(fraction)30/1,format=(string)I420" !<br>
queue ! x264enc tune=zerolatency  ! queue ! rtph264pay  pt=96 ! udpsink<br>
host=192.168.1.19 port=5000<br>
<br>
receiver side (Rpi)<br>
<br>
gst-launch-1.0 -v udpsrc port=5000 caps="application/x-rtp,<br>
media=(string)video, clock-rate=(int)90000,<br>
encoding-name=(string)H264" ! rtpjitterbuffer ! rtph264depay ! queue !<br>
h264parse ! queue ! omxh264dec !<br>
queue ! eglglessink<br>
<br>
the only thing that removes the problem is when i give up the zerolatency<br>
tuning (smoothing over many frames probably makes the glitch disappear) but<br>
this is not an option  for me since the frame rate drops for a video (toot<br>
much charge for the Pi ?) and probably the latency increases much...<br>
<br>
may be there are too many queues in my pipelines, i dont know...<br>
<br>
thank you in advance for advice and comments<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://gstreamer-devel.966125.n4.nabble.com/forwarded-screen-stutters-every-several-seconds-tp4675279.html" rel="noreferrer" target="_blank">http://gstreamer-devel.966125.n4.nabble.com/forwarded-screen-stutters-every-several-seconds-tp4675279.html</a><br>
Sent from the GStreamer-devel mailing list archive at Nabble.com.<br>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
</blockquote></div><br></div>