[MPlayer-users] A/V sync off on x86-64 (and ia32)

[Jasper Taylor]

On Monday 24 April 2006 17:59, Corey Hickey wrote:
> Jasper Taylor wrote:
> > Hiya...
> >
> > On Friday 14 April 2006 22:01, Guillaume POIRIER wrote:
> >> On 4/14/06, Nico Sabbi <nicola_sabbi at fastwebnet.it> wrote:
> >>> Jasper Taylor wrote:
> >>>> OK, I am putting up a 5MB sample of a file that causes the problem --
> >>>> it appears that only broadcasts on certain channels cause it!
> >>>>
> >>>> It is on your site, called mplayertimingoddity.mpeg
> >>>>       --Jasper
> >>>>
> >>>> On Friday 14 Apr 2006 12:43 pm, Guillaume POIRIER wrote:
> >>>>> Could you please put a sample online so I can try to reproduce the
> >>>>> problem? I've got a x86-64 machine, and all works fine there.
> >>>>>
> >>>>> You can use ftp://www.mplayerhq.hu/MPlayer/incoming/ to upload your
> >>>>> sample.
> >>>
> >>> it's completely and hopelessly broken. No other player can play it, so
> >>> mplayer is making miracles
> >>> already
> >>
> >> Confirmed, both on ia32 and x86-64
> >
> > Any chance of a fix, or should I start mining old versions to get one
> > from before it appeared?
>
> Try using binary search to find the CVS commit that made mplayer stop
> playing it right. I don't know if there's any chance of a fix, if the
> file is indeed hopelessly broken, but finding the exact change to
> mplayer CVS will make a possible fix more likely to happen.

Will do binary search some night I'm having trouble sleeping.

It can't be *that* broken -- this problem is happening about 25% of the time 
when I watch files recorded from UK DVB-T, including the BBC! 
Also on this thread...

On Saturday 15 April 2006 11:01, Nico Sabbi wrote:
> David Jacques wrote:
> >Hi,Nico Sabbi,
> >  The file format is normal mpeg2 ts, it was recorded from a satellite
> > card.
>
> as I suspected

DVB-T actually -- same difference
>
> >I think it is dealt by ~/libmpdemux/demux_ts.c and ~/libmpeg2.
>
> yes, it is.

...although I think what follows is doubtful...

> The problem here is that mplayer decodes data as fast as it can
> (ignoring the correlation between dts, pts and pcr), and sooner or later
> it will
> starve for data, audio and video pts will diverge too much and you will
> have
> an ugly still frame as "video stream".
>
> I'm afraid that in order to fix this problem mplayer will have to be
> modified to
> begin decoding only when the right "time" comes (pcr >= dts)

	--J