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 :-) 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. -- Regards, Laurent Pinchart _______________________________________________ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
