Udpsrc too slow / Kernel receive buffer too small

[Nicolas Dufresne]

Le samedi 05 octobre 2019 à 18:14 +0200, Christoph Eifert a écrit :
> 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).
> Is there anyway to force the udpsrc to keep handling packets and buffering them in the queue while that happens?

Add a queue right after udpsink, but you have rtpjitterbuffer which in
theory should have the same behaviour.

One of the main issue with udpsrc is that it retrieves a single packet
and push it. This isn't great, ideally it should try and empty the
socket and push a buffer list instead. That will increase performance
and reduce packet lost on received buffer. I have plans in that sense,
feel free to give it a look if you have time.

Nicolas

> 
> Best regards
> 
> Christoph
> 
> On Sun, Sep 29, 2019 at 10:58 PM Christoph Eifert <eifert.christoph at gmail.com> wrote:
> > Hi,
> > I'm facing a hopefully simple problem, where it seems as if the udpsrc element is far too slow in handling packets. 
> > 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.
> > The pipeline basically looks like this:
> > gst-launch-1.0 filesrc location=file.mp4 ! qtdemux ! video/x-h264 ! rtph264pay ! udpsink host=127.0.0.1 port=5000
> > and
> > gst-launch-1.0 -v udpsrc port=5000 caps='application/x-rtp, media=video, etc.' ! rtpjitterbuffer ! rtph264depay ! avdec_h264 ! autovideosink
> > 
> > The "bytes-served" property of udpsink confirms that all bytes of the source file have been sent.
> > On the receiving side, rtpjitterbuffer "stats" property tells me that about 1000 out of 8500 packets have been lost using my 10Mb test video.
> > 
> > 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.
> > 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.
> > (Same happens over a local network between two ubuntu machines and with both the basic pipeline using gst-launch and my application.)
> > 
> > So where could the bottleneck / my faulty reasoning be?
> > 
> > Any hints appreciated.
> > 
> > Best regards
> > 
> > Christoph
> 
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel