On 07.09.2011 10:05, Laurent Pinchart wrote: > 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 :-)).
That's nice :) and on kernel should provide file with statistics. Some thing like: /sys/kernel/debug/uvcvideo/stats It should have - packet count - frame count - payloads with error bit - empthy payloads - overruns, and underruns (for row) - jpeg completation (SOI - EOI) Any thing else? _______________________________________________ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
