TDeint and TIVTC

[zdark]

I am having certain lag in slow scenes. If I to use...telecide() for But its filter it is better, I changed setting.

source original: DVD NTSC 720x480
my script for desintrelaced

interp = separatefields().eedi2(field=-2)
deinted = tdeint(mode=2,edeint=interp,type=3)
TFM(clip2=deinted,order=-1,mode=5,pp=7,field=-1,slow=2)

now its fine?

is for anime Vision of escaflowne

You can say me because she is giving lag?

http://rapidshare.com/files/33066521/teste2.mp4.html

[Leak]

source original: DVD NTSC 720x480
[...]
interp = separatefields().eedi2(field=-2)
deinted = tdeint(mode=2,edeint=interp,type=3)
TFM(clip2=deinted,order=-1,mode=5,pp=7,field=-1,slow=2)
Since I very much doubt Escaflowne was animated at 30 FPS - where's your call to TDecimate?

Your current script will result in eveyr fifth frame being a duplicate.

Also, what's the deal with "fansubbing" something that's been released all over the world (at least Japan, America, Canada, UK, Germany and France) for years? :mad:

np: Legiac - Dide Skin (Mings Feaner)

[zdark]

I taste of you liven up old. I go to test adding the TDecimate!

[zdark]

leak my test.

no filter: http://rapidshare.com/files/33178778/escaflowne_no_filter.mp4.html
filtered: http://rapidshare.com/files/33175940/escaflowne_filter.mp4.html

now its fixed.

I used

edeintted = last.AssumeTFF().SeparateFields().SelectEven().EEDI2(field=-1)
deinted = TDeint(order=1,edeint=edeintted)
TFM(clip2=deinted,order=-1,mode=5,pp=7,field=-1,slow=2).tdecimate(hybrid=3)



thanks for help!

[DarkNite]

Also, what's the deal with "fansubbing" something that's been released all over the world (at least Japan, America, Canada, UK, Germany and France) for years?

Well, it may be that the translation was weak and erroneous (if it's anything like the English translation) or that it may not be available in his native language.

Or, it may just be that karaoke scripts are indeed that important to some people. :)

[tritical]

Haven't been able to reproduce the mode 5 problem, so I'm just gonna go ahead and release a new version with the fixes so far. [link removed], changes:
tdecimate:
- Lots of fixes for mode 2 and non-standard framerates
- Fixed problem in mode 0 decimation when using tfm hints and looking for
singleton match duplicates

tfm:
- Fixed incorrect handling of the top/bottom lines in cubic post-processing

[Terranigma]

You know the drill ;) :goodpost:

[zdark]

tritical thanks, good job!

[plugh]

An exclusion band in tdecimate could be accomplished by using the clip2 parameter:

mpeg2source()
tfm()
saved = last
stackvertical(crop(),crop()) # set crops to remove lines containing subtitles
tdecimate(clip2 = saved)

In this case, tdecimate will calculate everything based on the input clip, but will output frames from clip2. The clip2 clip only has to have the same number of frames as the input. All other properties: height, width, and colorspace can be different. You could replace cropping/stackvertical with another method of removing the subtitles (set the subtitle area to black using overlay, etc...)..

If I may inject a question:

In a thread in the avisynth usage forum, I'm trying to use tdecimate on an animated film that was sped up slightly for broadcast. One of the problems I'm having is (I believe) related to vertical film jitter; the animation has its own dups, but frame to frame film jitter means they don't always align perfectly leading to higher difference metrics.

How can I get the dup matching code to search up/down a few lines to find the min difference metric? That is, given current frame "C" and previous frame "P" calc metrics between

lines C 1 thru N vs lines P 1 thru N as usual,
but also
lines C 1 thru N-1 vs lines P 2 thru N
lines C 1 thru N-2 vs lines P 3 thru N
and
lines C 2 thru N vs lines P 1 thru N-1
lines C 3 thru N vs lines P 1 thru N-2

and use the min metric for the dup check.

BTW, I also encountered a mode 2 rate dependant accvio with this movie. I see your latest version addresses this - I'll give it a whirl.

Thanks!

[ChiDragon]

plugh, I don't get why you'd want it to detect these animation duplicates as dups and decimate them. If anything the higher metrics caused by the jitter should help you only remove the telecine dups.

[plugh]

The jitter isn't consistent. Sometimes it is there, sometimes it isn't. If they aren't detected as dups, then it seems as though mode 1 can't properly apply 'longest run' (and with 720p source at 60fps, there are long runs of dups).

Thank you for your interest. Do you have a suggestion on how to do this type of matching? I was reading about the FrameDiff function, and the post I quoted gave me the idea that there might be some way to tackle this. But 1) I'm not proficient at avisynth scripting, and 2) perhaps tcritical knows some trick in his code that will do this (or could)...

Thanks again.

[plugh]

In an effort to understand and verify the impact of the film jitter on the dup matching, after much RTFMing and experiments I came up with the following (probably horribly inefficient) script which uses tcriticals' CFrameDiff function to evaluate the current frame against vertically offset previous framessep=" "
file = "i:\work5\dupinfo.log"
c=mpeg2source("lk1.d2v",cpu=0)
c=converttoyuy2(c)
c=WriteFile(c, file, "current_frame","sep","u2","sep","u1","sep","at","sep","d1","sep","d2")
c=FrameEvaluate(c, "crop(0,0,0,-4).trim(0,current_frame-1)+crop(0,2,0,-2).trim(current_frame,0)"+chr(13)+"global u2 = CFrameDiff(norm=true)")
c=FrameEvaluate(c, "crop(0,1,0,-3).trim(0,current_frame-1)+crop(0,2,0,-2).trim(current_frame,0)"+chr(13)+"global u1 = CFrameDiff(norm=true)")
c=FrameEvaluate(c, "crop(0,2,0,-2).trim(0,current_frame-1)+crop(0,2,0,-2).trim(current_frame,0)"+chr(13)+"global at = CFrameDiff(norm=true)")
c=FrameEvaluate(c, "crop(0,3,0,-1).trim(0,current_frame-1)+crop(0,2,0,-2).trim(current_frame,0)"+chr(13)+"global d1 = CFrameDiff(norm=true)")
c=FrameEvaluate(c, "crop(0,4,0, 0).trim(0,current_frame-1)+crop(0,2,0,-2).trim(current_frame,0)"+chr(13)+"global d2 = CFrameDiff(norm=true)")
return(c)

