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

[D Richard Felker III]

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...)

> > The idea of taking max is that you can focus in on very small
> > artifacts, such as just a mouth moving in an otherwise still anime
> > scene.
> 
>   I'm very much interested in this idea, I think it's pretty good.  One
> problem for analog TV though is like when you have a video-speed station
> logo animating in the bottom right-hand corner.  Could help you or screw
> you with this method.

This will definitely screw you, since there's almost no chance the
telecine pattern will match, and the logo probably is true 30 fps
anyway. Your best bet is to have an option to ignore this region.

> > 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.

> > > But that said, the real thing missing here is something I was
> > > specifically trying to avoid:  a metric for detecting 'interlaced
> > > frames'.  I think that pulldown detection should be mostly biasd
> > > towards the difference metrics, since they work best, but we should
> > > still have
> > 
> > My current algorithm is to mark a frame if it matches "strongly" based
> > on any of the difference metrics or the noise metrics...
> 
>   You mark frames if they look similar?

A "match" is if max(even-odd) is much less than max(odd-even), or the
analogous conditions for noise metrics. That's why it's useful to make
these measurements. :))

Rich