Udpsrc too slow / Kernel receive buffer too small

[Christoph Eifert]

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?

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20191005/908b9a74/attachment.html>