Gst aravissrc receive buffer size too small

[kohtala]

Describe the bug

GStreamer aravissrc object creates new streams when it receives new caps. The new stream defaults with socket-buffer of fixed. Therefore the aravissrc relies on the default receive buffer size instead of asking the operating system for full frame sized receive buffer.

To Reproduce
Check the default receive buffer and permitted maximum receive buffer:

$ sysctl net.core.rmem_default net.core.rmem_max
net.core.rmem_default = 212992
net.core.rmem_max = 16777216

Connect a GigE camera (or start arv-fake-gv-camera-0.8) needing a larger buffer and launch

$ arv-tool-0.8 values PayloadSize
Aravis-Fake-GV01 (127.0.0.1)
        IntSwissKnife: 'PayloadSize' = 262144
$ gst-launch-1.0 aravissrc ! testsink

While it is getting frames, check the socket receive buffers for the gst-launch-1.0

$ ss -aumOp
State  Recv-Q Send-Q       Local Address:Port   Peer Address:Port  Process
...
UNCONN 0      0               10.224.0.1:57135       0.0.0.0:*      users:(("gst-launch-1.0",pid=2270720,fd=10)) skmem:(r0,rb212992,t0,tb212992,f4096,w0,o0,bl0,d0)
UNCONN 0      0               10.224.0.1:43286       0.0.0.0:*      users:(("gst-launch-1.0",pid=2270720,fd=13)) skmem:(r0,rb212992,t0,tb212992,f4096,w0,o0,bl0,d0)

The skmem value after rb is the receive buffer size. Here 212992 which is less than 262144 and net.core.rmem_max.

(Would it cause some problem to connect the UDP socket to receive only from the camera for easier finding of the socket for that camera?)

Expected behavior
Seeing rb212992 of at least the PayloadSize. I think it is currently larger to accommodate headers.

Camera description:
N/A

Platform description:

• Aravis version 0.8.34
• OS: Debian 11, 13
• Hardware x86_64

Additional context
Since 0.8.32 the stream object can be received from the aravissrc through stream property notification for modification. However this is difficult in a GStreamer pipeline and not available from gst-launch-1.0.

It is also possible to work around this with larger net.core.rmem_default, but it may affect other protocols on the host and not available without root access on the host.

[EmmanuelP]

Hi,

I guess a possible solution would be to add a property 'stream-properties' to the gstreamer plugin, which would be a space separated property list, for example: "buffer=fixed buffer-size=1000000".

Alternatively, a set of stream properties could be mapped to the gstreamer plugin properties.

Or we could just set "buffer" to "auto" for gigevision streams.

[kohtala]

To solve my problem, I dug out the aravissrc element from the pipeline and connected for the notify::stream signal. In the handler I modified the socket-buffer property to AUTO. I wanted to dig out the stream statistics also, so it was easy to do at the same time.

The auto buffer would seem to be a sane default. I don't know why anyone would want to go with something else.

Some redesign could bring improvement. We could derive new GStreamer elements for the GigE and USB and whatever other subclasses of devices there could be. That would allow cleaning up the current USB or GigE specific properties (usb-mode, packet-delay, packet-size, auto-packet-size, packet-resend) and adding new device type specific properties without cluttering the interface. If we use device specific properties, there is no benefit in a generic aravissrc element and we could use a device specific element just as well.

Recent GenICam versions support multiple streams and at some point we may want to support that on aravissrc. Properties don't support stream specific settings. Therefore those could be set through Caps. I'm not terribly fluent with GStreamer, so I can't tell if we can just use custom features on a GstStructure.