[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.
Rich
More information about the MPlayer-dev-eng
mailing list