Am Montag, den 21.02.2011, 08:46 +0100 schrieb Alexey Fisher:
> Am Sonntag, den 20.02.2011, 15:57 -0500 schrieb Philip Gladstone:
> > 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.
> >
> > 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?
Ok, i did some test with my webcam (046d:0991 Logitech, Inc. QuickCam
Pro for Notebooks). With normal conditions, get result with about 1bpp,
but it depend on framerate and captured image. Jpeg is really bad with
text, so i capteured moving text from command line on my display and i
got max 4bpp.
For my test i used this command:
gst-launch -v v4l2src ! image/jpeg,width=320,height=240 ! identity !
decodebin2 ! autovideosink
So it looks like we can recalculate buffer size for jpeg, but the
question is - why? If the cam still provide uncoressed stream it will
fail with big frame size, or it will fail with compressed but bigger
frame size.
The question is, is it possible to make driver calculate the bandwidth
and recalculate it if second cam is inserted, and reduce possible frame
size?
I think not...
Any solution for this problem?
There is a mistake in previous patch, here is fixed one. Can you test it please?
--
Regards,
Alexey
diff --git a/drivers/media/video/uvc/uvc_driver.c b/drivers/media/video/uvc/uvc_driver.c
index a1e9dfb..53e0847 100644
--- a/drivers/media/video/uvc/uvc_driver.c
+++ b/drivers/media/video/uvc/uvc_driver.c
@@ -348,7 +348,7 @@ static int uvc_parse_format(struct uvc_device *dev,
strlcpy(format->name, "MJPEG", sizeof format->name);
format->fcc = V4L2_PIX_FMT_MJPEG;
format->flags = UVC_FMT_FLAG_COMPRESSED;
- format->bpp = 0;
+ format->bpp = 4;
ftype = UVC_VS_FRAME_MJPEG;
break;
@@ -461,10 +461,16 @@ static int uvc_parse_format(struct uvc_device *dev,
* uncompressed formats this can be fixed by computing the
* value from the frame size.
*/
- if (!(format->flags & UVC_FMT_FLAG_COMPRESSED))
+ if (!(format->flags & UVC_FMT_FLAG_COMPRESSED) ||
+ (format->type == UVC_VS_FORMAT_MJPEG))
frame->dwMaxVideoFrameBufferSize = format->bpp
* frame->wWidth * frame->wHeight / 8;
+ printk("---> framesize %ix%i, buffsize %i, bpp %i\n",
+ frame->wWidth, frame->wHeight,
+ frame->dwMaxVideoFrameBufferSize,
+ format->bpp);
+
/* Some bogus devices report dwMinFrameInterval equal to
* dwMaxFrameInterval and have dwFrameIntervalStep set to
* zero. Setting all null intervals to 1 fixes the problem and
_______________________________________________
Linux-uvc-devel mailing list
Linux-uvc-devel@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
