TDeint and TIVTC

[tritical]

[link removed], changes:
tfm:
+ preserve hints from dgdecode through tfm
+ added flags=5 option... same as 4, except that only frames around scenechanges
are checked for being combed
+ changed 'sco' to 'scthresh' and added 'ubsco' and 'mmsco' parameters.
Using u/b matches only around scenechanges and using micmatching only
around scenechanges are now controlled with separate parameters.
- fixed incorrect d2v duplicate marking by tfm when using hints and not using
linear, forward play
- fixed frames with 'h' and 'l' matches not being correctly overridden by an
ovr file

tdecimate:
+ auto detect hints on load if hint is not explicitly set to true or false by
the user
+ restore dgdecode hints passed through tfm when outputting frames
- fixed batch option setting arrays to fake values even if mode was not set to 5
- fixed unneeded requesting of frames under certain conditions due to some logic
errors
- a few caching changes/fixes

I decided to modify tfm to recognize hints from dgdecode and to preserve them if present. If hint=false in tfm then they will be restored in tfm's output, if hint=true they wont be restored until after tdecimate. There is one situation where the hints will not survive and that is if tdecimate modifies a frame. TDecimate only modifies frames when blending two frames together, so if noblend=false or hybrid=1 or 3 it's a possibility. The blending wont destroy the hints if the hints for the two frames that are blended together are the same, but it will if they aren't.

The other thing is that with the change to preserve dgdecodes hints, TDeint wont be able to correctly read tfm's hints (it'll say it doesn't find any). I can't really think of a reason to use TDeint after tfm instead of using it via tfm's clip2 parameter so it shouldn't be much of problem, but it'll be fixed when the next version of TDeint is released.

[canuckerfan]

Thanks, tritical!

Now that the hints from dgdecode will survive, I am curious to know of it is now possible to use ColorMatrix after ivtc'ing?

EDIT: just tested it, works great! Thanks!!

[G_M_C]

Firstly; I'd like to apoligize in forehand for this (probably) dumb question ;)

I'm currently trying to deinterlace a Pal 50i stream to a PAL 25p stream. I've read through the manuals of tdeint/eedi etc. several times, but i'' m no expert so it's hard for me to understand ;)

Does tdeint produce a 25p stream after deinterlacing (wich seems logical to me after "merging together" both fields) or not ?

I ask this question because i want to try to understand what im doing (and what to expect) before actually starting to expiriment.

Also; I'm @ work atm, and obviously cannot actually start expirimenting :D

But i can "learn how to" @ work

[acrespo]

It's my script with TFM in RC6 version:

MPEG2Source("c:\encodes\2006-07-24\db57.d2v",info=3)
colormatrix(interlaced=true,hints=true)

AssumeTFF()
orig=last
TFM(mode=6,order=1,PP=1,slow=2)
TDeint(order=1,clip2=orig,slow=2)
TDecimate(mode=1)

In RC7, to use colormatrix, can I chage to:

MPEG2Source("c:\encodes\2006-07-24\db57.d2v",info=3)

AssumeTFF()
orig=last
TFM(mode=6,order=1,PP=1,slow=2,hints=false)
TDeint(order=1,clip2=orig,slow=2)
TDecimate(mode=1)
colormatrix(hints=true)

[tritical]

@acrespo
Not quite, but this will work, will do the same thing, and will be faster:

MPEG2Source("c:\encodes\2006-07-24\db57.d2v",info=3)
AssumeTFF()
deint = TDeint(slow=2)
TFM(mode=6,slow=2,clip2=deint)
TDecimate(mode=1)
colormatrix(hints=true)

@G_M_C
Yep, with mode=0 (the default) you will get 25p out. Specifically, it will create one frame from either the top field or bottom field of each input frame (which depends on the 'field' parameter). mode=1 (bobbing) will give 50p out and will create one frame from each field in the input stream.

[acrespo]

@acrespo
Not quite, but this will work, will do the same thing, and will be faster:

