View Full Version : Dup 2.0 for Avisynth 2.5
G_M_C
25th January 2007, 19:36
Hi guys, im currently working on a clip that's 59,940 fps and has a irregular pattern of duplicates. I've put Dup (show=true) in my script, and find that it correctly finds every duplicate throughout the movie (except on some very slow fades; I'll try to exclude chroma on those parts, see if it helps ).
But my question is; Since dup finds the duplicates, allmost without errors, is it somehow usable to remove the duplicates. I hope to replace a string of duplicates with exactly one blended one (effectively removing the dupes).
When i've done my math correctly i should be left with a correct 24 fps clip (mesured the old fashion way with pen and paper noting AAABCCDDEEEFGHHIJJ etc etc. No regular pattern for several complete alphabets :P)
foxyshadis
25th January 2007, 20:10
You can try DeDup, and just throw the timecodes away. You're almost guaranteed to throw off sync though, because it won't be perfectly accurate. You should probably use TDecimate with a high cycle and cycleR to compensate for the irregularity. (Or FDecimate, which is similar.) That could also lead to sync drift if you have long runs of dups, though.
Guest
25th January 2007, 20:16
FDecimate() won't cause sync drift.
G_M_C
25th January 2007, 20:51
You can try DeDup, and just throw the timecodes away. You're almost guaranteed to throw off sync though, because it won't be perfectly accurate. You should probably use TDecimate with a high cycle and cycleR to compensate for the irregularity. (Or FDecimate, which is similar.) That could also lead to sync drift if you have long runs of dups, though.
I've used both T and F Decimate with several settings. The best result i had was 1 dupe every 20 frames varying between 17 to 25 or so. I havent got a clue what's up with the source, been strugling with it for a long time now.
And speaking of sync audio; I'm at the point that I will try to sync the audio seperately through Audition or Nuendo, combined with a AC3 encoder (working roughly chapter by chapter and checking + correcting).
So i'll try DeDup first, and see if that option is working (finally).
But before i forget: Thx guys for your help and tips. Btw. the Chroma-false option seems to work very well on the slow fade :) Great dupe-detecting-plugin Neuron2 !
foxyshadis
25th January 2007, 21:41
FDecimate() won't cause sync drift.
I meant within a single cycle, if it's long enough, sorry.
Guest
25th January 2007, 21:56
Yes, I knew you meant that. :) I just wanted to make sure others knew that FDecimate() isn't cycle based.
G_M_C
26th January 2007, 09:40
DeDup seems to work out fine, better than i thought;
I finetuned the settings and from 59,94 fps i came out on 23,8fps .... allmost right. Never would have guessed that if would work out this good.
I'll retry FDecimate () tonight, maybe i did something wrong before and/or misunderstood the FAQ (reading so many FAQs in English isnt allways easy for me).
Fizick
6th March 2007, 21:20
I decide to release Dup version 2.23 with above mentioned bugfix:
first frame in the string of duplicates is included in blending too (now).
http://avisynth.org.ru/dup/dup223.zip
Please test
Guest
6th March 2007, 22:24
I decide to release Dup version 2.23 Did you ever hear from sh0dan about it?
Fizick
6th March 2007, 22:54
I sent PM to him 20 january, without answer.
Seems, he is busy with great SoundOut plugin :)
IMO, the question is: to use or not to use first frame in string for blending. I vote for "to use" and ask users to test.
plugh
13th February 2008, 17:34
a blksize argument was added to Dup, which allows 8, 16, or 32.
I'm requesting also 64.
Rationale: In my experience using tdecimate (which supports blockX and blockY args for metric blocks) with HD material, I find that 64x64 works much better than the default of 32x32. Thinking about it, this seems to make sense when you consider how much of a frame is subtended by the metric block.
Take your typical 16x9 SD frame - 640x352 - and consider the area covered by a 32x32 block. Now consider an HD frame of 1280x704, and that same 32x32 block covers one fourth less of the frame area. To get the metric block to cover the same relative section of the picture, it needs to include four times as many pixels - ie 64x64.
As is pointed out in the docs "The lesser block size, the greater sensitivity to small details change (and to noise)." My take on it is that this should be considered relative to the frame size - a 32x32 block on HD frame is analogous to using a 16x16 blocksize on SD frame.
Thanks for your consideration.
Guest
13th February 2008, 18:35
I have a lot of work on my plate right now. The source code is available. Can you please add it and send me the changes? Thanks.
Kumo
13th February 2008, 19:06
does this filter work by itself(calling it in the script),or do i need to configure the encoding settings in a certain way(variable frame rate or something like that)?
Adub
13th February 2008, 19:34
Call it in the avisynth script.
plugh
13th February 2008, 19:38
Pulled it down and took a quick look. The blocksize stuff seems to be tied to the mmx / isse code.
That would be a big learning curve for me in order to do the mod.
Am I correct that Fizick did the extension to the smaller blocksizes?
Guest
13th February 2008, 22:28
Am I correct that Fizick did the extension to the smaller blocksizes? That is correct.
Kumo
14th February 2008, 18:41
i can't understand how this filter work.if it finds 5(i.e.) equal frames(at least very very similar),it discard the firts 4 to keep just the last one.does it mean that the fps in that passage will be less than the original(i.e. less than 23,976),1 frame will last for the time 5 were suppose to last?that way,will the encoded file be variable frame rate?what kind of default/safe settings can i specify in my script to give it a try?
foxyshadis
14th February 2008, 19:08
DeDup works that way. Dup just copies the frames to make them 100% dupes.
Kumo
15th February 2008, 11:12
DeDup works that way. Dup just copies the frames to make them 100% dupes.
what's the point in making dupes?how can be the bitrate lower in that way?
Adub
15th February 2008, 12:09
The bitrate doesn't lower. It's just the same amount of bitrate.
With exactly duplicate frames, the difference between each frame is (obviously) null. So the compensation usually involved with the transition from one frame to another is not necessary.
Normally, when a new frame is drawn, it just takes all of the stuff that hasn't changed from the previous frame and adds the stuff that needs to be changed, this resulting in less info needed to store 2 frames. Think about it, you draw the first frame, then you only need to draw the stuff that is different in frame 2, and use references to the first frame for the rest.
What Dup does is make frame 2 and exact copy of frame 1, thus resulting in no change, meaning essentially storing 2 frames for the price of one.
Note: I am not 100% sure on this, but I think it's right.
Edit: Okay, I was slightly mistaken. With the averaged frames used to create a new dup frame, noise is essentially removed. No noise = lower bitrate. That is the reason for the bitrate reduction.
Kumo
15th February 2008, 13:20
now i see, thanks.should i put "dup()" at the beginning or at the end of the script?does it work better on untouched or denoised frames?
Adub
15th February 2008, 22:08
I think it would depend on both your source and your script. Post your script and either describe your sources, or post a small sample.
Kumo
16th February 2008, 10:22
the source is a japanese ntsc r2 anime dvd.here is my script
DGDecode_mpeg2source("E:\kor\VTS_01sample.d2v",info=3)
ColorMatrix(hints=true)
o = last
ox = o.width()
oy = o.height()
crop_L = 4
area_L = 32
crop_T = 4
area_T = 32
crop_R = 4
area_R = 32
crop_B = 0
area_B = 0
stackvertical(
\ stackhorizontal(
\ o.spline16resize(area_L,area_T,crop_L, crop_T,area_L-crop_L,area_T-crop_T),
\ o.spline16resize(ox-area_L-area_R,area_T, area_L,crop_T,ox-area_L-area_R,area_T-crop_T),
\ o.spline16resize(area_R,area_T,ox-area_R,crop_T,area_R-crop_R,area_T-crop_T) ),
\ stackhorizontal(
\ o.spline16resize(area_L,oy-area_T-area_B, crop_L,area_T,area_L-crop_L,oy-area_T-area_B),
\ o.crop(area_L,area_T,-area_R,-area_B),
\ o.spline16resize(area_R,oy-area_T-area_B, ox-area_R,area_T,area_R-crop_R,oy-area_T-area_B) ) )
source = last
backward_vec3 = source.MVAnalyse(isb = true, delta = 3, pel = 2, overlap=4, sharp=1, idx = 1)
backward_vec2 = source.MVAnalyse(isb = true, delta = 2, pel = 2, overlap=4, sharp=1, idx = 1)
backward_vec1 = source.MVAnalyse(isb = true, delta = 1, pel = 2, overlap=4, sharp=1, idx = 1)
forward_vec1 = source.MVAnalyse(isb = false, delta = 1, pel = 2, overlap=4, sharp=1, idx = 1)
forward_vec2 = source.MVAnalyse(isb = false, delta = 2, pel = 2, overlap=4, sharp=1, idx = 1)
forward_vec3 = source.MVAnalyse(isb = false, delta = 3, pel = 2, overlap=4, sharp=1, idx = 1)
source.MVDegrain3(backward_vec1,forward_vec1,backward_vec2,forward_vec2,backward_vec3,forward_vec3,thSAD=400,idx=1)
dfttest(sigma= 0.8)
LimitedSharpenFaster(ss_x=1.1, ss_y=1.1, smode=4, strength=150,undershoot= 10)
dup()
are others filters in the correct order?thanks
foxyshadis
16th February 2008, 23:03
That's a good place to put dup. You could put it before sharpening as well, as long as it's after deinterlacing and denoising.
Merlin, it's actually for both of the reasons you listed. ;)
Adub
17th February 2008, 00:18
I understood that, it's just that Kumo wanted to know about the reason for the lower bitrate, and bitrate specifically had to do with the noise, while overall size dealt with the duplicate frames.
And thanks.
Kumo
17th February 2008, 11:55
That's a good place to put dup. You could put it before sharpening as well, as long as it's after deinterlacing and denoising.
Merlin, it's actually for both of the reasons you listed. ;)
will it speedup the process if i put right after denoisers?i mean, will others filters be faster working on dups instead of original frames?
foxyshadis
17th February 2008, 18:02
Since the sharpeners and other random things at the end (in your other thread) are purely spatial, it won't affect speed at all.
Kumo
19th February 2008, 21:48
i'm trying to use dup in a script to encode an '80s japanese anime dvd.i get jerky video ,specially in slow zoom or vertical scrolls(calling it with default settings).how could be an ultra-safe(to avoid jerkyness) setting?would it help in lowering wasted bitrate anyway?
Adub
19th February 2008, 23:50
Your encoding to x264, correct? The fact is that x264 handles duplicate frames so well that it almost isn't worth it to use dup. The only real benefit is when it comes to denoising.
egrimisu
2nd July 2008, 22:56
Where to put DUP in this script + if i put something in wrong order tell me:
DGDecode_mpeg2source("D:\Work Hanbun no Tsuki ga Noboru Sora\Hanbun_no-Tsuki_ga_Noboru_Sora_01.DVD(MPEG2.WAV)[Misu]_Track1.d2v", cpu=0)
setmtmode(2)
dup()
setmemorymax(1024)
SmartFade(dgm=true)
source = last
backward_vec2 = source.MVAnalyse(isb = true, delta = 2, pel = 2, overlap=4, sharp=1, idx = 1)
backward_vec1 = source.MVAnalyse(isb = true, delta = 1, pel = 2, overlap=4, sharp=1, idx = 1)
forward_vec1 = source.MVAnalyse(isb = false, delta = 1, pel = 2, overlap=4, sharp=1, idx = 1)
forward_vec2 = source.MVAnalyse(isb = false, delta = 2, pel = 2, overlap=4, sharp=1, idx = 1)
source.MVDegrain2(backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=400,idx=1)
fluxsmoothST(5,5)
fft3dfilter(sigma=0.8, bt=1, bw=32, bh=32, ow=16, oh=16, plane=4, dehalo=0, ncpu=2)
ttempsmooth()
#FastLineDarkenMOD(strength=16,thinning=0)
#limitedsharpenfaster(Smode=4)
#maa()
gradfun2db(thr=1.2)
crop (4,0,-4,0)
Spline36resize(720,480)
SilentTweak
12th December 2008, 04:36
Is Dup considered fairly dangerous to use? Like I want to use Dup(Threshold=2.1), does anyone see any problems this might cause with Anime? Like maybe rape mouths? Or is that unlikely to happen? Like for example I want to use Dup to fix frames like these: http://rapidshare.com/files/172566014/DupFix.rar.html 01 is the broken frame 02 is the next frame being dupped for 01. So 01 becomes 02 when using Dup. Thing I'm worried about is if Dup causes any problems with miscalculating mouth movement at a setting of 2.0 to 3.0.
thetoof
12th December 2008, 17:30
High threshold is more likely to introduce losses in motion fluidity (jerks (especially slow pans and zooms), small movements will disappear (mouth movement...), etc...)
There was an attempt at creating a motion adaptative dup function some time ago:
# Dupped() by Corran
#
# This filter requires a YUV source. Use converttoyv12 if needed
# before calling dupped()
#
# thresh = Used to determine when to delare a frame as new
# Use stats=true to help determine the best value for your source
# Lower number = more sensitive. (Default=16)
# panthresh=1.7 This is used to determine when to consider a frame
# part of a low motion scene. (Default=1.65)
# stats = Enable/disable display of stats. (Default=false | Not shown)
# (Last = last frame, this = this frame, next = next frame)
# showme = Enable/disable display of video that most stats are
# derived from. (Default=false | Not shown)
#
# Do not use with SetMTMode(). This function requires the frames to be
# accessed sequentially. Instead, use MT() to mulit-thread on a per-filter basis.
#
# Example:
# dupped(thresh=20,panthresh=1.7,stats=true,showme=true)
function dupped(clip clip, int "thresh", float "panthresh", bool "stats", bool "showme")
{
global a = default(clip, last)
global thresh = default(thresh, 16)
global panthresh = default(panthresh, 1.65)
global stats = default(stats, False)
showme = default(showme, False)
function replaceframe(clip clip, int oldframe, int newframe)
{
a = default(clip, last)
trim(a,0,oldframe-1)++Trim(a,newframe,newframe)++trim(a,oldframe+1,Framecount(a))
}
b = a #for later use with showme conditional (it isn't passed to scriptclip)
global newframe = a
a = scriptclip(a,"""
b = a.duplicateframe(1)
d = a.deleteframe(1)
c = subtract(a,b)
YMinMax = YPlaneMinMaxDifference(c)
YAbvMed = YPlaneMax(c)-YPlaneMedian(c)
YBelMed = YPlaneMedian(c)-YPlaneMin(c)
YAbvBelMedDiff = Abs(YAbvMed - YBelMed)
new = (YMinMax>=thresh || YAbvBelMedDiff>=10)
YMinMax2 = !new ? YPlaneMinMaxDifference(subtract(a,d)) : 255
YMinMax3 = (YMinMax2<=thresh ) ? YPlaneMinMaxDifference(subtract(b,d)) : 255
pan = (YMinMax3 != 255 && YMinMax3!=0 && YMinMax3>=(YMinMax+YMinMax2)/2*panthresh)
stats ? subtitle(a,"YMinMax(last,this) = "+string(YMinMax)).\
subtitle("YAbvBelMedDiff(last,this) = "+string(YAbvBelMedDiff),y=54) \
: a
newframe = (current_frame<=1 || current_frame>=Framecount()-1) ? current_frame : newframe
stats ? !new ? subtitle("YMinMax(this,next) = "+string(YMinMax2),y=18) : subtitle("YMinMax(this,next) = Null",y=18) : last
stats ? (YMinMax3!=255) ? subtitle("YMinMax(last,next) = "+string(YMinMax3)+"|"+string(ceil((YMinMax+YMinMax2)/2*panthresh)),y=36) : subtitle("YMinMax(last,next) = Null",y=36) : last
newframe = (new || pan) ? current_frame : newframe
stats ? subtitle("Last New Frame = "+string(newframe),y=90) : last
(stats && pan) ? subtitle("(Slow pan/zoom or action detected)",y=108) : last
(current_frame != newFrame) ? replaceframe(current_frame,newFrame) : last
return last
""")
a = showme ? stackvertical(a,subtract(b,b.duplicateframe(1))) \
: a
return a
}
Have fun testing! Dupped(settings)
wyti
12th December 2008, 19:01
or if you want to not taking risk, use a low blksize (8 if possible)
so small movements are detected pretty well (a mouth move does about 4% IIRC)
so you don't have any problem with the treshold = 3.0 and don't kill small movements
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.