Am Donnerstag, den 16.06.2011, 11:31 -0700 schrieb Carl Michal:
>
> On Thu, 16 Jun 2011, Carl Michal wrote:
>
> >
> > On Wed, 15 Jun 2011, Alexey Fisher wrote:
> >
> >> 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
> >>
> > Hi,
> >
> > we're learning a little here. If I set nodrop=1, I get lots of frames that
> > are too short (gst complains that they are fewer bytes than expected) but
> > those coincide with the status < 0 test in uvc_video_decode_isoc - they do
> > not correspond to those with the error bit set.
> >
> > The buf->error=1 in uvc_video_decode_start=1 is unnecessary - harmful even,
> > since it means dropping frames that are in fact ok.
> >
> > I have captured some bad frames though - one that has the colors badly
> > screwed up - where everything is a bright green, and another where the
> > image
> > appears to be shifted about a quarter of a frame to one side - these were
> > collected without the nodrop=1 parameter, so they are not caught as corrupt
> > by any of the current tests. They are delivered as occuring with the full
> > expected frame size. Are there other flags we should be checking for?
> > (hmm,
> > like maybe an FID at the wrong time?)
> >
> > Carl
> >
> > _______________________________________________
> > Linux-uvc-devel mailing list
> > Linux-uvc-devel@lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
> >
>
> Hi,
>
> this gets weirder. Dropping frames where the FID bit is toggled
> unexpectedly looks like it drops lots of good frames, and not all the bad
> ones. But this is not so easy - capturing frames with gstreamer actually
> seems relatively reliable in any case. The fraction of bad frames
> generated seems to depend quite a bit on what program is used - guvcview
> and luvcview produce many more than gstreamer.
>
> I put in checks at the begining of uvc_video_decode_start to look at other
> bits in the header, and found that the camera does occasionally return the
> STI bit and RES bit set, and sometimes doesn't set the EOH. These usually
> happen together, but sometimes just one or two of these bits is
> unexpected. Dropping frames with any one of those unexpected *seems* to
> help, but there are still occasional bad frames.
>
> If EOH is not set does that mean there is more header somewhere?
Do you mean EOH or EOF?
can you please send me one sample of brocken frame, row, not jpeg. Use
"luvcview -C" to capture frames. It will probably use 640x480 in YUV by
default. YOu will get lots of files. To convert it in jpeg you can use
gstreamer:
for i in *.raw; do gst-launch-0.10 filesrc location=$i ! videoparse
format=3 width=640 height=480 ! jpegenc ! filesink location=$i.jpg; done
--
Regards,
Alexey
_______________________________________________
Linux-uvc-devel mailing list
Linux-uvc-devel@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
