|Site sponsored by IGEL|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[directfb-dev] Re: thoughts on why MPlayer dfbmga might be stuttering
email@example.com (firstname.lastname@example.org): > 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 email@example.com -- Info: To unsubscribe send a mail to firstname.lastname@example.org with "unsubscribe directfb-dev" as subject.