Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 26th May 2007, 20:21   #1061  |  Link
ChiDragon
Registered User
 
ChiDragon's Avatar
 
Join Date: Sep 2005
Location: Vancouver
Posts: 609
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.
ChiDragon is offline   Reply With Quote
Old 27th May 2007, 01:19   #1062  |  Link
plugh
A hollow voice says
 
Join Date: Sep 2006
Posts: 269
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 is offline   Reply With Quote
Old 28th May 2007, 18:58   #1063  |  Link
plugh
A hollow voice says
 
Join Date: Sep 2006
Posts: 269
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 frames
Quote:
sep=" "
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)
Code:
 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

Last edited by plugh; 28th May 2007 at 23:36.
plugh is offline   Reply With Quote
Old 2nd June 2007, 01:49   #1064  |  Link
plugh
A hollow voice says
 
Join Date: Sep 2006
Posts: 269
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
plugh is offline   Reply With Quote
Old 6th June 2007, 07:56   #1065  |  Link
WorBry
Registered User
 
Join Date: Jan 2004
Location: Here, there and everywhere
Posts: 1,182
Quote:
Originally Posted by tritical View Post
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 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.ph...73#post1010873
WorBry is offline   Reply With Quote
Old 6th June 2007, 10:15   #1066  |  Link
tritical
Registered User
 
Join Date: Dec 2003
Location: MO, US
Posts: 999
@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
Quote:
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:
Code:
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 .

Last edited by tritical; 6th June 2007 at 15:51.
tritical is offline   Reply With Quote
Old 6th June 2007, 13:30   #1067  |  Link
WorBry
Registered User
 
Join Date: Jan 2004
Location: Here, there and everywhere
Posts: 1,182
Quote:
Originally Posted by tritical View Post
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 .
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...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'.
WorBry is offline   Reply With Quote
Old 6th June 2007, 14:30   #1068  |  Link
plugh
A hollow voice says
 
Join Date: Sep 2006
Posts: 269
Quote:
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
Quote:
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
Quote:
TDecimate: mode 2 error, number of frames after decimation doesn't match!
Specifically - the dup counts are
Code:
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

Thanks in advance
Attached Images
  
plugh is offline   Reply With Quote
Old 6th June 2007, 15:56   #1069  |  Link
tritical
Registered User
 
Join Date: Dec 2003
Location: MO, US
Posts: 999
@plugh
Could you post the metrics file? Or just send it to my ftp:

12.216.251.99:17262
upload/upload
tritical is offline   Reply With Quote
Old 6th June 2007, 16:32   #1070  |  Link
tritical
Registered User
 
Join Date: Dec 2003
Location: MO, US
Posts: 999
@WorBry
Here are my results on the clip you posted:

yadif_test.zip

The four clips included are:
Code:
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
tritical is offline   Reply With Quote
Old 6th June 2007, 17:55   #1071  |  Link
plugh
A hollow voice says
 
Join Date: Sep 2006
Posts: 269
Quote:
Originally Posted by tritical View Post
@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
Quote:
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
Code:
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...

Last edited by plugh; 8th June 2007 at 22:30.
plugh is offline   Reply With Quote
Old 6th June 2007, 22:33   #1072  |  Link
plugh
A hollow voice says
 
Join Date: Sep 2006
Posts: 269
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
Code:
   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 is offline   Reply With Quote
Old 7th June 2007, 16:34   #1073  |  Link
plugh
A hollow voice says
 
Join Date: Sep 2006
Posts: 269
Quote:
Originally Posted by plugh View Post
576 film frames into 1409 video frames, which works out to 59.94*(576/1409) = 24.503506032, which yeilds
Quote:
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
Quote:
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 yeilds
Quote:
drop 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 is offline   Reply With Quote
Old 8th June 2007, 17:14   #1074  |  Link
plugh
A hollow voice says
 
Join Date: Sep 2006
Posts: 269
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.

Code:
Version().converttoyuy2()

frameevaluate("NOP()")

Writefile("avstst1.txt"\
,	"((current_frame==3) && (cframediff(prevf=false) >= 0))"\
,	"current_frame"\
)
This generates the following output:
Code:
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:
Quote:
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)
Quote:
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

Last edited by plugh; 8th June 2007 at 18:28.
plugh is offline   Reply With Quote
Old 10th June 2007, 08:40   #1075  |  Link
dude051
dead
 
dude051's Avatar
 
Join Date: Jun 2003
Location: who knows
Posts: 47
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.
__________________
If we all believed in an "Eye For an Eye", we would all be Blind...
dude051 is offline   Reply With Quote
Old 10th June 2007, 15:56   #1076  |  Link
plugh
A hollow voice says
 
Join Date: Sep 2006
Posts: 269
An OVR file in conjunction with tdecimate mode 7 does not seem to work.

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

debug output
Code:
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.
plugh is offline   Reply With Quote
Old 10th June 2007, 16:03   #1077  |  Link
Terranigma
*Space Reserved*
 
Terranigma's Avatar
 
Join Date: May 2006
Posts: 953
Quote:
Originally Posted by plugh View Post
As you can see, it chose to use 6803 in spite of the ovr file.
Maybe to retain synchronization?
Terranigma is offline   Reply With Quote
Old 22nd July 2007, 16:29   #1078  |  Link
juhu
Registered User
 
Join Date: Aug 2003
Posts: 37
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 ?
juhu is offline   Reply With Quote
Old 28th September 2007, 05:53   #1079  |  Link
tritical
Registered User
 
Join Date: Dec 2003
Location: MO, US
Posts: 999
@plugh
Quote:
Originally Posted by 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.

Quote:
Originally Posted by 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.

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.

Quote:
Originally Posted by plugh
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 is offline   Reply With Quote
Old 28th September 2007, 06:06   #1080  |  Link
tritical
Registered User
 
Join Date: Dec 2003
Location: MO, US
Posts: 999
@dude051

Quote:
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.

Quote:
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.

Quote:
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 is offline   Reply With Quote
Reply

Tags
tdeint, tivtc

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 15:43.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.