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
