buffer timestamps issue with do_gettimeofday
- Date: Thu, 19 Nov 2009 16:26:46 -0600
- From: Dan Vacura <danvacura@xxxxxxxxx>
- Subject: buffer timestamps issue with do_gettimeofday
I'm curious as to why the following recommendation, found here
http://v4l2spec.bytesex.org/spec/x15446.htm, has changed to use
"The struct v4l2_buffer timestamp was changed to a 64 bit integer,
containing the sampling or output time of the frame in nanoseconds.
Additionally timestamps will be in absolute system time, not starting
from zero at the beginning of a stream. The data type name for
timestamps is stamp_t, defined as a signed 64-bit integer. Output
devices should not send a buffer out until the time in the timestamp
field has arrived. I would like to follow SGI's lead, and adopt a
multimedia timestamping system like their UST (Unadjusted System
Time). See http://reality.sgi.com/cpirazzi_engr/lg/time/intro.html.
[This link is no longer valid.] UST uses timestamps that are 64-bit
signed integers (not struct timeval's) and given in nanosecond units.
The UST clock starts at zero when the system is booted and runs
continuously and uniformly. It takes a little over 292 years for UST
to overflow. There is no way to set the UST clock. The regular Linux
time-of-day clock can be changed periodically, which would cause
errors if it were being used for timestamping a multimedia stream. A
real UST style clock will require some support in the kernel that is
not there yet."
I am trying to develop a solution that uses the timestamps for video
encode and when NTP updates occur that go in the past, it's difficult
to establish a positive time delta between subsequent buffers. Also,
the last comment about getting a real UST clock does exist in the
kernel now: ktime_get_ts(...).
video4linux-list mailing list