Am Freitag, den 24.06.2011, 20:31 +0200 schrieb Laurent Pinchart:
> Hi Alexey,
>
> On Friday 24 June 2011 20:25:03 Alexey Fisher wrote:
> > Am Freitag, den 24.06.2011, 20:08 +0200 schrieb Laurent Pinchart:
> > > On Tuesday 14 June 2011 09:39:47 Alexey Fisher wrote:
> > > > Am Montag, den 13.06.2011, 22:48 -0700 schrieb Carl Michal:
> > > > > > Hi,
> > > > > >
> > > > > > I think you nailed it. Every frame looks perfect now. The trace
> > > > > > shows a few of these:
> > > > > >
> > > > > > Jun 13 09:24:24 uvcvideo: Dropping payload (error bit set)
> > > > > >
> > > > > > but I don't see corrupt frames any more in either MJPG or YUYV (at
> > > > > > 640x480 anyway) - in MJPG all the frames have the right size.
> > > > > >
> > > > > > There is a some weirdness with frame rates depending on the
> > > > > > exposure setting: 1) Exposure, auto gives 4 options: auto priority
> > > > > > mode, manual mode, shutter priority mode, and aperture priority
> > > > > > mode. Auto and shutter don't seem to be settable (errors from
> > > > > > guvcview when chosen). There is also an "Exposure, auto priority"
> > > > > > checkbox.
> > > > > >
> > > > > > Frame rates drop dramatically in manual mode (to 10-15fps from 30).
> > > > > >
> > > > > > But I can't really complain at this point - the corrupt frames are
> > > > > > gone. Will that quirk be added to the driver (usb id is:
> > > > > > 0408:2fb1)?
> > > > > >
> > > > > > Thanks,
> > > > >
> > > > > Hi,
> > > > >
> > > > > it seems like I am much better off by fully disabling FID (with your
> > > > > patch) than before. With the patch, YUYV frames are _always_ the
> > > > > right size. There are still some problems:
> > > > >
> > > > > 1) corrupt frames - with part of the image missing or the image
> > > > > displaced. Sometimes (but definitely not always) these occur at the
> > > > > same time as a trace message saying the error bit is set.
> > > > >
> > > > > 2) sometimes the camera just won't start. when guvcview (or
> > > > > luvcview) is started, no frames come back from the camera. There is
> > > > > a light next to the camera that comes on to indicate it should be
> > > > > active, but no frames arrive. There seems to be a fairly strong
> > > > > correlation with using luvcview (which from the traces seems to use
> > > > > some different mechanism to get frames from the driver from
> > > > > guvcview. guvcview polls, luvcview doesn't). Sometimes just
> > > > > restarting guvcview several times will work and the camera
> > > > > eventually starts. Sometimes just changing resolution or frame
> > > > > rates succeeds in starting the camera. I haven't found anything
> > > > > reproducible. I do not think this is related to your patch, as it
> > > > > did happen once before your patch was applied. Unloading and
> > > > > reloading the uvcvideo and ehci_hcd
> > > > >
> > > > > modules does not consistently solve it. guvcview just lists:
> > > > > Could not grab image (select timeout): Resource temporarily
> > > > > unavailable
> > > > >
> > > > > and the trace shows guvcview polling, but nothing else going on.
> > > > >
> > > > > I have tried adding the other quirks to the FID quirk, but haven't
> > > > > seen any improvement with any others.
> > > > >
> > > > > Thanks for you help -
> > > > >
> > > > > Carl
> > > >
> > > > Webcam returns error in the middle of some frame, theoretically we
> > > > should drop complete frame. But current uvcvideo just gather data and
> > > > assume the cam will resend previous parts to complete the frame.
> > > >
> > > > Try attached patch additionally to my previous one.
> > >
> > > What about not ignoring the data in addition to setting buf->error to 1 ?
> > > This won't solve corruptiong, but would avoid the image effect for
> > > uncompressed formats.
> >
> > My english (and c) are not my bet qualities. But currently i'm really
> > not sure if i understand. Was it sarcasm?
>
> Not at all :-)
Ok, i thought you mean some thing like "avoid the image effect" = "avoid
the image"
> If the error bit is set, the packet will be dropped. For uncompressed
> formats,
> dropping the data will shift part of the frame up/left and possibly mess the
> color ups. Instead of doing that, we could handle packets with the error bit
> set normally. The data will likely be corrupted, but that will "just" corrupt
> a small part of the frame, and won't shift the rest of the frame up/left. We
> should then also set buf->error to 1 as done in your patch, to tell
> applications that the V4L2 buffer contains errors.
Also, you mean:
- return -ENODATA;
+ if (buf != NULL)
+ buf->error = 1;
}
I'll try it on my netbook, it produce 200 packets with error bit set on
every start. Will see how it will looks like.
--
Regards,
Alexey
_______________________________________________
Linux-uvc-devel mailing list
Linux-uvc-devel@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
