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

D Richard Felker III dalias at aerifal.cx
Fri Dec 5 22:15:25 CET 2003

On Fri, Dec 05, 2003 at 12:00:28PM -0600, Zoltan Hidvegi wrote:
> > > > 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.

Yes, but it flickers at a steady, rapid 60 Hz, and your eyes filter
that out, just like on a real TV. On the other hand, 5 Hz flicker
looks horrible.

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

You only have to do the second pass if hard-interlaced is detected the
first time. As long as progressive or telecine is detected, you don't
have to bother with it.

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

I'll try x11. I don't have xv support.


More information about the MPlayer-dev-eng mailing list