[MPlayer-dev-eng] new deinterlace filters

[D Richard Felker III]

On Thu, Jan 23, 2003 at 10:14:18AM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Thursday 23 January 2003 07:49, D Richard Felker III wrote:
> [...]
> > 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? 
> hmm, yes, see: http://mountains.ece.umn.edu/~guille/inpainting.htm
> the algorithms on the papars there can replace missing image regions, and it 
> looks quite impressive even for large regions, so i guess it should be real 
> nice if it has to replace only every 2nd line

Hmm, I believe I've had this url thrown at me a few times before, and
although I haven't waded through all the papers yet, I imagine it's a
good bit more elaborate and cpu-intensive than what's needed for
deinterlacing (since it can fill in much larger gaps). Perhaps a
bilinear or bicubic filter would be sufficient. I suppose I could do
some simple tests by scaling down to half height with nearest neighbor
then scaling back up with the various software scalers and see which
(if any) fill in the missing lines well.

(BTW, this is yet another reason it would be nice to have -sws be
configurable per-instance. In the mean time I might just make a video
filter that doubles all strides...)

> > 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...?
> the dering filtr for example reads 10x10 block, so it is possible, if u do the 
> filter at the right place, but i am not sure if the pp code is the perfect 
> place for new filters, the only advantage over the filter layer is that the 
> filters are done interleaved on 8x8 blocks so that the filters allways read 
> from the cache, dunno if the filter layer supports slices and if yes then 
> dunno how to use them ...

Yeah, I read the postproc code for the first time yesterday when I
went to see how the median deinterlacer worked (and found that the C
code was missing so I implemented it), and I like the design a lot.
The advantage of interleaving filters like this should be huge. Also I
figured it might be nice to keep all the deinterlacers together in
postproc so they could be used in other projects, but maybe it's
simpler just to make a separate filter. I don't want to go polluting
libpostproc with nonsense.

I suppose in the long term it would be cool to make an improved video
filter layer that allows 'DR1' between filters... Or at least make
stride rendering between filters work...

Rich