B0201 camera stops after a minute of UDP streaming via GStreamer on Raspberry Pi

Frankgg7 · July 13, 2022, 2:47am

Title: B0201 drops out after ~1 minute of gstreamer UDP streaming (B0200s are fine)

Hi, hoping someone can help. I’ve got four Arducam USB cameras running off a Raspberry Pi, streaming H.264 over ethernet to a PC, and I’m pulling each one into OBS as a gstreamer source. Three of them are B0200 and they work perfectly. The B0201 is the problem - after about a minute of UDP streaming it just stops working. It gets quite hot, so I suspect overheating, but here’s the odd part: it ONLY fails when I use gstreamer. If I open the same camera in amcap.exe or the Windows camera app it works fine indefinitely.

The cameras came as B0200 but one was shipped as a B0201 because the supplier didn’t have enough B0200 stock.

I couldn’t get renaming working, so I set the Pi up to identify each camera by its physical USB port instead, which works fine for the other cameras.

Environment: Raspberry Pi sends the h264 stream over ethernet to the PC. The shell script assumes the receiving PC is at 192.168.2.1. OBS shows each port via a gstreamer source.

Shell script (4 cameras):

gst-launch-1.0 -v v4l2src device=/dev/v4l/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.1:1.0-video-index2 ! video/x-h264, width=1920,height=1080 ! h264parse ! queue ! rtph264pay config-interval=10 pt=96 ! udpsink host=192.168.2.1 port=5600 sync=false&
gst-launch-1.0 -v v4l2src device=/dev/v4l/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.2:1.0-video-index2 ! video/x-h264, width=1920,height=1080 ! h264parse ! queue ! rtph264pay config-interval=10 pt=96 ! udpsink host=192.168.2.1 port=5601 sync=false&
gst-launch-1.0 -v v4l2src device=/dev/v4l/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.3:1.0-video-index2 ! video/x-h264, width=1920,height=1080 ! h264parse ! queue ! rtph264pay config-interval=10 pt=96 ! udpsink host=192.168.2.1 port=5602 sync=false&
gst-launch-1.0 -v v4l2src device=/dev/v4l/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.4:1.0-video-index2 ! video/x-h264, width=1920,height=1080 ! h264parse ! queue ! rtph264pay config-interval=10 pt=96 ! udpsink host=192.168.2.1 port=5603 sync=false&

OBS gstreamer source pipeline (udpsrc port changed per camera):

udpsrc port=5600 ! application/x-rtp,media=(string)video,clock-rate=(int)90000,encoding-name=(string)H264 ! rtph264depay ! avdec_h264 output-corrupt=false ! videoconvert ! video.

No error logs really - the source just freezes/goes black. Tried amcap and the Windows camera app and both work fine on the same camera. Any idea why it’s only the B0201 and only under gstreamer?

Dion · July 13, 2022, 6:00am

Hi, Ketai from Arducam support here. Thanks for the detailed setup - that helps a lot.

Before I can point at a cause I’d like to reproduce this on our side using your exact command, since the caps and payload settings matter. Can you paste the exact gstreamer command that fails (the one for the B0201), plus the OBS-side pipeline you’re using to receive it? I’ll run the test and report back within working days.

Frankgg7 · July 13, 2022, 8:40am

Sure, here’s exactly what I’m running.

Shell script (4 cameras):

gst-launch-1.0 -v v4l2src device=/dev/v4l/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.1:1.0-video-index2 ! video/x-h264, width=1920,height=1080 ! h264parse ! queue ! rtph264pay config-interval=10 pt=96 ! udpsink host=192.168.2.1 port=5600 sync=false&
gst-launch-1.0 -v v4l2src device=/dev/v4l/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.2:1.0-video-index2 ! video/x-h264, width=1920,height=1080 ! h264parse ! queue ! rtph264pay config-interval=10 pt=96 ! udpsink host=192.168.2.1 port=5601 sync=false&
gst-launch-1.0 -v v4l2src device=/dev/v4l/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.3:1.0-video-index2 ! video/x-h264, width=1920,height=1080 ! h264parse ! queue ! rtph264pay config-interval=10 pt=96 ! udpsink host=192.168.2.1 port=5602 sync=false&
gst-launch-1.0 -v v4l2src device=/dev/v4l/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.4:1.0-video-index2 ! video/x-h264, width=1920,height=1080 ! h264parse ! queue ! rtph264pay config-interval=10 pt=96 ! udpsink host=192.168.2.1 port=5603 sync=false&

OBS gstreamer source pipeline (udpsrc port changed for each camera):

udpsrc port=5600 ! application/x-rtp,media=(string)video,clock-rate=(int)90000,encoding-name=(string)H264 ! rtph264depay ! avdec_h264 output-corrupt=false ! videoconvert ! video.

Separate but possibly related - I’ve been fighting the renaming too. Changing either the serial number OR the device name makes the cameras stop working properly once re-plugged. The UVC serial tool doesn’t seem to work right for me: after I change the name and follow the instructions on the webpage, the name never changes in Device Manager even after uninstalling and re-plugging, and the green progress bar doesn’t fill up after it completes. Weirdly, the tool DOES read the new name back from the camera. And after the name change the video comes through in grayscale. If I use the firmware tool to reset the cameras they go back to “arducam” and the video is in color again, so the firmware tool itself works fine. amcap.exe can still use the camera even after the “unknown device” error.

Tools I’ve been using: amcap.exe, usbview.exe, OBS gstreamer source, Device Manager. Cameras are B0200 and B0201.

I attached three usbview.exe logs: one right after a fresh firmware install + camera re-plug, one after changing the serial number to 001 but before the re-plug, and one after changing the serial number to 001 and after the re-plug.

Dion · July 13, 2022, 10:41am

Thanks, that’s exactly what I needed.

Given the details, this is starting to look like an isolated case with the B0201 - it’s a different/older design than the B0200 (which is why you got one), and the fact that it runs hot and only flakes out under sustained gstreamer streaming points toward a possible overheating/firmware issue rather than your pipeline. We’ll run your exact commands to confirm.

In the meantime, a couple of things to try:

Use the serial number field rather than changing the USB device name, then re-plug and check the name in Device Manager.
Capture usbview logs before and after as you did, so we can compare the descriptors.

I’ve sent you the firmware package through private message - please check it and try the update on the B0201.

For reference, these are the commands we’ll be testing on our side:

gst-launch-1.0 -v v4l2src device=/dev/v4l/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.1:1.0-video-index2 ! video/x-h264, width=1920,height=1080 ! h264parse ! queue ! rtph264pay config-interval=10 pt=96 ! udpsink host=192.168.2.1 port=5600 sync=false&
gst-launch-1.0 -v v4l2src device=/dev/v4l/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.2:1.0-video-index2 ! video/x-h264, width=1920,height=1080 ! h264parse ! queue ! rtph264pay config-interval=10 pt=96 ! udpsink host=192.168.2.1 port=5601 sync=false&
gst-launch-1.0 -v v4l2src device=/dev/v4l/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.3:1.0-video-index2 ! video/x-h264, width=1920,height=1080 ! h264parse ! queue ! rtph264pay config-interval=10 pt=96 ! udpsink host=192.168.2.1 port=5602 sync=false&
gst-launch-1.0 -v v4l2src device=/dev/v4l/by-path/platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1.4:1.0-video-index2 ! video/x-h264, width=1920,height=1080 ! h264parse ! queue ! rtph264pay config-interval=10 pt=96 ! udpsink host=192.168.2.1 port=5603 sync=false&

Reception side:

udpsrc port=5600 ! application/x-rtp,media=(string)video,clock-rate=(int)90000,encoding-name=(string)H264 ! rtph264depay ! avdec_h264 output-corrupt=false ! videoconvert ! video.

The failure seems specific to the B0201 under gstreamer UDP streaming (v4l2src over /dev/v4l/by-path → h264parse → rtph264pay → udpsink to 192.168.2.1 on ports 5600-5603), so that’s what we’ll reproduce.

Frankgg7 · July 14, 2022, 12:00am

OK, I just tried as suggested. The cameras work normally after changing the serial number - no grayscale and no dropout, which is a good sign. But when I try changing the USB name to just 001 I get the same problem as before: after re-plugging it stops working and OBS gets no stream.

One thing I noticed that might be a clue: after I change the name but BEFORE uninstalling/re-plugging, it actually works fine in amcap.exe - but the USB name still shows as “Arducam USB Camera”. It’s only after the reinstall/replug that it goes wrong. So it seems like the name change doesn’t really take effect until the replug, and that’s exactly when it breaks.

I used usbview.exe to check which port the camera is on, tried the firmware tool on the cameras, and also tried resetting them with the firmware tool.

Dion · July 14, 2022, 6:00am

That’s a really useful distinction - changing the serial number is fine, it’s the USB device name change that breaks it, and only after the replug when the new descriptor actually takes effect (which also matches the grayscale output you saw).

So for now, the practical workaround is: use the serial number method and leave the USB device name at the default (“Arducam USB Camera”). That keeps your color video and streaming intact, and you can still tell the cameras apart by serial / physical port as you’re already doing.

We’re still running the reproduction test with your exact gstreamer commands on our side, and the B0201 does look like an isolated unit rather than a pipeline problem. If the test shows it’s a firmware matter we can update it. If you have the new usbview logs from the “001” name attempt, send them over and I’ll compare the descriptors with the fresh-install log.