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

[Antonino Daplas <adaplas@pol.net>]

On Sat, 2002-12-07 at 14:27,
a40e8119bbddbe7b3d281db117f19b32@interlinx.bc.ca wrote:
> 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.
> 
Depends on the data.  Should be fast enough for VCD like mpegs, but DVD
needs a very fast bus/CPU.

> > 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.
> 
> Right.
> 
> > 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.
> 
If you're seeing half the rate, then the CPU is either too slow, you're
sleeping too long, or mpeg processing takes a lot of time.

request flip -> wait for sync1 -> return -> process next field/frame ->
takes too long, sync2 passed -> request flip -> wait for sync3 -> rinse
and repeat.

However, the symptom of a slow cpu is skipped frames, not a repeat of
the previous frame, because mplayer checks the time stamps (ie if actual
interval exceeds needed interval, skip this frame).

Some possibilites that can be considered:  

1.  Direct rendering implies writing to the video memory directly, which
is not just slow, but can be cached. In some hardware, you actually need
to do a read of the video memory (even just one byte, just to flush the
contents) to ensure that everything is in sync.  Especially true with
MTRR.  MTRR accumulates all those little writes and after a certain
threshhold, burst write everything at once.

2. Waiting for vsync does not necessarily mean that the actual flip has
occured.  If this happens, mplayer may begin writing to the same buffer
that is in the process of being flipped (can cause shaky display, or
visual artifacts). In some hardware, there is an extra flag which says,
"yes a vsync has occured, but I'm only setting this flag after the
actual buffer flip".  I don't know about matrox hardware, but maybe
there is one like that.  Or just wait for the end of vblank, since the
end of vblank occurs some time after the end of vsync.

3.  Direct rendering to video memory might not be the correct way to go,
not just for reasons 1 and 2.  It's better if the mplayer backend do the
processing of video to a temporary buffer in system memory, instead of
directly to video ram (This is how Xvideo does it). At first glance, it
might seem slower, but mplayer may read the contents of the previous
buffer (for hardware MC, or whatever?), and video memory reads are
10-20x slower than writes.

4.  Which is why we really need an AGP surface in DirectFB for things
like video :)

Tony





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