Hi Andrew, On Monday 13 September 2010 01:30:35 Andrew Leech wrote: > Hi Laurent, all, > That's interesting about the timestamps, I though they were supposed to be > essential for synchronising audio and video properly.
Yes they are... :-) > I'm not using audio myself so not too concerned about that side of things. Same here, that's why timestamp support hasn't been implemented yet. And also because it doesn't seem to be supported in the USB Audio Class driver either. I'd love it if someone could write timestamps support for the uvcvideo driver, but that's a difficult task. > Also, there was a small footnote on one of the msdn pages about interlacing > requiring timestamps so I had tried that for make interlacing work...it > didn't work and interlacing still isn't working properly so I stripped out > oll the interlacing descriptors and I'm going to do deinterlacing manually > now anyway because I need to do frame grabbing to disk so having proper > video card deinterlacing wouldn't help much anyway. > > I think I may have found the source of my fps problems however, my frame is > 768 x576, and as a point of convenience I found that sending 4 lines in a > uvc packet seemed to work just fine. 4 x 768 + 12 (header) turns out to be > 1028 x 3 isoc usb packets, which is obviously more than you're allowed, but > because it was showing the picture just fine I thought it was ok. > Cropping the image to a smaller width though, and making the usb packets > smaller, seems to fix the frame rate in windows. It seems that while the > usb stack can handle the larger isoc packets, there's some buffering in > the uvc driver that's not large enough to work. I still need to do more > testing to confirm that's the root of the problem however. That's actually > what that other message I sent here by mistake was about, I meant to send > it to the lpc3000 group, I need a lot more buffering in chip to get my usb > packet sizes back down to legit sizes. I'll let you all know if I get it > sorted out, because it's a pretty deceptive problem, and highlights a way > your linux driver handles dodgy hardware better! Given the amount of dodgy hardware out there, I'm not surprised that the Linux driver works better than the Windows driver :-) Several vendors ship (or at least used to ship) a custom UVC driver for Windows to work around device bugs. -- Regards, Laurent Pinchart _______________________________________________ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel