[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