MPEG2Source("c:\encodes\2006-07-24\db57.d2v",info=3)
AssumeTFF()
deint = TDeint(slow=2)
TFM(mode=6,slow=2,clip2=deint)
TDecimate(mode=1)
colormatrix(hints=true)


@tritical
You said in previous post that need hint = false in TFM to use colormatrix(hints=true). Why you don't put this parameter above?
When I use clip2=deint TFM get deinterlaced frames from TDeint and don't use the internal deinterlace?

[tritical]

You said in previous post that need hint = false in TFM to use colormatrix(hints=true). Why you don't put this parameter above?
You only need hint=false in tfm if you are not following it with tdecimate. If you follow tfm with tdecimate, then you'll want to keep hint=true so that tdecimate gets the information from tfm... tdecimate will then remove tfm's hints and restore dgdecode's hints.

When I use clip2=deint TFM get deinterlaced frames from TDeint and don't use the internal deinterlace?
Correct, it grabs frames from clip2 instead of using one of its internal methods.

[Terranigma]

Thanks tritical for the update. Just curious: is AssumeTFF or AssumeBFF really necessary since tdeint uses the parity from Avisynth? Maybe for avi files, or other types of file that don't have info about which field order is assumed, but I'm talking about .d2v files.

[tritical]

Yes, generally you shouldn't have to add assumetff() or assumebff() when using mpeg2source() since it sets the field order. However, its rule for setting the field order based on the tff flag of the first frame is technically only correct for progressive sequence==0 && FRAME_PICTURE (see the known issues and limitations thread). Personally, I've only seen two clips where the field order set by dgdecode was incorrect.

[ChiDragon]

Thanks for flags = 5! :D BTW, you missed adding 5 as one of the modes that trimIn is used for in the TFM readme.

[anton_foy]

I am not sure this would be an improvement that would be added to Tdeint or if this should be done seperately afterwards.

