Hey Laurent, Would you accept a patch for a quirk that adjusts the timestamp for the latency caused by urb_submit(). The adjustment would be done by counting ISO packets. The quirk would be disabled by default. It's a hack but it would do what I need. The URB completion routine runs every 125us - 4 ms depending on the size of the video frame. At 4 ms it limits the resolution of v4l2_buffer.buf.timestamp to 250 Hz. With the proposed patch, the resolution would always be 8 kHz.
I think skew/jitter is a little out of scope for what I am trying to accomplish. I am trying to establish the time at which the photo was taken with as much accuracy as possible. I'm tracking a fast moving target in 3 dimensional space using two webcams. For this, 4 ms accuracy is not enough but 125 microseconds is. The cameras run independent clocks so I need to correlate them to a common clock. At the moment my best option is to correlate it to the PC system time. My application isn't susceptible to clock skew/jitter. It doesn't buffer any data and can accept video whenever it becomes available. Thoughts? Jake -----Original Message----- From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] Sent: Friday, January 01, 2010 2:41 PM To: Jacob Fehr Cc: linux-uvc-devel@lists.berlios.de Subject: Re: [Linux-uvc-devel] Timestamp Accuracy Patch Hi Jacob, On Tuesday 22 December 2009 19:32:38 Jacob Fehr wrote: > Hey Laurent, > > I'm just having a quick look at section 2.4.3.3 in the UVC spec. If I read > that correctly, the SCR SOF counter is not necessarily the same as the USB > SOF frame number. The device can maintain it's own 1 KHz counter and send > that instead of the USBS SOF frame number. That's correct. > That would mean that there is no way to correlate device time to USB time > for devices that maintain their own counter. The only thing the PTS, SCR > could be used for is to determine interframe jitter/skew. > > I have a camera that seems to take advantage of this. I modified the UVC > driver to print out the SCR SOF and urb.start_frame then I plugged two > cameras into the same USB controller. This is a sample log: > > [ 249.799452] uvcvideo: stream = 0xe9ea2000, urb->start_frame = 7590 > [ 249.812207] uvcvideo: stream = 0xe9ea5000, sof = 1158 > [ 249.812217] uvcvideo: stream = 0xe9ea5000, urb->start_frame = 7700 > [ 249.815195] uvcvideo: stream = 0xe9ea2000, sof = 843 > [ 249.815203] uvcvideo: stream = 0xe9ea2000, urb->start_frame = 7723 > [ 249.830206] uvcvideo: stream = 0xe9ea5000, sof = 1174 > [ 249.830216] uvcvideo: stream = 0xe9ea5000, urb->start_frame = 7834 > [ 249.833196] uvcvideo: stream = 0xe9ea2000, sof = 860 > [ 249.833205] uvcvideo: stream = 0xe9ea2000, urb->start_frame = 7857 > [ 249.845958] uvcvideo: stream = 0xe9ea5000, sof = 1191 > [ 249.845967] uvcvideo: stream = 0xe9ea5000, urb->start_frame = 7967 > [ 249.848949] uvcvideo: stream = 0xe9ea2000, sof = 877 > [ 249.848957] uvcvideo: stream = 0xe9ea2000, urb->start_frame = 7990 > [ 249.861710] uvcvideo: stream = 0xe9ea5000, sof = 1208 > [ 249.861720] uvcvideo: stream = 0xe9ea5000, urb->start_frame = 8100 > [ 249.864701] uvcvideo: stream = 0xe9ea2000, sof = 893 > [ 249.864710] uvcvideo: stream = 0xe9ea2000, urb->start_frame = 8123 > [ 249.879704] uvcvideo: stream = 0xe9ea5000, sof = 1224 > [ 249.879714] uvcvideo: stream = 0xe9ea5000, urb->start_frame = 41 > [ 249.882696] uvcvideo: stream = 0xe9ea2000, sof = 910 > [ 249.882705] uvcvideo: stream = 0xe9ea2000, urb->start_frame = 64 > [ 249.895457] uvcvideo: stream = 0xe9ea5000, sof = 1241 > [ 249.895466] uvcvideo: stream = 0xe9ea5000, urb->start_frame = 175 > [ 249.898451] uvcvideo: stream = 0xe9ea2000, sof = 927 > > Camera 0xe9ea5000 seems to be running off a different time reference from > camera 0xe9ea2000. If the cameras did echo the USB SOF into the SCR they > should track with urb->start_frame. Just for the sake of correctness, the start_frame field isn't the SOF counter. It seems to wrap around at 8192, so I guess it's a micro-frame count for high- speed transfers. > As far as I can tell there is no way to correlate the SCR SOF counter to > the USB SOF. It looks like there is no way to (generically) determine the > device latency... The SCR SOF and USB SOF *are* correlated. They run at the same speed and differ by a fixed (but non-deterministic) value. The PTS/SCR relationship can be computed using the PTS/SCR fields in video data headers. The SCR/SOF relationship is known (except for the constant difference), and the SOF/host clock relationship can be computed using the SOF counter and the system time. With all those information, the PTS timestamp associated with the image can be converted to a system time, eliminating clock drift between the camera and system clocks. That's what the PTS/SCR fields are for. > I can't tell when a device will use it's own counter or when it'll echo the > USB SOF frame number. -- Regards, Laurent Pinchart _______________________________________________ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
