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

D Richard Felker III dalias at aerifal.cx
Thu Dec 4 17:28:21 CET 2003


On Thu, Dec 04, 2003 at 01:13:57AM -0600, Zoltan Hidvegi wrote:
> > 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
> 
> OK, I've looked at that.  When I mention frame numbers below, I start
> then from 0.  My filter thinks that the first 10 frames are hard
> interlaced.  They are quite noisy, I'm not sure what can you do with
> them.  When my filter detects hard interlaced content, it will pick a
> field based on the rate control, takes its two neighbors, and fills
> the missing field from the better neighbor, and if it still looks
> interlaced, it will drop the pixel from the neighboring fields and use
> the average of the key field.

Very good.

> Frames 10-24 are detected as well telecined.  Frame 25 is detected to
> have a scene change in the middle of the frame, and the first field of
> frame 25 is not considered a good match for the last field of frame 24
> because there is too much noise.  Then this field pair is droped for
> rate control.  Maybe my heuristics could be changed to treat these
> fields as a match.

All three other filters treat them as a match with no problem.

> Similar thing happens at frame 44, scene change in the middle, and the
> first field is not a good match.  And while frame 43 was a perfect
> progressive frame, its display was delayed for rate conrol, and now
> the first field of frame 44 is shown, which happens to merge in most
> of the last field of frame 43, so fortunately it still mostly does the
> right thing.

Ok...

> After that, everything is fine again until frames 192-200, which are
> horrible hard-interlaced frames, like an interlaced video fade-out was
> added.  My filter does lots of deinterlacing here.

These frames are perfectly good telecine, just very noisy. Failing on
these is very bad.

> > lain-op-wire.avi. I can find much worse examples for you if you like.
> 
> In here, frame 3 has a bad edit scene change in the middle, the first
> field of frame 3 does not match anything.  Then an other bad edit
> between frames 3 and 4.  Again, the fields of frame 4 do not match
> anything.

It's interlaced material.

> Frames 5-8 are like 30fps progressive frames.  Frame 9-31 are hard
> interlaced.  Frames 32-76 are well telecined, 

Does your filter do the right thing with the very first frame of this
sequence? It was always one of the most difficult for me without
buffering ahead.

> frames 77-80 are
> interlaced, and frames 81-107 are detected as 30fps progressive.
> Frames 108-131 are interlaced, 132 is progressive, 133-135 are
> interlaced, 137-143 are 30fps progressive, 144-149 are interlaced.

Agree.

> This is really bad, I do not know how can you get a good 24fps output
> of this.  Variable rate seems to be more sutable for this, but my
> filter still produces an acceptable result.

Right. That's why I target variable-rate.

BTW, if you're going to do fixed-fps output, you should find some way
to try to drop the frames with the least motion (which might in fact
be duplicate fields during a still scene, just not detectable).
Dropping frames with significant motion in them is bad.

Rich




More information about the MPlayer-dev-eng mailing list