Transferring Two 30fps USB 2.0 Cameras to Another Computer via  Ethernet - Page 1
Forum section: electronics / projects

author: electronx
author_rank: Regular Contributor
timestamp: August 05, 2025, 06:00:43 am
content: Hi everyone,In my project, I have two USB 2.0 cameras, each outputting video at 30 FPS.1. Raw Video Stream CalculationResolution: 5MP (approximately 2592 x 1944 pixels)Frame Rate: 30 FPSFormat: YUV (uncompressed) or MJPG (compressed)YUV (Raw) Stream:1 frame = 2592 x 1944 x 2 bytes (for YUV422) ≈ 10 MB1 second (30 frames) ≈ 300 MB/s (raw data, very high!)MJPG (Compressed) Stream:1 frame is typically between 0.5–2 MB (depending on compression)1 second (30 frames) ≈ 15–60 MB/s2. Actual RAM UsageThe camera image is not continuously written to RAM; usually, a temporary buffer is used.Most capture software keeps a buffer of 2–3 frames (maximum 100–200 MB).I want to transfer the video data from these cameras to a Linux computer over Ethernet. For this conversion,I am considering the following options:Using a direct USB to Ethernet bridge (dont know if uvc needed)Using a USB MCU with megabit Ethernet (mcus doesnt have enough internal ram and doesnt have gigabit ethernet and most of mcu doesnt have uvc , only other usb classes)Using a USB SoM (System on Module) with gigabit Ethernet (best thing , but if there is more cheap solution its bad)My Questions:Which of these solutions would be the most reliable for this use case?Does the host device need to support UVC (USB Video Class) in order to stream the video data from USB cameras to gigabit Ethernet?Is it possible to use a simple and cheap bridge to directly transfer the USB camera data over Ethernet, without a full host system in between?Any advice or suggestions would be greatly appreciated!

author: fchk
author_rank: Frequent Contributor
timestamp: August 05, 2025, 10:00:21 am
content: The best and most reliable solution would be using Ethernet cameras.If you can't go this route because the USB camaras are something special, then you need a small Linux box in between - something like a Raspberry Pi 5.I'm not aware of direct USB-Ethernet bridges that would be suitable. Most USB device servers use Linux SOMs anyway. USB microcontrollers might be possible from a hardware standpoint, but the software is usually not there.For reliability reasons I prefer a Compute Module with EMMC and a suitable carrierboard (Waveshare sells these) over a standard Pi. EMMC is more reliable than most standard uSD cards.https://www.waveshare.com/product/raspberry-pi/boards-kits/cm5/cm5-io-base-b.htm

author: kloetpatra
author_rank: Regular Contributor
timestamp: August 05, 2025, 10:20:48 am
content: Just use a raspi at the sender with dicaffeine. It supports UVC and NDI for network transmission. You may use dicaffeine on your receiver end as well but are not forced to. NDI is state of the art.https://dicaffeine.com/

author: tszaboo
author_rank: Super Contributor
timestamp: August 05, 2025, 10:43:31 am
content: You set up an RSTP server on a SBC and pipe the video feeds into it.Or you buy those cheap wifi security cameras, they are like 20 EUR.

author: kloetpatra
author_rank: Regular Contributor
timestamp: August 05, 2025, 11:15:48 am
content: Quote from: tszaboo on August 05, 2025, 10:43:31 amRSTP = Rapid Spanning Tree Protocol - has nothing to do with thisRTSP = Real-Time Streaming Protocol - is probably what you meantHowever RTSP is really bad as it would need live transcoding. Encoding two 1080p30 streams is an intensive task which most SBCs can not perform. Most not even one.Also RTSP adds hundreds of milliseconds delay. It has poor quality (h264 or h265). Tends to have frame drops and is unstable.NDI however offers near real-time broadcast (1 frame latency). No need for transcoding, better quality, better performance, stable connection, and could do PTZ control / metadata channels.

author: electronx
author_rank: Regular Contributor
timestamp: August 05, 2025, 11:20:38 am
content: Ah, I forgot to mention that I'm designing a final product and I need to use a special form factor. IP cameras are quite large. I actually said we could do this with a SOM module, but a friend of mine insisted on working with MCU. I actually wanted to ask you to confirm.So, when working with two USB cameras, I need a 5-megapixel USB 2.0. In this case, how can I calculate the maximum amount of RAM I need (on embedded Linux) and my maximum CPU speed?

author: magic
author_rank: Super Contributor
timestamp: August 05, 2025, 11:58:44 am
content: You could try USB/IP, which is supposedly a way to make USB devices accessible over network in Linux. It should be easy to set things up if the target machine is Linux and if you could employ a Linux SBC as the USB host. This is likely the optimal solution for minimizing CPU and memory use on the USB host and it doesn't require the host to know anything about UVC and video. Disclaimer: I have never tried it myself.The matter of bandwidth is pretty simple: you can't exceed 30~40MB/s per bus with USB 2.0 no matter what resolution and framerate you use. And if the cameras use isochronous transfer (which is common, though some cameras use bulk transfer) the limit will be even lower at 24MB/s. In practice, you will be forced to use compression for this sort of framerate and I would strongly suggest not re-encoding the video stream on the USB host machine but finding a way to pass it unchanged to the target PC. So most likely, 48MB/s is the bandwidth that you will need for two cameras on separate buses, maybe a ilttle more if they are bulk cameras.The USB host shouldn't need a lot of RAM, but as an absolute minimum, it needs to buffer received USB data until they are successfully sent (and delivered, if you choose a reliable delivery protocol) over the network. For example, at 48MB/s 1MB of spare RAM suffices to cover 20ms latency - probably overkill.

author: fchk
author_rank: Frequent Contributor
timestamp: August 05, 2025, 12:13:42 pm
content: Quote from: electronx on August 05, 2025, 11:20:38 amAre you stuck with these USB cameras? CSI2 cameras are very small and have much lower latency. A Pi (CM4/CM5) can use two CSI2 cameras at a time.And no, don't use a raw MCU. Nobody will pay you for the additional software development. There are tested software stacks for Linux, and you should use them.And yes: I recommend Raspberry CM4 or CM5. Not because they are the best or the cheapest, but because of the whole software ecosystem.

author: kloetpatra
author_rank: Regular Contributor
timestamp: August 05, 2025, 12:38:37 pm
content: Quote from: fchk on August 05, 2025, 12:13:42 pmDon't go for raspi 5 / CM5. Raspi 4 is the only one which got a hardware video encoder (h264). In case you have to encode to h264 raspi 5 can software encode only 1x 1080p30 in ultra poor quality. 2x 1080p30 is not possible. If you really have to transcode video I recommend the jetson nano module or a RK3568 based SoM.

author: fchk
author_rank: Frequent Contributor
timestamp: August 05, 2025, 12:44:51 pm
content: The question is wether to use H.264 or H.265 at all. MJPEG has lower latency and other advantages.The Jetson boards do have much more computing power for transcoding etc. However, Jetson Nano is EOL. You should be using Jetson Orin Nano, which is 3 generations newer. And it's much more expensive.