which I ran on the opening sequence of my 'problem' film. The opening consists of a black background and red stationary letters which fade in and back out (no scroll, pan, or zoom). The following (editted for formatting) is a portion of the script output, which clearly shows the jitter and it's impact on the dup metric (middle column is the non-shifted metric) 29 17.001106 9.122610 0.000000 9.624715 18.472639
30 17.005119 9.123948 0.305900 9.626945 18.470409
31 8.893853 1.430508 9.107002 17.618704 25.334885
32 16.609142 8.854167 0.000000 9.027629 17.556274
33 16.600225 8.830979 0.531535 9.004441 17.549141
34 23.565033 16.905233 9.010684 0.497200 9.523937
35 16.892748 9.003550 0.366991 9.539098 18.390589
36 16.899437 9.008454 0.141356 9.540436 18.392818
37 16.897207 9.009792 0.472674 9.546233 18.392372
38 16.891855 9.009792 0.520387 9.545341 18.389698
39 16.891855 9.009792 0.131100 9.545341 18.389698
40 16.891855 9.009792 0.663973 9.545341 18.389698
41 16.891855 9.009792 0.051727 9.545341 18.389698
42 16.891855 9.009792 0.223851 9.545341 18.389698
43 16.885612 9.008009 0.367437 9.543557 18.387022
44 16.882936 9.002658 0.085616 9.538206 18.380779
45 8.827412 0.139127 9.002658 17.533087 25.325075
46 16.597103 8.827412 0.140910 9.002658 17.533087
47 23.467377 16.760756 8.859072 1.454142 9.607770
48 16.890518 8.935324 0.127087 9.490047 18.414669
49 16.896315 8.933540 0.127087 9.491831 18.411993
50 16.896315 8.937553 0.059307 9.493169 18.415115
51 16.896315 8.937553 0.057078 9.493169 18.415115
52 16.896315 8.937553 0.021404 9.493169 18.415115
53 16.896315 8.937553 0.000000 9.493169 18.415115
54 16.896315 8.937553 0.000000 9.493169 18.415115
55 16.896315 8.937553 0.000000 9.493169 18.415115
56 16.896315 8.937553 0.000000 9.493169 18.415115
57 16.896315 8.937553 0.000000 9.493169 18.415115
58 16.890518 8.932649 0.296982 9.484696 18.396832
59 16.884722 8.934878 0.000000 9.488709 18.390144
60 16.884722 8.934878 0.074468 9.488709 18.390144
61 8.926851 1.258383 8.865761 17.437660 25.249269
62 16.601563 8.854167 0.000000 9.027629 17.555384
63 16.602455 8.850599 0.572114 9.026737 17.558950
64 23.569492 16.901220 9.017373 0.302779 9.555597
65 16.890965 9.003996 0.000000 9.546233 18.386129
66 16.886505 9.003103 0.074914 9.553368 18.386129
67 16.890965 9.006671 0.117277 9.542665 18.381670
68 16.890965 8.997752 0.000000 9.539990 18.386129
69 16.890965 8.997752 0.111034 9.539990 18.386129
70 16.886505 8.991509 0.084725 9.534639 18.384346
71 16.888288 8.987943 0.000000 9.530180 18.383455
72 16.888288 8.987943 0.049051 9.530180 18.383455
73 16.885612 8.992401 0.070009 9.535531 18.382563
74 16.888288 8.997752 0.000000 9.539990 18.383455
75 16.888288 8.997752 0.041025 9.539990 18.383455
76 16.890072 8.997752 0.058861 9.544449 18.384346
77 16.890965 9.002212 0.000000 9.544449 18.386129
78 16.890965 9.002212 0.028093 9.544449 18.386129
79 8.972335 1.400185 8.910353 17.450592 25.309467
80 16.681828 8.883597 0.000000 9.057952 17.646797
81 16.678707 8.892962 0.112372 9.062857 17.645458
82 23.489672 16.706354 8.810467 1.412225 9.757599
83 16.869560 8.952269 0.000000 9.469089 18.372753
84 16.852169 8.947364 0.178814 9.475778 18.369631
85 16.857965 8.955836 0.325967 9.457495 18.347780
86 16.857965 8.949594 0.000000 9.466413 18.361158
87 16.859749 8.951377 0.114155 9.468197 18.357592
88 16.868668 8.949594 0.233216 9.461954 18.372753
89 16.867777 8.948702 0.000000 9.465522 18.370970
90 16.867777 8.948702 0.101224 9.465522 18.370970
91 16.933773 9.023616 0.807559 9.457495 18.341537
92 8.798427 0.397314 8.938891 17.521938 25.271564
93 16.578375 8.795752 0.345141 8.941566 17.532640
94 23.573059 16.888288 8.977241 0.266660 9.506992
95 16.885612 8.963417 0.000000 9.511451 18.387468
96 16.883829 8.962525 0.047267 9.510559 18.385685
97 16.883383 8.960296 0.131992 9.506546 18.389698
98 16.889181 8.962525 0.000000 9.510559 18.391035
99 16.889181 8.962525 0.049943 9.510559 18.391035
100 16.890965 8.964309 0.083387 9.515018 18.391928
101 16.891855 8.968768 0.000000 9.516802 18.393711
102 16.891855 8.968768 0.019620 9.516802 18.393711
103 16.893639 8.972335 0.060645 9.520370 18.393711
104 16.893639 8.973228 0.000000 9.521261 18.395494
105 16.893639 8.973228 0.037457 9.521261 18.395494
106 8.951823 1.404199 8.871112 17.413136 25.279591
107 16.641695 8.820277 0.000000 8.976794 17.601313
108 16.645262 8.826520 0.063320 8.980362 17.606665
109 16.646601 8.822061 0.104345 8.983037 17.607109
110 23.477633 16.704124 8.805116 1.358269 9.680009
111 16.858858 8.943796 0.155180 9.464184 18.346889
112 16.864208 8.942904 0.277808 9.463292 18.343323
113 16.860195 8.941566 0.000000 9.461954 18.345552
114 16.860195 8.941566 0.182381 9.461954 18.345552
115 16.860195 8.941566 0.285834 9.461954 18.345552
116 16.860195 8.941566 0.000000 9.461954 18.345552
117 16.860195 8.941566 0.111926 9.461954 18.345552
118 16.858412 8.940675 0.073131 9.457495 18.341093
119 16.855736 8.938000 0.000000 9.458386 18.341093
120 16.855736 8.938000 0.050389 9.458386 18.341093
121 16.904787 8.992401 0.869988 9.332638 18.212667
122 16.764769 8.830087 0.000000 9.356717 18.253693
123 16.754066 8.819385 0.838328 9.339772 18.286690
124 16.777700 8.822952 0.162315 9.373662 18.305418
125 16.782606 8.844802 0.000000 9.385702 18.307648
126 16.782606 8.844802 0.045484 9.385702 18.307648
127 16.781713 8.847478 0.109696 9.397296 18.315676
128 16.791525 8.852829 0.000000 9.396404 18.318350
129 16.807577 8.865314 0.045484 9.397296 18.314783
130 8.812250 1.475546 8.881814 17.469320 25.242580
131 16.695652 8.853721 0.000000 9.028075 17.658836
132 16.694759 8.857288 0.221622 9.021832 17.658836
133 16.691193 8.849261 0.185948 9.030750 17.663296
134 16.695652 8.853721 0.000000 9.028075 17.658836
135 23.490564 16.802671 8.834546 1.364066 9.674212
136 16.913260 8.971443 0.074023 9.495399 18.441423
137 16.913260 8.971443 0.000000 9.495399 18.441423
138 16.913260 8.971443 0.035674 9.495399 18.441423
139 16.916826 8.966092 0.177030 9.486480 18.437857
140 16.911476 8.966092 0.000000 9.490939 18.437857
141 16.913260 8.963417 0.049943 9.490047 18.437857
142 16.908800 8.965200 0.109250 9.492723 18.440533
143 16.907909 8.966092 0.000000 9.490939 18.434290
144 16.907909 8.966092 0.075806 9.490939 18.434290
145 16.909246 8.967430 0.075806 9.491385 18.431168
146 16.907017 8.966092 0.000000 9.489155 18.429831
147 16.907017 8.966092 0.028539 9.489155 18.429831
148 16.907017 8.966092 0.020512 9.489155 18.429831
149 16.907017 8.966092 0.000000 9.489155 18.429831
150 16.907017 8.966092 0.034782 9.489155 18.429831
151 16.907017 8.966092 0.818261 9.489155 18.429831
152 8.831425 1.478221 8.898759 17.474672 25.225636
153 16.578821 8.812250 0.465985 8.980807 17.546465
154 16.578375 8.816263 0.243918 8.975456 17.537546
155 23.445526 16.752729 8.821169 1.395280 9.590825
156 16.902557 8.950485 0.075360 9.480682 18.391481
157 16.903450 8.951377 0.155626 9.480682 18.391481
158 16.900774 8.948702 0.000000 9.478899 18.390589
159 16.899881 8.948702 0.101670 9.478007 18.389698
160 16.899881 8.947809 0.071347 9.478007 18.389698
161 16.899881 8.947809 0.000000 9.478007 18.389698
162 16.899881 8.947809 0.028093 9.478007 18.389698
163 16.899881 8.947809 0.061091 9.478007 18.389698
164 16.899881 8.947809 0.000000 9.478007 18.389698
165 16.899881 8.947809 0.026755 9.478007 18.389698
166 16.897654 8.942904 0.132884 9.467752 18.384792
167 16.889181 8.935324 0.000000 9.465522 18.378996
168 16.889181 8.935324 0.063320 9.465522 18.378996
169 16.897207 8.949594 0.308130 9.445901 18.353132
170 16.887842 8.925068 0.000000 9.452144 18.378103
171 8.778360 0.121290 8.932649 17.531303 25.325521
172 16.603792 8.785941 0.099440 8.922392 17.517481
173 23.601599 16.879816 8.924176 0.089184 9.446793
174 16.881599 8.922392 0.089184 9.449469 18.371861
175 16.880262 8.926406 0.065104 9.448131 18.375874
176 16.884275 8.926851 0.000000 9.453928 18.374537
177 16.886505 8.926406 0.070901 9.454373 18.374983
178 16.886951 8.926851 0.035228 9.453928 18.377213
179 16.886951 8.926851 0.000000 9.453928 18.377213
180 16.886951 8.926851 0.021404 9.453928 18.377213
181 16.894531 8.980807 1.240992 9.342002 18.245667
182 16.768335 8.822061 0.000000 9.369649 18.282677
183 16.808023 8.876908 0.541791 9.366528 18.268854
184 16.777700 8.829641 0.197096 9.382581 18.296501
185 8.801994 1.439872 8.876908 17.434093 25.210920
186 16.674248 8.835884 0.132884 9.004441 17.635649
187 16.678707 8.834101 0.102115 9.007117 17.632973
188 23.485214 16.761648 8.834101 1.318136 9.659050
189 16.888735 8.941121 0.072685 9.481575 18.413332
190 16.893194 8.952715 0.061091 9.473548 18.407089
191 16.886951 8.944688 0.000000 9.479791 18.412439
192 16.886059 8.942904 0.042808 9.479791 18.410656
193 16.886505 8.945134 0.152504 9.472210 18.407534
194 16.882492 8.941121 0.000000 9.475331 18.405304
195 16.879816 8.938445 0.092751 9.475331 18.404413
196 16.879816 8.938445 0.105683 9.473548 18.405304
197 16.879816 8.938445 0.000000 9.473548 18.405304
198 16.879816 8.938445 0.054402 9.473548 18.405304
199 16.879816 8.938445 0.042808 9.473548 18.405304
200 16.879816 8.938445 0.000000 9.473548 18.405304
201 16.879816 8.938445 0.021404 9.473548 18.405304
202 8.798427 0.161869 8.917933 17.520155 25.292522
203 23.536940 16.863317 8.924176 0.157855 9.488709
204 16.878923 8.942013 0.034782 9.477116 18.404413
205 16.878923 8.942013 0.034782 9.477116 18.404413
206 16.878923 8.942013 0.000000 9.477116 18.404413
207 16.878923 8.942013 0.028539 9.477116 18.404413
208 16.879370 8.942458 0.028539 9.477561 18.403967
209 16.879370 8.942904 0.000000 9.478454 18.403521
210 16.878923 8.942458 0.018729 9.478007 18.403967
211 16.865992 8.942458 0.513253 9.470427 18.378103
212 16.839684 8.918379 0.000000 9.456158 18.359821
213 16.872681 8.943351 0.648366 9.388377 18.300068
214 16.797321 8.855059 0.108804 9.396404 18.313000
215 16.792416 8.867990 0.000000 9.406660 18.310770
216 16.792416 8.867990 0.047713 9.406660 18.310770
217 16.798658 8.871557 0.253728 9.408443 18.316120
218 16.804010 8.873342 0.000000 9.412011 18.322363
219 8.829195 1.440764 8.871112 17.425175 25.205568
220 16.671572 8.841681 0.329088 9.001766 17.619595
221 16.662207 8.830533 0.000000 8.995077 17.610231
222 16.664883 8.830533 0.135559 8.995969 17.612907
223 23.627907 16.955622 8.971443 0.342466 9.528842
224 16.968554 8.987050 0.000000 9.507884 18.472193
225 16.972120 8.989726 0.105237 9.506100 18.470409
226 16.966770 8.976349 0.125303 9.508776 18.480219
227 16.965878 8.989726 0.000000 9.510559 18.469517
228 16.965878 8.989726 0.050835 9.510559 18.469517
229 16.964987 8.990618 0.151167 9.512343 18.470409
230 16.965878 8.987943 0.000000 9.508776 18.469517
231 16.965878 8.987943 0.034782 9.508776 18.469517
232 16.965878 8.987943 0.051727 9.508776 18.469517
233 16.965878 8.987943 0.000000 9.508776 18.469517
234 16.965878 8.987943 0.025863 9.508776 18.469517
235 16.965878 8.987943 0.047713 9.508776 18.469517
236 16.965878 8.987943 0.000000 9.508776 18.469517
237 16.965878 8.987943 0.018729 9.508776 18.469517
238 16.964987 8.987050 0.168557 9.511451 18.466841
239 8.920609 1.451020 8.909461 17.604879 25.417826
240 16.713488 8.907231 0.101670 9.061519 17.660173
241 16.715271 8.906340 0.717484 9.063303 17.657499
242 23.522671 16.802671 8.948702 1.434075 9.559610
243 16.783052 8.868436 0.312589 9.417362 18.320580
244 16.791969 8.863976 0.120398 9.406660 18.302744
245 16.789295 8.872004 0.000000 9.411119 18.308094

