Hi Bruce, On Tuesday 09 June 2009 19:12:28 bruce m beach wrote: > > > If the camera doesn't set the EOF bit and doesn't toggle the FID bit > > there's very little I can do. Without any frame boundary information > > the driver can't synchronize itself to the video stream. I'm really > > puzzled by how this camera can work at all. Your last e-mail showed > > that it toggled the FID bit once from 0 to 1 and left it at 1 forever > > after. Is my understanding correct ? > > 100% correct. But don't despair of the republic just yet. Right now > the best you can do is just give me your insights and suggestions. I'm > going to continue working on this thing. I currently believe that it > is a UVC-compliant device (complete with working FID and EOF bits) but > that it is not being set up correctly and is streaming in a mode that > is for diagnostics or some undocumented mode.
I've learnt with time that all kinds of weird behaviours are possible. Vendors tend to be very imaginative when it comes to implementing bugs :-) > I spent a couple of days documenting the lsusb listing and everything points > to it being UVC-compliant. Now what I would really like to know is if I'm > right about the following: > > If there is a stream of mjpeg payloads coming in, whether or not > we can sync them, we still should be able to detect things like > > M_SOF0, M_SOI, M_EOI ... > > in the stream, yet when I scan the packets I get messages like > > lapsystemx kernel: uvcvideo: doing scan > lapsystemx last message repeated 4360 times > > "scan" just searches any packet greater than the header size > (typically 12) and if it finds 0xff it prints out the preceding > and following byte. (in case there is some endianess lurking about) > I can't believe that 4360 payloads come in whithout any jpeg > information at all. If this is the case what are these packets? Good question. Could you dump them ? You could give usbmon a try to dump USB traffic. > Are there other quick tests that I could try in case the device is saying > that it is putting out mjpeg packets but is really putting out another > format? If the device outputs YUYV instead of MJPEG we'll really need a way to synchronize on frame boundaries. I'm not sure it's worth it trying to analyze the data format before getting proper synchronization information. > The other thing I am wondering is what is the format of the *.raw files that > luvcview creates. Are they more or less jpeg files (assuming this particular > case of a webcam doing mjepg streaming) I suppose they're just raw frames of data as received from the driver without any header. > If I toggle the video->last_fid every time a packet comes in it gives me a > convenient way of sending this data to user-land and luvcview then can write > the *.raw files which I can the examine so currently information on these > files is helpful. Be careful that the "frame" rate could get quite high, and luvcview could then loose frames. Best regards, Laurent Pinchart _______________________________________________ Linux-uvc-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
