Re: [Linux-uvc-devel] Quanta integrated webcam

Mon, 13 Jun 2011 22:51:53 -0700 

On Mon, 13 Jun 2011, Carl Michal wrote:


On Mon, 13 Jun 2011, Alexey Fisher wrote:


 On So, 2011-06-12 at 21:05 -0700, Carl Michal wrote:
>  On Sun, 12 Jun 2011, Alexey Fisher wrote:
> > > Am Samstag, den 11.06.2011, 23:33 -0700 schrieb Carl Michal: > > > > > > On Sun, 12 Jun 2011, Alexey Fisher wrote: > > > > > > > On Sa, 2011-06-11 at 21:55 -0700, Carl Michal wrote: > > > > > > > > > > > > > > 2011/6/7 Alexey Fisher <bug-tr...@fisher-privat.net>: 
> > > > > > > >   On Mo, 2011-06-06 at 17:31 -0700, Carl Michal wrote:
> > > > > > > > >   Hello,
> > > > > > > > > > > > > > > > > > I'm having some trouble with a Quanta integrated > > > > > > > > > webcam. It 
> > > > > > > > >   identifies
> > > > > > > > > itself as: Laptop_Integrated_Webcam_2HDM, usbid: > > > > > > > > > 0408:2fb1. This is 
> > > > > > > > >   built
> > > > > > > > >   in to a Dell XPS-15 (L501X).
> > > > > > > > > > > > > > > > > > The uvcvideo module works, but the video stutters and > > > > > > > > > has some 
> > > > > > > > >   distortions, even at low resolutions and frame rates.
> > > > > > > > > > > > > > > > > > With the Camera Output set to MJPG (in guvcview) > > > > > > > > > "Ignoring empty 
> > > > > > > > >   buffer ..."
> > > > > > > > >   messages occur with most glitches.
> > > > > > > > > > > > > > I would say the camera is not returning the full frame (or > > > > > > > maybe empty 
> > > > > > >   ones) for same reason.
> > > > > > > > > > > > > > > > > > > > > > > > > If the output is set to YV12, the errors look like: > > > > > > > > > > > > > > > > > > VIDIOC_DQBUF - Unable to dequeue buffer : Input/output > > > > > > > > > error 
> > > > > > > > >   Error grabbing image
> > > > > > > > > libv4l2: error converting / decoding frame data: > > > > > > > > > v4l-convert: error 
> > > > > > > > >   parsing JPEG header: Not a JPG file ?
> > > > > > > > > > > > > > > > > > > > > > > YV12 is a format returned by libv4l, and it's obtained by > > > > > > > decompressing the MJPG stream, so in fact the camera is > > > > > > > still in MJPG 
> > > > > > >   format like above.
> > > > > > > > > > > > > > > > With cheese, the video preview looks ok, but video > > > > > > > > > capture is > > > > > > > > > unusable - the video stutters badly at low resolution, > > > > > > > > > and the capture > > > > > > > > > hangs at high resolution (the program doesn't hang, but > > > > > > > > > after a couple 
> > > > > > > > >   of
> > > > > > > > >   frames no more get captured).
> > > > > > > > > > > > > > > > > > > > > > Probably the same situation as above (incomplete or empty > > > > > > > frames) > > > > > > > > > > > > > > > > > > > > > You should also increase uvc video verbosity and check > > > > > > > dmesg for errors. > > > > > > > > > > > > > > From the looks of it I would say you are having some > > > > > > > hardware sync > > > > > > > issues, did you try all possible resolutions and frame > > > > > > > rates ? 
> > > > > > >   Do these issues happen in all formats
> > > > > > > > > > > > > > Regards, 
> > > > > > >   Paulo
> > > > > > > > > > > > > > > > > I've looked through the traces I've gotten with this webcam a > > > > > little and > > > > > noticed something that may help. The out of sync errors are > > > > > always starts 
> > > > >  with a sequence like this:
> > > > > > > > > > Jun 11 21:41:59 uvcvideo: Frame complete (EOF found) buf: 1, > > > > > bytes: 64684. 
> > > > >  Jun 11 21:41:59 uvcvideo: EOF in empty payload.
> > > > >  Jun 11 21:41:59 uvcvideo: uvc_v4l2_poll
> > > > >  Jun 11 21:41:59 uvcvideo: uvc_v4l2_ioctl(VIDIOC_DQBUF)
> > > > >  Jun 11 21:41:59 uvcvideo: Dequeuing buffer 1 (4, 64684 bytes).
> > > > >  Jun 11 21:41:59 uvcvideo: uvc_v4l2_ioctl(VIDIOC_QBUF)
> > > > >  Jun 11 21:41:59 uvcvideo: Queuing buffer 1.
> > > > >  Jun 11 21:41:59 uvcvideo: uvc_v4l2_poll
> > > > > Jun 11 21:41:59 uvcvideo: Frame complete (EOF found) buf: 2, > > > > > bytes: 64728. 
> > > > >  Jun 11 21:41:59 uvcvideo: EOF in empty payload.
> > > > >  Jun 11 21:41:59 uvcvideo: uvc_v4l2_poll
> > > > >  Jun 11 21:41:59 uvcvideo: uvc_v4l2_ioctl(VIDIOC_DQBUF)
> > > > >  Jun 11 21:41:59 uvcvideo: Dequeuing buffer 2 (4, 64728 bytes).
> > > > >  Jun 11 21:41:59 uvcvideo: uvc_v4l2_ioctl(VIDIOC_QBUF)
> > > > >  Jun 11 21:41:59 uvcvideo: Queuing buffer 2.
> > > > >  Jun 11 21:41:59 uvcvideo: uvc_v4l2_poll
> > > > > Jun 11 21:41:59 uvcvideo: Frame complete (FID bit toggled) buf: > > > > > 3, bytes: 63504. > > > > > Jun 11 21:41:59 uvcvideo: Frame complete (EOF found) buf: 0, > > > > > bytes: 1072. 
> > > > >  Jun 11 21:41:59 uvcvideo: EOF in empty payload.
> > > > >  Jun 11 21:41:59 uvcvideo: uvc_v4l2_poll
> > > > >  Jun 11 21:41:59 uvcvideo: uvc_v4l2_ioctl(VIDIOC_DQBUF)
> > > > >  Jun 11 21:41:59 uvcvideo: Dequeuing buffer 3 (4, 63504 bytes).
> > > > >  Jun 11 21:41:59 uvcvideo: uvc_v4l2_ioctl(VIDIOC_QBUF)
> > > > >  Jun 11 21:41:59 uvcvideo: Queuing buffer 3.
> > > > >  Jun 11 21:41:59 uvcvideo: uvc_v4l2_poll
> > > > >  Jun 11 21:41:59 uvcvideo: uvc_v4l2_ioctl(VIDIOC_DQBUF)
> > > > >  Jun 11 21:41:59 uvcvideo: Dequeuing buffer 0 (4, 1072 bytes).
> > > > >  Jun 11 21:41:59 uvcvideo: uvc_v4l2_ioctl(VIDIOC_QBUF)
> > > > >  Jun 11 21:41:59 uvcvideo: Queuing buffer 0.
> > > > >  Jun 11 21:41:59 uvcvideo: uvc_v4l2_poll
> > > > >  Jun 11 21:41:59 uvcvideo: Dropping payload (out of sync).
> > > > >  Jun 11 21:41:59 uvcvideo: Dropping payload (out of sync).
> > > > > > > > > > I've added a couple of fields to the frame complete messages to > > > > > indicate > > > > > which buffer is marked as complete and how many bytes were > > > > > delivered to 
> > > > >  it.
> > > > > > > > > > Most frames are terminated with EOF, but occasionally an FID and > > > > > EOF > > > > > are found in the same packet. So two buffers are marked as > > > > > completed, but 
> > > > >  the second one shouldn't be (I don't think).
> > > > > > > > > > Any advice on where to look next? > > > > > > > > Try fid quirk: 
> > > >  uvcvideo quirks=0x10
> > > > > > > > for more quirks see: 
> > > >  grep QUIRK linux-2.6/drivers/media/video/uvc/uvcvideo.h
> > > >  UVC_QUIRK_STATUS_INTERVAL 0x00000001
> > > >  UVC_QUIRK_PROBE_MINMAX 0x00000002
> > > >  UVC_QUIRK_PROBE_EXTRAFIELDS 0x00000004
> > > >  UVC_QUIRK_BUILTIN_ISIGHT 0x00000008
> > > >  UVC_QUIRK_STREAM_NO_FID 0x00000010
> > > >  UVC_QUIRK_IGNORE_SELECTOR_UNIT 0x00000020
> > > >  UVC_QUIRK_FIX_BANDWIDTH 0x00000080
> > > >  UVC_QUIRK_PROBE_DEF 0x00000100
> > > >  UVC_QUIRK_RESTRICT_FRAME_RATE 0x00000200
> > > > > > > > -- 
> > > >  Regards,
> > > >         Alexey
> > > > > > > > > > > > > > the fid quirk actually makes it quite a bit worse - many more out of > > > sync 
> > >  errors.  None of the other quirks (individually) solve the issue.
> > > > > > I stuck in a crude hack to ignore the EOF that is found in the same > > > packet > > > as the fid toggle, and then the number of sync errors is > > > dramatically 
> > >  reduced, but there are still some bad frames.  What next?
> > > > Am i correct, your trace is for mjpeg format? > > Becouse buffers have different size, with uncompressed stream should > > get 
> >  always same size.
> > There are two way to mark frame as complete, at frame beginning (FID) > > or > > at frame end (EOF). EOF is optional, FID is important. Some cams do > > not 
> >  do FID or brake it, in this case we use QUIRK_NO_FID, so EOF is used.
> >  But we do not have EOF quirk. Let us try to ignore EOF, there is
> >  attached patch.
> > > > -- 
> >  Regards,
> >         Alexey
> > > Hi, > > With your patch the sync errors are almost completely gone, but there > are 
>  still corrupt frames - YUYV output is much worse than before (yes - the
>  earlier traces were MJPG).
> > This is from YUYV at 640x480, 30fps 
>  things are good for a while but then:
> > Jun 12 09:36:14 uvcvideo: Frame complete (FID bit toggled) buf: 3. > bytes: 614400 
>  Jun 12 09:36:14 uvcvideo: uvc_v4l2_poll
>  Jun 12 09:36:14 uvcvideo: uvc_v4l2_ioctl(VIDIOC_DQBUF)
>  Jun 12 09:36:14 uvcvideo: Dequeuing buffer 3 (4, 614400 bytes).
>  Jun 12 09:36:14 uvcvideo: uvc_v4l2_ioctl(VIDIOC_QBUF)
>  Jun 12 09:36:14 uvcvideo: Queuing buffer 3.
>  Jun 12 09:36:14 uvcvideo: uvc_v4l2_poll
> Jun 12 09:36:14 uvcvideo: Frame complete (FID bit toggled) buf: 0. > bytes: 150952 > Jun 12 09:36:14 uvcvideo: Frame complete (FID bit toggled) buf: 1. > bytes: 2024 
>  Jun 12 09:36:14 uvcvideo: uvc_v4l2_poll
>  Jun 12 09:36:14 uvcvideo: uvc_v4l2_ioctl(VIDIOC_DQBUF)
>  Jun 12 09:36:14 uvcvideo: Dequeuing buffer 0 (4, 150952 bytes).
>  Jun 12 09:36:14 uvcvideo: uvc_v4l2_ioctl(VIDIOC_QBUF)
>  Jun 12 09:36:14 uvcvideo: Queuing buffer 0.
>  Jun 12 09:36:14 uvcvideo: uvc_v4l2_poll
>  Jun 12 09:36:14 uvcvideo: uvc_v4l2_ioctl(VIDIOC_DQBUF)
>  Jun 12 09:36:14 uvcvideo: Dequeuing buffer 1 (4, 2024 bytes).
>  Jun 12 09:36:14 uvcvideo: uvc_v4l2_ioctl(VIDIOC_QBUF)
>  Jun 12 09:36:14 uvcvideo: Queuing buffer 1.
>  Jun 12 09:36:14 uvcvideo: uvc_v4l2_poll
> Jun 12 09:36:14 uvcvideo: Frame complete (FID bit toggled) buf: 2. > bytes: 461400 
>  Jun 12 09:36:14 uvcvideo: uvc_v4l2_poll
>  Jun 12 09:36:14 uvcvideo: uvc_v4l2_ioctl(VIDIOC_DQBUF)
>  Jun 12 09:36:14 uvcvideo: Dequeuing buffer 2 (4, 461400 bytes).
>  Jun 12 09:36:14 uvcvideo: uvc_v4l2_ioctl(VIDIOC_QBUF)
>  Jun 12 09:36:14 uvcvideo: Queuing buffer 2.
>  Jun 12 09:36:14 uvcvideo: uvc_v4l2_poll
> Jun 12 09:36:14 uvcvideo: Frame complete (FID bit toggled) buf: 3. > bytes: 614400 > > where interestingly - the 150952+2024+461400 = 614376, which is 24 bytes > short of 614400. The headers are 12 bytes long. Seems like a weird > conincidence. 

 "Dropping payload (out of sync)" say nothing but: FID was not tugged at
 the time we was expecting it.

 I just realized: NO_FID quirk, do not disables FID handling if there is
 some wrong FID bit appear. It assume webcam do not use FID bit at all.

 Try attached patch and load module with NO_FID quirk - quirks=0x10

 --
 Regards,
        Alexey


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,

Carl






_______________________________________________
Linux-uvc-devel mailing list
Linux-uvc-devel@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/linux-uvc-devel



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

Reply via email to