linux-kernel - Re: [PATCH] media: uvc: limit max bandwidth for HDMI capture

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YNGmXmxMIXpq7I83@pendragon.ideasonboard.com>
Date:   Tue, 22 Jun 2021 11:59:10 +0300
From:   Laurent Pinchart <laurent.pinchart@...asonboard.com>
To:     Dave Stevenson <dave.stevenson@...pberrypi.com>
Cc:     Mauro Carvalho Chehab <mchehab+huawei@...nel.org>,
        Linux Media Mailing List <linux-media@...r.kernel.org>,
        linuxarm@...wei.com, mauro.chehab@...wei.com,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] media: uvc: limit max bandwidth for HDMI capture

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