[MPlayer-dev-eng] design for motion-adaptive deinterlacer

[D Richard Felker III]

On Sun, Apr 25, 2004 at 01:47:30AM +0200, Michael Niedermayer wrote:
> Hi
> 
> On Saturday 24 April 2004 22:09, D Richard Felker III wrote:
> > I've been thinking about writing a good motion-adaptive deinterlacer,
> > since they all seem to suck. So I'm sending a few ideas to the list
> > for feedback (or in case someone wants to implement it since I'm
> > lazy... :)
> ive also thought about a similar filter a long time ago, but so far i just 
> wrote  0 lines of code for it :)

Well as a side-effect, the test code I wrote so far doubles as an
inverse-telecine postprocessor. (If you ivtc bad mpeg2 encodes, you
get some combing from the quantization errors not matching up between
the fields, and you need a filter to detect and blend out the
remaining combing. This doesn't require motion compensation, just
detecting motion+combing and blending it away. :)

> > I've performed tests for step 3 and 4 and it looks promising. The
> > resulting data also suggested a procedure like 5. I suspect the
> > results would be much better with steps 1 and 2 to help us throw away
> > false positives (by only checking for combing where there's motion).
> >
> > I also tested some motion estimation/compensation stuff, but I have no
> > experience with that so it came out really bad... :)
> yes, ME is IMO the most difficult part, thats also why i never wrote such a 
> filter ...

Well IMO steps 1-5 alone will give you good results if you use a good
non-motion-compensating deinterlacer afterwards. Certainly much better
than kerndeint & similar stuff in the various windows apps. But I
agree, ME is the holy grail of deinterlacing.

> one problem, with finding the true motion, which is pretty much the goal here 
> and in similar filters, is that motion estimation tends to fail in areas 
> without enough details, simply because there are many well matching vectors 
> and the correct one is rarely the best matching, think of nearly constant 
> color areas or a simple edge, locally a edge often looks quite similar at 
> many points

Well if you have solid color, the comb-detect won't trigger and you
don't have to worry about motion comp. But yes, sharp edges are a
major problem. IMO this goes back to the #1 flaw of interlacing: the
fields are aliased pictures. If they were properly band-limited, all
the comb detection, field matching, motion estimation, etc. would work
great...but it wouldn't be useful because the missing field would be
exactly what you'd get from scaling the other one up with sinc scaler.
:(

Anyway this is what I tell anyone who argues that interlacing is a
"valid" method of analog compression: it's simply not, because it
inherently involves bad sampling.

> one way to "solve" this is to define a score function which does not only take 
> the matching error but also the difference between adjacent motion vectors 
> into account, and then "just" find the global minimum ...

"Just"... :)

Still, it's often valid for adjacent pixels to have radically
different motion vectors if one is a moving foreground object and
the other a part of the background.

Rich