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

[D Richard Felker III]

On Fri, Dec 05, 2003 at 03:31:58AM -0600, Zoltan Hidvegi wrote:
> > On Tue, Dec 02, 2003 at 10:10:08AM -0600, Zoltan Hidvegi wrote:
> > > This is a new inverse telecine filter, similar to detc, ivtc and pullup,
> > 
> > OK, I finally tried it, and here's my evaluation...
> > 
> > The main problem I see is that it's too quick to switch to
> > hard-interlaced mode instead of inverse telecine. If it switches even
> > for just one frame in the middle of a telecined sequence, you get a
> > _nasty_ flicker to low quality, especially if there's any small text
> > or other fine detail on the screen. This is very visible in
> > lain-op-hardlaceboy.avi, and to a lesser extent in lain-op-evil-m.avi.
> 
> Yes, lain-op-hardlaceboy.avi is not handled well, try the attached
> patch, that should fix that.  It also lowers the default dint_thres.
> But what's wrong with lain-op-evil-m.avi?  I do not switch to
> interlaced there except in frames 192-200.

It also switches to interlaced for one frame after the M scrolls by,
when the background rapidly brightens.

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.

> > Furthermore, it outputs at least one combed frame on all of the
> > following clips:
> > 
> > lain-ep6-bogus-pulldown.avi
> > lain-ep11-blurroom.avi
> > lain-ep11-bogusmouth.avi *
> > lain-ep11-laser1.avi
> > lain-ep11-laser2.avi *
> > lain-ep11-pronsite.avi
> > lain-ep11-zoomout.avi
> > lain-op-combedbird.avi
> 
> Only had time to look at combedbird, but my output looks good to me,
> and I do not switch to interlace mode in this example.  Which frames
> you do not like?  Since this clip is so still, I have hard time
> finding the trouble spots.

Use -vo png or load in avidemux. There's one frame where at least one
bird is badly combed. It's near the middle of the screen in the lower
right quadrant.

> > BTW, I also found a couple bugs in your code. I'm not sure why, but
> > output is horribly corrupted when rendering
> > 
> >   vd --dr--> pullup2 --export/alloc--> vo
> 
> Exactly what vd/vo did you use?  What is the source format?

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!)

> > but the bug goes away when I change the filter chain to:
> > 
> >   vd --slices--> scale --dr--> pullup2 --export/alloc--> vo
> 
> Because scale uses MP_IMGTYPE_TEMP.

Yes.

> > BTW, if you're curious why all my sample clips are from Lain,
> > everything else I have that I've tried to inverse-telecine has been
> > trivial -- naive algorithms work fine. There are some other
> > contributed clips you could check, some of which have problems with
> > your filter. But many of these are broken or pathological cases and
> > perhaps not worth considering...
> 
> I'll check more samples when I have time.  My heuristics could
> probably use some improvement.  Maybe it would be best to have a
> separate heuristic for anime, since there are more sharp edges and
> fine detail there.  The complex asian characters are also difficult,
> because they look like interlace artifacts to the metric.  But if a
> writing is still, my metric should not detect it as interlaced, since
> it caps the neighbor field diffs with the odd field diff.  The problem
> is that in your samples the characters that should be completely still
> flicker.

Hmm, which ones flicker? I see flicker in the chroma, but luma looks
fairly steady.

Rich