[plugh]

buglet report:

In the process of working with CFrameDiff, I discovered the following:

As expected, (mode=0,norm=false) and (mode=1,norm=false) return radically differant values.
However, (mode=0,norm=true) and (mode=1,norm=true) give IDENTICAL results.

Appears you can't get the normalized 'mode=min' values.


And FWIW, building upon my previous post, I put together a 'vertical jitter correction' script, which I have posted in the other forum here (http://forum.doom9.org/showthread.php?p=1009932#post1009932)

[WorBry]

I actually find the idea behind yadif quite interesting, but the major drawback IMO is the edi method it is uses is overly prone to artifacts. It uses the typical two sliding window method which is highly likely to choose the wrong direction around anything more than a single, thick, lone edge. Every other filter/program that I know of that uses this method caps the output value to be within +-2 or 3 of the min/max of the vertical neighbors to prevent major artifacts. Just to see what would happen, I created a c only version with such capping and to me it looked much better. I also made it possible to take spatial predictions from an external clip. I have some results here: deinterlace_comparison.txt (http://bengal.missouri.edu/~kes25c/deinterlace_comparison.txt) from a comparison I am working on, which I think show the benefits.


Hi Tritical,

The metrics obtained with your modified version of Yadif are very interesting.

Is it possible that the potential interpolation errors introduced by not 'capping' the output might explain the 'vertical jittering' (shimmering) that Yadif seems (by my observation at least) quite susceptible to, or is that a quite different phenomenon?

http://forum.doom9.org/showthread.php?p=1010873#post1010873

[tritical]

@plugh
Yep, it is indeed a bug (actually a missing return statement). As for using the minimum of metrics calculated with different vertical offsets, the method you came up with is probably the simplest. There isn't an easy way to modify tdecimate to do this internally.

@WorBry
Is it possible that the potential interpolation errors introduced by not 'capping' the output might explain the 'vertical jittering' (shimmering) that Yadif seems (by my observation at least) quite susceptible to, or is that a quite different phenomenon?
I think they are slightly different. The artifacts I'm talking about stem from running yadif's type of edi interpolation on something like:

006 202 004 200 004 199 004
o
003 200 005 204 005 198 003

which is an extreme case. However, it would choose to replace 'o' with 4, while it should simply use vertical interpolation. This causes problems mainly around fine lines and details (thick edges are usually fine).

Could you describe more what you mean by 'vertical jittering' or 'vertical shimmering'. I think I know what you are talking about but just want to be sure before writing a lengthy reply :p.

[WorBry]

Could you describe more what you mean by 'vertical jittering' or 'vertical shimmering'. I think I know what you are talking about but just want to be sure before writing a lengthy reply :p.

Sure. I'm referring to a slight jumping up and down ('over-bobbing' you might say) of relatively static objects from frame to frame, resulting in a vertical jitter or shimmering type effect. Most noticable with fine detail - patterns, lettering etc.

There are good examples in the src reference clips that you have been using in your comparison tests, for example the pattern on the shirt of the piano player in the 'Musicians' Clip' and in the 'Toy Train' clip, the sheep on the wall-paper and the dates on the calender.

I'm also posting a short home DV clip that shows the effect quite well

http://rapidshare.com/files/35553085/Shimmer_example_PAL_DV_Type_II.avi

If you run it through Yadif (Mode=1, Order=0) you'll note the marked 'shimmering' of the toy car mat. With MCBob, it is effectively 'calmed-down'.

[plugh]

the method you came up with is probably the simplest. There isn't an easy way to modify tdecimate to do this internally.
OK, thanks.

The mode4 / mode2 combo with the de-jittered stream has produced the best decimation results so far, but it still isn't quite right. I *have* identified the telecining pattern used in this 720p broadcast - 576 film frames into 1409 video frames, which works out to 59.94*(576/1409) = 24.503506032, which yeilds
rate = 24.503506 actual rate = 24.503515
mode2_num = 1 mode2_den = 2 numCycles = -20 clength = 12
mode2_cfs 0 = 12
mode2_cfs 1 = 132
mode2_cfs 2 = 3564
mode2_cfs 3 = 99792
or (60000/1001)*(576/1409) = 24.503530536, which yeilds
TDecimate: mode 2 error, number of frames after decimation doesn't match!
Specifically - the dup counts are
212121212121212121 45->18
112121212121212121 44->18
112121212121212121 44->18
202121212121212121 44->18
202121212121212121 44->18
211121212121212121 44->18
211121212121212121 44->18
212021212121212121 44->18
212111212121212121 44->18
212111212121212121 44->18
212120212121212121 44->18
212121112121212121 44->18
212121112121212121 44->18
212121112121212121 44->18
212121202121212121 44->18
212121211121212121 44->18
212121211121212121 44->18
212121212021212121 44->18
212121212111212121 44->18
212121212111212121 44->18
212121212120212121 44->18
212121212120212121 44->18
212121212121112121 44->18
212121212121112121 44->18
212121212121202121 44->18
212121212121211121 44->18
212121212121211121 44->18
212121212121212021 44->18
212121212121212021 44->18
212121212121212111 44->18
212121212121212111 44->18
212121212121212120 44->18
The most notable 'feature' of the resulting decimation (using 24.503506032) is that sometimes tdecimate eliminates three frames in a row (you can see runs of three telecine dups never occur in the above pattern) and thus ends up including dups elsewhere (see attached images - you can clearly see where dups are getting through). Thus, screen motion is jerky in places.

So my question is, how can I get this 'right', short of hand crafting an ovr file? Are the decimation cycles being derived by mode2 not quite correct? Is there any way to tell it 'max dup length=2' (if that would help)? Or am I doing something fundamentally wrong :confused:

Thanks in advance

[tritical]

@plugh
Could you post the metrics file? Or just send it to my ftp:

12.216.251.99:17262
upload/upload

[tritical]

@WorBry
Here are my results on the clip you posted:

yadif_test.zip (http://bengal.missouri.edu/~kes25c/yadif_test.zip)

The four clips included are:

yadif-type0 - same as yadif(mode=1,order=0)
yadif-type1 - w/ capped edi
yadif-edeint0 - w/ tdeint's temporally switched kernel interpolation for spatial prediction
yadif-edeint1 - w/ eedi2 for spatial prediction

[plugh]

@plugh
Could you post the metrics file? Or just send it to my ftp:


You got it - lk2-try5-tdout.txt
...

So, I thought I'd try something simpler...

Noting the basic blocks of 44 pattern, I decided to try to eliminate just the '2's - ie remove 8 from 44.

Thus:
tdecimate(mode=1,cycleR=8,cycle=44,sdlim=-2,hint=false,blockx=64,blocky=64,nt=1,input=base+tag+"-tdout.txt",batch=true,debug=true)

No joy. For example
TDecimate: 2376: 6.07 0.14 0.10 11.20 0.34 20.93 0.83 23.67 0.15 23.06 0.82 0.13 20.12 0.44 17.25 0.15 0.08 20.86 0.15 18.62 0.14 0.15 27.64 0.34 25.47 0.81 0.39 26.08 0.51 31.60 0.81 0.08 30.27 0.28 25.64 0.19 0.22 16.07 0.41 20.31 0.12 0.30 29.53 0.50
TDecimate: 2376: 0 1 1 0 1 0 1 0 1 0 1 1 0 1 0 1 1 0 1 0 1 1 0 1 0 1 1 0 1 0 1 1 0 1 0 1 1 0 1 0 1 1 0 1
TDecimate: 2376: x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x
TDecimate: 2420: 28.05 0.44 0.19 30.24 1.34 29.10 0.21 25.14 0.66 19.43 0.36 0.06 20.21 0.14 39.44 0.20 0.17 59.02 0.17 54.47 0.06 0.23 56.35 0.87 32.10 0.21 0.08 31.95 0.22 36.14 0.18 0.32 38.80 0.36 54.67 0.12 0.39 57.76 0.49 54.34 0.51 0.51 58.11 0.49
TDecimate: 2420: 0 1 1 0 0 0 1 0 1 0 1 1 0 1 0 1 1 0 1 0 1 1 0 1 0 1 1 0 1 0 1 1 0 1 0 1 1 0 1 0 1 1 0 1
TDecimate: 2420: x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x
TDecimate: 2464: 0.49 0.12 0.13 50.22 0.12 1.44 0.02 0.05 3.34 1.04 0.07 0.10 3.36 0.05 0.13 0.03 0.05 3.41 0.74 1.42 0.07 0.03 3.03 0.17 1.15 0.06 0.26 3.27 0.19 1.30 0.02 0.04 2.93 0.06 1.30 0.10 0.04 3.01 0.13 1.08 0.05 0.04 2.92 0.06
TDecimate: 2464: 1 1 1 0 1 0 1 1 0 1 1 1 0 1 1 1 1 0 1 0 1 1 0 1 0 1 1 0 1 0 1 1 0 1 0 1 1 0 1 1 1 1 0 1
TDecimate: 2464: x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x
TDecimate: 1980: Dropping Frames: 2422 2431 2436 2440 2446 2450 2455 2463
to do what I wanted, it should have dropped 2461, not 2463

I'm guessing it got confused by 2462 being followed by 4 dups - a telecine dup, a FILM dup, then two telecine dups.
But that is why I specified sdlim. Oh, sdlim only kicks in for mode1 if not enough dups found.
Uh, wouldn't it make more sense for it to kick in if too many dups are found, so it could enforce a spacing?

EDIT: hmmm. no, this really needs pattern guidance.
Note the seventh and eighth lines in the pattern above
211121212121212121 44->18
212021212121212121 44->18
Here is my breakdown of the above debug output
TDecimate: 2420: 0 1 1 0 0 0 1 0 1 0 1 1 0 1 0 1 1 0 1 0 1 1 0 1 0 1 1 0 1 0 1 1 0 1 0 1 1 0 1 0 1 1 0 1
F d d F d F d F d F d d F d F d d F d F d d F d F d d F d F d d F d F d d F d F d d F d
2 1 1 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1

TDecimate: 2464: 1 1 1 0 1 0 1 1 0 1 1 1 0 1 1 1 1 0 1 0 1 1 0 1 0 1 1 0 1 0 1 1 0 1 0 1 1 0 1 1 1 1 0 1
D d d F d D d d F D d d F d D d d F d D d d F d D d d F d D d d F d D d d F d D d d F d
2 1 2 0 2 1 2 1 2 1 2 1 2 1 2 1 2 1
('F' is Film, 'D' is film dup, and 'd' is telecine dup)
threshhold dup longest run based algo, even with a full blown sdlim constraint probably can't cope with those film dups on top of the telecine dups.

EDIT (again): OOPS - it is '8 out of 44' only in the blocks with '111' in the pattern. All others have 9 dup pairs. Back to the drawing board...

[plugh]

a stream of consciousness / thought experiment...
-----------------------------------------------------
Given a telecine pattern input, and a set of frame metrics:

assume pattern is expressed as say, 0,1,1,0,... (0=frame, 1=dup)

convert metrics to pattern form using threshold test
(eg less than threshold = -1, more = 0)

pattern match

pat_end = pat_lng-1
for i = 0 to pat_end
for j= 0 to pat_end
correlation(i)= pattern( mod( i+j, pat_lng) ) + metric(j)

This tests every possible rotation of the pattern against the metric.
A perfectly aligned match would give a correlation value of zero.

hmmm. but so would an 'off by one' alignment
pattern = 1 0 1 0 1 0
metric = 0-1 0-1 0-1

perhaps metric should be tri-state (like mode7)
-1 = definite dup, 1 = definite non-dup, 0 = indeterminate?

then pattern is expressed same way
-1 = dup, 1 = non-dup (no zeroes?)

[perhaps 'pattern zeroes' allows fuzziness later?]
[[hmmm... 'fuzzy logic' & pattern matching - where is that text from school?]]


[thoughts -
other choices of 1/0/-1 mapping?
choice of correlation computation? (SAD? SSD?, stats 'correlation coefficient'?)
perhaps binary representation and XOR? ]

Continuing---

With 'best' correlation established, and rotation of pattern aligned,
start decimation process, 'rolling' the pattern along the input.

hmmm. What about pattern breaks? (commercial edits, etc)?

OK, instead of simply rolling the pattern along the input,
at each frame you find the 'best' correlation.

If there was no pattern break, the current rotation should
provide the best correlation.

Yuck - but as you approach the break from upstream, your current 'correct'
rotation of the pattern produces increasingly worse correlation.

So we need a way to recognize discontinuities: hmmm -

-Behind the discontinuity, for the preceding pat_len frames,
we are 'highly' correlated with the 'old' pattern alignment.
-In front of the discontinuity, for the following pat_len frames,
we are 'highly' correlated with the 'new' pattern alignment.
-The discontinuity causes a decrease in correlation as you
approach it (from either side) with a given pattern alignment.
-As you approach the discontinuity, NO (?) pattern alignment will
give a 'good' correlation (what is 'good'?)

Hmmm. perhaps a 'lookahead'?

Given a correlated pattern alignment at frame/metric(n),
ie pattern matches metric(n) through metric(n+pat_lng)
at each frame we check the current alignment against
metric(n + pat_lng) through metric(n +pat_lng +pat_lng)

ie Does the current pattern alignment correlate for two cycles?

If it matches metric n thru n+pat_lng but not n+pat_lng thru n+2*patlng
you have found a discontinuity / pattern break . You need to re-sync
the pattern alignment when you get to that point !


SO - the algo becomes

at the start, you align / correlate pattern to metric.

At each frame, you check to see if the current alignment is
still 'best choice' one full cycle ahead of your current position.

If so, you continue rolling the pattern along the frames.

If not, you finish the current cycle up to the discontinuity,
and start over with new 'best choice' at the new position.

Cool! I think that would work!

Requires input of guidance pattern,
and ability to look ahead two full cycles.

Just leaves choice of 'pattern matching' / correlation algo TBD

Where is that fuzzy logic textbook?
Should also review the stats textbook.
The key is the pattern matcher!!!

[plugh]

576 film frames into 1409 video frames, which works out to 59.94*(576/1409) = 24.503506032, which yeildsrate = 24.503506 actual rate = 24.503515
mode2_num = 1 mode2_den = 2 numCycles = -20 clength = 12
mode2_cfs 0 = 12
mode2_cfs 1 = 132
mode2_cfs 2 = 3564
mode2_cfs 3 = 99792
or (60000/1001)*(576/1409) = 24.503530536, which yeilds TDecimate: mode 2 error, number of frames after decimation doesn't match!

I trim()'d a few frames off the end, deleted the same number from end of metrics file, and second case now yeildsdrop count = 174539 expected = 174539
rate = 24.503531 actual rate = 24.503535
mode2_num = 1 mode2_den = 2 numCycles = 24603 clength = 12
mode2_cfs 0 = 12
mode2_cfs 1 = 132
mode2_cfs 2 = 3564
mode2_cfs 3 = 103356

Which is interesting in several ways.

1) That's how to 'fix' that error condition

2) numCycles is a positive number this time (?)

3) an extra line of debug output that wasn't present before

