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 Mon, Dec 09, 2002 at 01:01:15AM +0500, Antonino Daplas wrote:
> Neither am I.  You probably know more about matrox hardware than I.

Doubt it very much.  :-)  Ville on the other hand...

> Ahh, okay then.  So the matrox hardware automatically displays an
> interlaced data stream to an interlaced display device without
> additional processing.

That is my impression.  Check out this thread:

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

I seriously doubt my PVR is experiencing several hundred millisecond
latencies.  I could always be wrong, but I am in doubt.

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

How can the framerate be increased or decreased with fixed framerate
hardware like a television.  The only way to do that is to duplicate
or eliminate frames as necessary to maintain the constant output

> Here is where latency comes in to play.  Assuming that during waiting
> for vsync for Frame0, the signal arrived 20ms too late.

You mean the interrupt?  The signal will always arrive at the right
time.  The kernel may not deliver the interrupt for some time after
the signal arrives however.

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

I don't think so.  It is my understanding that the process is to load
frames into the display buffer prior to the vsync, as early as you can
in fact.  You then tell the card where the image is.  Once this is
done, processing is done until the vsync interrupt because the
hardware will take care to change to the frame you just loaded during
the vblank.  The only way you could lose is that if you take longer
than two fields to load up the next frame.  But MPlayer detects this a
drops frames if I am not mistaken.

> This misordering/irregular ordering of the display of fields is probably
> not noticeable if the scene is slow-paced (delta between fields is
> small).

Correct.  You see juddery movement.


Brian J. Murrell

Attachment: pgp00010.pgp
Description: PGP signature

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