These two pictures below are a comparison of the artifacts left behind from Tdeint+eedi2 and MvBob.
Artifacts (http://www.xtreem.nu/jonas/D-comp.png)

Notice the compressionlike artifacts left by Tdeint (face and shirt) opposed to MVbob's output. Some combing is left aswell but it can be reduced with undot() pretty well.

I was thinking that maybe a smoothingfilter that works together with Tdeint right after the deinterlacing process occur. This could be activated by some memory function perhaps storing what pixels has been deinterlaced and smooth these areas like degrainmedian does. Being a total retard regarding programming this may possibly be stupid suggestion but hope it will be of some interest in the area.

Tdeint is so good and get almost the same quality on my footage as MVBob but about 3 times faster.

[Terranigma]

Hi. Is there anyway to use eedi2 with tdeint via external deinterlacing @ scene changes? I've tried to do a manual override, but it won't deinterlace, so in order to avoid that, i'd use tfm(flags=5,hint=true). Maybe there's something that i'm doing wrong?:o

[Revgen]

You can use the clip2 parameter.

Look here (http://forum.doom9.org/showthread.php?p=746020#post746020)

[ChiDragon]

tritical, sorry to bother you again, but I've got a new problem. I've specified a video section with an override file, and it properly overrides everything in the section except one cycle. My ovr line is "28779,29087 v". Frame 28806 is being dropped and none of the frames in its cycle are blended, although it does state VIDEO in the display stats. This cycle is also treated the same way without the ovr file, which is weird because it properly finds and blends 5 cycles before and 10+ after, and I have conCycle set to default (my vidThresh is 3). Not only that, but it doesn't even drop the frame with the lowest displayed metric (28809 has 10.45 vs. the 18.46 of 28806).

I'm using an input file on the actual encode, although I tested without the input file and found the same results. As a workaround I edited the second value for frame 28806 in the TDecimate stats file and it now properly blends all the frames in the cycle (I just copied the next frame's metric).

Original stats:
28805 67940 6099494
28806 62565 6437117
28807 95045 8689400
28808 73794 6207936
28809 35429 3322493
Edited stats:
28805 67940 6099494
28806 62565 8689400
28807 95045 8689400
28808 73794 6207936
28809 35429 3322493

Editing the first value increased the metric displayed by TDecimate but the frame was still dropped.

[tritical]

@ChiDragon
Try increasing the scenechange threshold in tdecimate. When using hybrid=1, and a scenechange is detected in a video cycle, it prefers to drop a frame one side of the scenechange over blending the cycle. For scenechange detection only one frame in the prev, curr, and next cycles can be over the threshold, so by changing the stats file as you did you probably made 2 frames be over the limit making it not detect a scenechange and thus blending the cycle.

@anton_foy
It would be possible to do what you propose, but it would also be quite a bit of work. Such artifacts are a result of poor motion detection, so I think improving motion detection is a better place to invest time than trying to filter the mistakes. I've had a new motion-masking filter finished for a while, but just haven't sat down and written the help file.

[Didée]

@ anton_foy ( & tritical, too)

Anton, from your post it is not too easy to gather what are the "good effects", and what are the bad ones. But after reading several times and looking at the zoooomed picture often, I think that you, tritical, got it the wrong way round. (Not sure, though.)

Notice the compressionlike artifacts left by Tdeint (face and shirt) opposed to MVbob's output. Some combing is left aswell but it can be reduced with undot() pretty well.
Ah, language ... let's try to work it up. ;)

Mentioned are two different types of "artefacts": the "compressionlike" ones, and the combing artefacts. Truth is, both filters show good (read: bad) amount of residual combing, MVBob even more than TDeint. In this point, both filters are basically equal.
But the "compressionlike" artefacts of TDeint shall appear *opposed* to MVBob, so these can't be related to residual combing. Okay, there is this area on the shirt, right below the collar, where the residual combing of TDeint is most obvious ... but that's a small area only, and moreover nothing like this is to be seen in the face, where the "compressionlike" artefacts shall appear, too.

So, my guess is that the wording "compressionlike" is targetting at the, well, "chunky" look in those areas where TDeint did deinterlace: at the very edges of the face (cheeks), at the light-shadow transition of the nose bridge, and, especially in the left part of the picture, at the dark parts of the shirt's folds.
In these areas, TDeint did deinterlace, and interpolation left back this chunky look. MVBob, in comparison, did not deinterlace most of these areas, but decided (falsely, imo) to weave them. So, MVBob did create more residual combing, but in this scene, this did the visual trick of "dithering" the chunkyness that (probably) is inherent to the source from the start.

Now, what's good, what's bad, and what is to do?

But in any case: any filtering like "smoothing" or "noise reduction" of those areas that actually have been deinterlaced, this should not be the task of the deinterlacer (again, imo.) A deinterlacer should either weave or interpolate pixels, eventually do postprocessing to reduce residual combing. But active image processing is just not the job of a deinterlacer.

(BTW: while in *this* case MVBob's "residual-combing-denoising" visually worked out, there are instances where it will fail big time. You might check these short samples (http://rapidshare.com/files/659527/BobComparison_artefacts.rar.html) here.)


But while I'm babbling anyways :o , this brings up another point that has bugged me for quite some time: most of tritical's filters have these nice options to spit out visualizations of "what is done where". A really nice feature! ... but: often it's a pity, that from those relatively slow filters you can only have either the actual processing, or the visualization mask. Imagine, you want to have the actual processing, *and* the visualization mask in order to do further processing based on the mask. This means that you have to run the (relatively slow) filter *two times*, to get both the processing and the mask.
Wild suggestion: would it be possible to add an option, which would force to give out both the processing and the mask (say, stacked vertically)? Then one could simply do some cropping after calling the filter, and would have both outputs with only one call of the filter. :)

TDeint and TTempsmooth are the filters where I would love to have this feature, quite frequently ...

[Chainmax]

Hey Didée, there's still no match for SmartDecimate on Restore24, right?

[Didée]

Frankly, I can't tell. Last time I checked, I found TDecimate/mode7 not always reliable in long encodings - but that was a looong time, perhaps a year, ago ... things might have changed.

Since R24 offers the option to use either one or the other, feel free to test it out, and report back. :)

[ChiDragon]

@tritical:
Ah, scenethresh=16 also did the trick. Makes sense now how it would be appropriate to drop the scene change frame rather than blend where possible (although in this case it wasn't a scene change ;)). Thanks for clearing it up.

[akapuma]

Only 18 months since v1.0 beta 1 ;)... here is TDeint v1.0 Final (http://bengal.missouri.edu/~kes25c/TDeintv1.zip). Changes:
+ added blend deinterlacing option (type = 4)
- changed denoise default to false
- pixels detected as moving, but with absolute difference < 4 to both vertical
neighbors are no longer automatically weaved (should fix problems with slow fades)
Hello,

why the denoise default is changed from true to false?

Best regards

akapuma

[tritical]

@akapuma
I changed it to false because it is kinda worthless and just slows things down imo. All it currently does is remove individual pixels that were detected as moving but who had no immediate neighbors (8 surrounding pixels) that were. I originally wanted to expand it to do more, but I never found an algorithm that worked well.

@ChiDragon
I'm glad that something finally worked how it's suppose to :D.

@Didée
Yeah, I misinterpreted the artifacts he was talking about in the image. Though either way I'm not keen on incorporating postprocessing like that into tdeint. However, with AP > 0 TDeint internally creates a mask marking weaved pixels with AP value > thresh (also subject to APType conditions) vs. other pixels. Outputting that mask as part of the map parameter could make such processing possible externally.

Creating both the map and the regular frame and stacking them vertically or horizontally is a great idea. I'll add it in the next version of tdeint.

@Chainmax + Didée
As far as mode 7 goes, I have only one clip to test on and for me it produces no duplicates. Also, smartdecimate always crashes after processing only a few frames so I haven't done much in the way of comparisons. Though a few days ago I built avisynth_c v0.15 using an updated avisynth lib/header and then built smartdecimate v0.23 using the updated avisynth_c and it all works fine now. So I'd be happy to look at samples where mode 7 gives crappy results compared to smartdecimate.

[ChiDragon]

tritical:
What do you think about extending that "drop one side of scene change during video w/SC" thing so that if the hints declare that only of the two frames (or maybe one in the whole cycle) is combed, drop that one. I just noticed a scene where that would help (a bad edit between two actual film patterns).

On the other hand, I suppose the current method would be preferable if vidthresh is set too low and TDec sees a dupe at the scene change as being video. Then it would be better to keep the combed frame...

Just a thought. :P

[Livesms]

Can anybody tell me why when I use two pass deinterlace with

#1 pass
d2vname = "Untitle.d2v"
MPEG2(d2vname, true)

tfm(d2v=d2vname, output="matches.txt")
tdecimate(mode=4, output="metrics.txt")
and

#2 pass
d2vname = "Untitle.d2v"
MPEG2(d2vname, true)

tfm(d2v=d2vname, input="matches.txt")
tdecimate(mode=5, hybrid=2, vfrDec=0, input="metrics.txt", tfmIn="matches.txt", mkvOut="mkv-timecodesfile.txt") # not anime or cartoon

I'm getting 23.822fps instead of 25.000fps

And when I use
d2vname = "Untitle.d2v"
MPEG2(d2vname, true)

tfm(d2v=d2vname)
tdecimate(cycle=25)

it produses 24.000fps instead of 25.000fps.

Source is 25.000fps. How can get 25.000fps - deinterlace without changing fps?

PS. I'm looking for quality deinterlace of VHS video captured with DVD-Recoder MPEG-2 8000kbit/s. Here is another canidate MPEG2("Untitle.d2v", true)

interp = separatefields().selecteven().EEDI2(field=1)
deinted = tdeint(edeint=interp,order=1,field=1)
tfm(clip2 = deinted,order=1)

But two pass or another IVTC for PAL gives more accurate results.

[ChiDragon]

If you don't want to change the framerate, just use TFM without TDecimate. TDecimate is intended for telecine, not normal PAL speedup with mismatched fields.

[Livesms]

If you don't want to change the framerate, just use TFM without TDecimate. TDecimate is intended for telecine, not normal PAL speedup with mismatched fields.

Should I skeep tdecimate both in first and second pass?

Will it cause in result quality?

[foxyshadis]

You have to figure out whether it's field-shifted, fully interlaced, or telecined. (Once in a while PAL is telecined from film.) And if it's hybrid telecined pal, TIVTC doesn't support that one yet, but I can't imagine that being common.

Here's some information on each: http://www.doom9.org/ivtc-tut.htm
And the method neuron2 drills into everyone for finding out what you have, is just use separatefields and step through it, until you find the pattern, if any.

[Livesms]

You have to figure out whether it's field-shifted, fully interlaced, or telecined. (Once in a while PAL is telecined from film.) And if it's hybrid telecined pal, TIVTC doesn't support that one yet, but I can't imagine that being common.

Here's some information on each: http://www.doom9.org/ivtc-tut.htm
And the method neuron2 drills into everyone for finding out what you have, is just use separatefields and step through it, until you find the pattern, if any.

I've got PAL (720*576) material with such frames (http://dump.ru/files/2/288457137/1.png). Source fps is 25.000

IVTC ADVICE in http://www.doom9.org/ivtc-tut.htm page mostly deal with NTSC. But I work with PAL DVD video.

[foxyshadis]

Did that come from a cooking show? (Yum!) If so, the chances are very good that it's fully interlaced, needing deinterlacing, and ivtc is the wrong operation. It's impossible to say without a sequence of frames though.

[Livesms]

Did that come from a cooking show? (Yum!) If so, the chances are very good that it's fully interlaced, needing deinterlacing, and ivtc is the wrong operation. It's impossible to say without a sequence of frames though.
Ok. Here is 10 frames from video http://dump.ru/files/3/379894795/PAL.rar (comporessd by Huffyuv)

If IVTC is wrong way, so why it gives me better results :)

[manono]

Hi-

As foxyshadis speculated, it is pure interlace. Put on a bobber (or separate the fields) and step through it, and you'll see that every frame/field is different. No repeats. The reason (maybe) why you think TIVTC does such a good job is that it doesn't find any field matches and just deinterlaces. You can do as well, and do it faster, by just using TDeint. And if this is for DVD, then I wouldn't recommend deinterlacing at all.

[Livesms]

Hi-

As foxyshadis speculated, it is pure interlace. Put on a bobber (or separate the fields) and step through it, and you'll see that every frame/field is different. No repeats. The reason (maybe) why you think TIVTC does such a good job is that it doesn't find any field matches and just deinterlaces. You can do as well, and do it faster, by just using TDeint. And if this is for DVD, then I wouldn't recommend deinterlacing at all.

Yes!

SeparateFields() gives me half height picture and all different (step by step) video. So it is pure interlaced video.

So what can you reccomend as deinterlacing filter. I have some variants
interp = separatefields().selecteven().EEDI2(field=1)
deinted = tdeint(edeint=interp,order=1,field=1)
tfm(clip2 = deinted,order=1)http://dump.ru/files/8/826331359/0.jpg
2 pass TIVTC
first pass
tfm(d2v=d2vname, output="matches.txt")

second pass
tfm(d2v=d2vname, input="matches.txt")
http://dump.ru/files/0/0508170020/1.jpg
TIVTC for PAL
tfm(d2v=d2vname)http://dump.ru/files/1/100852183/2.jpg
Some samples from MeGui
#TDeint with EDI
edeintted = last.AssumeTFF().SeparateFields().SelectEven().EEDI2(field=-1)
TDeint(order=1,full=false,edeint=edeintted)http://dump.ru/files/6/6827235/3.jpg
#TDeint
TDeint(order=1,full=false)http://dump.ru/files/0/074818498/4.jpg
#FieldDeinterlace
AssumeTFF().FieldDeinterlace(full=false)http://dump.ru/files/4/4845181842/5.jpg
#FieldDeinterlace (no blend)
AssumeTFF().FieldDeinterlace(blend=false,full=false)http://dump.ru/files/4/4192710577/6_1.jpg
#LeakKernelDeint
LeakKernelDeint(order=1,sharp=true)http://dump.ru/files/2/223364508/7.jpg
#TomsMoComp
TomsMoComp(1,5,1)http://dump.ru/files/9/9263911186/8.jpg

Maybe there is other method, which will give me better/best results?

[foxyshadis]

How much time are you willing to spend on the project? SecureBob, MVBob, and MCBob (http://forum.doom9.org/showthread.php?p=892518#post892518) are very slow but very good at creating crisp 60 fps video without combing. You should try those you posted, however, and see if they might work well enough for a fast deinterlace. Especially TDeint and TomsMoComp.

[Livesms]

How much time are you willing to spend on the project? SecureBob, MVBob, and MCBob (http://forum.doom9.org/showthread.php?p=892518#post892518) are very slow but very good at creating crisp 60 fps video without combing. You should try those you posted, however, and see if they might work well enough for a fast deinterlace. Especially TDeint and TomsMoComp.

Time is not obligation. The main aim is quality.
Can you give working examples for quality/slowest and quality/normal speed scripts.

TDeint sometimes give some artifacts like lines and scratces, while TomsMoComp adds some blur in to picture.

What does it mean "creating crisp 60 fps" - i need 25P and my source is 25I(50p/2).

[foxyshadis]

Oh right, PAL - 50 fps then, to which you'd use SelectEven after if you only want 25. I can't really give you good arguments, but that's because I've always been able to get very good results without any parameters.

[Livesms]

Oh right, PAL - 50 fps then, to which you'd use SelectEven after if you only want 25. I can't really give you good arguments, but that's because I've always been able to get very good results without any parameters.

Yes, but SelectEven will lose half of frames.
I need good deinterlace :)

I've always been able to get very good results without any parameters.

Can you explaine it :)?

[Chainmax]

tritical, I didn't forget about the Mode0,2 and 7 tests. I'll get to them most likely today.

[foxyshadis]

Yes, but SelectEven will lose half of frames.
I need good deinterlace :)

You said you needed 25 fps, not 50, right? Bob.SelectEven means the same as Deinterlace. You end up with 25 fps either way, because bobbing doubles the frames.

[Livesms]

You said you needed 25 fps, not 50, right? Bob.SelectEven means the same as Deinterlace. You end up with 25 fps either way, because bobbing doubles the frames.

Is there any sence to search in parametres for Mvbob?

How can I found out what shell I use Mvbob().SelectEven or mvbob.SelectOdd()

[Mug Funky]

use selecteven unless you've got half a line of black on the top of the screen (in that case use selectodd)

[tritical]

What do you think about extending that "drop one side of scene change during video w/SC" thing so that if the hints declare that only of the two frames (or maybe one in the whole cycle) is combed, drop that one.
Choosing which frame, of the two around the sc, to drop based on only one of the two being combed is possible. Atm, it always selects to drop the frame before the sc since it has the lower difference metric. I'll add it in the next release. Requiring that it be the only combed frame in the cycle would probably help as well.

@All
I also came across some clips where the regular field matching function in tfm wasn't able tell the difference between two matches but the MIC values made the correct choice obvious (such as 85 vs 9). So I've extended micmatching modes 1/2/3 to include a post match comparison step that looks at the mic values and will change the match decision in such blantantly obvious cases.

[DarkNite]

@All
I also came across some clips where the regular field matching function in tfm wasn't able tell the difference between two matches but the MIC values made the correct choice obvious (such as 85 vs 9). So I've extended micmatching modes 1/2/3 to include a post match comparison step that looks at the mic values and will change the match decision in such blantantly obvious cases.

