[MPlayer-dev-eng] New inverse-telecine filter
mplayer at hzoli.2y.net
Fri Dec 5 10:31:58 CET 2003
> 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. You can load the mencoded
result into avidemux, and you can do frame steps, and see exact frame
numbers. Which frame is wrong in evil-m?
> Furthermore, it outputs at least one combed frame on all of the
> following clips:
> lain-ep11-bogusmouth.avi *
> lain-ep11-laser2.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.
> 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?
> 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.
> 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
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
More information about the MPlayer-dev-eng