Support for Raspberry Pi 4?

This project is insanely useful, congratulations on a job well-done.

Can you think of any reason why it might not work on a Raspberry Pi 4?

It compiles fine, but when I try to use it in a gstreamer pipeline, nothing seems to happen. :confused: It sits here non-ending, using very little CPU.

gst-launch-1.0 -e -v aravissrc ! fakevideosink 
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
/GstPipeline:pipeline0/GstAravis:aravis0.GstPad:src: caps = video/x-raw, format=(string)GRAY8, width=(int)516, height=(int)384, framerate=(fraction)7/1
/GstPipeline:pipeline0/GstFakeVideoSink:fakevideosink0.GstGhostPad:sink.GstProxyPad:proxypad0: caps = video/x-raw, format=(string)GRAY8, width=(int)516, height=(int)384, framerate=(fraction)7/1
/GstPipeline:pipeline0/GstFakeVideoSink:fakevideosink0/GstFakeSink:sink.GstPad:sink: caps = video/x-raw, format=(string)GRAY8, width=(int)516, height=(int)384, framerate=(fraction)7/1
/GstPipeline:pipeline0/GstFakeVideoSink:fakevideosink0.GstGhostPad:sink: caps = video/x-raw, format=(string)GRAY8, width=(int)516, height=(int)384, framerate=(fraction)7/1

It seems like it might be doing something, because of the non-zero CPU usage and bandwidth usage (~5KB/s). When I run this on my laptop, it uses ~1.2MB/S with my current camera configuration.

This is compiled from the 0.6.4 release tarball.

Let me know if there’s more information I can provide.

Hi Muny,

What sort of camera is this ? Ethernet or USB ?

Did you try with tests/arv-camera-test ?

You may want to try to enable debugging using export ARV_DEBUG=all for example.

Hi emmanuel,

Thanks for the quick response. It’s a GigE camera.

I think this has something to do with the packet size/MTU configured on the RPi.

When I first ran arv-camera-test, it reported using a gv packet size of 1532 bytes. It showed a frame rate of 0 Hz and when I Ctrl+C’d, it showed all failures.

I ran it again with -i 1500, and it started started receiving frames successfully (and so does the original gst pipeline).

I suppose I will have to look into increasing the configured max MTU on the RPi.


Yes, increasing the MTU will improve the performance.

You may want to try to packet socket support, by running arv-camera-test as root, and if it works, by setting the needed capability as explained here: .



Thanks, I will try this tomorrow.

Bit of an old thread, but just to say (for the pi3) I run:
sudo sysctl -w net.core.rmem_max=16777216 net.core.rmem_default=16777216
sudo sysctl -w net.ipv4.route.flush=1
sudo ifconfig eth0 mtu 9000

and inside my python module I run:
os.system(“sudo chrt -f -p 1 %d” % os.getpid()) #makes it more real time??
self.aravis_camera.gv_set_packet_size(8000) #supposed to also help??

I guess I gleaned this from other threads and issues. Just thought it might help.

Thanks Mike for sharing your informations. Could you tell us a bit more about your setup ? What device are you using ? With which image size and framerate ?

Hi again,
I realised I spoke too soon - that config worked for the pi 3s, but I’ve been also having some trouble with the pi4: When I try to set the mtu>1500 on the pi 4 it reports an error message.
From a pi forum discussion:

The LAN7515 in the RPi 3B+ does support 9K jumbo frames and the lan78xx driver it uses also has support. The RPi 4 internal gigabit MAC does support jumbo frames as well but the driver doesn’t.

This thread proposed recompiling the kernel (ugh) - but does report success.

The problem seems to have temporarily gone away for me. Can’t say that’s very useful!

My setup is using either a GCC2062M or a HIK MV-CA032-10GM. Both used at their full resolution (both are monochrome). I only take at most 6 photos/second, usually fewer.

For me the symptom is ARV_BUFFER_STATUS_TIMEOUT when there’s a problem. I should probably understand where/why there are timeouts - I wish I could just increase whatever timer is timing out!

Thanks again for the library.
Hope some of that info/links are useful.

This usually means all the packet for a given buffer are not received. You may want to play with the following ArvGvStream properties: packet-timeout, frame-retention and packet-request-ratio. Obviously, it will only increase the success rate if packet resend feature is implemented by your camera.

The other properties you can change are socket-buffer and socket-buffer-size. By increasing the socket buffer size, there is more chance the kernel does not miss a packet.

And finally, the use of the packet socket interface will make a big difference on low performance platforms like the raspberry pi.


1 Like

Thanks so much for these really helpful tips. I’ll try them over the next few weeks.
I think one other thing I found, that might be useful for other pi users: I was saving all the images onto the sd card. When the sd card was getting full I found I had more buffer timeouts: I think this is probably because the kernel was busy trying to organise the last few Mb of free space and taking up large contiguous chunks of time to do this leading to various buffers etc not being serviced in time? I’m also using a faster sd card which might be helping too. Just some ideas for others using the pi.

You can achieve faster write speeds if you write to an USB and not to the SD that holds the OS.

Oh interesting tip!
Really appreciate as this is a bottleneck on some of the projects using the system.