<div dir="ltr">I've managed to narrow it down now. The reason for the packet drops is actually the startup time of the client pipeline. So packets are only dropped at the beginning. Especially the decodebin and fakesink apparently take their time negotiating stuff. And the udpsrc is not handling packets while that happens. Even though the udpsrc is running in it's own thread and the client application is started before the server, it still seems to stop handling packets for a while after receiving the first and the pipeline organizes itself (with decodebin creating a src pad and connecting with the sink).<div>Is there anyway to force the udpsrc to keep handling packets and buffering them in the queue while that happens?</div><div><br></div><div>Best regards</div><div><br></div><div>Christoph</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Sep 29, 2019 at 10:58 PM Christoph Eifert <<a href="mailto:eifert.christoph@gmail.com">eifert.christoph@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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>
</blockquote></div>