[MPlayer-dev-eng] New inverse-telecine filter

[Zoltan Hidvegi]

> > in the middle of the frame, it would show up as a bad match.  My field
> > compare is more accurate than licomb, so I can do better decisions
> > just by comparing adjacent fields.
> 
> Maybe so. BTW, I've heard that using a linear [3 1] filter for qpel
> translate isn't very good, and that a 3tap or even 4tap filter should
> be used instead. That's what I did in vf_tfields. Any opinions on
> whether this would improve the metric?

I've actually experimented with more complicated metrics, but it was
not better.  [3 1] is not that good for qpel, but better than [1 1]
hpel used in licomb.  And I qpel on both fields, and somehow the
errors tend to cancel out, that's how you get zero on all quadratic
curves.  I've tried 4-tap cubic interpolation, and it was worse.  I
think the problem is that many-tap works well for smoth changes, but
do badly at sharp edges.  Perhaps n-tap looks good on screen, but it
does not necessarily mean that it is a good metric.  I've tried many
metrics, testing them on known progressive sources, where they should
show near perfect match between the fields of a progressive frame.
More complicated filters were slower, and were not more accurate.

One of the worst sequence is the Miramax opening logo with the
nightline of New York, some parts of which looks interlaced by any
metrics I can come up with.  But that's a rather extreme example,
which hardly ever happens in real movies.

> > I have a flag in vf_priv_s called swapped (bad name, I know), which is
> > set it the current frame is BFF.  And if it is set, the metric routine
> > will reduce the frame hight by 1 and it will crop one line from the
> > top, then the frame becomes TFF.  And I assume that repeat-first-field
> > frames are never interlaced.
> 
> Ah, yeah, special-casing RFF frames like that would make it easy... :)

Do you have any examples where an RFF frame is interlaced?  That would
look bad even on interlace-scan TV sets.

> > I see.  My metric for the neighbouring fields (like yours, but yours
> > is 2x bigger because of the 16-line bug), is trying to measure the
> > distance between the neighbouring fields just like the diff metric
> > measures the distance between the even or odd fields.  They should be
> > comparable, so for example, the distance between the odd fields should
> > be close to noise+temp, where noise is the distance between the two
> > fields in the current frame, and temp is the distance between the
> > current first field and the previous last field. 
> 
> I think Pythagoras might prefer to see some squares and square roots
> in there... :)

No, this is a one-dimensional space, so I do not think so.

> > And you can do
> > pretty good decisions just by using these `affinity' measures.  I can
> 
> I particularly like the 'breaks' method, because it's very definitive,
> and based on the most objective information you have available:
> duplicate fields. The affinity method, though usually correct, is much
> more heuristic in nature, and in fact it will behave very incorrectly
> during certain pathological cases. One example I know is a "fade-in"
> from random noise to a still picture. In this case, each field has
> affinity towards the next field. :(

But telecined fade-in will still happen in 24fps steps, which should
be detectable, unless the fade-in is very slow (like slower than 2
luma levels per film-frame) and there is no other motion at all.  And
you can change the thresholds on my filter to be more sensitive, if
you have a low noise source.  Do you have samples with such fade-in
problems?

If they do interlaced video effects, like fading on the top of
telecined film, that's bad, I do not think my filter can handle that
well, it will probably detect interlace content and will try to do
some de-interlacing, but I do not think it'll look good.

Zoli