[MPlayer-dev-eng] new deinterlace filters

[D Richard Felker III]

Hey, Michael. I've been playing with the median deint filter in the
postprocess code (and I just committed a C version of it), but I'm
curious about possibly expanding on it and adding one or more other
deinterlacers to the postproc lib.

First, some quick results of testing the various filters (this should
prolly go in DOCS/tech sometime):

lb -- I've had success with this one before (sometimes applying it
recursively even) to clean up files with high frequency vertical noise
(from improper deinterlacing combined with scaling). However, with
real interlaced material where the two fields come from different
time, the blending makes half-transparent 'ghosts' in some frames,
which looks really bad.

li, ci -- Both do what they're expected to do and probably work fine
with source material filmed from the real world, but with anime they
butcher black outlines, especially near-horizontal diagonal ones.

halfpack -- Very naive and ugly, but looks better than li/ci for
anime.

scale (w/-ssf 4) -- Also naive and ugly, but better than lb/li/ci.

fd -- This one's very interesting. For the most part it does a great
job. However, where the edges of the 'ghost' would be if I used lb, I
get a very faint ringing/outline of the ghost, which looks quite bad
when it happens.

md -- Quite excellent. IMHO the concept behind this one is very sound.
When no motion is going on, the deinterlaced picture looks almost
identical to the original. However, when there's motion, edges get
somewhat jagged.

So, that brings us to the point of this message. I'd like to work on
one or more better deinterlacers, keeping the same idea as md, but
adapting it to reduce the jagged edges during motion.

I think the strong point of md is that it's adaptive, only changes the
odd lines, and most importantly, only changes them when they appear to
be interlaced. What I question, though, is whether using the median of
the three pixels values as a replacement is a good choice. I would be
inclined to check to see whether the pixel on the odd line lies
between the values on the even lines, and if so, leave it alone, but
otherwise, compute a new pixel value for the odd line based on some
sort of interpolation.

The natural naive choice would be to linear interpolate from the two
surrounding even lines. Perhaps cubic interpolation would be better.
But I would imagine both will look rather bad on the fine outlines
found in animated material, as will ANY interpolation that just uses
the vertical dimension.

So, presumably the solution is to do some sort of fancier
interpolation with the surrounding pixels to the left and right. And
here's where we get to the questions... Do you have any ideas or
recommendations on good 2d interpolation algorithms that should be
used here? And, more importantly, is this possible with the current
postproc architecture, or would it need to be a separate mplayer
filter? As far as I can tell, the deinterlacers get 8x16 blocks at a
time and can work with the 8x8 region in the middle, but that doesn't
seem to allow interpolation from the sides. Or, is it safe to just
read a few bytes beyond the 8x8 block to the left and right as long as
you don't do so on the first or last line...?


Rich