Udpsrc too slow / Kernel receive buffer too small

[Christoph Eifert]

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/20190929/b9c3866d/attachment.html>