[MPlayer-G2-dev] transcode filters

[D Richard Felker III]

On Wed, Apr 21, 2004 at 01:32:49PM +0400, Vladimir Mosgalin wrote:
> On Wed, 21 Apr 2004, D Richard Felker III wrote:
> 
> DRFI>> You are a little wrong here. Sure, since you never tried those filters
> DRFI>> in transcode you might think so, but the following sequence of filters
> DRFI>> -J ivtc,32detect=force_mode=3,decimate
> DRFI>> 
> DRFI>> in transcode has no working alternative in mplayer. I tried a lot, but
> DRFI>What is this sequence supposed to do?
> 
> It's supposed to er.. remove telecine, I presume ;) It was a strange and
> hard case, looked like material that was deinterlaced after telecine,
> but not quite, and it was on dvd.

Hmm, but you shouldn't need a complicated filter chain like that to
remove telecine. The steps make no sense...

> DRFI>> Yes, ivtc filters in mplayer are overally better. But _there are_ cases
> DRFI>> when transcode gives desired result and mplayer doesn't.
> DRFI>
> DRFI>If you have example clips where the various filters mess up, I'd
> DRFI>appreciate seeing them.
> 
> Sorry.. I have only slow modem connection, and uploading even parts of
> dvd's is a hard thing to do.

:(

> DRFI>I think it's the same thing. I tried it on telecined content because I
> DRFI>didn't have any true interlaced material handy, and I must say I
> DRFI>wasn't impressed. The kernel it uses for deinterlacing the interlaced
> DRFI>parts is bad (produces nasty edge-ghosts) and it deinterlaces wherever
> DRFI>there's motion, rather than just the areas that have combing.
> 
> If you are interested, there is some info about kerndeint (from its
> author):
> http://neuron2.net/journal/journal.html

Thanks, very informative.

> And yes, it looks like it is the same filter as smartdeint, or something
> close to it; at least, they are written by the same person. They seem to
> use the similar technique to detect motion, but possibly deinterlacing
> algorithm is different. In smartdeint, you can choose either lb, li or
> ci filter (speaking in mplayer terms ;) for actual deinterlacing. I've
> yet to find [dis]advantages of kerndeint comparing to smartdeint...

Ah. li and ci are correct deinterlacers but the output looks "low
resolution". lb is incorrect but looks ok if there's only low motion.
fd (aka ffmpeg deinterlacer, aka lavcdeint, which kerndeint seems to
mimic) is completely wrong (but based on formulae in some mpeg
spec...) and produces a ghost that looks like an edge-detect image of
the other field over top of the picture.

Rich