On Wed, Nov 02, 2011 at 11:58:04AM +0100, Daniel Glöckner wrote: > On Wed, Nov 02, 2011 at 12:14:49PM +0200, Sakari Ailus wrote: > > > How about making all drivers record monotonic timestamps and doing > > > the conversion to/from realtime timestamps in v4l2-ioctl.c's > > > __video_do_ioctl if requested? We then just need an extension of the > > > spec to switch to monotonic, which can be implemented without touching > > > a single driver. > > > > Converting between the two can be done when making the timestamp but it's > > non-trivial at other times and likely isn't supported. I could be wrong, > > though. This might lead to e.g. timestamps that are taken before switching > > to summer time and for which the conversion is done after the switch. This > > might be a theoretical possibility, but there might be also unfavourable > > interaction with the NTP. > > Summertime/wintertime is purely a userspace thing. UTC as returned by > gettimeofday is unaffected by that. Indeed, that's correct. > NTP AFAIK adjusts the speed of the monotonic clock, so there is a constant > delta between wall clock time and clock monotonic unless there is a leap > second or someone calls settimeofday. Applications currently using the > wall clock timestamps should have trouble dealing with that as well. I wonder if applications do use it for something these days. Some might, but I don't know of any that would be affected. > > I'd probably rather just make a new timestamp in wall clock time in > > v4l2-ioctl.c if needed using do_gettimeofday(). > > I think that would be worse than subtracting ktime_get_monotonic_offset(). > You don't know the delay between capturing a frame and calling dqbuf. Right. As Laurent suggested, doing that in videobuf2 is better option since it gets called when the buffer gets dequeueable. If videobuf2 already has knowledge on what kind of timestamp the user expects it would be possible to do it here. > If there is a settimeofday between capturing a frame and calling dqbuf, > the wall time clock was probably wrong when the frame was captured > and subtracting the new ktime_get_monotonic_offset() yields a better > timestamp. > > > Or just do the wall clock timestamps user space as they are typically > > critical in timing. > > > > How would this work for you? > > As I keep the cpu busy with video encoding in the same thread, I'd expect > a high jitter from taking timestamps in userspace. True. Kind regards, -- Sakari Ailus e-mail: sakari.ailus@xxxxxx jabber/XMPP/Gmail: sailus@xxxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
