[xine-devel] PTS values in mpeg1 streams. was: Re: [xine-user] Audio/video sync

[Heiko S. <hsc...@ft...>]

Hi Scott,

On Sat, 10 Nov 2001, Scott Bigham wrote:

> At first I thought this was a problem with the way I was creating my
> MPEGs, but I've since observed the same symptoms on MPEGs from other
> sources.
>
> First, I'm using the following Debian packages:
>
> ii  libxine0       0.9.4-1        the xine video player library, binary
> ii  xine-dvdnav    0.9.3.beta-1   xine DVD plugin that is capable of
> ii  xine-ui        0.9.4-1        the xine video player, user interface
>
> When I play MPEGs with oss_audio_sync set to 0 (I'm using the oss audio
> driver, as you no doubt already guessed), the audio and video drift out
> of sync; after just a few minutes, the video is aabout a second behind
> the audio, and it gets worse the longer it plays.  With oss_audio_sync
> set to 1, audio and video appear to be in sync, but I get repeated
> messages of the form 'audio_out: adjusting master clock NNNNNNN ->
> MMMMMMM', and anywhere from 3 to 8 frames are reported discarded out of
> every 200 delivered, often resulting in obvious skips in the video.
>
> This doesn't appear to be a CPU overload problem; I had top running in
> another window and it was reporting ~95% idle CPU (for reference, I'm
> running on a Duron 700).  xdpyinfo reports XVideo is supported, and the
> video driver is set to Xv in .xinerc.  hdparm -d /dev/hda reports DMA is
> on; I don't think hard drive speed is likely to be a problem, as it's
> been fast enough to play and record MJPEG files, which are much bigger
> -- and I've also observed the same symptoms on the same MPEGs after
> burning them to VCD.  I'm not entirely sure how to proceed from here.
> Thoughts?  TIA.

i guess you are talking mostly about 'selfmade' non-dvd mpeg1 (or possibly
mpeg2)  streams. if so, then i know this problem - and it appears to be
because of the way lots of these streams are made.

i've had quite a bit of discussion about this topic with guenter, and so
far we agreed that these streams have bad PTS values in them (PTS values
'presentation time stamps' are supposed to tell the player when a video
frame or audio sample should be presented). bad PTS values seem to be a
very widespread problem in mpeg streams - but all evidence points in the
direction that most mpeg1 encoders (or rather: multiplexers) are somewhat
broken.

currently i am planning to do some work on xine's metronom to accept such
'broken' streams - but i'm not yet sure if it's easily possible to find a
good solution that will work for all the numerous types of 'broken' mpeg
streams out there. additionally such a change to xine has to be made
cautiously so that playback of 'good' streams, such as dvds, will not
suffer.

bottomline: please be patient, hopefully this situation will improve in
the next couple of days. if so then i'd be happy to hear if your problem
goes away.

cheers,

Heiko