[MPlayer-users] A/V sync off on x86-64 (and ia32)
jasper at simulistics.com
Mon Apr 24 19:40:20 CEST 2006
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
> 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)
More information about the MPlayer-users