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

[D Richard Felker III]

On Fri, Dec 05, 2003 at 10:18:26AM -0600, Zoltan Hidvegi wrote:
> > > 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?

I'll have to use vo_png to do so I think, but I'll try sometime.

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

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

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.

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

Yes, I've found in pullup that you always need to take the safe
approach, even when it hurts performance. There are too many cases
where trying to avoid merging will give you bad output.

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

Yep.

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

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.

> flag when exporting?  Does vd -> crop -> vo_mga work?

Yes, of course.

Rich