Hi Paulo, On Wednesday 05 November 2014 10:13:45 Paulo Assis wrote: > 2014-11-04 23:32 GMT+00:00 Sakari Ailus <sakari.ailus@xxxxxx>: > > Sakari Ailus wrote: > >> yavta does, for example, print both the monotonic timestamp from the > >> buffer and the time when the buffer has been dequeued: > >> > >> <URL:http://git.ideasonboard.org/yavta.git> > >> > >> $ yavta -c /dev/video0 > >> > >> should do it. The first timestamp is the buffer timestamp, and the latter > >> is the one is taken when the buffer is dequeued (by yavta). > > I've done exaclty this with guvcview, and uvcvideo timestamps are completly > unreliable, in some devices they may have just a bit of jitter, but in > others, values go back and forth in time, making them totally unusable. > > Honestly I wouldn't trust device firmware to provide correct timestamps, or > at least I would have the driver perform a couple of tests to make sure > these are at least reasonable: within an expected interval (maybe comparing > it to a reference monotonic clock) or at the very least making sure the > current frame timestamp is not lower than the previous one. I can add that to the uvcvideo driver, but I'd first like to find out whether the device timestamps are really unreliable, or if the problem comes from a bug in the driver's timestamp conversion code. Could you capture images using yavta with an unreliable device, with the uvcvideo trace parameter set to 4096, and send me both the yavta log and the kernel log ? Let's start with a capture sequence of 50 to 100 images. > > Removing the uvcvideo module and loading it again with trace=4096 before > > capturing, and then kernel log would provide more useful information. -- Regards, Laurent Pinchart -- 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
