Jacob Hi, 2009/12/1 Jacob Fehr <jacobf...@smarttech.com>: > Hey Paulo, > > I posted another patch a while ago that is somewhat related to what you are > doing. It removes the latency that happens as a result of USB IO (+/- 4ms) > and takes advantages of the PTS and STC values that are carried in the stream. > > Not sure if you need your timestamps _that_ accurate but I thought I'd let > you know about it. I submitted it to the mailing list a little while. Laurent > is in the process of reviewing the changes that I made.
The problem with latency is the sync between audio and video, also since regular audio frames don't have timestamps, these must be added in the application side and an error is also introduced here, fortunately this is only really noticeable above some tens of miliseconds, so unless you capturing at very low frame rates it won't be much of an issue. The real problem is the variation in time between frames (frame duration), for 30 fps, this would yield an average of 33.333 ms, with a monotonic clock like ktime_get, the frame duration is quite stable (ms) 32-32-36-32-32-36-... (3 frames in 100 ms = 30 fps) but the same is not true for do_gettimeofday in some multicore processors where the frame duration is a bit random, so some players will have a hard time trying to play a video with this random frame durations specially when they expect a steady frame rate. Also non-monotonic based timestamps are subject to big errors in case the system time changes, this is especially true if you are running a ntp server. Anyway gstreamer based applications, like totem, don't seem to have any problems with random frame duration and xine also seems to work without much problems, so the big issue here is the use of a non-monotonic timer, that can cause a negative/future timestamps (this would break any media player). Best regards, Paulo _______________________________________________ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
