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

[a40e8119bbddbe7b3d281db117f19b32@interlinx.bc.ca]

On Tue, Dec 03, 2002 at 08:17:22PM -0600, Billy Biggs wrote:
> 
>   You're playing an interlaced MPEG file?

Most definately.

>   It's not that mplayer is doing anything wrong, they're just treating
> the input as progressive.

Which is not wrong if the input is actually interlaced?

> The problem is that interlaced MPEG files
> may give frames as either top-field-first or bottom-field-first

Right, which we (Billy and I) have discussed before.  And I can agree
that if you are treating the data as progressive and de-interlacing
every adjacent field/frame, who cares?  But we most definately are
not.  We need to preserve the field parity.

In my last message on this thread Billy, I described a scene which was
pretty still except for a waiter walking left to right across the
scene.  While his general movement was left to right, his movement did
have little right to left jumps in it.  I played this scene over and
over again (MPlayer's "seek -1" command) and I *think* I saw smoother
motion in some instances than I saw in others.  I am wondering if it
was making a difference if the "seek -1" was restaring at a top-field
or a bottom-field.

I wonder how much work it would be to get MPlayer to treat field
ordering properly.  I have never really looked at MPlayer's mpeg2
decoder but it would be a worthwhile effort.  Maybe I will crack it
open and see if I can learn a thing or two about decoding MPEG2 with
libmpeg2.

> and
> they may switch if the repeat-first-field flag is ever used in the
> file.

This is an MPEG2 compression technique to basically say that there was
no change between the last field and this one, so just repeat the last
field?

Do you think MPlayer ignores these and just continues to take field
after field and make "progressive" frames out of them?  Would this not
screw up the A/V sync?

b.

-- 
Brian J. Murrell

Attachment: pgp00002.pgp
Description: PGP signature