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

[D Richard Felker III]

On Wed, Dec 03, 2003 at 03:41:33PM -0600, Zoltan Hidvegi wrote:
> > > For mencoder-g1 it is better than pullup, since pullup cannot keep the
> > > framerate. 
> > 
> > I guess you mean force 24 fps output, and you're right. But it's still
> > not better to output incorrect frames. I can upload some samples where
> > your code will output incorrect frames if you'd like. :)
> 
> I do not think I am outputing incorrect frames, but if I do, I'd like
> to see a sample, so I'd be very much interested to try those samples.
> But I do not think I have download access from mplayerhq incoming.

I haven't tested it yet and I'm a bit busy today, but you might check
out the examples at http://brightrain.aerifal.cx/~dalias/video_examples.
The "evil M" shows a particularly nasty scene change, as does
lain-op-wire.avi. I can find much worse examples for you if you like.
When I have some extra time I'll apply your patch and test these
things myself.

> > output. The only thing I don't consider is nasty broadcast noise or
> > watermarks (imo a form of broadcast noise :).
> 
> Yes, but unfortunately, I use this mostly for broadcast.  From your
> timezone I assume that you are in Europe, so you do not have to deal
> with broadcast telecine there.

Nope, USA.

> > > And for watching live TV
> > > it is an advantage that you have no delay, and it was one of my goals,
> > > to have a filter good for live TV.
> > 
> > I agree this is useful. But you absolutely need at least one field
> > delay or you _WILL_ mess up at scene change splices.
> 
> Sometimes I do delay, when the match does not look good, my filter
> will delay. 

Interesting approach.

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

> > > > The pullup module was already designed to handle all the buffer
> > > > management and field merging with minimal copy overhead. It's also
> > > 
> > > My pullup2 has zero copy for most frames, only the merged frames,
> > > usually 1 out of 4 are copied.  The pullup filter can do direct
> > > rendering, but not after a crop filter, which used EXPORT.  I'm
> > 
> > The solution is to set the boundary sizes for pullup to ignore and
> > then perform the actual crop after pullup. There's no way to do this
> > yet from the command line, but adding it is trivial.
> 
> Yes, that works too to speed up the metrics, but the merging is still
> slower if you do not crop.

Good point. Perhaps integrated cropping does belong there, then.

> > I'm not quite sure how your code works on mixed input where some input
> > frames are TFF and others BFF (mixed hard+soft telecine)...
> 
> 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... :)

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

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

Rich