Seems obvious to me now, but the correct way to calculate the tdecimate target frame rate is in terms of the rate passed in from mpeg2source - in this case 60000/1001 = 59.94005994...

Don't expect it will make a big difference, but we'll see...

[plugh]

I noticed some puzzling results from a script that uses cframediff.

Dug into it, and eventually distilled it down to the following which illustrates the behaviour.

Version().converttoyuy2()

frameevaluate("NOP()")

Writefile("avstst1.txt"\
, "((current_frame==3) && (cframediff(prevf=false) >= 0))"\
, "current_frame"\
)


This generates the following output:
false0
false1
false2
true4
false4
false5
false6
false7

If prevf is set true, you get correct output (ie 'true3').
If the frameevaluate is deleted, you get correct output.

a cframediff buglet?
avisynth weirdness??
stupidity on my part???

Is this cosmetic, or is something getting fundamentally borked?

My application script uses both prevf=true and prevf=false, uses writefileIF rather than writefile, and has a number of scriptclips rather than the frameevaluate. It also has a fair number of references to 'current_frame' other than in the output statement.

I am using avisynth 2.5.6 and tivtc 1.0.2

EDIT: Oh yeah, forgot to ask...

When I look at the debug output of, for example, tdecimate(mode=0), part of the display are some number that I assume are 'normalized framediff metrics'. I also assume that the results from cframediff should be the same as those.

