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 Sat, Dec 07, 2002 at 04:42:39AM +0200, Ville Syrjälä wrote:
> Missing every other vsync would be harmless since mplayer only deals with
> complete frames.

Right.  I understand that.

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

PIII-600.  That should be fast enough I would think.

> 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.


> That too. It sleeps while we're waiting for the interrupt.

By means of the VSYNC ioctl?  But, since I am seeing 29.97 (or
thereabouts) of these in log, my computer must be fast enough to
decode a frame and wait for the interrupt, otherwise I would be seeing
less.  A lot less to account for the judder I am seeing.

> 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.

Right.  This is the reason for Nick's MPlayerXP.

> 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.

And A'rpi won't take it.  He is dead set against threading MPlayer.
That is why Nick had to fork MPlayer into MPlayerXP.  I should go
check his progress.  See if he has merged from MPlayer lately enough
to have the dfbmga driver in it (cvs updating it right now).

> Well there's nothing really special in the hw wrt double buffering. We
> just tell the hardware to look for the data somewhere else.

And we can do that way ahead of the vsync interrupt and have it
actually change it's buffer pointer during the vsync right?

> We just have
> to make sure not to flip the buffers

We have to flip them (as in be fast enough to get woken from our sleep
and issue the flip before the next buffer is actually starting to be
displayed) or ask the hardware to flip them on the vsync?  The
distinction here is huge.  I always thought it was the latter.

> 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.


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

OK.  Sorry about all the questions.  I am both trying to understand,
so I can help debug, as well as thinking (aloud) the whole process
through hoping somebody (you?) will have and epiphany and go "wait!  I
know what it is!".



Brian J. Murrell

Attachment: pgp00005.pgp
Description: PGP signature

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