Problem sending high-bandwidth raw video over localhost UDP

[Michael Franzl]

Hello,

I'm trying to send 1280 x 720 @ 30fps BGRA video via rtpvrawpay and
udpsink from one gst-launch process to another on the same machine, but
I'm seeing visual artefacts on the receiver which suggest to me that
there could be packets lost (due to bandwidth?), or memory issues.

The sender:

> gst-launch-1.0 -v \
> videotestsrc pattern=ball flip=1 is-live=1 ! \
> video/x-raw,format=BGRA,width=1280,height=720,pixel-aspect-ratio=1/1,interlace-mode=progressive,framerate=30/1 ! \
> rtpvrawpay ! queue ! udpsink host=127.0.0.1 port=50000


The receiver:

> gst-launch-1.0 -v \
> udpsrc port=50000 caps="application/x-rtp,clock-rate=90000,encoding-name=RAW,sampling=(string)BGRA,width=(string)1280,height=(string)720" ! queue ! rtpvrawdepay ! videoconvert ! autovideosink


I'm attaching a screenshot of the receiving window, showing the type of
visual artefacts I mean (I hope the attachment comes through).

I calculate the bandwidth to 1280 x 720 x 32 bits x 30fps = 884
MBit/sec. Localhost *should* be able to handle this, but since that goes
through the Linux kernel, I don't know exactly.

I'm seeing the same problem on a wide range of machines (8 year old
Laptop to brand-new Intel Kaby Lake architecture desktop machine), and
from Gstreamer 1.10 to a very recent git version.

Tweaking MTU size and chunks-per-frame on rtpvrawpay changes the
artefact size and frequency but doesn't eradicate them. There is a small
hint that it *could* be Gstreamer. The following ...

> gst-launch-1.0 -v videotestsrc pattern=ball is-live=1 ! video/x-raw,format=AYUV,width=1280,height=720,pixel-aspect-ratio=1/1,interlace-mode=progressive,framerate=30/1 ! rtpvrawpay mtu=65000 chunks-per-frame=100 ! fakesink

... gives an exception ...

> (gst-launch-1.0:26037): GLib-ERROR **: /build/glib2.0-B1uXKV/glib2.0-2.50.3/./glib/gmem.c:100: failed to allocate 34359738456 bytes
> Trace/breakpoint trap

Any hints appreciated,

Thanks,
Michael

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Arjen Veenhuizen]

You are actually flooding the (small) UDP buffers at these
bandwidths.Increasing the buffer size will work-around your problem:



Ps. 800 Mbps should be no problem for localhost.



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Michael Franzl]

Arjen Veenhuizen wrote
> You are actually flooding the (small) UDP buffers at these
> bandwidths.Increasing the buffer size will work-around your problem:

It didn't improve the problem. Could you provide a working example pipeline?

Here are the two pipelines with buffer-size added (I tried various buffer
sizes):

Sender:


> gst-launch-1.0 -v \
> videotestsrc pattern=ball flip=1 is-live=1 ! \
> video/x-raw,format=BGRA,width=1280,height=720,pixel-aspect-ratio=1/1,interlace-mode=progressive,framerate=30/1
> ! \
> rtpvrawpay mtu=65000 chunks-per-frame=1 ! queue ! udpsink host=127.0.0.1
> buffer-size=100000000 port=50000 sync=false async=false

Receiver:


> gst-launch-1.0 -v \
> udpsrc port=50000
> caps="application/x-rtp,clock-rate=90000,encoding-name=RAW,sampling=(string)BGRA,width=(string)1280,height=(string)720"
> buffer-size=1000000000 ! queue ! rtpvrawdepay ! videoconvert !
> autovideosink

Using Wireshark to inspect traffic, I can see that each frame is split into
approx. 41 UDP packets with approx. 65040 bytes each, sent approx. 30us from
each other.

Still, what perplexes me is that in above sending pipeline, setting
chunks-per-frame=1 works, but chunks-per-frame=100 gives the "failed to
allocate 34GB" error message.



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Tim Müller]

On Fri, 2018-03-30 at 08:53 -0700, Michael Franzl wrote:

> You are actually flooding the (small) UDP buffers at these
> > bandwidths.Increasing the buffer size will work-around your
> > problem:
>
> It didn't improve the problem. Could you provide a working example
> pipeline?
>
> Here are the two pipelines with buffer-size added (I tried various
> buffer sizes):
>  (snip)

Did you check the debug log (or otherwise) that these buffer-sizes are
actually effective?

You likely will have to increase some kernel limits e.g. with

 sudo /sbin/sysctl -w net.core.rmem_max=33554432
 sudo /sbin/sysctl -w net.core.wmem_max=33554432

or somesuch.


> Still, what perplexes me is that in above sending pipeline, setting
> chunks-per-frame=1 works, but chunks-per-frame=100 gives the "failed
> to allocate 34GB" error message.

That sounds like an overflow in some calculation somewhere. Please file
a bug. Not sure if 100 chunks-per-frame really makes sense here though.

Cheers
 -Tim

--
Tim Müller, Centricular Ltd - http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Michael Franzl]

Tim Müller wrote
> You likely will have to increase some kernel limits e.g. with
>
>  sudo /sbin/sysctl -w net.core.rmem_max=33554432
>  sudo /sbin/sysctl -w net.core.wmem_max=33554432

That fixed it. I had to increase net.core.rmem_max to 100000000 (100M)
before the video became perfectly smooth. Even with 10MB there were some
skips. It was not neccessary to change net.core.wmem_max (my system defaults
were 212992). Also, it was only necessary to set buffer-size on the
receiver, not on the sender.

Thanks a lot for the solution.



Tim Müller wrote
> That sounds like an overflow in some calculation somewhere. Please file
> a bug. Not sure if 100 chunks-per-frame really makes sense here though.

I will file a bug, thanks.



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel