TDeint and TIVTC

[foxyshadis]

That pic is absolutely useless without some background, which would consist of posting at least both a short clip and your script.

[Chainmax]

Isn't animation usually telecined rather than interlaced?

[Valeron]

i'm sorry for forgetting post a short sample
here is a chopped vob

http://rapidshare.com/files/4665877/sample.vob.html

i simply use tdeint to deinterlace without any other filter, just lower the thresh and switch "field" to see if it help.

@Chainmax:
it's very source/scene dependent, some bad mixed dvd do exist.

btw, i've tried eedi2 as a same frame rate deinterlacer for this section and found it works excellent. but i can't leave it as 30fps cause it's so jerky. i'm considering a bobber.
anyway, i'm also looking forward a good settings with tdeint to see if the pixel based motion adaption would work more fantasy.

[foxyshadis]

I don't know where you got the idea that needs to be deinterlaced, but it is 100% telecined. It's a bit of an older telecine job, not perfectly smooth, bot tfm().tdecimate() does great on it.

Deinterlacing everything because a few hybrid dvds exist in the wild is a terrible idea, it'll cause all kinds of jerkiness and combing when ivtc is called for. That's why tdecimate has such good hybrid support.

[Valeron]

so sorry for missing checking the field patterns.....
there's really something wrong with me these days......

now i see it's not interlaced but also not a popular telecined section with 3:2, since i can't find the matched field for some frames with decomb(i've overrided the matched field decision for any of the 3 field). do i have to go with postprocess? how does tfm+tdecimate solve this section?

and more, i don't deinterlace everything but just several scene i can't get rid of combs with ivtc(postprocess off)

thx

PS: i know this post is a bit off topic, if it really disturb the topics of tdeint, i'd like to see it splitted to the usage forum.

[foxyshadis]

When Decomb fails you, go straight to TIVTC before you start trying more esoteric solutions. There's a very good chance it'll detect or correct whatever problem your script has, and it'll give you more options for fixing it, without having to deal with manually override every movie. In fact, I never bother with Decomb at all anymore, TIVTC is almost as fast and so much better at handling hiccups.

I mean, using the defaults gave me excellent results on your clip; the pp took care of the residual combing from the bad post-telecine merge, even if it's not 100% smooth (which a deinterlacer will have just as much trouble on).

[Valeron]

@foxyshadis:
thx for the suggestion, tivtc sounds great.
i'll give it a try for my next rip

[tritical]

[link removed], changes:

tdecimate:
   + added sdlim parameter
   - expanded file input line buffers from 80 bytes to 1024 bytes
   - small change to debug output format of match/d2v duplicate info lines

tfm:
   - expanded file input line buffers from 80 bytes to 1024 bytes

sdlim is the name I gave to the option ChiDragon asked for a few weeks ago. When using cycle based decimation with cycleR>1, tdecimate will not choose to remove any frames that are within "sdlim" distance of a frame that is already marked for decimation. Frames are marked for decimation in order from lowest to highest difference metric in the cycle (assuming it's not longest string mode). sdlim must be >= 0 and (sdlim*2+1)*cycleR must be <= cycle.

@Chainmax

I guess I'll stick to either mode=0 or mode=7, could you tell me the pros and cons of either and on what kind of source they would perform better than the other?

The major con of mode 0 is that it doesn't care about spreading out the decimation to maintain sync. If you have cycleR=10 and cycle=50, mode 0 could end up removing the first ten frames from the cycle if they happen to have the lowest difference metrics. Mode 7 will always spread the decimation and maintain sync pretty well, but it looks at only a small number of frames (usually 3-7) when deciding whether to keep or drop a frame. The addition of the sdlim parameter should help with the problems of mode 0, though in your case with cycleR=2003/cycle=5000 it wont have any effect. Mode 2 is a kind of hybrid method combining ideas from mode 0 and mode 7, but I haven't spent enough time developing or testing it to say how well it performs. Combined, I've probably tested mode 2 and mode 7 on a total of 4-5 clips.

[Chainmax]

Mode=7 it is then. Thanks for all the help .

[ChiDragon]

Thanks for sdlim. If you don't mind my asking though, why are its possible values so constrained? I was able to set a limit of 3 with that code you gave me, but only 2 for sdlim (with cycleR=35, cycle=185). Doesn't seem like much but 3 vs. 2 really makes a difference in those black fades.

[tritical]

Actually, I got the formula slightly wrong. Instead of:

(2*sdlim+1)*cycleR <= cycle

it should have been

(2*sdlim+1)*(cycleR-1) < cycle

Allowing any larger sdlim size leaves open the possibility that tdecimate would not be able to mark a full cycleR worth of frames for decimation. That is worst case. Best case would be:

(sdlim+1)*(cycleR-1) < cycle

One possible option for allowing larger sdlim sizes would be to initially mark as many of the cycleR worth of frames as possible with the given sdlim value. If a point is reached such that there are still frames needing to be marked but it's not possible with the given sdlim value then decrease sdlim by 1 and try again to mark the remaining frames. Keep doing that until a full cycleR worth of frames are marked.

Another variation would be to try with the given sdlim value and if tdecimate runs into the problem of not being able to mark enough frames then decrease sdlim by 1 and start completely over. Keep decreasing sdlim until it reaches a value where it is possible to mark a full cycleR worth of frames.

When I say decrease sdlim I mean only for the current cycle being processed, not for the entire clip.

I think the second option would probably be more stable than the first option.

[ChiDragon]

What about doing the first run through with sdlim, and if there are still not enough frames marked, just disregard sdlim and place the extras at the lowest metric frames? That way the "properly" marked frames aren't disrupted, and if it's at a commercial edit point one of the black frames should be dropped. I think those should be the only places in my videos where sdlim would need to be lowered. If not, at least the extra necessary drop should be a fairly low metric. I dunno how that would work for other people's usage of sdlim though.

This reminds me of something I was thinking about before and I believe was brought up at some point (maybe on the Decomb board), a different decimation mode where preference is given to drop frames whose neighbours have higher metrics, since duplicates in low motion are much less visible than duplicates in high motion. Maybe use dupThresh to mark dups, then find the differences between each dup's metrics and those of its previous and next frames (and average them?), and drop according to the highest of those.

What do you think?

[travisbell]

Originally Posted by tritical

TIVTC v1.0 RC 9, changes:

tdecimate:
   + added sdlim parameter
   - expanded file input line buffers from 80 bytes to 1024 bytes
   - small change to debug output format of match/d2v duplicate info lines

tfm:
   - expanded file input line buffers from 80 bytes to 1024 bytes

Hey guys, I don't know much about all this stuff but here's an issue I just discovered...

I have a 1080i source that, with the RC6 release of TIVTC.dll works properly. However, when I use the latest RC9 release, it doesn't. for whatever reason, it's not being IVTC'd.

I am using AutoMKV, so I am unsure his process, but you can see the discussion here: http://forum.doom9.org/showthread.ph...456#post909456

Is this a TIVTC.dll bug?

[tritical]

@travisbell
Could you post the actual avs script that AutoMKV generates? If you make your own avs script with just:

source()
tfm()
tdecimate()

Does it work? Between RC6 and RC7 I changed/removed/added some of tfm's parameters. That might be causing the problem. I'll try to look into later tonight.

@ChiDragon
Both ideas are possible. I am still not sure which method for the sdlim problem would be the best. I'm leaning towards the second suggestion I mentioned before, just because it would do the best job at evenly spreading the duplicate removal throughout the cycle. However, your suggestion would be better at handling uneven duplicate distribution. Your other suggestion could definitely be useful. Actually, mode 2 already does something similar to what you described, but it uses the minimum of the current/prev and current/next metric differences, as well as some absolute and relative thresholds. However, there are some problems with it.

[canuckerfan]

tritical, is TDeint2 in the works? just curious...

[buzzqw]

@tritical

this is the script used
http://forum.doom9.org/showthread.ph...705#post902705

bautodeint analyzing this log will decide to telecide or not... maybe the log produced is different from rc6 to rc7 ?

BHH

[tritical]

@buzzqw
Hm, the log produced by RC7+ should be the same as RC6 unless I managed to break IsCombedTIVTC... probably the most likely cause. I'm not at a computer I can test on atm though.

@canuckerfan
It is in various forms. I've worked on a new motion detection routine, heirarchical, overlapping, block based phase correlation motion estimation (all that I could figure out from a week of digging through all the bbc/wilcox/teranex patents I could find online), and edge directed interpolation using neural networks. The problem is that most of those pieces are only 50-75% complete.

In the short term, I almost have the next update for TDeint done. Besides the things I've mentioned before, I also added a 6 field motion check and the ability to run the motion detection on a clip other than the input clip.

[Terranigma]

Originally Posted by tritical

@canuckerfan
It is in various forms. I've worked on a new motion detection routine, heirarchical, overlapping, block based phase correlation motion estimation (all that I could figure out from a week of digging through all the bbc/wilcox/teranex patents I could find online), and edge directed interpolation using neural networks. The problem is that most of those pieces are only 50-75% complete.

In the short term, I almost have the next update for TDeint done. Besides the things I've mentioned before, I also added a 6 field motion check and the ability to run the motion detection on a clip other than the input clip.

That sounds awesome; if it's not too much trouble, could you also add where it'd let us know which frame's considered progressive or interlaced like with Fielddeinterlace and/or telecide's show parameter?

[ChiDragon]

Terranigma, you can see whether a frame is being deinterlaced or not using the map parameter (any frame that doesn't have a map overlayed isn't deinterlaced, and vice versa). I agree that a real "display" parameter that would show the calculated MIC, the use of hints, etc. like the debug output would be nice though, eh tritical?

[Terranigma]

I know about the map function, but I'd prefer to get the info in text form.