They are not. With identical args (blockx, blocky, chroma, nt) I get somewhat similar, but not identical results.

Are one of my assumptions incorrect?

For example:
TDecimate: 968: 0.02 0.03 0.03 0.01 2.54 0.04 0.09 0.04 1.09 0.08 0.12 0.09 0.02 2.55 0.00 0.03 0.14 0.01 0.76 0.08 0.00 0.08 0.05 1.46 0.02 0.03 0.06 0.01 0.62 0.00 0.02 0.12 0.01 2.71 0.05 0.01 0.16 0.05 1.56 0.03 0.04 0.16 0.01 1.77
TDecimate: 968: x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x
TDecimate: 792: Dropping Frames: 969 974 978 983 987 993 997 1003
output from a script (related to above) -
first value is prevf=true, second is prevf=false
(I think; as you can see 'true' output is borked,
so I'm not sure what I'm *really* getting, but
the first column is similar to the above)
true969 - 0.137566 0.115047
false969 - 0.137566 0.115047
false970 - 0.115047 0.063989
false971 - 0.063989 2.397595
false972 - 2.397595 0.086843
true974 - 0.208690 0.134556
false974 - 0.208690 0.134556
false975 - 0.134556 1.227280
false976 - 1.227280 0.184499
false977 - 0.184499 0.239236
true979 - 0.178479 0.062206
false979 - 0.178479 0.062206
false980 - 0.062206 2.563254
false981 - 2.563254 0.001561
false982 - 0.001561 0.115493
true984 - 0.266325 0.045261
false984 - 0.266325 0.045261
false985 - 0.045261 0.952706
false986 - 0.952706 0.173351
false987 - 0.173351 0.000000
true989 - 0.185837 0.134333
false989 - 0.185837 0.134333
false990 - 0.134333 1.654136
false991 - 1.654136 0.104568
false992 - 0.104568 0.128536
true994 - 0.180597 0.069563
false994 - 0.180597 0.069563
false995 - 0.069563 0.793401
false996 - 0.793401 0.000000
false997 - 0.000000 0.088180
true999 - 0.270673 0.060756
false999 - 0.270673 0.060756
false1000 - 0.060756 3.016084
false1001 - 3.016084 0.183273
false1002 - 0.183273 0.029654
true1004 - 0.237340 0.162092
false1004 - 0.237340 0.162092
false1005 - 0.162092 1.813664
false1006 - 1.813664 0.117277
false1007 - 0.117277 0.149383
true1009 - 0.245924 0.060756
false1009 - 0.245924 0.060756
false1010 - 0.060756 2.123355
false1011 - 2.123355 0.041470
false1012 - 0.041470 0.095538