Thank you tritical. I was just about to post on that issue as it became apparent when I was running through an old torture test source that I would like to actually get respectable results on someday without scripting hundreds of FreezeFrame ranges again.

That still won't happen, but it's bound to help out in other cases.

[tritical]

[link removed], changes:
TDecimate:
- switch setfps() with muldivfps() for modes 0, 1, and 5
- use FloatToFPS() from assumefps/changefps/convertfps for modes 2 and 7

TFM:
+ micmatching modes 1, 2, and 3 now check each match decision for cases where the
correct match is obvious based off mic values but the field matching routine
is unable to distinguish the correct match
+ added micmatching mode 4, does the post match decision check and nothing else

For the moment, the override decision to switch from m1 to m2 is simply:

if ((mics[m2]*3 < mics[m1] || (mics[m2]*2 < mics[m1] && mics[m1] > MI)) && abs(mics[m2]-mics[m1]) >= 30 && mics[m2] < MI)

where m1 was the chosen match, m2 was the alternative, and mics[x] is the MIC value for match x. The >= 30 means the MIC value for match m2 doesn't need to be calculated unless m1 has a MIC value >= 30. Since that usually isn't the case, there shouldn't be much of a slowdown vs previous versions.

[tritical]

Anyone ever noticed Vinverse? It's just this: Make a small-range blur. Then, of this make an inverse blur at a wider range (speak: USM), /w configurable strength. Manipulate the result so that the 2nd one isn't allowed to add (remove) more than the 1st one previously did remove (add).
Compared to the ease of operation, the outcome is valuable. Try. One might say, it seems almost like a plugin function candidate.

Don't say I never did anything useful ;)... vinverse (http://bengal.missouri.edu/~kes25c/vinverse.zip).

[Didée]

Didn't ever say so ... your plugins eat much of my CPUs' cycles every day. ;)

Ah, the speed! With a 10fold call, pace is ~400% of the script function. (what, is that all? booo! :D ) Configurable 'scale' is nice, too. (I was lazy to silently fix it at .25)

Really great, thank you. :)

[Chainmax]

tritical, sorry to have procrastinated for so long. I downloaded SysInternals's DebugView and tried a slightly different mode=2 script:

[script deleted]

Which, upon loading gave me the following error message:
http://img292.imageshack.us/img292/8628/vderrzi3.png (http://imageshack.us)
(that would be the TDecimate line)

and the following DebugView log:
http://img355.imageshack.us/img355/7715/dbgvwerrpm8.png (http://imageshack.us)

The stats file was created from an earlier clip but it was made according to your instructions and in that regard the script didn't change.

[foxyshadis]

Open the stats files and delete the parts marked crc; they're normally designed to require exactly the same input as the first run, but you can override it that way. Once you do that, you'll be able to open to debug further if necessary.

[tritical]

Alright, I don't know where to put this so I'm putting it here: smartdecimate+avisynthc (http://bengal.missouri.edu/~kes25c/smartdecimate_avisynthc.zip). These are builds I made from the sources on Kevin Atkinson's site (avisynth_c 0.15/smartdecimate 0.23)... the normal version would always crash if weave/bob were the same... at least for me.

Ah, the speed! With a 10fold call, pace is ~400% of the script function. (what, is that all? booo! )
My first attempt was only about 1.5x the speed of the script function... luckily the second one was a little faster :).


@Chainmax
I'm definitely interested in the results of your tests.

[DarkNite]

Wow, that was straight out of left field... I haven't seen smartdecimate in a while. In fact, I haven't used it since I started using TIVTC regularly. :D

[Chainmax]

...
@Chainmax
I'm definitely interested in the results of your tests.

They are coming up soon, I decided to make a new stats file as I changed bobbing to SecureBob since it looked better.

[Chainmax]

tritical: Phew! Stats creation took over a day :D.
The tests were conducted with the following script:

SetMemoryMax(256)

LoadPlugin("X:\wherever\DGDecode.dll")

LoadPlugin("X:\wherever\ColorMatrix.dll")

