<div dir="ltr">Hi,<div>I'm facing a hopefully simple problem, where it seems as if the udpsrc element is far too slow in handling packets. </div><div>I have a small test application to send and receive a rtp stream. The problem is that I'm losing a lot of packets on the receiver side, even when just using localhost.</div><div>The pipeline basically looks like this:</div><div>gst-launch-1.0 filesrc location=file.mp4 ! qtdemux ! video/x-h264 ! rtph264pay ! udpsink host=127.0.0.1 port=5000<br>and<br>gst-launch-1.0 -v udpsrc port=5000 caps='application/x-rtp, media=video, etc.' ! rtpjitterbuffer ! rtph264depay ! avdec_h264 ! autovideosink<br></div><div><br></div><div>The "bytes-served" property of udpsink confirms that all bytes of the source file have been sent.<br>On the receiving side, rtpjitterbuffer "stats" property tells me that about 1000 out of 8500 packets have been lost using my 10Mb test video.<br><br>If I increase the kernel receive buffer size with net.core.rmem_max and net.core.rmem_default, it works. But I need it to work without changing kernel values.</div><div>The bitrate is just 8 MBit/sec, which means there are less than 1000 packets per second. And on a 3Ghz cpu I should be able to handle a lot more than 1000 packets per second, especially on localhost, so it should work just fine with the default kernel values.<br>(Same happens over a local network between two ubuntu machines and with both the basic pipeline using gst-launch and my application.)<br><br>So where could the bottleneck / my faulty reasoning be?<br><br>Any hints appreciated.<br><br>Best regards<br><br>Christoph<br></div></div>