[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.
> 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.
> 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
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
> 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.
> 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.
More information about the MPlayer-dev-eng