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

[Antonino Daplas <adaplas@pol.net>]

On Sun, 2002-12-08 at 16:25,
a40e8119bbddbe7b3d281db117f19b32@interlinx.bc.ca wrote:
> On Sun, Dec 08, 2002 at 02:29:32PM +0500, Antonino Daplas wrote:
> > 
> 
> [ disclaimer: I am no expert at all on G400 hardware.  My statements
> come solely from what I have learned from an expert or two ]
> 
Neither am I.  You probably know more about matrox hardware than I.

[...]
> 
> >From what I have been told, you can give the G400 a field interlaced
> frame (a frame with both fields in it) and it will display the first
> field, and then the second field, timed properly to the vsyncs.  I
> don't see a need for the front-end to wait for a vsync between those
> fields.  The video card does the work of making sure they are
> displayed one after the other while the front-end goes on th prepare
> the next field interlaced frame for the vsync that occurs after the
> 2nd field is displayed.
> 
Ahh, okay then.  So the matrox hardware automatically displays an
interlaced data stream to an interlaced display device without
additional processing.

>From what I know about this kind of hardware (which is not much), is
that they are more sensitive to the overall system latency rather than
CPU power.  You probably know the latency condition of linux, it's not
just the high latency, but the irregularity of it.  You can easily
compensate for high latency as long as you know it's constant, but a
high latency range from a few milliseconds to a few hundred milliseconds
is a killer.

It's the way how each field is displayed by typical hardware.  This may
not be true with matrox hardware, but with interlaced data, the display
of field 1 starts almost immediately after flipping the frame. The
display of field 2, on the other hand, occurs at a fixed interval
independent of the frame rate. The interval is determined by the
system.  For a PAL system:  25fps, 40ms/frame, 20ms/field.  So field 2
is displayed 20ms after field 1 and whether the frame rate is decreased
or increased, field 2 will always occur 20ms after field 1.

Here is where latency comes in to play.  Assuming that during waiting
for vsync for Frame0, the signal arrived 20ms too late.  Frame0Field1
therefore gets displayed at t20ms, and Frame0Field2, at t20ms+20ms = 
t40ms.  Next, you wait for vsync for Frame1, but this time it gets
delayed by only 5ms.  So Frame1Field1 gets displayed at t45ms.  However
Frame0Field2 is still being displayed by the hardware, and this can
cause visual artifacts.

This misordering/irregular ordering of the display of fields is probably
not noticeable if the scene is slow-paced (delta between fields is
small).  However, with fast-paced scenes (delta is high), that's when
you see tearing, unusual artifacts, etc.  You will also notice that not
a single frame is actually dropped,  and all these artifacts can be
accounted for by irregular delays during the display process.  

This is one of the reasons why frame based data is so much easier to
display properly (because you can always choose to wait or drop frames
depending on the time delay). This is a bit problematic with interlaced
data because of the presence of fields, and worse with NTSC systems
which has a lower frame interval of 33ms.

Anyway, all of the above is moot and academic if you do not use IRQ's
when waiting for vsync, or if the matrox hardware drops delayed fields
automatically.  Polling the registers directly, although it consumes a
lot of CPU cycles, suffers almost no latency penalty.  So, if you are
doing this already, then disregard my entire post and consider it as a
waste of bandwidth.

Tony




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