[dude051]

I got a few questions about the two pass vfr function of TIVTC, and have searched the entire day but found no concrete answers. I am interested in how the vfr function exactly outputs its frames, I am used to Decomb512VFR so bare with me on this. My source is an anime DVD just for reference.

I realize that in using the two pass method, it makes the video seekable by use of the metric files, and the output uses non-padded frames at a cfr output (24fps?). When using the timecodes file this adapts the framerate of the listed frame ranges (correct if I am wrong please) to, in my case, either 23.976024(FILM) or 17.982018(?) with 29.970030(VIDEO) as the rest. This is what creates the variableness of vfr?

My question though is does the process actually remove or insert any frames? I was under the assumption that the process worked mainly by removing frames and using the timecode file to change the frame rate of the range of frames that were removed to make it run at full speed in each cycle. I've noticed that when I have always run Decomb512VFR that the output video was always shorter, and I noticed the parts that sped up from the resulting missing frames. In my source this results in a video with 33474 frames at 18:36.

But when I ran TIVTC's vfr, the resulting number of frames was shorter but also 31 frames larger than the cfr 23.976 counterpart using tdecimate(mode=1,hybrid=1). Resulting in a video with 33381 frames at 23:10 (equal time). So is the vfr output sped up to true FILM 24fps? Does the vfr routine differ from the two, and that accounts for the frame difference? The only thing I can think of, since the time/frame ratio is so drastically different (18:36 more frames to 23:10 less frames), is that Decomb512VFR outputs 29.976fps material and TIVTC outputs 24fps material in their vfr routines. Unfortunately, development has ceased and none of the documentation of Decomd512VFR addresses this for me.

One last thing, could it ever be possible to implement a similar thing in TIVTC where the filter in itself will run the first pass for metrics on the video and create the time codes file? Decomb512VFR is able to run the first pass somehow where ever the avisynth script has been called, so I know its possible, not that I am wining and complaining; but I'm not a programmer and this would just be a nicer feature. Thanks to MeGUI I had to dust off VirtualDub to get the first pass done with TIVTC. On a lighter note, TFM is the best around combined with eeid2 and tdeint, it tears through anime like swiss cheese.

As always, any help appreciated, please correct me if I'm wrong. Thanks.

[plugh]

An OVR file in conjunction with tdecimate mode 7 does not seem to work.

Example:
extract from ovr file
6793 -
6803 -
6808 -

