Re: transcode filters

On Wed, 21 Apr 2004, D Richard Felker III wrote:

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

Nope, it's just transcode way of performing ivtc. It is written in
documentation
---
   Additionally, when the telecine pattern shifts (as a result
of, maybe, field editing by the DVD authors) a couple of
interlaced frames will pass through. These should be deinterlaced 
on their own. You shouldn't use global deinterlacing after ivtc 
- it would blur out the otherwise perfect progressive frames 
that get reconstructed from 'ivtc'. However, transcode's '32detect'
filter comes to the rescue: It first checks whether the frame 
is interlaced, and only then it forces a frame deinterlacing. 
So, this is what I recommend for your sessions:

transcode -M 0 -f 23.976 -J ivtc,32detect=force_mode=3,decimate ...
---

DRFI>> And yes, it looks like it is the same filter as smartdeint, or something
DRFI>> close to it; at least, they are written by the same person. They seem to
DRFI>> use the similar technique to detect motion, but possibly deinterlacing
DRFI>> algorithm is different. In smartdeint, you can choose either lb, li or
DRFI>> ci filter (speaking in mplayer terms ;) for actual deinterlacing. I've
DRFI>> yet to find [dis]advantages of kerndeint comparing to smartdeint...
DRFI>
DRFI>Ah. li and ci are correct deinterlacers but the output looks "low
DRFI>resolution". lb is incorrect but looks ok if there's only low motion.
DRFI>fd (aka ffmpeg deinterlacer, aka lavcdeint, which kerndeint seems to
DRFI>mimic) is completely wrong (but based on formulae in some mpeg
DRFI>spec...) and produces a ghost that looks like an edge-detect image of
DRFI>the other field over top of the picture.

Well, result from kerndeint looks almost like cubic interpolation to me.
I liked smartdeint in blend mode more...

-- 

Vladimir