I've just tested my assumption on do_gettimeofday and as expected the buffer timestamps do some time traveling when changing the system time :D using jiffies is not an ideal option since it has a lower resolution but since it's monotonic changing system time doesn't affect the time stamps. The ideal would be to use a highres monotonic clock and construct the timestamp from there. This is a major problem for anyone running ntp servers or with any type of automatic time sync.
Best regards, Paulo 2009/11/27 Paulo Assis <[email protected]>: > Laurent, > I've notice that the buffer timestamps are obtained with > do_gettimeofday, this makes me a bit worried, if the system time > changes while streaming I believe this can cause a major error in the > time stamps, also on many systems gettimeofday uses the TSC, but on > some multicore systems the TSC on each core may be out of sync, in > which case the cpu you are running on may give a different > gettimeofday result than another cpu (this may explain the time drift > between consecutive frames in my quad processor) > You should use clock_gettime(CLOCK_MONOTONIC) instead of > gettimeofday() for interval timing, or just do like gspca and use > jiffies, this works very well since it's reference is boot time and > it's monotonic, it also seems more accurate than uvc, at least I don't > notice the same clock drift between consecutive clock frames. > The change for uvc should be easy enough: > > --- uvc_queue.c 2009-11-27 00:26:13 +0000 > +++ uvc_queue_patched.c 2009-11-27 10:06:47 +0000 > @@ -20,6 +20,7 @@ > #include <linux/vmalloc.h> > #include <linux/wait.h> > #include <asm/atomic.h> > +#include <linux/jiffies.h> > > #include "uvcvideo.h" > > @@ -497,7 +498,8 @@ > spin_unlock_irqrestore(&queue->irqlock, flags); > > buf->buf.sequence = queue->sequence++; > - do_gettimeofday(&buf->buf.timestamp); > + jiffies_to_timeval(get_jiffies_64(), > + &buf->buf.timestamp); > > wake_up(&buf->wait); > return nextbuf; > > This change would be very much appreciated, since I'm struggling a bit > with matroska files in some video players (mplayer, vlc) they seem to > require perfectly synced timestamps, I guess they set the internal > clock to the given fps, gstreamer in the other hand works without > problems, it probably uses a higher and fixed resolution clock ( 1ms > ??). > Video Captures from the few gspca cameras I've tested work without > major problems in any of these players. > AVI since it doesn't contain time stamps also works without issues. > > Best regards, > Paulo > _______________________________________________ Linux-uvc-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
