how to do conditional frame dropping ?

[juhu]

is there a way with avisynth to do the following :

(after some decimation with tdecimate) If I still have 6 consecutive frame numbers kept, then drop the 3rd...

ie if my decimated sequence keeps the following frames : 100-102-103-104-106-107-109-110-112-113-114-115-116-117-119
then drop frame 115 (the 3rd frame in the 6 consecutive frames (112-117) sequence)

short example, but my source is 175000 frames long, so I'll try to avoid doing manually an override file that would take me ...way too much time :cool:

[stickboy]

I'm pretty sure you can't (unless tdecimate provides such functionality), because there's no way to know that you have "six consecutive frames kept". For a given frame in the output clip, you can't determine what its frame number was in the original clip.

[juhu]

I'm pretty sure you can't (unless tdecimate provides such functionality), because there's no way to know that you have "six consecutive frames kept". For a given frame in the output clip, you can't determine what its frame number was in the original clip.

Are you sure ? because a simple "display=true" in tdecimate parameters displays BOTH "inframes" (after decimation) and "useframes" (original frame number)
that's how I targeted the remaining dupes and saw there were 6 consecutive frames in that case and that's why I think if tdecimate is able to use & display this original framenumber, there must be an accessible variable in avisynth somewhere storing this info...

[leiming2006]

If I were you, I will probably try to write some codes to produce a file like dedup's first-pass log then use dedup in avisynth to load it.

[juhu]

If I were you, I will probably try to write some codes to produce a file like dedup's first-pass log then use dedup in avisynth to load it.

interesting suggestion (I never used dedup before)
...but that raises many other questions :

1)
. first pass with dupMC went ok, I have my log file
. 2nd pass keeps telling me "dedup first pass missed : frame 0"

dupMC(log="e:\test.txt") # for 1st pass
DeDup(threshold=0.3,maxdrops=2, log="e:\test.txt", times="timecode.txt") # for 2nd pass

can't I use dedup on a trimmed section ??
here are the first log lines from 1st pass :
"DeDup 0.17 by Loren Merritt, based on Dup 2.20 beta 1 by Donald Graft/Klaus Post, Copyright 2004
frm 123145: diff from frm 123146 = 1.2608% at (576,128)
frm 123146: diff from frm 123147 = 1.6685% at (576,128)
frm 123147: diff from frm 123148 = 1.4889% at (448,352)
frm 123148: diff from frm 123149 = 1.3938% at (544,128)
frm 123149: diff from frm 123150 = 4.3168% at (384,128)
frm 123150: diff from frm 123151 = 4.9011% at (384,128)
frm 123151: diff from frm 123152 = 20.2685% at (288,512)
"

2)
Also , based on log, I can see almost all intertitles frames will be considered dupes. meaning I would have to process separately/override hundreds of sections in the film :eek:

[leiming2006]

I mean, don't use dedup to do the analysis pass, write a program to produce the log, so you can try to use your program to output a file like this:
frm 115: diff from frm 114 = 0% at (1,1)
......
then dedup will delete the 115th and ...... frame.
try to make this log by program instead of manually doing this.

[juhu]

programming :confused:
sorry to be probably dumb, but this is completely out of range for me, I'm just using avisynth functions, I'm no coder...

anyway, last chance with dedup :
I have this kind of output that seems usable :

frm 0: diff from frm 1 = 22.7344% at (224,352)
frm 1: diff from frm 2 = 27.8221% at (192,384)
frm 2: diff from frm 3 = 2.9796% at (512,160)
frm 3: diff from frm 4 = 32.1863% at (192,224)
frm 4: diff from frm 5 = 24.7793% at (192,256)
frm 5: diff from frm 6 = 22.2378% at (384,416)
frm 6: diff from frm 7 = 2.5736% at (448,544)
frm 7: diff from frm 8 = 21.1569% at (288,320)
frm 8: diff from frm 9 = 24.5483% at (288,480)
frm 9: diff from frm 10 = 26.8866% at (288,480)
frm 10: diff from frm 11 = 2.3978% at (480,0)
frm 11: diff from frm 12 = 25.6109% at (224,288)
frm 12: diff from frm 13 = 23.3390% at (256,480)
frm 13: diff from frm 14 = 2.5981% at (640,96)
frm 14: diff from frm 15 = 28.6968% at (256,416)
frm 15: diff from frm 16 = 24.4003% at (288,480)
frm 16: diff from frm 17 = 25.8876% at (192,416)
frm 17: diff from frm 18 = 2.8449% at (416,0)
frm 18: diff from frm 19 = 31.8600% at (320,448)
frm 19: diff from frm 20 = 28.1653% at (320,480)
frm 20: diff from frm 21 = 2.8162% at (480,160)
frm 21: diff from frm 22 = 17.2386% at (352,480)
frm 22: diff from frm 23 = 19.7037% at (320,384)
frm 23: diff from frm 24 = 22.5000% at (320,384)
frm 24: diff from frm 25 = 2.9800% at (416,0)
frm 25: diff from frm 26 = 21.0277% at (224,352)
frm 26: diff from frm 27 = 22.0591% at (320,448)
frm 27: diff from frm 28 = 3.1998% at (448,128)
frm 28: diff from frm 29 = 19.8949% at (224,384)
frm 29: diff from frm 30 = 27.0857% at (288,480)
frm 30: diff from frm 31 = 22.9717% at (288,480)
frm 31: diff from frm 32 = 2.4443% at (416,0)


there's clearly a dupe every 2 or 3 frames here (around 2-3% diff)
I set maxcopies & maxdrops to 2 as there's only one dupe at a time

what is the threshold value / other parameters to get rid of these frames with this log ? I tried threshold=0.04 (4 % ?) / threshold=4, in one case , nothing is dropped and in the other, random frames (ie not especially dupes) are dropped . I don't get it at all...

and remember : :stupid:

[stickboy]

Are you sure ? because a simple "display=true" in tdecimate parameters displays BOTH "inframes" (after decimation) and "useframes" (original frame number)
that's how I targeted the remaining dupes and saw there were 6 consecutive frames in that case and that's why I think if tdecimate is able to use & display this original framenumber, there must be an accessible variable in avisynth somewhere storing this info...Of course tdecimate knows how to map the frame numbers from the original clip to the clip it outputs, but another filter won't be able to know which frames tdecimate dropped.

[foxyshadis]

can't I use dedup on a trimmed section ?? No, start to end only. To do this, put the trims before dedup. However, dedup won't affect the timings at all, when properly muxed, so there will still be jerkiness (or desync when improperly muxed).

A Tdecimate override file will probably be much simpler, however. Basically, you have two options: Play with tdecimate's thresholds and possibly the cycles until you find values that work without cutting good frames, or dig in and start doing it manually.