On Tue, Jun 22, 2021 at 09:50:37AM +0100, Dave Stevenson wrote: > On Tue, 22 Jun 2021 at 09:29, Mauro Carvalho Chehab wrote: > > Em Mon, 21 Jun 2021 21:22:26 +0300 Laurent Pinchart escreveu: > > > > > Hi Mauro, > > > > > > Thank you for the patch. > > > > Thanks for reviewing it! > > > > > > > > On Mon, Feb 01, 2021 at 08:08:59PM +0100, Mauro Carvalho Chehab wrote: > > > > This device: > > > > 534d:2109 MacroSilicon > > > > > > > > Announces that it supports several frame intervals for > > > > their resolutions for MJPEG compression: > > > > > > > > VideoStreaming Interface Descriptor: > > > > bLength 46 > > > > bDescriptorType 36 > > > > bDescriptorSubtype 7 (FRAME_MJPEG) > > > > bFrameIndex 1 > > > > bmCapabilities 0x00 > > > > Still image unsupported > > > > wWidth 1920 > > > > wHeight 1080 > > > > dwMinBitRate 768000 > > > > dwMaxBitRate 196608000 > > > > dwMaxVideoFrameBufferSize 4147200 > > > > dwDefaultFrameInterval 166666 > > > > bFrameIntervalType 5 > > > > dwFrameInterval( 0) 166666 > > > > dwFrameInterval( 1) 333333 > > > > dwFrameInterval( 2) 400000 > > > > dwFrameInterval( 3) 500000 > > > > dwFrameInterval( 4) 1000000 > > > > > > > > However, the highest frame interval (166666), which means 60 fps > > > > is not supported. For such resolution, the maximum interval > > > > is, instead 333333 (30 fps). > > > > > > What happens if you try to select it ? > > > > Basically, URBs get lost: they cause apps like qv4l2 to crash > > sometimes, with: > > > > v4l-convert: libjpeg error: Corrupt JPEG data: premature end of data segment > > > > The image keeps blinking, and part of the image is replaced by > > white noise. > > > > Clearly, it tries to send more data than the maximum available bandwidth > > on this chipset. > > What platform are you running this on? > I've previously encountered a USB3 camera module where the datastream > was VERY bursty. The memcpy of the data from URB to V4L2 buffer took > long enough that sometimes the module didn't have an URB to fill at > the appropriate moment, and it dropped data. I seem to recall > increasing UVC_URBS from the default of 5 to 10 to handle the peak > data rate without loss, but it may have been higher still. This was on > a ~1.5GHz Atom processor, so not lacking in performance. > > I wonder if the same is true in your case. If it's MJPEG compressed > then the peak rate may again be high. Just a thought. It's worth investigating indeed. How often are URBs dropped ? Does it occur for every frame, or once in a while ? > > Sent a v2 addressing the issues you pointed. -- Regards, Laurent Pinchart
