public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Dave Stevenson <dave.stevenson@raspberrypi.com>
Cc: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
	Linux Media Mailing List <linux-media@vger.kernel.org>,
	linuxarm@huawei.com, mauro.chehab@huawei.com,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] media: uvc: limit max bandwidth for HDMI capture
Date: Tue, 22 Jun 2021 11:59:10 +0300	[thread overview]
Message-ID: <YNGmXmxMIXpq7I83@pendragon.ideasonboard.com> (raw)
In-Reply-To: <CAPY8ntAkb_57Nk_8UR-d_uR+juPigLKWwCAxoFzuCSKwETYpQg@mail.gmail.com>

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

  reply	other threads:[~2021-06-22  8:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-01 19:08 [PATCH] media: uvc: limit max bandwidth for HDMI capture Mauro Carvalho Chehab
2021-06-21 18:22 ` Laurent Pinchart
2021-06-22  8:29   ` Mauro Carvalho Chehab
2021-06-22  8:50     ` Dave Stevenson
2021-06-22  8:59       ` Laurent Pinchart [this message]
2021-06-22  9:09         ` Mauro Carvalho Chehab
2021-06-25 19:18     ` Nicolas Dufresne

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YNGmXmxMIXpq7I83@pendragon.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=dave.stevenson@raspberrypi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=mauro.chehab@huawei.com \
    --cc=mchehab+huawei@kernel.org \
    --cc=mchehab@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox