Re: transcode filters

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

DRFI>This most likely indicates that the ivtc filter is buggy. It should
DRFI>never output any interlaced material for purely telecined content.
DRFI>If the original is a mix of telecined film and video, then all bets
DRFI>are off...

Yes, it was about mix. In "good" case 32detect won't be needed. Just
ivts,decimate.

DRFI>> However, transcode's '32detect'
DRFI>> filter comes to the rescue: It first checks whether the frame 
DRFI>> is interlaced, and only then it forces a frame deinterlacing. 
DRFI>
DRFI>This will result in ugly flicker in your movie where frames
DRFI>incorrectly get deinterlaced rather than properly matched. You'd be
DRFI>better off deinterlacing all the frames with a blend filter so it's
DRFI>uniform at least...

Um.. But what about cases when there are 500-1000 interlaced frames
after imperfect ivtc process in the whole movie on complex cases? They
are noticable when they are interlaced, but they aren't if they will
just flicker a little.

On the other hand, quality of this 32detect isn't perfect too. It tends
to skips frames with slight interlacing pattern.

DRFI>> So, this is what I recommend for your sessions:
DRFI>> 
DRFI>> transcode -M 0 -f 23.976 -J ivtc,32detect=force_mode=3,decimate ...
DRFI>I still don't understand how decimate is useful...

ivtc creates 5 progressive frames, decimate actually throws one of them.
Nothing to do about it, it's just the way. 32detect is inserted because
the case was hard. In easy cases, of course, every filter inserted
between them will potentially ruin the process.

But. As the side effect (the cases where ivtc will fail, but due to
movie nature - say, it was deinterlaced) decimate, which will still work
on that frames, /may/ do something useful and throw away right frame.
That's the rare case, but I needed this once.

DRFI>> Well, result from kerndeint looks almost like cubic interpolation to me.
DRFI>
DRFI>It's definitely not. As far as I can tell it's the same
DRFI>lowpass/highpass thing the Decomb author described on that web site
DRFI>you cited. Cubic would "look bad" but not create artifacts.

I took two cases: animation with complex non-interlaced still frame, and
interlaced pal dvd (the sequence was recorded from the camera). Then I
ran mplayer -vf pp,pp=ci (I compared with other filters too) in one
desktop and -vf pp,kerndeint. Then I was switching between them. The
two pictures were wery close.

Another oddity: on still frame, kerndeint was working _only_ if the
output driver is xv, xvidix or sdl, but not with x11. Adding scale
filter at the end of the chain disabled its effect with any driver.
This was regardless thresh=0 (which I suppose is required to force
deinterlacing still frame). What kind of bug is this?

-- 

Vladimir