Hi Philip, On Sunday 20 February 2011 21:57:24 Philip Gladstone wrote: > I attached two C910s to a small linux box, and ran into the 'Failed to > submit URB' problem. > > When I look at the descriptors for this camera, I think I understand the > problem. I'm capturing at 5 Mpixels and I'm trying two cameras. > > VideoStreaming Interface Descriptor: > bLength 38 > bDescriptorType 36 > bDescriptorSubtype 7 (FRAME_MJPEG) > bFrameIndex 28 > bmCapabilities 0x01 > Still image supported > wWidth 2592 > wHeight 1944 > dwMinBitRate 403107840 > dwMaxBitRate 806215680 > dwMaxVideoFrameBufferSize 10077696 > dwDefaultFrameInterval 1000000 > bFrameIntervalType 3 > dwFrameInterval( 0) 1000000 > dwFrameInterval( 1) 1333333 > dwFrameInterval( 2) 2000000 > > The video frame size is set to 10Mb. This is surprisingly large as > actual frames captured with MJPEG on this camera are typically 500kb or > less. When I checked the descriptor for the uncompressed version of the > same frame, it came back with the same value of dwMaxVideoFrameBufferSize > (effectively 16 bits per pixel). The values for min/max bit rate are > (correctly) calculated from the frame intervals and the buffer size.
The uvcvideo driver doesn't use the dwMaxVideoFrameBufferSize field to compute the required bandwidth but queries the device at runtime instead. You can enable the UVC_TRACE_VIDEO trace flag to get the driver to print the bandwidth requested by the device to the kernel log. > Typical JPEG compression gets down to 1 bit per pixel, and 2 bits is > very unusual. > > What I want to know is what the impact would be of defining a new QUIRK > that overrode the frame buffer size for compressed frames and calculated > them at (say) 2 bits per pixel? > > Do other webcams get this right? You would be surprised by how many webcams get things wrong. -- Regards, Laurent Pinchart _______________________________________________ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