debug output
TDecimate: inframe = 5563 useframe = 6799 chosen = 2
TDecimate: prev = 6798 curr1 = 6799 curr2 = 6800 next = 6800
TDecimate: 6796: 18.79 276299 (N) *
TDecimate: 6797: 0.13 1909 (D) *
TDecimate: 6798: 14.07 206950 (N) *
TDecimate: 6799: 3.37 49609 (S) *
TDecimate: 6800: 0.36 5306 (D)
TDecimate: 6801: 14.50 213178 (N)
TDecimate: 6802: 0.71 10417
TDecimate: ------------------------------------------
TDecimate: inframe = 5564 useframe = 6801 chosen = 1
TDecimate: prev = 6799 curr1 = 6800 curr2 = 6801 next = 6801
TDecimate: 6798: 14.07 206950 (N) *
TDecimate: 6799: 3.37 49609 (S) *
TDecimate: 6800: 0.36 5306 (D)
TDecimate: 6801: 14.50 213178 (N) *
TDecimate: 6802: 0.71 10417
TDecimate: 6803: 14.78 217278 (N)
TDecimate: 6804: 1254484575869219.00 18446744073709551615 (N)
TDecimate: ------------------------------------------
TDecimate: inframe = 5565 useframe = 6802 chosen = 2
TDecimate: prev = 6801 curr1 = 6801 curr2 = 6802 next = 6802
TDecimate: 6799: 3.37 49609 (S) *
TDecimate: 6800: 0.36 5306 (D)
TDecimate: 6801: 14.50 213178 (N) *
TDecimate: 6802: 0.71 10417 (D) *
TDecimate: 6803: 14.78 217278 (N)
TDecimate: 6804: 0.30 4364 (D)
TDecimate: 6805: 1254484575869219.00 18446744073709551615 (N)
TDecimate: ------------------------------------------
TDecimate: inframe = 5566 useframe = 6803 chosen = 1
TDecimate: prev = 6802 curr1 = 6802 curr2 = 6803 next = 6804
TDecimate: 6800: 0.36 5306 (D)
TDecimate: 6801: 14.50 213178 (N) *
TDecimate: 6802: 0.71 10417 (D) *
TDecimate: 6803: 14.78 217278 (N) *
TDecimate: 6804: 0.30 4364 (D)
TDecimate: 6805: 0.07 979 (D)
TDecimate: 6806: 13.25 194905 (N)

As you can see, it chose to use 6803 in spite of the ovr file.

[Terranigma]

As you can see, it chose to use 6803 in spite of the ovr file.
Maybe to retain synchronization?

[juhu]

Hi
I'm currently trying to remove dupes from a dvb-t capture (silent flick). A basic tdecimate(cycler=9,cycle=32) gets rid of the large majority of the dupes...but there are still some

