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

[Zoltan Hidvegi]

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

Whis frame, can you give a frame number?

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

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

OK, I've fond it, at frame 42 in the input.  In the first pass this
frame is indentified at the end of a 3-frame sequence.  The safest
approach would be to show the first two of these 3, which is the last
field of the previous frame, and the first field of the current, but
that would require merging, so for speed, I export the current frame.
But I should probably detect this break correctly in the heuristics,
I'll try to change it.  When the next frame comes, it decides that the
frame boundary is really in the middle of the frame that is already
shown, too late to fix.  This is when delaying by one frame would
help.

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

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
flag when exporting?  Does vd -> crop -> vo_mga work?

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

Maybe, I'll have to look more, I was looking at the full picture, I'll
have to look luma only.

Zoli