Linux: data collection problems with Two USB cameras

Introduction: The subject needs to collect data from two cameras at the same time. The frequency is not high, but at the same time. The problem encountered in the middle is hard to say!

Uvc cameras are used for graphic purposes, but the Board uses the USB interface. Therefore, a UVC-compatible camera is selected, and two 301v chips are selected first, because the frequency is not high, the collection frequency is set to a minimum of five frames per second. It is normal to enable the video stream! Video Buffer out of column, column, normal! Save the image. Normal! Add another camera and use vidioc_streamon to open a camera. Normally, open another camera and report an error!

Error code:

Uvcvideo: failed to submit urb 0 (-28 ).

Suspected insufficient bandwidth,

(From the http://answerpot.com/showthread.php? 272129-stream + from + multimple + cameras)

The uvcvideo driver requests bandwidth based on values reported by the camera.

There are two settings involved there. The first one is the alternate settings
For the video streaming interface. The video streaming interface has
Isochronous endpoint for video streaming, and each alternate setting has
Different Maximum packet size for the endpoint, resulting in different
Bandwidth requirements.

The second one is the dwmaxpayloadtransfersize value reported by the camera
When querying its video streaming control. The driver selects the alternate
Setting with the lowest bandwidth that fulfills the dwmaxpayloadtransfersize
Requirements.

If your camera has a single alternate setting (this can be checked using
Lsusb) You're probably screwed, as the bandwidth is fixed. If it has multiple
Alternate settings, it might be requesting a bandwidth higher than what it
Really needs. In that case you cocould try to hardcode a lower bandwidth (see
The uvc_init_video function in uvc_video.c), or let the driver compute
Bandwidth Estimation on its own by setting the uvc_quirk_fix_bandwidth quirk.

It's also possible to play with urb submission order to use higher bandwidths
And alternate capture between the different webcams. Dennis muhlestein
Investigated that and got interesting results. Search the list archives for
Thread called "multiple camera framerate ".

Depressed for several days, just like a year! Confused, unsolved, alas, cainiao! Are the birds that eat food really not high? Maybe it is not a natural source of code.

Later, I tried two other cameras, 301pl and USB1.1, and linux2.6.28 included the driver of this type of camera (gspca, which is said to be compiled by a French scholar ), two cameras are opened at the same time. Unexpectedly, after three errors are reported

Zc3xx: Probe 2wr ov VGA 0x0000
Zc3xx: Probe 2wr ov VGA 0x0000
Gspca: usb_submit_urb [0] err-28
S3c2410-ohci s3c2410-ohci: leak ed ff1d2140 (#81) state 2
Zc3xx: Probe 2wr ov VGA 0x0000
Gspca: usb_submit_urb [0] err-28
S3c2410-ohci s3c2410-ohci: leak ed ff1d2180 (#81) state 2
Zc3xx: Probe 2wr ov VGA 0x0000
Gspca: usb_submit_urb [0] err-28
S3c2410-ohci s3c2410-ohci: leak ed ff1d21c0 (#81) state 2
Zc3xx: Probe 2wr ov VGA 0x0000
This is vidcapture_thread of left
The 1 of left
State at: 978442537 719669
This is vidcapture_thread of right
The 1 of right
State at: 978442537 823039

I don't know why, but comparing the source code of UVC and gspca drivers, we found that the processing of the return values of the usb_submit_urb () function is different. The gspca adds a judgment on the error code, treat error 28 (enospc) differently from others

/* Submit the URBS */
614 for (n = 0; n <gspca_dev-> OpenGL; n ++ ){
615 ret = usb_submit_urb (gspca_dev-> urb [N], gfp_kernel );
616 If (Ret <0 ){
617 pdebug (d_err | d_stream,
618 "usb_submit_urb [% d] err % d", N, RET );
619 gspca_dev-> streaming = 0;
620 destroy_urbs (gspca_dev );
621 if (ret =-enospc)
622 break;/* try the previous alt */
623 goto out;
624}
625}

In UVC, the system exits as long as the submission fails.

 

Cainiao can only raise the problem, but it is up to the heroes to solve the problem.