Am Dienstag, den 14.06.2011, 23:31 -0700 schrieb Carl Michal:
> On Tue, 14 Jun 2011, 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.
> > --
> > Regards,
> > Alexey
> >
>
> Hi,
>
> its very hard to say if this helps or not. There are still corrupt
> frames, and some seem to occur at about the same time as the error bit
> trace messages, but some don't show anything unusual in the traces that
> I've noticed yet.
>
> Since all the uncompressed frames were the right size (even ones where the
> error bit was set somewhere) those frames are at least complete.
>
> Is there some convenient way to capture just those frames with the error
> bit set?
>
> Thanks,
>
> Carl
>
you can try this command:
gst-launch-0.10 -v v4l2src ! video/x-raw-yuv,width=320 ! identity ! jpegenc !
multifilesink location=tmp-%05d.jpg
it will produce for each frame one jpeg file. Watch out, it will produce
lots of files.
Attached patch is replacement for the last one. You do not need setting
trace option, it will print all we need.
--
Regards,
Alexey
diff --git a/drivers/media/video/uvc/uvc_queue.c b/drivers/media/video/uvc/uvc_queue.c
index 109a063..8a9d5af 100644
--- a/drivers/media/video/uvc/uvc_queue.c
+++ b/drivers/media/video/uvc/uvc_queue.c
@@ -608,7 +608,10 @@ struct uvc_buffer *uvc_queue_next_buffer(struct uvc_video_queue *queue,
struct uvc_buffer *nextbuf;
unsigned long flags;
+ pr_info("%s:%i\n", __func__, __LINE__);
+
if ((queue->flags & UVC_QUEUE_DROP_CORRUPTED) && buf->error) {
+ pr_info("%s:%i drop corrupted frame\n", __func__, __LINE__);
buf->error = 0;
buf->state = UVC_BUF_STATE_QUEUED;
buf->buf.bytesused = 0;
diff --git a/drivers/media/video/uvc/uvc_video.c b/drivers/media/video/uvc/uvc_video.c
index d0b59ca..eb2c720 100644
--- a/drivers/media/video/uvc/uvc_video.c
+++ b/drivers/media/video/uvc/uvc_video.c
@@ -421,8 +421,10 @@ static int uvc_video_decode_start(struct uvc_streaming *stream,
/* Skip payloads marked with the error bit ("error frames"). */
if (data[1] & UVC_STREAM_ERR) {
- uvc_trace(UVC_TRACE_FRAME, "Dropping payload (error bit "
- "set).\n");
+ pr_info("Dropping payload (error bit "
+ "set): (%u)\n", stream->sequence);
+ if (buf != NULL)
+ buf->error = 1;
return -ENODATA;
}
@@ -436,8 +438,10 @@ static int uvc_video_decode_start(struct uvc_streaming *stream,
/* Increase the sequence number regardless of any buffer states, so
* that discontinuous sequence numbers always indicate lost frames.
*/
- if (stream->last_fid != fid)
+ if (stream->last_fid != fid) {
stream->sequence++;
+ pr_info("start new frame: %u\n", stream->sequence);
+ }
/* Store the payload FID bit and return immediately when the buffer is
* NULL.
_______________________________________________
Linux-uvc-devel mailing list
Linux-uvc-devel@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
