Hi Alexey, On Wednesday 07 September 2011 10:46:41 Alexey Fisher wrote: > On 07.09.2011 10:05, Laurent Pinchart wrote: > > 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)
I don't think the driver should parse MJPEG data to extract markers. This can be done by the userspace application. > Any thing else? The number of failed and total control requests would also be interesting. Statistics about the status endpoint would also be interesting, to verify that the device correctly sends control change events for instance (although those are not properly supported in the driver yet). -- Regards, Laurent Pinchart _______________________________________________ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
