Hi Alexey,

On Wednesday 07 September 2011 08:14:45 Alexey Fisher wrote:
> Am 06.09.2011 17:24, schrieb Laurent Pinchart:
> > On Monday 05 September 2011 17:48:42 Alexey Fisher wrote:
> >> Am 31.08.2011 00:32, schrieb Laurent Pinchart:
> >>> On Thursday 25 August 2011 09:44:10 Alexey Fisher wrote:
> >>>> Hi Laurent,
> >>>> 
> >>>> are there any reason why uvc_video_decode_start do not do precise
> >>>> header size checks? Are there many cameras with broken header size
> >>>> too?
> >>> 
> >>> How precise do you mean ? The driver currently doesn't use much of the
> >>> header, so it just makes sure that the header size is smaller than or
> >>> equal to the packet size, and that it's at least 2 bytes long.
> >>> 
> >>>> I send you patch on what i work now to catch streams with fragmented
> >>>> packets.. what do you think about it? Will you apply some thing like
> >>>> this?
> >>> 
> >>> I'm not sure about that. Webcams that would require something like that
> >>> are so broken that I'm tempted to consider them as not UVC-compliant.
> >>> They should be returned to vendors with a loud complaint.
> >>> 
> >>> Your patch might help, but the sad story is that it can't completely
> >>> fix the streams. There's always a chance that fragmented packets that
> >>> contains no header will start with data that looks like a header. You
> >>> won't be able to find a buller-proof solution.
> >> 
> >> You are right,
> >> the idea is not to show definitely broken frames. If there is some thing
> >> what we can't filter, is ok. we did our best.
> > 
> > I understand. I'm not sure if this should be included in the mainline
> > uvcvideo driver though. It makes the code more complex to support a
> > couple of completely broken devices, and doesn't guarantee that those
> > devices will work correctly.
> 
> ok, i give up.

I'm sorry about that. I definitely appreciate the work you've done on this, 
but as I said I don't think we should cripple the driver with complex code 
just to try to support a bit better a webcam that is completely broken anyway.

> >> I just thinking about build in uvc compliance tester insight of the
> >> module. Some thing what users can use right in shop or at home before
> >> 14 day return guarantee.
> >> You enables compliance test and it print results in in dmesg.  One of
> >> test should be header check, error/drop rate, and so on.
> > 
> > That's an interesting idea. It should probably come with a userspace
> > stress test software as well.
> 
> you mean luvcview or some thing other?

I'm thinking about a new command line software that would get/set controls at 
high speed for instance, verify that all controls reported by the device are 
actually supported, start/stop streaming multiple times, ... Something that 
would stress the device and try to crash it (which is unfortunately often 
quite easy :-)).

-- 
Regards,

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

Reply via email to