DirectFB - Home of the pragmatist Roadmap

[directfb-dev] Re: Seeing "tearing" using mplayer dfbmga
Mailing List archive

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

[directfb-dev] Re: Seeing "tearing" using mplayer dfbmga

On Fri, Dec 06, 2002 at 08:32:16PM -0500, wrote:
> > Altough I'm not sure
> > the symptoms would be clearly visible with PAL timing. But wouldn't hurt
> > to try.
> Can you even play an NTSC coded MPEG on a PAL set?

Sure. The only real difference is the frame rate. It's just a matter of
dropping some frames to display "NTSC" MPEGs on a PAL display. And
duplicating some frames if you want to do it the other way around.

> > But if you run mplayer without '-nosound -benchmark'
> > it throttles the output.
> "Ties up" the process for the duration of the (double field) frame you
> mean, which has the effect of missing the vsync between the two fields
> within the frame it's holding for?

Missing every other vsync would be harmless since mplayer only deals with
complete frames.

> > The ioctl is only used when we want an
> > interrupt.
> Right.  And since MPlayer ties up the process, we only end up getting
> the one that happens between Mplayer's frames, not between the two
> fields that are in a frame?  Am I right?


> > If you move the calculation to the irq handler
> Rather than the IOCTL?


> This talk of "throttling" output.  Is it possible that MPlayer is
> holding up the process for too long and we are somehow miss the vsync
> between frames, and playing the same frame twice, in some cases?

Possible and likely if your computer isn't fast enough.

> What does MPlayer do exactly to throttle?  Time how long it has taken
> to decode a frame and load it up and then actively go to sleep for the
> difference between the last frame interval, decoding time and the next
> frame interval?

Yes. A major factor here is the audio since glitches in the audio stream
will be nasty whereas dropping/duplication the occasional frame will not
matter much.

> Or does MPlayer just do it's work and wind up getting blocked trying
> to access something if it can go faster (which it has to of course, or
> it will drop frames itself) than the display frame rate?  What is it
> that MPlayer is trying to access that it gets blocked from?

That too. It sleeps while we're waiting for the interrupt. And this is not
very nice when the computer isn't fast enough. In the worst case the
process ends up sleeping one whole field. Time that could have been used
to decode the next frame. Triple buffering would solve this problem.
Fortunately we already have sort of triple buffering in dfbmga since we
decode to an offscreen surface and blit from there to the backbuffer. I
have a patch for mplayer that creates another thread which will do the
waiting and let's the main thread keep on decoding. Unfortunately
sometimes it breaks down mysteriosly so I haven't submitted it.

> I understand that the G400 is double buffered, so that the
> "back" buffer can be written to while the (front -- is that the right
> term?) is being displayed.

Well there's nothing really special in the hw wrt double buffering. We
just tell the hardware to look for the data somewhere else. We just have
to make sure not to flip the buffers while the hardware is reading them in
the middle of the screen. Fortunately the registers involved will do this
for us but we still have to make sure that they actually have flipped
before we start writing to the new back buffer. Thus we wait for the irq
after flipping not before.

> Is there some kind of semaphore or
> something that gets cleared when the card has moved the back buffer
> contents into the front buffer and it's safe to write into the back
> buffer again? Could MPlayer being missing this event and not writing
> the next frame into the back buffer perhaps?

No. The kernel just puts the process to sleep and wakes it up when irq

Ville Syrjälä

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

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