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. |
27th May 2007, 01:19 | #1061 | Link |
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. |
28th May 2007, 18:58 | #1062 | Link | |
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:
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. |
|
2nd June 2007, 01:49 | #1063 | Link |
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 |
6th June 2007, 07:56 | #1064 | Link | |
Registered User
Join Date: Jan 2004
Location: Here, there and everywhere
Posts: 1,197
|
Quote:
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 |
|
6th June 2007, 10:15 | #1065 | Link | |
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:
Code:
006 202 004 200 004 199 004 o 003 200 005 204 005 198 003 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. |
|
6th June 2007, 13:30 | #1066 | Link | |
Registered User
Join Date: Jan 2004
Location: Here, there and everywhere
Posts: 1,197
|
Quote:
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'. |
|
6th June 2007, 14:30 | #1067 | Link | |||
A hollow voice says
Join Date: Sep 2006
Posts: 269
|
Quote:
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:
Quote:
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 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 |
|||
6th June 2007, 16:32 | #1069 | Link |
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 |
6th June 2007, 17:55 | #1070 | Link | ||
A hollow voice says
Join Date: Sep 2006
Posts: 269
|
Quote:
... 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:
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 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. |
||
6th June 2007, 22:33 | #1071 | Link |
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) 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!!! |
7th June 2007, 16:34 | #1072 | Link | ||||
A hollow voice says
Join Date: Sep 2006
Posts: 269
|
Quote:
Quote:
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... |
||||
8th June 2007, 17:14 | #1073 | Link | ||
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"\ ) Code:
false0 false1 false2 true4 false4 false5 false6 false7 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:
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:
Last edited by plugh; 8th June 2007 at 18:28. |
||
10th June 2007, 08:40 | #1074 | Link |
dead
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... |
10th June 2007, 15:56 | #1075 | Link |
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) |
22nd July 2007, 16:29 | #1077 | Link |
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 ? |
28th September 2007, 05:53 | #1078 | Link | |||
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
@plugh
Quote:
Quote:
Quote:
|
|||
28th September 2007, 06:06 | #1079 | Link | |||
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
@dude051
Quote:
Quote:
Quote:
|
|||
28th September 2007, 07:50 | #1080 | Link |
Registered User
Join Date: Dec 2003
Location: MO, US
Posts: 999
|
[link removed], changes:
Code:
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 Last edited by tritical; 22nd November 2007 at 06:22. |
Tags |
tdeint, tivtc |
Thread Tools | Search this Thread |
Display Modes | |
|
|