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

Billy Biggs vektor at dumbterm.net
Mon Apr 14 00:00:24 CEST 2003


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.

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

> > I think that even though history stuff can get too complicated, as
> > long as you keep your history REALLY SMALL, things are pretty much ok.
> 
> Yeah, I don't call history over the last 5 frames "really small"
> though... :)

  It's a full sequence and it's just a history of the repeat numbers,
but yeah, you're right. :)

> But 1frame delay could work for realtime. :)

  Yes, it works fine.

> > Still, I should maybe better describe my offline algorithm's
> > handling of cuts to you as it might be helpful.  Old code is in CVS
> > at www.sf.net/projects/reetpvr/
> 
> Thanks. It'd be easier if you could just explain it, but if that's too
> much trouble I'll read the code sometime.

  I guess I mentioned the source location since it's been like over a
year and a half or so since I looked at that code, maybe more!  So, I
don't entirely remember it, but I'll take a look at it soon and post a
summary.

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

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

  -Billy



More information about the MPlayer-dev-eng mailing list