[FFmpeg-devel] libavdevice: PTS stability and risks of drift
Mon Feb 2 16:22:54 CET 2009
On Mon, Feb 02, 2009 at 02:50:02PM +0100, Luca Abeni wrote:
> Olivier Guilyardi wrote:
> > Hi everyone,
> > I'm currently writing a JACK indev for libavdevice, and trying to understand how
> > PTS are/must be computed, and how they're used for A/V sync.
> > First, in the packets returned by the libavdevice read_packet() function, is the
> > PTS used as a running counter, or does its absolute value matter?
> In my understanding, the absolute time matters (otherwise, it would be impossible
> to synchronise a video input with an audio input, for example).
> I do not know what to say about the "gettimeofday() vs monotonic clock" issue,
> since I do not know NTP too much (can it really cause such large "jumps" in the
> system time?).
yes, if your time is off by an hour, it can change it by an hour
for ffmpeg, id say that if the admin configures his system in a way that
allows such things to happen then thats the admins problem, such system is
not fit for capturing audio or video.
she either should ensure that the system clock is just adjusted very slightly
or not at all. In practice running something once a day or hour should be a
bad idea, one either should have a daemon or nothing.
And nothing of course will cause problems if the duration of a long recording
> Anyway, I believe that directly using gettimeofday() (or some other call
> providing the current system time) is problematic, because we need to know
> the time when the data was sampled, not the time when we read it from the
> device... In this regard, I believe that both the v4l2 input and the ALSA
> input use the correct value for PTS. Does the Jack API provide some similar
> call for reading the time when the data was sampled?
> > If the PTS absolute value doesn't matter, why not use the POSIX
> > clock_gettime(CLOCK_MONOTONIC, ..) function, or, on osx, mach_absolute_time()
> >  if available?
> This has the same problem I pointed out above.
also it seems not mandatory in posix just optional
besides monotonic we need a accurate clock
monotonic and otherwise wrong is not any better than non monotonic
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Frequently ignored awnser#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel