[MPlayer-dev-eng] More on inverse telecine!

[Billy Biggs]

D Richard Felker III (dalias at aerifal.cx):

> On Sun, Apr 13, 2003 at 05:00:24PM -0500, Billy Biggs wrote:
> > D Richard Felker III (dalias at aerifal.cx):
> > 
> > > > Thanks a ton for describing them.  This is really helpful.  The
> > > > metrics I'm using are mostly blurred difference, so rather than take
> > > > into account noise later, blur the input before trying to detect
> > > > differences across fields.
> > > 
> > > Hmm, I'm curious as to how this works... Do you do a blend filter like
> > > -vf pp=lb and then look for the 'ghosts'?
> > 
> >   No I just meant filter the input scanline with a low-pass filter
> > before looking at absolte difference.  Like [1 4 6 4 1] before you do
> > the abs.
> 
> Ah, hmm... This is fairly difficult to do without serious additional
> computation, which would slow the process down even more. It could
> have some benefits, but from a mathematical standpoint I don't think
> you really get more info from the difference of the blurred lines than
> the original difference before blurring. (I'd have to sit down and
> work it out to be sure though...)

  It's not that hard.  Even a [1 1 1 1] filter can help.  I've used
something like this successfully on YUY2 content (luma every second
byte):

    ret = 0;
    while( width-- ) {
        unsigned int tmp1 = (cur[ 0 ] + cur[ 2 ] + cur[ 4 ] + cur[ 6 ])>>2;
        unsigned int tmp2 = (old[ 0 ] + old[ 2 ] + old[ 4 ] + old[ 6 ])>>2;
        tmp1  = (tmp1 - tmp2);
        tmp1 *= tmp1;
        tmp1 >>= 6;
        ret += tmp1;
        cur += 8;
        old += 8;
    }
    return ret;

  Lots of improvement you could do there though.


> > > Yeah, I made the mistake of adding chroma checking to vf_detc. It
> > > messes things up horribly because of "chroma crawl" or whatever
> > > the crappy artifacts from the analog signal were. For my new
> > > filter, I decided to just ignore chroma entirely in the detection.
> > 
> > Good, it's best to ignore chroma.  However, chroma artifacts will
> > appear in the luminance channel, and that's why I mentioned it.  A
> > blur filter before looking for motion will help.
> 
> Oh. I think this is more of a concern with broadcast tv, especially
> with the horrible way chroma is carried on NTSC. As long as the source
> material was edited only as composite video and/or with digital
> methods, chroma should not mess up the luma.

  Sorry, but composite video is what messes it up, broadcast video is
just a form of composite video, but with more noise.  Composite means
you're mixing the luma and chroma on the same channel, and they will
conflict.  If you're going straight from a DVD, you just have to hope
the DVD wasn't mastered from a composite format like LD or even VHS
(hey, I've seen it!).  If you're capturing analog, make sure you capture
over component, but just using S-Video can ensure your luma won't be too
messed up (again, depending on the source).

  I've seen lots of chroma artifacts intrude into the luma when doing
analog capture over composite to my DVD player, while the original
frames show none.

  -Billy