I have a pair of 501c cameras plugged into this same box.
It's a simple ASUS NUC. It has a high speed USB bus. In fact, currently, both cameras are plugged into their own bus. Not sure if that should even matter.
lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 002: ID 1ab2:0001 Allied Vision Vision device
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 8087:0037 Intel Corp.
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 004 Device 002: ID 1ab2:0001 Allied Vision Vision device
I'm using a docker compose to try and stand up a simple rtsp re-streamer system.
I have a container I named gstreamer that attempts to open up both cameras together and rtsp redirect their frames to an instance of go2rtc also running on this machine. I figured out that I could not run a separate docker container for each camera, and that I apparently needed both camera feeds to be running in the same "process". This was very unfortunate.
I'm using the following GStreamer command in a simple shell script to attempt to feed both cameras to the rtsp server.
gst-launch-1.0 -e \
vmbsrc camera="${CAM0_ID}" settingsfile=/tmp/cam0-settings.xml \
! video/x-raw,format=UYVY \
! videoconvert \
! vah264enc bitrate=8000 key-int-max="${KEYFRAME0}" \
! h264parse \
! queue \
! rtspclientsink location="rtsp://rtsp-server:8554/${CAM0_NAME}" protocols=tcp \
vmbsrc camera="${CAM1_ID}" settingsfile=/tmp/cam1-settings.xml \
! video/x-raw,format=UYVY \
! videoconvert \
! vah264enc bitrate=8000 key-int-max="${KEYFRAME1}" \
! h264parse \
! queue \
! rtspclientsink location="rtsp://rtsp-server:8554/${CAM1_NAME}" protocols=tcp
However, one of the 2 cameras never seems to quite start and work.
I'm able to connect to the 1st camera, and view it's stream via the rtsp server. but the 2nd camera seems to fail to feed it's stream. When running a 'probe' on the 1st camera rtsp re-stream, i get a succesfull output. the probe on the 2nd camera returns an error every time.
If I modify the command to only launch one or the other camera , it works perfectly. In other words, I have no trouble streaming to the rtsp server from either camera by itself. I'm unable to get them both to feed to the rtsp serer though.
This is a log output of the container running the above gstreamer launch command.
gstreamer | Starting GStreamer pipeline for both cameras
gstreamer | Timezone: UTC (all timestamps will be in Zulu/UTC)
gstreamer | Configuration:
gstreamer | cam0: cam0 (DEV_1AB22C044677) @ 10fps
gstreamer | cam1: cam1 (DEV_1AB22C044678) @ 10fps
gstreamer | RTSP: rtsp://rtsp-server:8554/cam0 and rtsp://rtsp-server:8554/cam1
gstreamer | [2026-02-24T16:02:59+00:00] Starting GStreamer pipeline...
gstreamer | 0:00:00.058422591 12 0x58e5e616ca70 WARN msdk msdk.c:393:msdk_init_msdk_session: Failed to initialize a MFX session (undeveloped feature)
gstreamer | Setting pipeline to PAUSED ...
gstreamer | 0:00:01.049911533 11 0x5cdcb6076f60 WARN vmbsrc gstvmbsrc.c:1302:gst_vmbsrc_start:<vmbsrc0> "/tmp/cam0-settings.xml" was given as settingsfile. Other feature settings passed as element properties will be ignored!
gstreamer | Pipeline is live and does not need PREROLL ...
gstreamer | Got context from element 'vah264enc0': gst.va.display.handle=context, gst-display=(GstObject)"\(GstVaDisplayDrm\)\ vadisplaydrm2", description=(string)"Intel\(R\)\ Gen\ Graphics", path=(string)/dev/dri/renderD128;
gstreamer | Progress: (open) Opening Stream
gstreamer | Progress: (connect) Connecting to rtsp://rtsp-server:8554/cam0
gstreamer | Progress: (open) Retrieving server options
gstreamer | Progress: (open) Opened Stream
gstreamer | Pipeline is PREROLLED ...
gstreamer | Setting pipeline to PLAYING ...
gstreamer | New clock: GstSystemClock
gstreamer | Progress: (request) Sending RECORD request
gstreamer | Redistribute latency...
gstreamer | 0:00:01.295387972 11 0x74a2d4000d90 WARN rtspstream rtsp-stream.c:5381:rtp_pad_blocking: Passing event.
gstreamer | 0:00:01.295532352 11 0x74a2d4000d90 WARN rtspstream rtsp-stream.c:5381:rtp_pad_blocking: Passing event.
gstreamer | 0:00:01.295546761 11 0x74a2d4000d90 WARN rtspstream rtsp-stream.c:5381:rtp_pad_blocking: Passing event.
gstreamer | 0:00:01.295553670 11 0x74a2d4000d90 WARN rtspstream rtsp-stream.c:5381:rtp_pad_blocking: Passing event.
gstreamer | 0:00:01.295571942 11 0x74a2d4000d90 WARN rtspstream rtsp-stream.c:5381:rtp_pad_blocking: Passing event.
gstreamer | 0:00:01.295580905 11 0x74a2d4000d90 WARN rtpsession gstrtpsession.c:2484:gst_rtp_session_chain_send_rtp_common:<rtpsession0> Can't determine running time for this packet without knowing configured latency
gstreamer | Progress: (record) Sending server stream info
gstreamer | Progress: (request) SETUP stream 0
gstreamer | Redistribute latency...
gstreamer | Redistribute latency...
gstreamer | Progress: (record) Starting recording
gstreamer | Redistribute latency...
gstreamer | Redistribute latency...
this is a copy of the settings xml template file we use to setup each camera at runtime.
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!--
VimbaX Camera Settings Template — Allied Vision 1800 U-510c (Alvium)
Tokens replaced at container startup by gstreamer-pipeline.sh:
__CAMERA_ID__ → camera device ID (e.g. DEV_1AB22C0B1BFE)
__CAMERA_FPS__ → acquisition frame rate (e.g. 3)
All other values are static. Edit here and rebuild the container to apply.
Format matches VimbaX Viewer "Save Camera Settings" export.
Key settings:
PixelFormat YCbCr422_8_CbYCrY → UYVY in GStreamer
DeviceLinkThroughputLimit 100,000,000 bytes/s (100 MB/s, down from 200 MB/s default)
Rationale: each ~5 MB frame at 100 MB/s takes ~50 ms to transfer (50% duty
cycle at 10fps). Spreading transfers prevents USB burst collision on the
shared root hub when both cameras fire simultaneously at the default 200 MB/s.
ExposureAuto Continuous — camera manages exposure automatically
-->
<ModuleSettings>
<SettingsStruct>
<PersistType Description="Persist all features except LUTs" Value="2" />
<MaxIterations Description="How often implementation shall try to write values to specific feature (due to complex feature dependencies, multiple write operations are sometimes necessary)" Value="10" />
<LoggingLevel Description="All: all messages will be logged (Info, Error, Warning, Debug, Trace)" Value="4" />
</SettingsStruct>
<CameraInfo Id="__CAMERA_ID__" Model="1800 U-510c">
<RemoteDevice>
<Feature Name="AcquisitionFrameRate" Value="__CAMERA_FPS__" Type="Float" />
<Feature Name="AcquisitionFrameRateEnable" Value="1" Type="Bool" />
<Feature Name="AcquisitionFrameRateMode" Value="Basic" Type="Enum" />
<Feature Name="AcquisitionMode" Value="Continuous" Type="Enum" />
<Feature Name="DeviceLinkThroughputLimitMode" Value="On" Type="Enum" />
<Feature Name="DeviceLinkThroughputLimit" Value="100000000" Type="Int" />
<Feature Name="ExposureAuto" Value="Continuous" Type="Enum" />
<Feature Name="Height" Value="2064" Type="Int" />
<Feature Name="PixelFormat" Value="YCbCr422_8_CbYCrY" Type="Enum" />
<Feature Name="Width" Value="2464" Type="Int" />
</RemoteDevice>
</CameraInfo>
</ModuleSettings>
Should we be able to combine 2 cameras in a single GStreamer launch command? Is this possible? or am I attempting to do somethign that can not work. Also, is there any way to have 2 separate containers run their own separate gstreamer process to access each camera. This is a preferred architecture for our system. So far, all my research has indicated that all cameras must be loaded in the same process. A limitation of the SDK I believe.
I have a pair of 501c cameras plugged into this same box.
It's a simple ASUS NUC. It has a high speed USB bus. In fact, currently, both cameras are plugged into their own bus. Not sure if that should even matter.
I'm using a docker compose to try and stand up a simple rtsp re-streamer system.
I have a container I named
gstreamerthat attempts to open up both cameras together and rtsp redirect their frames to an instance of go2rtc also running on this machine. I figured out that I could not run a separate docker container for each camera, and that I apparently needed both camera feeds to be running in the same "process". This was very unfortunate.I'm using the following GStreamer command in a simple shell script to attempt to feed both cameras to the rtsp server.
However, one of the 2 cameras never seems to quite start and work.
I'm able to connect to the 1st camera, and view it's stream via the rtsp server. but the 2nd camera seems to fail to feed it's stream. When running a 'probe' on the 1st camera rtsp re-stream, i get a succesfull output. the probe on the 2nd camera returns an error every time.
If I modify the command to only launch one or the other camera , it works perfectly. In other words, I have no trouble streaming to the rtsp server from either camera by itself. I'm unable to get them both to feed to the rtsp serer though.
This is a log output of the container running the above gstreamer launch command.
this is a copy of the settings xml template file we use to setup each camera at runtime.
Should we be able to combine 2 cameras in a single GStreamer launch command? Is this possible? or am I attempting to do somethign that can not work. Also, is there any way to have 2 separate containers run their own separate gstreamer process to access each camera. This is a preferred architecture for our system. So far, all my research has indicated that all cameras must be loaded in the same process. A limitation of the SDK I believe.