TDeint and TIVTC

[tritical]

What are the numerator and denominator values for the fps of the clip being fed into tdecimate (should be able to see the values using info())? Unfortunately, the mode 2 debug output doesn't tell much about what might be happening except that it isn't getting all the way through tdecimate's constructor. For mode 2 w/ 50 fps input and 29.970 rate, it should spit out:

[4548] TDecimate: v0.9.12.5 by tritical
[4548] mode2_num = 1 mode2_den = 3 numCycles = 19 clength = 15
[4548] mode2_cfs 0 = 15
[4548] TDecimate: inframe = 0 useframe = 1 rate = 29.969999

If you remove everything after tdecimate from the script does it still crash?


EDIT:

I was able to run this script without any problems:

mpeg2source("C:\test clips\t4.d2v",idct=7,info=3)
assumefps(25,1)
ColorMatrix(hints=true,interlaced=true)
SecureBob()
TDecimate(mode=2,input="test.txt",rate=29.970,debug=true)

and the same script without stats input.

[canuckerfan]

i have some dvd telecined footage with an altering field structure (most of the movie is TFF, but sometimes it will change to BFF, I know, it's bad). Is there any possibility of handling the TTF part of the footage as TFF, and the same with respect to BFF. Thanks.

[tritical]

You could use mode=4 or mode=5 in tfm, both of which can handle alternating field order since they use 3-way (p/c/n) matching. The alternative is to manually find the places where the field order changes and then either use a series of trim()'s to create a new clip out of each and field match them separately or keep it as one clip and use an overrides file in tfm to change the value for order over the necessary frame ranges.

[canuckerfan]

I see. So if I had TIVTC+EEDI2 called like this:

AssumeTFF()
Interp = SeparateFields().SelectEven().EEDI2(field=1)
Deinted=TDeint(order=1,field=1,edeint=Interp)
TFM(mode=6,order=1,PP=7,slow=2,mChroma=true,Clip2=Deinted)
TDecimate(mode=1)

Changing the modes wouldn't simply work, would it? TDeint params would have to change, right? Wondering if there's any quick way of finding out where the field order changes in the footage without manually scanning through DGIndex.

EDIT: well, initially I was using mode 6, and it left some combing in some scenes. however, mode 4 seems to leave almost none. so far, things seem fine without adjusting the TDeint params.

[ChiDragon]

tritical:
I've got a video that seems to require decimation by 184-frame cycles. Since the cycles are so large, some frames are incorrectly decimated (particularly at fades to black, where it will drop a bunch of black frames and leave duplicates in the real video). Anyway, I was trying to override these parts and TDecimate appears to be ignoring the override line past a certain point. It will only read this far:

0,1000 -++++-++++-+++++-++++-++++-++++-+++++-++++-++++-++++-+++++-++++-++++-+++

Adding anything to the end of this line doesn't actually change the decimation, whether it's + or -. The 72nd frame is where it stops following the override line.

[tritical]

I probably used an 80 byte buffer for reading each line so the rest gets cut off. I'll increase the size in the next release.

[Chainmax]

What are the numerator and denominator values for the fps of the clip being fed into tdecimate (should be able to see the values using info())? Unfortunately, the mode 2 debug output doesn't tell much about what might be happening except that it isn't getting all the way through tdecimate's constructor. For mode 2 w/ 50 fps input and 29.970 rate, it should spit out:

[4548] TDecimate: v0.9.12.5 by tritical
[4548] mode2_num = 1 mode2_den = 3 numCycles = 19 clength = 15
[4548] mode2_cfs 0 = 15
[4548] TDecimate: inframe = 0 useframe = 1 rate = 29.969999

If you remove everything after tdecimate from the script does it still crash?
...

I'll try it and report back ASAP.

[Livesms]

What it the defference beatween
AssumeTFF()
interp = separatefields().selecteven().EEDI2(field=1)
tdeint(order=1,field=1,edeint=interp)

AssumeTFF()
Interp = SeparateFields().EEDI2(field=3)
TDeint(mode=1,order=1,edeint=Interp).selecteven()
AssumeTFF()
edeintted = SeparateFields().EEDI2(field=-2)
TDeint(mode=1,order=-1,full=false,edeint=edeintted).Selecteven()

[ChiDragon]

I tried increasing the fgets value from 80 to 300 myself, and now it's actually crashing when the ovr line is longer than 103 chars.

[tritical]

@canuckerfan
Sorry I didn't reply to your last post earlier, I must of missed it. You're correct on TDeint not working correctly in that script if the field order changes. I was thinking of tfm by itself (its pping doesn't depend on field order). If it is deinterlacing only a few frames it'll probably be fine though. I don't know of any automatic way to determine where the field order changes. It's interesting that you get field order changes without dgindex finding illegal tff flag transitions in the stream... what version of dgindex are you using?

@Livesms
The first two scripts are logically equivalent and should run at the same speed and produce the same output. The third script is the same as the first two except for the full=false part (it will check each input frame to see if it's combed or not).

@ChiDragon
That's strange that it crashes. I changed all the fgets() calls in tdecimate.cpp/tfm.cpp/tfmpp.cpp from 80 to 1024 and increased the linein[] arrays to 1024 bytes, and everything seemed to work fine. I did a short test with cycle=120, cycleR=2, and the ovr file marking frames 96/116 to drop and it worked fine. What are the cycle/cycleR values you are using? and what are the lines in the ovr file?

[ChiDragon]

Whoops, it never occurred to me to check the linein array declaration! I was busy checking over all the ovrArray stuff... As you may have guessed, I'm not actually a programmer. :P Changing that fixed it of course, thanks.

Weird that it managed to work up until the 104th byte though, when it was only set for 80...

[Livesms]

@Livesms
The first two scripts are logically equivalent and should run at the same speed and produce the same output. The third script is the same as the first two except for the full=false part (it will check each input frame to see if it's combed or not).


So what one can you reccomnd for deinterlace?

Or maybe you have some other variations?

[ChiDragon]

tritical, would it be possible to add a parameter such that no 2 dups may be closer to each other than "n" (when cycleR > 1)?

I think this would solve the problem I'm having with multiple drops at black frames, and dropping the wrong frames in general with a large cycle of this kind. I've had to do a lot of overrides so far since it's often dropping stationary new frames instead of the actual dups. I know with this video that there should never be two real dups less than 5 frames apart.

I was gonna attempt this for myself so I didn't have to bug you again, but I couldn't even find the specific code that takes the lowest cycle metric and declares it as a decimated frame (not for lack of searching...). :confused:

[tritical]

@Livesms
It really depends on the clip at hand and how long you are willing to let it take. I rarely have true interlaced material to process (I mainly work with anime), and primarily use tdeint(mode=2) w/ eedi2 for postprocessing. For true interlaced material I think people concerned the most with speed tend to use LeakKernelDeint() and those concerned the most with quality tend to use mvbob() or now mcbob(). TDeint and TDeint+eedi2 are somewhere in the middle.

@ChiDragon
You should be able to do it by changing this code in void Cycle::setDecimateLow(int num) inside cycle.cpp:


for (v=0, i=0; v<num-ovrDec; ++i)
{
if (decimate[lowest[i]] != 1)
{
decimate[lowest[i]] = 1;
u = lowest[i];
while (decimate2[u] == 1) ++u;
decimate2[u] = 1;
++v;
}
}

to


for (v=0, i=0; v<num-ovrDec; ++i)
{
if (decimate[lowest[i]] != 1)
{
bool update = true;
for (int c=max(cycleS,lowest[i]-LIM); c<=min(cycleE,lowest[i]+LIM); ++c)
{
if (decimate[c] == 1)
{
update = false;
break;
}
}
if (update)
{
decimate[lowest[i]] = 1;
u = lowest[i];
while (decimate2[u] == 1) ++u;
decimate2[u] = 1;
++v;
}
}
}

Replace LIM with the limit you want. I can't test it atm, but it should work... just make sure that lim isn't so large that it can't mark at least cycleR number of frames. To make it an actual parameter in tdecimate would take a little more work. You'd need to modify the cycle class, tdecimate class, and the env->addfunction() call in PluginInit.cpp.

The code in tivtc is definitely not easy follow, but that's what happens after two years of hacking a poorly planned initial design to add new functionality :). I've thought about rewriting it from scratch quite often, but have never found the motivation for that much work.

[Livesms]

@Livesms
It really depends on the clip at hand and how long you are willing to let it take. I rarely have true interlaced material to process (I mainly work with anime), and primarily use tdeint(mode=2) w/ eedi2 for postprocessing. For true interlaced material I think people concerned the most with speed tend to use LeakKernelDeint() and those concerned the most with quality tend to use mvbob() or now mcbob(). TDeint and TDeint+eedi2 are somewhere in the middle.


And what is the most common variant for deinterlacing using EEDI2+TDeint?

MeGui provide sample
edeintted = last.AssumeTFF().SeparateFields().SelectEven().EEDI2(field=-1)
TDeint(order=1,full=false,edeint=edeintted)

WorBry use such script
interp = separatefields().eedi2(field=-2)
tdeint(mode=1,order=1,edeint=interp)
and
interp = separatefields().eedi2(field=3)
tdeint(mode=1,order=1,edeint=interp, AP=5, APType=0 )

Chainmax suggest
#For TFF Clips:
Interp = SeparateFields().EEDI2(field=3)
TDeint(mode=1,order=1,edeint=Interp) and #For BFF Clips:
Interp = SeparateFields().EEDI2(field=2)
TDeint(mode=1,order=0,edeint=Interp)

Another one
Interp = AssumeBFF().SeparateFields().EEDI2(field=3)
TDeint( mode=1, order=1, edeint=Interp, mthreshL=1, mthreshC=2 )

I just messed up

[canuckerfan]

@canuckerfan
Sorry I didn't reply to your last post earlier, I must of missed it. You're correct on TDeint not working correctly in that script if the field order changes. I was thinking of tfm by itself (its pping doesn't depend on field order). If it is deinterlacing only a few frames it'll probably be fine though. I don't know of any automatic way to determine where the field order changes. It's interesting that you get field order changes without dgindex finding illegal tff flag transitions in the stream... what version of dgindex are you using?
i'm using dgindex 1.4.9b3. well, it outputted two d2v files, one with a bad tag and one without the tag. the log for operation stated this:
D2V Fix Output

Field order transition: 0 -> 2
d00 1 0 2732797456 0 0 b0 b0 90 b0 b0 a0 b0 b0 a0 b0 b0 a0 b0 b0 a0
d00 1 0 2733054080 0 0 b2 b2 92 b2 b2 a2 b2 b2 a2 b2 b2 a2 b2 b2 a2
corrected...
d00 1 0 2732797456 0 0 b0 b0 90 b0 b0 a0 b0 b0 a0 b0 b0 a0 b0 b0 a1
d00 1 0 2733054080 0 0 b2 b2 92 b2 b2 a2 b2 b2 a2 b2 b2 a2 b2 b2 a2

so i'm guessing dgindex somehow "fixed" the FO?

[ChiDragon]

That worked great tritical, thanks! :D

canuckerfan, if I'm not mistaken you should be able to treat the whole video as either TFF or BFF (whichever the D2V says) since DGIndex fixed the field order switch.

[canuckerfan]

^I see. so with the following ivtc method, with the above situation:

AssumeTFF()
Interp = SeparateFields().SelectEven().EEDI2(field=1)
Deinted=TDeint(order=1,field=1,edeint=Interp)
TFM(mode=4,order=1,PP=7,slow=2,mChroma=true,Clip2=Deinted)
TDecimate(mode=1)

TDeint's param's need not be changed? And I'm guessing mode 4 or 5 for TFM would still work the best? Thanks.

[Mug Funky]

@ tritical:

i just discovered the new compiles of smartdecimate et al.

excellent!

does this solve all the caching problems? because i've always had probs with the old smartdecimate (crash on 2nd pass start the most annoying one), but i just quickly hacked in into my auto-pal function and it worked a treat. massive speedup. and thanks to vinverse plugin no artefacts either!

[foxyshadis]

^I see. so with the following ivtc method, with the above situation:

AssumeTFF()
Interp = SeparateFields().SelectEven().EEDI2(field=1)
Deinted=TDeint(order=1,field=1,edeint=Interp)
TFM(mode=4,order=1,PP=7,slow=2,mChroma=true,Clip2=Deinted)
TDecimate(mode=1)

TDeint's param's need not be changed? And I'm guessing mode 4 or 5 for TFM would still work the best? Thanks.

When using dgdecode, overriding field order is superfluous, even dangerous. At the very least annoying needing two different variations, when one does fine.
Interp = SeparateFields().SelectEven().EEDI2(field=-1)
Deinted=TDeint(edeint=Interp)
TFM(mode=4,PP=7,slow=2,mChroma=true,Clip2=Deinted)
TDecimate(mode=1)
Tritical, I'm curious, what is the logic behind setting TDeint's field to 0 if hints=true? I'd never noticed that before.

[Chainmax]

What are the numerator and denominator values for the fps of the clip being fed into tdecimate (should be able to see the values using info())? Unfortunately, the mode 2 debug output doesn't tell much about what might be happening except that it isn't getting all the way through tdecimate's constructor. For mode 2 w/ 50 fps input and 29.970 rate, it should spit out:

[4548] TDecimate: v0.9.12.5 by tritical
[4548] mode2_num = 1 mode2_den = 3 numCycles = 19 clength = 15
[4548] mode2_cfs 0 = 15
[4548] TDecimate: inframe = 0 useframe = 1 rate = 29.969999

If you remove everything after tdecimate from the script does it still crash?
...

Yes, it still crashes with the error message pointing to the TDecimate line even removing everything after it, so I can't answer the firt part either.

[tritical]

@Chainmax
Yes, it still crashes with the error message pointing to the TDecimate line even removing everything after it, so I can't answer the firt part either.
The error msg is an access violation msg? To get the num/den values just remove tdecimate and put info() in its place:

MPEG2Source("X:\wherever\familytape.d2v",info=3)
Trim(0,1982)+Trim(2355,0)
ColorMatrix(hints=true,interlaced=true)
SecureBob()
info()

and could you post the d2v file? Also, how big is the source file? ... the easiest way to debug the problem would be to have the source, but if it's really big I'll try with just the d2v file first.

@foxyshadis
TDeint sets field to 0 if it detects hints because telecide matches off the bottom field. TFM can match off either, but it includes the field that it matched from in the hints that it passes... so TDeint uses the field value in the hints in that case.

@Mug Funky
does this solve all the caching problems? because i've always had probs with the old smartdecimate (crash on 2nd pass start the most annoying one) Dunno. The only problem I specifically looked at was the crashing when bob and weave were set to the same clip. If you have any other problems just post a script causing it and I'll take a look.

@canuckerfan
The d2v file without the .bad extension should be free of field order changes, so the normal tdeint/tfm script should work fine. Also, mode 4 or 5 should be unnecessary if the field order doesn't change.

@Livesms
Reading the eedi2 and tdeint help files for descriptions of the parameters would be the easiest way to tell how the scripts you posted differ from each other. The default versions of tdeint+eedi2 are:

for same rate deinterlacing:

interp = separatefields().selecteven().eedi2()
tdeint(edeint=interp)

for bobbing:

interp = separatefields().eedi2(field=-2)
tdeint(mode=1,edeint=interp)

Then add assumetff() or assumebff(), whichever the video is, just before the interp line.

[Chainmax]

@Chainmax

The error msg is an access violation msg? To get the num/den values just remove tdecimate and put info() in its place:

MPEG2Source("X:\wherever\familytape.d2v",info=3)
Trim(0,1982)+Trim(2355,0)
ColorMatrix(hints=true,interlaced=true)
SecureBob()
info()

and could you post the d2v file? Also, how big is the source file? ... the easiest way to debug the problem would be to have the source, but if it's really big I'll try with just the d2v file first.
...

Yes, the error message points to an access violation corresponding to the TDecimate line. The script you posted doesn't yield num/den values even if I add TDecimate in mode=7 before or after the info() line.
The source is a DVD and the VOBs occupy ~3.3GB, so unless you know of a place where I can upload at least 0.99GB at a time I'd have to snail mail it to you, which is ok y me if it comes to that. Anyway, you can download the d2v file here (http://www.31012.com/~azulftp/familytape.d2v). Let me know when you download it so I can delete it.

[Livesms]

I've got 720*480 29.970fps interlaced(telecined) video. Here is the sample (http://www.egoshare.com/63775068be522ecbf9b0803f9cad26f1/sampleavi.html).


I need to reencode it to play with PAL 4:3 25p

It's look like 4:2 pattern - 4 interlaced frames and 2 progressive frames, but it looks like this has been processed before - because the first of 2 progressive frames has some artifacts that look like a bad deinterlacing.

MeGui test analyse
http://j.foto.radikal.ru/0611/06513d2ba9b4t.jpg (http://foto.radikal.ru/f.aspx?j061106513d2ba9b4png)
And suggested script is
edeintted = AssumeTFF().SeparateFields().SelectEven().EEDI2(field=-1)
tdeintted = TDeint(edeint=edeintted,order=1)
tfm(order=1,clip2=tdeintted).tdecimate(hybrid=3)


But result is not good enough.

What can you suggest - is it possible to turn such video to 4:3 x 25p?

[Didée]

@Livesms - that's fieldblended crappola. The underlying "true" framerate seems to be 22 fps, perhaps 22.5 fps. (Not in the mood now to count exactly;) )
Pretty strange source. Qualified for cabinet of curiosities ...

[Livesms]

@Livesms - that's fieldblended crappola. The underlying "true" framerate seems to be 22 fps, perhaps 22.5 fps. (Not in the mood now to count exactly;) )
Pretty strange source. Qualified for cabinet of curiosities ...

You say 22fps source was telecined to 29.97 with 4:2 pulldown?

So is it possible to correct this source and make it 25fps progressive?

I tried
AssumeTFF()
ConvertToYUY2()
Bob(height=576)
BicubicResize(768,576)
ConvertFPS(50)
SeparateFields.SelectEvery(4,0,3)
Weave()

Look not bad 25i but now there is mixed video with some progressive frames and some interlaced.

[Didée]

Correcting myself: after having a 2nd look, it seems to have been standard 23.976fps film that has been blendconverted. (the source is so crappy, it's not trivial for the naked eye to decide what's a blend and what should be "assumed clean" :D )

Restore24 doesn't play too well with this source: result is jumpy. Try MOmonster's solutions, or the manual deblending approach (blow_up_fps plus SelectEvery(offset) ) that scharfis_brain did show several times.


Edit:

Seems like I'm telling nothing but nonsense this evening, and R24 is more reliable than my eyes. ;)
I got this result (http://rapidshare.com/files/3900394/livesms_R24.avi.html), using
Restore24(numr=2500,deno=5994,useLL=false,fulltriples=false,fra=1,frr=1,edgetype=1,r24size=0.7,nr=-5,ldmp=128.0)

[Livesms]

Correcting myself: after having a 2nd look, it seems to have been standard 23.976fps film that has been blendconverted. (the source is so crappy, it's not trivial for the naked eye to decide what's a blend and what should be "assumed clean" :D )

Restore24 doesn't play too well with this source: result is jumpy. Try MOmonster's solutions, or the manual deblending approach (blow_up_fps plus SelectEvery(offset) ) that scharfis_brain did show several times.

Ok. Thanks - I'll try.

Seems like I'm telling nothing but nonsense this evening, and R24 is more reliable than my eyes. ;)
I got this result (http://rapidshare.com/files/3900394/livesms_R24.avi.html), using
Restore24(numr=2500,deno=5994,useLL=false,fulltriples=false,fra=1,frr=1,edgetype=1,r24size=0.7,nr=-5,ldmp=128.0)
1.38 fps as a result - but total number of frames are correct for 25fps - so I should just andd AssumeFPS(25.00)?

[tritical]

@Chainmax
Could you try these two scripts and see if either crashes:

blankclip(length=287626,pixel_type="YV12",width=720,height=576,fps=50,fps_denominator=1)
tdecimate(mode=2,rate=29.97,debug=true)

blankclip(length=287626,pixel_type="YV12",width=720,height=576,fps=50,fps_denominator=1)
tdecimate(mode=2,rate=29.97,input="stats.txt",debug=true)

you'll have to generate a stats file for the second, but it should be very fast to make. The blankclip clip should be exactly the same as the clip going into tdecimate in your case except for the actual imagecontent. Both scripts work fine here.

[Terranigma]

tritical, will there be an update to Tdeint in the future, and if so, will it have this function Here (http://forum.doom9.org/showpost.php?p=889533&postcount=748) that you and I were discussing?
:D
It's seems like it'd function similar to the AdaptOvr (http://forum.doom9.org/showthread.php?t=117869) script I once requested, which i'll be happy with either or. :)

[tritical]

There will be one in the next week sometime. I've already added the tswitch function, fixed the problem with reading tfm's hints when passing through dgdecode's hints, and added a new blend deinterlacing mode. The remaining items are outputting a map and the deinterlaced frame at the same time (should be quick to add) and having the motion detection correctly handle the top/bottom lines (did about half of this already). Atm, I am messing other things.. neural network based edi, phase plane correlation motion estimation, and trying to improve some pso variations (clpso/dms-pso) for very high dimensional optimization (that last one is for school, but I'm using dms-pso/clpso to train the nn's for my nn-edi attempt).

[buzzqw]

i have a little problem

this script

Import("C:\holding zone c\createautodeintmovie.avs") #original script filename
global unused_ = blankclip(pixel_type="yv12", length=10).TFM()
file="C:\holding zone c\createautodeintmovie.avs.bautodeint_temp.data"
global sep="-"
function IsMoving() {
global b = (diff < 1.0) ? false : true}
c = last
global clip = last
c = WriteFile(c, file, "a", "sep", "b")
c = FrameEvaluate(c, "global a = IsCombedTIVTC(clip, cthresh=9)")
c = FrameEvaluate(c, "IsMoving")
c = FrameEvaluate(c,"global diff = YDifferenceFromPrevious(clip)")
crop(c,0,0,16,16)
SelectRangeEvery(15,15,0)



and this is "createautodeintmovie.avs"

LoadPlugin("C:\Programmi\PureBasic4\AutoMKV\exe\filter\dgdecode.dll")
LoadPlugin("C:\Programmi\PureBasic4\AutoMKV\exe\filter\decomb.dll")
LoadPlugin("C:\Programmi\PureBasic4\AutoMKV\exe\filter\TIVTC.dll")
movie = mpeg2source("C:\holding zone c\movie.d2v")
return movie

will produce some errors in "bautodeint_temp.data" (the log file), example (and all row are the same)

I don't know what "a" means-true
I don't know what "a" means-true
I don't know what "a" means-true


where is the error ?

thanks !

BHH

[Chainmax]

@Chainmax
Could you try these two scripts and see if either crashes:

blankclip(length=287626,pixel_type="YV12",width=720,height=576,fps=50,fps_denominator=1)
tdecimate(mode=2,rate=29.97,debug=true)

blankclip(length=287626,pixel_type="YV12",width=720,height=576,fps=50,fps_denominator=1)
tdecimate(mode=2,rate=29.97,input="stats.txt",debug=true)

you'll have to generate a stats file for the second, but it should be very fast to make. The blankclip clip should be exactly the same as the clip going into tdecimate in your case except for the actual imagecontent. Both scripts work fine here.

The first script works perfectly. I'll get to the second one soon.


The second one loads fine as well :confused:.
Maybe it's just some Avisynth weirdness on my end, so 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?

[Wilbert]

Import("C:\holding zone c\createautodeintmovie.avs") #original script filename
global unused_ = blankclip(pixel_type="yv12", length=10).TFM()
file="C:\holding zone c\createautodeintmovie.avs.bautodeint_temp.data"
global sep="-"
global diff=1.0
global a=true
function IsMoving() {
global b = (diff < 1.0) ? false : true}
c = last
global clip = last
c = WriteFile(c, file, "a", "sep", "b")
c = FrameEvaluate(c, "global a = IsCombedTIVTC(clip, cthresh=9)")
c = FrameEvaluate(c, "IsMoving")
c = FrameEvaluate(c,"global diff = YDifferenceFromPrevious(clip)")
crop(c,0,0,16,16)
SelectRangeEvery(15,15,0)

does that work?

[Chainmax]

Should I cut&paste that into a script and try to load it?

[buzzqw]

@Wilbert

Yes ! is working... now i will ask Berrinam to update BAutoDeint.exe

thanks again

BHH

[Livesms]

I'm sorry. Could anybody tell me what does it script for
Import("C:\holding zone c\createautodeintmovie.avs") #original script filename
global unused_ = blankclip(pixel_type="yv12", length=10).TFM()
file="C:\holding zone c\createautodeintmovie.avs.bautodeint_temp.data"
global sep="-"
global diff=1.0
global a=true
function IsMoving() {
global b = (diff < 1.0) ? false : true}
c = last
global clip = last
c = WriteFile(c, file, "a", "sep", "b")
c = FrameEvaluate(c, "global a = IsCombedTIVTC(clip, cthresh=9)")
c = FrameEvaluate(c, "IsMoving")
c = FrameEvaluate(c,"global diff = YDifferenceFromPrevious(clip)")
crop(c,0,0,16,16)
SelectRangeEvery(15,15,0)

and where can I find createautodeintmovie.avs script. From script name I see it has some auto function for TDeint - does it mean this script analyse video and chose best setting for deinterlace?

[buzzqw]

http://forum.doom9.org/showthread.php?p=765485

not truly create an avs to deinterlace BUT analyze the clip, and find the "interlace pattern"

watch at result and then apply something like....

interlaced: LeakKernelDeint(order=xxx)
decimating: tfm(movie.d2v).tdecimate()
partly film: tfm(d2v="movied2v").tdecimate(hybrid=1)
film:tfm(d2v="movie.d2v").tdecimate()
partly interlaced:
edeintte=last.SeparateFields().SelectEven().EEDI2(field=-1)
TDeint(full=false,edeint=edeintted)

(as automkv do...)

BHH

[Valeron]

hi, i'm new to tdeint and found it's not easy to tweak it for some stuff.

here's a sample
http://img205.imageshack.us/img205/7106/interlacesamplegr6.jpg

i've tried lowering the mthresh and cthresh to try catch the comb, type 1 and 3 are also employeed.
any parameter i missed can help improve the result?

btw, tomsmocomp(1,5,1) give me far better result, at least, no comb left, but i found the result a bit smeared.

[AVIL]

Hi,

Could be a problem of field ordering. To test it, use tdeint with only the parameter "order". Admits three value. -1, 0, 1. Try with 0 and 1. If the result is good with parameter 0 then your video is bff. If the resutl is good with parameter 1 your video is tff. In none is good, then really tdeint is not well suited. But is the first case I've heard of. Anyway is convenient post also the script used.

Good luck

[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.....:stupid:
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.