Hi, On Tuesday 01 December 2009 23:20:08 Paulo Assis wrote: > 2009/12/1 Jacob Fehr <[email protected]>: > > > > 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.
I've reviewed the patch and sent a reply to the mailing list. Have you received it ? > 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). I've discussed the issue with Mauro Carvalho Chehab and Devin Heitmueller, and both agree that moving to a monotonic clock is the right solution. However, this could break applications that rely on the realtime clock. Testing is thus required. I could easily create a test tree on linuxtv.org, but the issue is to get people to test the driver with their applications, as building and using a linuxtv.org mercurial tree is rather difficult for many users. I will thus commit the change to the uvcvideo driver and push that to mainline in order to get a bigger user base for testing. I'm pretty confident few applications (if any) will break, but to be on the safe side I could add a module parameter to select the clock and use the realtime clock by default. What's the general opinion regarding adding a module parameter for clock selection vs. replacing the realtime clock by a monotonic clock completely ? Is anyone here concerned about application breakage ? -- Regards, Laurent Pinchart _______________________________________________ Linux-uvc-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
