[MPlayer-users] DVD a/v sync strikes back

[Arpi]

Hi,

> As I promised, I've done some research on the DVD a/v sync in my
> library. Here are the results.
> 
> I'm uploading right now three files to mplayerhq: LastBoyscout.vob,
> Fugitive.vob and Unbreakable.vob. Each one is 5M piece of
> VTS_01_1.VOB from DVD with the movie.
> 
> First two files play with constant a/v desync. When I tried to set delay
> by ear I decided that -delay -0.3 was OK. vStrip on the other hand told
> something like this:

>   Sub 0x80 packets = 293, total bytes = 591856 (delay -0:00:00.083)
>   Sub 0x81 packets = 147, total bytes = 296936 (delay -0:00:00.083)

> I was quite amused, but I tested mplayer -delay -0.083 and... The movie
> sounded quite right, both dialogs and shoots/explosions. I guess we are
> more tolerant to audio/video delay in one direction than in the other.

hmm, weird. are you sure that -delay 0.3 and -delay 0.083 are both perfect?
(i mean for human ears)

> When played with mplayer without any a/v delay correction (i.e. simple
> "mplayer -dvd 1") it sounds OK.
> 
> vstrip shows 0.880 delay for audio.
> 
> But when I play this DVD with -mc 0 or -delay 0.880 it is very badly
> desynced.

what about -delay 0.083 ? is it also ok?

why am i asking that?
i've found several possible reasons for 0.80-0.120 ms delays.
there is no special handling of possible delay caused by B frames.
for the standard streams, there are 2 B frames between I/P frames,
it would mean 2*40=80ms delay for 25fps, 2*33ms for 30fps movies.
the another one is double/triple buffering. now it only happens with
-vo mga/xmga by default, and for dga, xv, *vidix with -double.
it may delay 1 (33/40 ms) or 3 (3*33/3*40) ms.
both can be fixed, but it would mean a constant delay.

> What bugs me is this third file. Normally vstrip is right when it takes
> timestamp (that's what PTS is, right?) from first video and audio
yes

> packets in VOB and calculates a/v shift from it.
no, imho vstrip's method is bad.
there is no standard restricting the distance of audio-video packets.
there is probably a maximum (few seconds). there are PTS values
(presentation timestamp) to pair these packets, and play them in sync.
if the timestamps are bad, it's bad. mplayer ignores interleaving for mpegs,
and uses only the timestamp values to sync v to a.

anyway i can imagine that the PTS values were calculated for the original
stream (before mpeg2-compressed) so B frame delay (added by encoder) should
be corrected at playback time. anyway i didn't notice such code in other
players.

> PS. Yes, when I went hunting through my library for DVDs with bad a/v
> sync in mplayer, I've found that lots of them are very badly mastered.
hmm

> But on the other hand, Creative player that comes with DXR3 has no
> problem with correct a/v sync on any of those discs.
it means nothing. afair the dxr3 does the a-v syncing by hardware
(firmware), so the player doesn't matter. it isn't true for mplayer, it
re-creates the mpeg stream including the timestamps...

> PPS. mplayer-0.90pre5

alyways use cvs for testing, anyway the mpeg part didn't change since pre5
so it's ok for now


A'rpi / Astral & ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu