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