Multiple cameras work better on a RPi than a Gaming PC?

Hello,
This problem has stumped me for a while, but I am unable to resolve.

I’m currently working with cameras that feature USB 2.0, H.264 hardware-encoded video streams, and I’m facing an issue when trying to set up a UDP stream using GStreamer. Here’s the pipeline I’m using:

gst-launch-1.0 v4l2src device=${device} ! video/x-h264, width=${width}, height=${height} ! h264parse ! queue ! rtph264pay config-interval=10 pt=96 ! udpsink host=${host} port=${port} sync=false

I’ve had successful experiences running multiple cameras on different hardware configurations:

  • Raspberry Pi 4 with 4GB RAM can handle up to 5 cameras at 1080p each.
  • Nvidia Jetson Nano Developer Kit (2GB RAM) can handle up to 4 cameras at 1080p each.
  • Lenovo Desktop, running Ubuntu 22.04.3 LTS, with 16GB RAM and Intel i5-12400, can handle up to 3 cameras at 1080p each.

Multiple cameras are connected via the same USB Hub to each system.

However, when I attempt to add another stream beyond these limits, I encounter the following error:

Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Failed to allocate required memory.
Additional debug info:
../sys/v4l2/gstv4l2src.c(759): gst_v4l2src_decide_allocation (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
Buffer pool activation failed
ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Internal data stream error.
Additional debug info:
../libs/gst/base/gstbasesrc.c(3127): gst_base_src_loop (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
streaming stopped, reason not-negotiated (-4)
Execution ended after 0:00:00.057663072
Setting pipeline to NULL ...
Freeing pipeline ...

Sometimes, I also receive “memory buffer” related errors instead of the “internal data stream error.”

I would greatly appreciate any guidance or insights on how to resolve this issue and potentially increase the number of cameras I can run on these systems. Your assistance would be invaluable.

I have tried this with no resolution: Increase USBFS memory limit in Ubuntu | HalfaGeek

Because I am not changing any variables other than the system/OS, I believe there is an artificial limit on usb memory bandwidth or related being set within gstreamer or the OS itself. I am not sure why the RPi and the Desktop are so drastically different in terms of performance, but I would ideally like to use a higher power system to potentially use even more cameras.

Thank you in advance for your help!

In general, USB bandwidth saturation comes into play With usb2. This is not greatly reported to GStreamer, hence the random error messages.

I’d suggest to keep an eye on your kernel logs, and maybe enable more, and try to spread the cameras across multiple hubs and ports.

(p.s. consider using sync=true and/or a bitrate configuration on udpsink, on faster machines you may end up with more packets lost due to burst.)

It doesn’t make sense to me that the same usb hub with the cameras attached works better on a worse system.

Like why would multiple usb 2.0 cameras, attached to one hub on a rpi work better than a full desktop machine? I don’t think this is a usb bandwidth limitation since more cameras should work on a higher machine

I will try this and report back

Check your USB topology perhaps? The performance of the host is kind of irrelevant, the hardware topology and driver quality are to be the main criterias.

Per your advice, I split the cameras across multiple USB hubs, and it seems to have remedied the issue! Seems like the USB driver for each system is behaving differently due to some lower level issue. I will be looking into the usb hub driver, but for now this is the solution it seems.

Thank you very much for your help! :slight_smile:

Great, and now that you comment in this form, I just remember it could also be a power delivery issue, in which case a powered hub might also give you successful results.

It was already a powered hub to begin with, I had already measured the power draw for each camera, and it was well within any limits.