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

[a40e8119bbddbe7b3d281db117f19b32@interlinx.bc.ca]

On Sat, Dec 07, 2002 at 02:03:17AM +0200, Ville Syrjälä wrote:
> 
> Can you post the clip somewhere so I could try it?

I would give you a clip, but I don't have anything to "clip" one out
of a nearly 60 minute episode of the Sopranos, as downloaded from
alt.binaries.multimedia, posted my "Mistress".  Any one of them will
do.  She posts them weekly shortly after Sunday.

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

> Should be per field.

Well, that is what I was thinking too.

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

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

> you should see
> more interrupts.

Indeed, I could see how that could be.

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?

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?

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?

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

b.

-- 
Brian J. Murrell

Attachment: pgp00004.pgp
Description: PGP signature