[FFmpeg-devel] libavdevice: PTS stability and risks of drift

[Olivier Guilyardi]

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?

Regarding the clock, In libavdevice/oss_audio.c, the pts is computed out of
av_gettime(), which in turns call gettimeofday().

However, gettimeofday() returns a non monotonic value. In other terms, it is
subject to sudden changes due to NTP updates, etc...

If the PTS absolute value doesn't matter, why not use the POSIX
clock_gettime(CLOCK_MONOTONIC, ..) function, or, on osx, mach_absolute_time()
[1] if available?

This problem also seems to affect the v4l2 demuxer, which computes the pts out
of the timestamp returned by the VIDIOC_QBUF ioctl, which is itself based on
gettimeofday() [2]

I took a look at the dv1394 demuxer (libavdevice/dv1394.c), and I'm unsure how
the video PTS is computed. Is it based on the system clock in any way or on the
dv hardware clock?

My first impression is that the PTS is computed out of the number of retrieved
frames from the DV hardware, which, if this is interrupt-driven, means the dv
hardware clock is used. This is likely to drift away from the system time, and
thus get out of sync of, say, audio recorded using oss (NTP or not). Isn't it?

The libdc1394 demuxer (libavdevice/libdc1394.c) also seems to base its PTS on
the number of frames that has been received from the HW.

[1] http://www.wand.net.nz/~smr26/wordpress/2009/01/19/monotonic-time-in-mac-os-x/

[2]
http://www.linuxtv.org/downloads/video4linux/API/V4L2_API/spec/x3475.htm#V4L2-BUFFER

--
  Olivier