[MPlayer-dev-eng] New inverse-telecine filter

[Zoltan Hidvegi]

> > > Also, the way hard-interlaced mode alternates a couple times per
> > > second between using bottom and top field as a source of interpolation
> > > creates a horrible low-frequency flicker.
> > 
> > Yes, but what else can I do, that's the only way to keep the output
> > rate even for interlaced content.  Ive started to write a motion
> 
> Well then at the very least, you need a better filter.

Yes.  Any suggestions?  That's the same problem as tfields, that
flickers too.

> > compensated deinterlacer which should be used to handle such places,
> > that would reduce or eliminate the flicker, but I do not have time to
> > finish that now.  And I do not think I'll handle fadeing, that would
> > require 3 dimensional motion vectors, where the third dimension is the
> > intensity change.
> 
> How about this. Detect uniform intensity changes across the whole
> frame, and discard them in determining whether the frame is
> progressive/telecine/hard-interlaced. Then compensate for the
> intensity difference. Ultimately the problem is that this material
> _is_ telecined, then poorly edited post-telecine, so it needs to be
> treated as such rather than being treated as interlaced video.

But this requires two passes, first to detect fading, then to look at
what's really happening.  Of course you have to do this only when
interlacing is detected, but then yo have to do 3 pass: normal metric,
if interlacing is detected, an other pass to detect fading, then if
interlaced fading is detected, compensate and do an other pass at the
metrics.  This is a high price to pay for a few badly edited movies,
and a lot of code to write.  My priorities would be to have a good
motion-compensated de-interlacer first for non-fading video.  When
that's working well, be can add the candy to process special effects.

> > > Source format is dvd, vo is mga. It looks to me like you're reusing
> > > your DR buffers before the codec is finished using them for
> > > prediction. (Think B frames!)
> > 
> > I'm not, B frames ate TEMP, I use a separate buffer for those, I look
> > at the type.  And it works with xv and x11, I do not have mga.  Is is
> > possible that the vo is writing it?  Maybe I should set the preserve
> 
> No, the vo doesn't write it, because the vo copies whatever picture it
> gets to video memory. I'm pretty sure the error is on the codec side,
> since putting the scale filter in between fixes it.

But then how come x11 and xv works?  Did you try x11 and xv?

Zoli