[MPlayer-users] A-V Synch and timers...

[Luca Abeni]

Hi all,

I am interested in investigating the effect of the timer (usec_sleep())
precision on the A-V synch accuracy. I see that the CVS version of
mplayer contains some code for using the RTC, and I am trying to do some
experiment to evaluate its effects. I use a very fast CPU (pentium 4 at
1800 Mhz) in order to be sure that the CPU speed is not a problem in my
experiments.

1) As a first thing, I tried to write to a file the difference
     sh_video->timer - (sh_audio->timer - delay)
  and I verified that using RTC can reduce the variance in this value,
but the
  advantage of using the RTC is not really noticeable...
  Since I am fairly new to mplayer, it may be that I am measuring the
wrong value,
  or I am missing something...
  Has someone some suggestion on how the measure the advantages of RTC
in a
  quantitative way?

2) After that, I tried to measure the difference between the time when a
frame is
  played (measured with GetTimer()) and sh_video->timer. Surprisingly,
this value
  decreases during the reproduction of an MPEG movie... After 120
seconds, its mean
  value decreases of about 15 ms. If I understand well, this means that
the video is
  not reproducing at the correct speed (33 FPS). BTW, using the RTC does
not
  change anything here (it only decreases the variation in the measured
value).

I noticed that there is an alternative synch code that can be used (with
-dapsync), but I don't fully understand it... Running with -dapsync, I
obtain some frame drops at the beginning of the movie, then
WARNING: A-V SYNC LAG TOO LARGE: 0.086 {0.026 - -0.060} (too little
UNEXP_CORR_MAX?)
but the difference between the frame display time and sh_video->timer
becomes stable (after an initial transient, in which mplayer tries to
play the video as fast as possible). Hence, the ``problem'' (is it a
problem?) described in 2) seems to be solved...

Has anyone comments/suggestions about new experiments to perform?

				Thanks,
					Luca