So I played a bit with tdecimate mode2 and maxndl parameter.
As it seems there are never more than 3 real consecutive frames, I used maxndl=3, but to my surprise it doesn't seem to work : with debug (display) mode, I can clearly see almost each time a dupe is still there, it's in a SIX consecutive frames sequence (ie let's say displayed useframe= 1000 to 1005, dupe @ 1003.)
I shouldn't have 6 consecutive frame numbers with maxndl set to 3... What did I miss ?

[tritical]

@plugh
An OVR file in conjunction with tdecimate mode 7 does not seem to work.
Yeah, overrides in mode 7 of tdecimate are not currently possible. I will add that to the readme.

I noticed some puzzling results from a script that uses cframediff.

Dug into it, and eventually distilled it down to the following which illustrates the behaviour.

prevf is set true, you get correct output (ie 'true3').
If the frameevaluate is deleted, you get correct output.

a cframediff buglet?
avisynth weirdness??
stupidity on my part???
I can confirm this happens, but am not sure 100% sure why. The code in cframediff is correct in that it calculates the difference between frames n and n+1. What I think happens is that when cframediff requests frame n+1 it increments the "current_frame" value. As a test I changed cframediff to request frame n+2 instead of n+1 and I got true5. I'm not sure how to change cframediff so this works correctly, or if it is possible to.

When I look at the debug output of, for example, tdecimate(mode=0), part of the display are some number that I assume are 'normalized framediff metrics'. I also assume that the results from cframediff should be the same as those.

They are not. With identical args (blockx, blocky, chroma, nt) I get somewhat similar, but not identical results.
Can you post the script for this. I tried it here and get identical results.

[tritical]

@dude051

My question though is does the process actually remove or insert any frames? I was under the assumption that the process worked mainly by removing frames and using the timecode file to change the frame rate of the range of frames that were removed to make it run at full speed in each cycle. I've noticed that when I have always run Decomb512VFR that the output video was always shorter, and I noticed the parts that sped up from the resulting missing frames. In my source this results in a video with 33474 frames at 18:36. Yes the process only removes frames from film sections. Video sections are left undecimated. It never inserts extra frames. The timecode file is then used to set the appropriate display length for each frame.

But when I ran TIVTC's vfr, the resulting number of frames was shorter but also 31 frames larger than the cfr 23.976 counterpart using tdecimate(mode=1,hybrid=1). Resulting in a video with 33381 frames at 23:10 (equal time). So is the vfr output sped up to true FILM 24fps? Does the vfr routine differ from the two, and that accounts for the frame difference? The only thing I can think of, since the time/frame ratio is so drastically different (18:36 more frames to 23:10 less frames), is that Decomb512VFR outputs 29.976fps material and TIVTC outputs 24fps material in their vfr routines. Unfortunately, development has ceased and none of the documentation of Decomd512VFR addresses this for me.
tdecimate sets the framerate of mode 3/5 output such that the duration of the output is the same length as the input (some gui's with bitrate calculators need this). If you actually play it at that rate without using the timecode file it will be out of sync. I am pretty sure DecombVFR just sets the frame rate to 29.970 or leaves it the same as the input.

One last thing, could it ever be possible to implement a similar thing in TIVTC where the filter in itself will run the first pass for metrics on the video and create the time codes file? Decomb512VFR is able to run the first pass somehow where ever the avisynth script has been called, so I know its possible, not that I am wining and complaining; but I'm not a programmer and this would just be a nicer feature. Thanks to MeGUI I had to dust off VirtualDub to get the first pass done with TIVTC. It is possible, but I'm not going to go the trouble of adding in a gui window that pops up. So it would simply be an option to request every frame in the constructor.

[tritical]

[link removed], changes:
FrameDiff/CFrameDiff:
+ added display modes 3/4 to framediff
+ added ability to return block position to cframediff
- fixed bug in cframediff which caused mode=0 to return the highest value instead of
the lowest when norm was set to true

TFM:
+ added relative indexing from end frame number for trimIn files
+ added ability to set trimIn to a string containing a single frame range

TDecimate:
- fixed "number of frames after decimation doesn't match" error being incorrectly
thrown in mode 2

I plan to look into the reported problems and shortcomings of tdecimate's mode 7 and mode 2 when I have some more time.

[MOmonster]

:eek:
tritical you are great!

Thanks so much for adding these features so fast. I´ll try out as soon as possible.

:thanks: for all your expertise.

[zdark]

thanks for your job tritical!!!

[tritical]

[link removed], changes:
- fixed CFrameDiff returning invalid positions when rpos=true and there
was no motion
- added elim parameter to RequestLinear

Thanks to MOmonster for the CFrameDiff bug report and RequestLinear idea.

[kilik]

hello, i have a source with 5 frame interlaced and 1 frame progressive, is NTSC source, music dvd. I thing is called combed?

In dgindex i got NTSC Interlaced.

How to filter this source? only Tivtc or tivtc + tdeint?

Thank in advance.. bye :thanks::scared:

[manono]

Neither. You use some sort of an unblender most likely, RePAL or some such. It's hard to be positive without a sample, though.

[Vesi]

Need help for using TFM with tdeint.

I analyse my source with megui's analyse and show it film partially and suggest this.

DGDecode_mpeg2source("C:\...)
ColorMatrix(hints=true,interlaced=true)
tfm(order=1).tdecimate(hybrid=1)
crop( 2, 48, -2, -50).

Most of my source are 29 fbps and i want to bring them to 23.976 fbps.

as i am new to this filter, i want to know how to get good quality for my outputs.

[manono]

Indian DVD? Got a small sample you can upload somewhere so we can have a look? I'd trust the MeGUI analysis about as far as I can throw it.

[Vesi]

sample http://maxupload.com/7670C9B1

[manono]

Hi-

The next time you upload a sample, please try and have more movement. There's not much that can be learned from a sample where 2 people are sitting and talking. Anyway, you asked via PM for a full tutorial, something I have no intention of doing. By keeping it public, others can learn as well, and others who know more about the subject than I can also add to the discussion.

It's from an Indian DVD, as I suspected. However, this one is just hard telecined, and based solely on the sample, a simple:

TFM()
TDecimate()

will work fine. The reason I said I wouldn't trust MeGUI's analysis (or any automatic analysis), especially for NTSC Indian DVDs, was because over 90% of the classic film DVDs and probably over half of modern film DVDs are field blended, and no analysis is going to pick up on that. In such cases you use the RePAL filter, Restore24, MRestore, CDeblend, or some other unblender.

One way to determine what you have is to separate the fields (SeparateFields()), or put on a bobber (Bob()), and examine the fields carefully. In this case, after seeing that DGIndex confirmed it to be NTSC and Interlaced, and making the D2V with Honor Pulldown Flags, followed by bobbing it, I saw there were 2 fields the same followed by 3 fields the same, a sure indication of an already telecined source. For field blended sources, after separating the fields or bobbing the source, an examination of the fields will show a good percentage of them being blended, or ghosted, or having double images. In such cases an IVTC such as TIVTC won't work well, and I prefer to use rePAL. But sometimes they're even worse, being field blended 23.976->29.97fps, or even double blended, and those are especially difficult to work with.

To learn more I would suggest reading at the AviSynth site, reading the documentation included with TIVTC, reading the documentation included in the DGMPGDec package, and reading the DVD2AVI tutorial, outdated as it is:

http://www.doom9.org/ivtc-tut.htm

[Vesi]

Thanks alot manono for your replay.

I will do more reading on this subject as you suggest me. and will upload a sample with more details next time.

o.Since i am dealing with xvid and new to riping dvd to xvid, what is the good way or which way you recommend to analysis my source and chose the right deinterlacing type?

[manono]

In the case of your movie, the MeGUI analysis worked fine. There may be some real interlaced stuff elsewhere - studio logo, maybe - which might be why it called it hybrid, but mostly film.

The only good analysis is done with your eyes, in my opinion, again, especially true where Indian DVDs are concerned. And the knowledge of how to interpret what you see can only come with experience. Make a basic Avisynth script, separate the fields, and open it in VDub(Mod). Then scroll to a place with movement and start advancing a frame at a time. Since this is the TIVTC and TDeint thread, one or the other can handle most types of video, but not blended fields since I don't consider just deinterlacing a field blended video an option.

I have maybe 250 Indian DVDs, and more than 200 of them have blended fields. I prefer the classics, but the situation is only marginally better with DVDs of newer films. As long as you remember that the DVDs produced by the Indian DVD production companies are the worst in the world, that whatever can go wrong will go wrong, and that working with them requires a great deal of knowledge and experience, then you'll be better prepared for what you're going to encounter.

[Vesi]

Edit:
I made this simple script with out any deinterlacing line. And put the (SeparateFields()) line at the end of script and load it in VDM, now I see the image change to half size. Nothing else

DGDecode_mpeg2source("C:\Documents and Settings\vesi\Desktop\Test\Test.d2v",cpu=4)
crop( 2, 62, -2, -62)

Spline36Resize(640,272)
(SeparateFields())

I just download the DGMPGDec package and reading the documents on it, i am trying to understand what each things means, a bit hard for me since i have never done such thing before.I am some how lost in this, and trying to learn it
manono told me to do that, but it is hard for me to get him what he relay meant.

[laserfan]

how i separate the fields? should i remove the SeparateFields line when my script is ready for rip?You need to understand what manono has already told you: you use SeparateFields in Vdub in order to step-thru your video field-by-field to see what you have, and thus what you need to do.

As he has said already too, especially the DGMPGDec package contains excellent information/guides for examining video.

[tyee]

Can I use TDeint on HD-DVD to ivtc a movie?

I'm backing up to divx and H.264 but I get jerkyness every couple of seconds when I set my encoder to 23.976 output. AFAIK all HD-DVDs are flagged for 29.97fps but are 23.976fps on the disk.

Am I heading in the right direction to solve this?

[Chainmax]

While preparing a filterchain for ripping Robot Chicken based on advice MOmonster gave me a long time ago, I came across a section that has issues with modes 3 and 5 in TFM. Here's the current filterchain:

Mpeg2source("C:\Robot Chicken\Eps\RC_S1E1.d2v")

Interp = nnedi()
Deint = TDeint(type=1,cthresh=8,mi=66,edeint=Interp,emask=TMM())
TFM(mode=6,PP=7,slow=2,ubsco=false,cthresh=8,mi=66,clip2=deint)

Here's the problem (source) frame:
http://img165.imageshack.us/img165/8099/sourcesq9.png (http://imageshack.us)

Here's mode = 3:
http://img247.imageshack.us/img247/2712/mode3oo3.png (http://imageshack.us)

Here's mode = 5:
http://img292.imageshack.us/img292/6558/mode5eb0.png (http://imageshack.us)

All the other modes handle this frame perfectly. [link removed] a short clip with the frame in question.

[tedkunich]

@tritical

Is there any special trick/dlls needed for the output feature of TFM to actually generate an output file? Playing the script in Vdub, a file is created, but it is blank/empty. I am using TFM v1.0.3


AVISource("C:\test.avi")
AssumeBFF()
converttoYUY2(interlaced=false)
tfm(,output="C:\tfm.txt")

[LigH]

1) From my experience with clip comparing functions and plugins, which are able to output files, they held the output file exclusively open until you close the script or the application. So, for example: Loading a script in VirtualDub, and running it once, gives you an open file, which gets finalised only when you close the script or exit VirtualDub.

2) It may not harm, but the comma before "output" is strange. Possibly unnecessary.

[tritical]

TFM creates the file in the constructor, but it doesn't write anything to the output file until the destructor is run so either go to "file->close video file" after you've requested all the frames or just quit vdub and it will write everything to the file.

LigH beat me to it.

@Chainmax
I tried to download the clip, but the download link on the page you linked to wont work for me.

[tedkunich]

1) From my experience with clip comparing functions and plugins, which are able to output files, they held the output file exclusively open until you close the script or the application. So, for example: Loading a script in VirtualDub, and running it once, gives you an open file, which gets finalised only when you close the script or exit VirtualDub.

2) It may not harm, but the comma before "output" is strange. Possibly unnecessary.

Thanks, that was the problem.

[Chainmax]

...
@Chainmax
I tried to download the clip, but the download link on the page you linked to wont work for me.

It doesn't for me either. Please try this link (http://rapidshare.com/files/83086326/sample.demuxed.m2v.html) instead.