[MPlayer-dev-eng] new deinterlace filters

[Tinic Uro]

Since you talk about deinterlacing, how about actually including some of the deinterlace modes from Dscaler?

http://deinterlace.sourceforge.net/

It has some rather interesting algorithms and most of the code is well optimized. It would be even better if there would be direct support for the plugins in mplayer.

Tinic


-----Original Message-----
From: D Richard Felker III [mailto:dalias at aerifal.cx] 
Sent: Thursday, January 23, 2003 1:44 PM
To: mplayer-dev-eng at mplayerhq.hu
Subject: Re: [MPlayer-dev-eng] new deinterlace filters


On Thu, Jan 23, 2003 at 06:22:12PM +0100, Michael Niedermayer wrote:
> > 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.
> this wont look any better then the cubic or linear deinterlace filters 
> as its
> identical, bilinear & bicubic ipol suck at sharp lines ->they get blurred, 

Well it's not so much the blurring that's the problem... Rather, when they have low slope they get segmented looking -- bogus gradients appear in the line going back between light and dark.

> thats why i posted the url, the stuff described there shouldnt blur 
> lines,
> allthough it might be too slow for practical use, dunno

Hmm. Actually, I was looking a bit at the 2xSaI code to see if it could be adapted for primitive, fast inpainting (right now it seems useless for movies because it checks equality instead of similarity of pixels), but it's painful to read. Something like that could work well, though...

> > (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...)
> per instance -sws is planned (since a long time) ...

Yeah... If you have in mind a good syntax for it, I'd be happy to implement it. Perhaps we should wait til after 0.90 though.

> > 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.
> more filters are not nonsense :)

OK. :)

Rich

_______________________________________________
MPlayer-dev-eng mailing list
MPlayer-dev-eng at mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng