[MPlayer-users] A/V sync bug report (not h/w problem AFAICT)

[Peter Schuller]

Hello,

I've mentioned this before, but I do not think I made myself clear
enough then. The consensus seems to be that if one is having audio sync
problems after having tried all the known fixes, there is a hardware or
driver problem.

I believe I have good reason to believe this is *not* the case because I
am seeing a behavior that, although I'm certainly no hardware / driver
expert, I cannot see be caused by a driver or by hardware.

Firstly, let me say that this occurs mostly on DVD:s, and some times on
DivX files. I can understand the DivX files if they are broken; but I
have no reason to believe the DVD:s are. I am seeing this with at least
the Star Trek: The Motion Picture Director's Cut and Das Boot, and some
ST: TNG episodes from the season 1 DVD set.

Let me explain what typically happens. Please bare with me, I think I
will have you convinced this is not a hardware or driver problem at the
end...

I begin watching a a movie. After a while, I notice that the video is
slowly drifting away from the audio (or the other way around - or both).
So far I believe I have only seen the video lagging behind the audio;
not the other way around.

At this point there is a certain time differential between the audio and
the video. Suppose I have watched for a while, and the differential is
enough to be measurable - say a second or so.

At this point I try re-syncing the video with the audio by pressing the
minus sign; thus making mplayer speed up the video temporarily until the
video is 10 ms "ahead of itself". I keep doing this until the audio and
video appear more or less synchronized.

At this point, interesting things happen. One might expect that it would
again start drifting slowly. However, it doesn't. It drifts *very
quickly* until it is desynced about as much as before I tried resyncing
it. This takes perhaps a few seconds to happen, whereas it took much
longer to "achieve" the original drift.

Speaking purely on intuition without being able to measure this stuff
accurately, I believe mplayer is quickly re-syncronizing with whichever
position in the audio or video stream it deems correct. When it is done,
the a/v drift is equal to what it would have been at that point in time
if I had not tried to resync the audio to begin with. This is the
crucial point I am trying to make; mplayer is actualy *increasing* the
speed of the drift until it reaches a certain amount of a/v desync, at
which time it resumes drifting slowly again.

Pausing and resuming playback has no effect.

Jumping (with the arrows keys) has no effect. Doing so neither increases
nor decreases a/v drift. (I have seen files where jumping will
irreversibly cause an a/v drift; but I am assuming those files were
broken. No a/v drift happened when watching it all the way through
without jumping. -idx had no effect. In either case; I do not believe it
is relevant here.)

The reason I don't believe this to be a driver/hardware problem is the way
it drifts quicker after I resync. Plus; when seeking/jumping the a/v
sync remains exactly what it was before, it does not re-sync anything.
Also, after a while of watching the drift becomes *huge*; I don't
believe there are buffers that large at work in the software nor the
hardware. Especially considering the fact that moving around virtual
desktops in enlightenment while playing a movie yields audio buffer
underruns (I assume; the sound stops for half a second or so)
if the machine is otherwise busy (like if I'm encoding a couple of
oggs at the same time). This would indicate there is not a huge
buffer of several seconds...

I have tried various tricks such as -softsleep, manually specifying an
fps (-fps), and both with and without use of /dev/rtc.

This always happens on some files; never on other's.

Interestingly, if I use mencoder to encode such a DVD using ffmpeg, I no
longer have the lag problem, even when doing AC3 passthrough (I think,
i'm not 100% sure on this; it might only be when using mp3). THis would
indicate that it's not just a matter of the drivers not handling 48khz
audio. Also, if it were to play 48khz audio at 44kz, I would see the
video going *faster* than the audio, not the other way around.

The output of mplayer -v -fs -dvd 1 is available at:

   http://www.scode.org/mplayer-bug/mplayer-bug

I am running on a Linux 2.4.19 kernel; X-server is AcceleratedX
Summit 2.x; video card is ATI Radeon 8500. Sound card is SB Live!, using
the kernel's built-in driver (not ALSA).

Mplayer verison is 0.90pre6, but I've had the same problem on earlier
versions.

I noticed pre7 is out. *compiles pre7 and tries* Nope, same problem :( I
suppose I really should try the current CVS too; but this problem has
been present for a *long* time and I have seen nothing of relevance in
recent list traffic that might indicate the bug has been squashed or
even discussed.

Here's the output of "ldd mplayer":

   http://www.scode.org/mplayer-bug/lddoutput.txt

If there is more information I should provide, or things I should try,
please tell me. But again, as far as I know I've tried all the known a/v
sync tweaks.

-- 
/ Peter Schuller, InfiDyne Technologies HB

PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller at infidyne.com>'
Key retrival: Send an E-Mail to getpgpkey at scode.org
E-Mail: peter.schuller at infidyne.com Web: http://www.scode.org