DirectFB - Home of the pragmatist Roadmap

[directfb-dev] Re: thoughts on why MPlayer dfbmga might be stuttering
Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[directfb-dev] Re: thoughts on why MPlayer dfbmga might be stuttering (

> I was just having a conversation with somebody about his work with
> getting double-buffered Xvideo working in XFree86 with it's tdfx
> Voodoo3 driver (in CVS currently).  He is speculating that his judder
> problem is due to the input and output not being "phase-locked" (i.e.
> Mplayer keeping it's own timing with regard to frame flips).
> That got me to thinking... could this be the problem I am seeing with
> MPlayer -dfbmga -vsync currently?  Even at half-rate (320x240) MPEG1 I
> was seeing a lot of frame re-displays last night.  Is it possible that
> what I am seeing is the result of MPlayer keeping it's own timing
> independent of the G400's vsync?

  For sure.  You can see this pretty easily with the CNN text crawl.
Also make sure mplayer is posting frames regularily, not speeding up and
slowing down around i-frames.  You should do a null output driver that
just takes timestamps and look at them and compare that way first.

  I mean, my ideal thing for 'movietime' was to have it so that I could
sync to the video refresh rate.  PC apps don't like to do this: they
like to sync to your soundcard.  Since your soundcard isn't at exactly
48000khz, it's at like 47500, that adds alot to the 'phase-lock'
problem.  Still, if your input is, say, 'tvtime', then the phase lock
problem shouldn't be all _that_ bad.  Like, you should notice a stutter
maybe once an hour if you're closely watching the CNN text crawl.

  I thought your problem was actually stuff jumping back in time though,
not just the occasional frame-hold?

Billy Biggs

Info:  To unsubscribe send a mail to with 
"unsubscribe directfb-dev" as subject.

Home | Main Index | Thread Index / Development / Old Archives