LoadPlugin("X:\wherever\Corrector.dll")
LoadPlugin("X:\wherever\EEDI2.dll")
LoadPlugin("X:\wherever\LeakKernelDeint.dll")
LoadPlugin("X:\wherever\MVTools.dll")
LoadPlugin("X:\wherever\MedianBlur.dll")
LoadPlugin("X:\wherever\SangNom.dll")
LoadPlugin("X:\wherever\TomsMoComp.dll")
Import("X:\wherever\MVBob.avs")

LoadPlugin("X:\wherever\TIVTC.dll")

LoadPlugin("X:\wherever\MT_MaskTools.dll")
LoadPlugin("X:\wherever\DCTFilter.dll")
Import("X:\wherever\DeBlock_QED_MT2.avs")

LoadPlugin("X:\wherever\FFT3DFilter.dll")

LoadPlugin("X:\wherever\Deen.dll")
Import("X:\wherever\HQDering_MT2.avs")

LoadPlugin("X:\wherever\RemoveGrain.dll")
Import("X:\wherever\LimitedSharpenFaster.avs")
Import("X:\wherever\Soothe_MT2.avs")

LoadPlugin("X:\wherever\AddGrainC.dll")




MPEG2Source("X:\wherever\familytape.d2v",info=3)

Trim(0,1982)+Trim(2355,0)

ColorMatrix(hints=true,interlaced=true)

SecureBob()

TDecimate(cycleR=2003,cycle=5000,input="stats.txt",debug=true)
TDecimate(mode=2,rate=29.97,input="stats.txt",debug=true)
one of these per test, of course ;)

DeBlock_QED()

Crop(22,6,688,552,align=true)

FFT3DFilter(sigma=6,plane=3,bw=32,bh=32,bt=3,ow=16,oh=16)

ColorYUV(off_y=-3,gain_y=20,cont_u=0,cont_v=51.2,opt="coring")

HQDering(255)

FFT3DFilter(sigma=1,bw=32,bh=32,bt=3,ow=16,oh=16,sharpen=0.3)

Lanczos4Resize(656,448)

dull=last
sharp=dull.LimitedSharpenFaster(SMode=4,Strength=150,wide=true)
Soothe(sharp,dull,25)

AddGrainC(5,2)

AddBorders(32,16,32,16)

Levels(0,1,255,16,235)

a = ImageSource("X:\wherever\Otrarr.bmp")
ApplyRange(2354,2357,"Overlay",a)

b = ImageSource("X:\wherever\Frm3.bmp")
ApplyRange(2358,2393,"Overlay",b)

c = last.Trim(2395,2395)
ApplyRange(2394,2394,"Overlay",c)

d = last.Trim(72151,72151)
ApplyRange(72150,72150,"Overlay",d)

e = last.Trim(82220,82220)
ApplyRange(82219,82219,"Overlay",e)

f = last.Trim(152177,152177)
ApplyRange(152176,152176,"Overlay",f)

g = last.Trim(164536,164536)
ApplyRange(164532,164656,"Overlay",g)

h = last.Trim(164660,164660)
ApplyRange(164657,164659,"Overlay",h)

i = last.Trim(165675,165675)
ApplyRange(165676,165676,"Overlay",i)

j = last.Trim(165686,165686)
ApplyRange(165681,165686,"Overlay",j)

k = last.Trim(165687,165687)
ApplyRange(165688,165688,"Overlay",k)

l = ImageSource("X:\wherever\HiPay.bmp")
ApplyRange(171430,172184,"Overlay",l)

I'm happy to report that Mode=0 seemed to work perfectly, it loaded just fine and I could even drag the slider to jump around the video. You can download DebugView's log here (http://rapidshare.com/files/2730976/M0Dbgvw.LOG.html).

Mode=2, however, was not so lucky. I received the same access violation error that points at the TDecimate line. DebugView's log was as follows:

http://img204.imageshack.us/img204/3901/m2dbgvwdo0.png (http://imageshack.us)

I hope this helps.