View Full Version : Dup 2.0 for Avisynth 2.5
sh0dan
13th January 2003, 23:37
@neuron: If you're interested, I've written a very fast ISSE routine that returns the largest accumulated sum of differences of a 32x32 pixel area on the entire image.
It processes 16 pixels in parallel, with less than 1 cycle per pixel, so it's probably maxed out at memory speed. It'll be committed to avisynth now, but it's not activated, because I'd like to reference test it, so it would be great if you could help there.
It might actually not be useful for what I'm doing, but it's just an experiment.
cvs sourceforge link (http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/avisynth2/avisynth/focus.cpp?rev=1.3.2.8&content-type=text/vnd.viewcvs-markup) see int TemporalSoften::isse_scenechange(const BYTE* c_plane, const BYTE* tplane, int height, int width, int pitch)
Guest
14th January 2003, 00:58
@sh0dan
Thank you for the offer and link. I need the function to return the x and y coordinates of the block so that I can display the little box when show=true. Any chance of that?
sh0dan
14th January 2003, 08:49
Not entirely impossible - I can send you an offset x + (y*width/32) that should be enough. Pure luck I still have an mmx register, but I may need two to avoid memory reads, or stalls.
edit: cr*p I didn't have an mmx-register - not even a general purpose register. Couldn't you use the C-code, when show is true? I assume the C-code does exatly the same, so if you test the results, and see if they are the same, it would be pretty safe to use it.
It could added to the code, but in real life there isn't anything time-critical, when show=true (ie. it's not an encode).
Edit2: Wouldn't it make more sense, for it to be used as scene-change detector to add all the differences together and simply threshold-test this value.
Edit 3: Just saw, that the code assumes that the pitch of both images is the same - not a good thing. I'll correct it.
Guest
15th January 2003, 18:18
Couldn't you use the C-code, when show is true? I assume the C-code does exatly the same, so if you test the results, and see if they are the same, it would be pretty safe to use it.
It could added to the code, but in real life there isn't anything time-critical, when show=true (ie. it's not an encode).
Yes. That would be acceptable.
Wouldn't it make more sense, for it to be used as scene-change detector to add all the differences together and simply threshold-test this value.Yes, of course. That application is very different from a duplicate detector.
Just saw, that the code assumes that the pitch of both images is the same - not a good thing. I'll correct it.If you fix that I can give it a try.
Thank you.
esby
24th January 2003, 14:16
Good thing,
both protagonists are here ^^ (see below...)
This code giving me avisynth error...
It seems linked to cnr2() and dup() [edit : Cnr2 and not Dnr2, sorry for the typo ]
I put the whole script cause it could come from other plugins used...
source = avisource("...").killaudio()
source = source.SwapUV()
#used to correct somes frames before decomb fails on them...
#note : frames 36 and 37 are KF but frame 36 is just baaaaad (mixing of 35 & 37)
dest = source
dest = dest.freezeFrame(36,37,37)
#(...) some freezeframes too
dest = dest.freezeFrame(36249,36250,36250)
source = dest
#ivcting cause raw is 29.76 fps (anime)
Source = source.Telecide(chroma=true,dthreshold=13)
source = source.Decimate(cycle=5,show=false,mode=2)
#cropping evil baaaaad bar & resizing
source = source.crop(0,2,628,478)
source = source.BiLinearResize(640,480)
#one of the two plugin alone works
#but both together just won't work
source = source.Cnr2("xxx",6,7,255)
source = source.dup()
#just to check the 1000 first frames in nandub ( or vdub)
return source.trim(0,1000)
When i put
dup() before cnr2()
or cnr2() before dup()
...I m getting an "avisynth read error : AviSynth caught an access violation at 0x01651c17, attempting to write frame 0x00000000..."
Any idea why, or how to avoid it, (I tried moving it before ivtc etc.,
but i haven't found a way to do not crash avisynth actually.)
of course i can do cnr in vdub... But that just mean that cnr2 avs is useless for me in this case ;)
Versions I am using:
AViSynth: 2.50 beta 22 jan. 2003
Decomb: Version 4.06
Dup: 2.00 ( took from the realm of Mordor ;) )
Cnr2: Chroma Noise Reducer for AviSynth (v2.4)
esby
Guest
26th January 2003, 15:48
@esby
You say dnr2() in one place and cnr2() in another. I assume you mean cnr2().
I put Dup() first in the script followed by a debug build of Cnr2(). It crashes in Cnr2():
PVideoFrame __stdcall Cnr2::GetFrame(int n, IScriptEnvironment* env)
{
if (n<1) return child->GetFrame(n, env);
PVideoFrame src = child->GetFrame(n, env);
if (lastn+1!=n || !pre) {
pre = child->GetFrame(n-1, env); // CRASHES HERE !!!
env->MakeWritable(&pre);
}
const uc *srcp = src->GetReadPtr();
uc *prep = pre->GetWritePtr();
...It crashes in the Avisynth core on the marked GetFrame() call when stepping from frame 0 to frame 1. I verified that n-1 is 0 at this call.
So it appears to be a bug in the Avisynth core, maybe the cache. We need to get sh0dan involved. I will PM him to draw his attention to this thread.
sh0dan
26th January 2003, 20:13
Couldn't it just be CNR2 crashing?
It has been known to do that.
(but I'll look at it ASAP)
esby
26th January 2003, 20:31
It's possible,
But as far i remember cnr2 alone or dup2 alone worked for the first frame processed.
And both crashed together.
I think i ended removing both, not satisfacted of the final result.
(prolly cause dup blending mode not really good with some 'decombed' frames)
esby
Guest
26th January 2003, 20:56
@sh0dan
I traced through Cnr's code and it crashes on the simple GetFrame() call for frame 0. I don't know how you can blame Cnr2. But by all means if you can think of a mechanism let me know and I'll look some more at it. Thank you.
sh0dan
27th January 2003, 17:21
@neuron: Sorry - I thought you were listing the Dup-code (thus the crash would be in CNR2's GetFrame). I'll do a testsetup, and hopefully find it.
flipdon
27th January 2003, 18:28
i'd like to bring my http://forum.doom9.org/showthread.php?s=&threadid=44202 (recent post) over here since it seems it could be a similar problem.
I get a problem when i have Dup() before Convolution3D. VirtualDub tells me i have an Avisynth read error when i try to move the slider. I don't get the problem when Dup is put after C3D, but wouldn't dup after C3D be bad, since there is smoothing. Is there something im missing here? I read a thread on the exact opposite of my problem, where they had errors when dup was after a smoothing filter like C3D ( http://forum.doom9.org/showthread.php?s=&threadid=37996 ).
LoadPlugin("F:\Avisynth\MPEG2Dec3_094.dll")
LoadPlugin("F:\Avisynth\Decomb.dll")
LoadPlugin("F:\Avisynth\Convolution3DYV12.dll")
LoadPlugin("F:\Avisynth\Dup.dll")
mpeg2source("G:\Flame of Recca\Recca3.d2v")
telecide()
decimate(15)
FieldDeinterlace()
Dup()
Convolution3D(1, 12, 22, 8, 8, 2.8, 0)
LanczosResize(640,480)
and if there's any suggestions to make about my script, please feel free to tell me (ex. deinterlacing, C3D or Dup settings). I've read i need to experiment alot with dup to get good results, but im not really sure which settings i should be playing around with yet.
sh0dan
27th January 2003, 23:00
When using a debug build of CNR2, dup and AviSynth, it always crashes at:
for (y = 0; y < pre->GetHeight(); y++)
memcpy(pre->GetWritePtr()+pre->GetPitch()*y,
src->GetReadPtr()+src->GetPitch()*y,
pre->GetRowSize());
I replaced it with
env->BitBlt(pre->GetWritePtr(PLANAR_Y),pre->GetPitch(PLANAR_Y),
src->GetReadPtr(PLANAR_Y),src->GetPitch(PLANAR_Y),
src->GetRowSize(PLANAR_Y),src->GetHeight(PLANAR_Y));
But it still crashes. Marc doesn't make the "pre" frame writable each time he tries to write to it, thus a null pointer is returned when he requests a writepointer.
He also tries to deallocate the frame, when his filter it destroyed, which it shouldn't (it is already being automatically destroyed). Therefore some people will recieve access violations on unload.
Basicly I'd advice a rewrite of the filter - it may have a good algorithm, but it's badly implemented, and will cause a lot of random crashes and other issues. BTW, the source and binary doesn't match.
I'll also check out the C3D issue in the other thread.
Guest
28th January 2003, 01:03
@sh0dan
Now you're really confusing me!
The pre frame is always made writable right after getting it. See the code I posted above. Are you saying that has to be repeated every time a write pointer is fetched on pre?
Also, I have it crashing on the pre GetFrame() call. Is that not happening for you?
sh0dan, please, we need to get to the bottom of this. I'd hate to have to shelve 2.5 work and withdraw my filters. But I can't have stuff crashing all over the place. All indications are that the cache has a problem. I see other combinations of filters failing in a similar way. And the MakeWritable thing is certainly distressing.
sh0dan
28th January 2003, 11:10
Where you get the crash depends on what frame is the first requested.
I can only reproduce the crash, in cases where the frame isn't requested and made writable (in case the if is false). The filter requests a writepointer to pre later, even though it has not been made writable.
Moving the makewritable out of the if-loop partially solves the problem, but it is still a problem that the filter tries to store the frame across GetFrame calls, which isn't allowed (the frame gets recycled).
Guest
28th January 2003, 15:15
The if test has the clause || !pre so it must have been run once and the pre is stored in what should be the lifetime of the filter.
Anyway, as I have said I think 3 times now, it is failing on the on the very first GetFrame call in the if clause. It worries me that you don't seem to care to try to understand that because this behavior makes 2.5 unusable.
Am I misunderstanding things or are you trying to frustrate me? :)
EDIT: Now, thinking about what you said... We can't put a PVideoFrame in our filter class data and have it remain stable throughout? It gets recycled?! Why? There should be an enduring reference to it. Please explain this in detail as I will have to redesign Dup and possibly others. Thank you for your patience.
sh0dan
28th January 2003, 16:21
(Check PM)
Frames need to be recycled, because that's how AviSynth controls the memory usage. It has always done so, so there is nothing new there. AviSynth 3.0 could very well change that, but that's far in the future.
WarpEnterprises
22nd April 2003, 15:54
Would it make sense to
1) make a calculate-only version of Dup
2) with an output that can be used in the ConditionalFilters
3) and - most important - that can take TWO clips as source
My goal would be to detect blended fields in some circumstances.
E.g. if you have
a - ab - b
then Dup detects motion between (1) a->ab and (2) ab->b.
If I would now compare ab to a merge of a and b there should be much less motion than (1) and (2) which can only be the case if it's a blend.
Bidoche
22nd April 2003, 16:39
@sh0dan
Are you saying that even VideoFrame copies you keep for yourself and never return to GetFrame can be altered ? I always thought those were safe. :/
AviSynth 3.0 could very well change that, but that's far in the future. 3.0 is not that far, the core is almost complete.
We can have a first version without the parser and the COM interfaces in a few weeks.
Since i can not found another thread about Dup therefore i will carry on with this one.
It seems version 2.2 is already in beta. May i ask what change is there apart from low level optimize??
I like this filter very much as it is a great help for anime encoding. However i don't understand why MarcFD say it is useless... was it a joke?? ( If it is then i don't get it.:confused: )
Guest
28th May 2003, 19:44
Originally posted by iwod
Since i can not found another thread about Dup therefore i will carry on with this one.
It seems version 2.2 is already in beta. May i ask what change is there apart from low level optimize??
I like this filter very much as it is a great help for anime encoding. However i don't understand why MarcFD say it is useless... was it a joke?? ( If it is then i don't get it.:confused: ) Dup 2.2 beta 1 has been around for a long time. It added low-level optimizations and fixed a problem with frame blending (not all the frames had equal weighting).
toraneko
7th June 2003, 09:13
@neuron2
first, thanks for this great filter
I'm dealing with an anime which has LONG period of non changing frames (sometimes several MINUTES)
could you please remove the limitation of 20 consecutive frames ?
Guest
7th June 2003, 11:19
Sorry, no.
EDIT: Two minutes would require me to fetch 2*60*30 = 3600 frames from Avisynth at a time. It's simply not practical. It could be done with a two-pass algorithm, but how may real-world clips have minutes-long duplicate runs? And even if they do, it's much more reasonable just to use Avisynth's FreezeFrame(), isn't it?
will 2.2 get out of beta? And there any more features planned to be added to Dup? I know you are hardworking on Decomb, so there is no rush. ( Thx for your Decomb and it IS GREAT :D )
Guest
8th June 2003, 14:13
I am always amused by people taking that "beta" word so seriously. If I simply rereleased the same code without the beta, you'd be happier?
Yes, I suppose I should go back and remove the beta moniker from all my stable filters. But until I do, you can rest assured that Dup is of release quality.
I don't plan any new features. What did you have in mind?
iwod
15th June 2003, 12:11
Hi, i have a new feature idea that i don't know if it is possible to implement.
It is poosible for dup to drop a frame instead of copy a frame if they are the same?
sh0dan
15th June 2003, 13:48
Why? You'll only desync your movies (as they must have constant framerate). Use decimate from the decomb package, which removes one of every x frames, based on several ways of finding the closest match.
iwod
15th June 2003, 16:02
Originally posted by sh0dan
Why? You'll only desync your movies (as they must have constant framerate). Use decimate from the decomb package, which removes one of every x frames, based on several ways of finding the closest match.
Well......... on the New A/V forum, it has come up with using AVIsynth with RV9, which support variable framerate.
So i intend to try what will RV9 react to that.......
sh0dan
15th June 2003, 16:47
AviSynth doesn't support variable framerate.
iwod
15th June 2003, 17:53
sorry for my poor english....... ( why is my english so poor even i live in brit?? )
I meant RV9 support Varible frame rate..........
I might have to rethink all these idea......
scmccarthy
15th June 2003, 20:06
I think AviSynth would need to tell RV9 what frame rate to use and it does that only once at the beginning, because AviSynth does not support variable frame rates.
Stephen
scmccarthy
15th June 2003, 20:23
After more thought, I realized that the point of DUP is to make it easier for the codec to compress the video, but it is up to the codec to decide whether it can drop a frame. Avisynth frame serves the uncompressed frames to the codec. When you open an AviSynth script in VirtualDub, it reports that every frame is a key frame, and that is true until the video gets compressed. So if you compress your video using a variable frame rate, it probably will drop the duplicate frames. It depends on the codec, not AviSynth.
Stephen
MightyKnife
17th August 2005, 22:12
Hello,
ok, now i'm playing gravedigger a little bit, as i'm just playing with the DUP filter. Some small ideas from me, if someone is still interested to maintain this filter.
1.) On one hand i'm missing a little bit a possibility in the debug-mode (show=true) to find the 32x32-block that's responsible for the highest percentage value.
2.) Is it possible to include a "guiding clip" that replaces the main clip in searching for differences in frames? Ok, to explain this: By deinterlacing anime-material captured from TV, one point that misleads the filter is the noise in the near of sharp lines. On the other hand, by simply resizing the video to half the size in height/width, this noise is much less present.
So why not use something like
DUP (mainclip, guidingclip)
with guidingclip being an arbitrary clip with the same length as mainclip, e.g. a resized, noise-reduced version of it. DUP analyzes the guiding clip for when to drop frames and then drops these frames from the main-clip.
Guest
17th August 2005, 22:39
The source code is available. Go for it!
MightyKnife
18th August 2005, 11:27
I know...
If i'm able to do that, i would do it ^^
But writing filters is still a little bit above my skills...
Was only a small idea...
Guest
18th August 2005, 13:31
@MightyKnife
Thanks for the ideas. I'll note them for future reference if I ever continue any development on Dup.
And I forgot to say...Welcome to the forum!
JnZ
3rd October 2005, 00:00
Hi, guys.
I'm litlle newbie with avisynth programming. I know basic scripts,but now, I have serious problem and can't solve it.
I have video (29.97fps,progressive) with some repeating frames (maybe bad IVTC). Video is very choppy. When I use Decimate(), some duplicite frames stays, and some non duplicite frames are cut off.
Following frames are same. I need to remove each one of them, to obtain video with non-repeating frames.
Frames: 1=2,8=9,13=14,20=21,25=26,30=31,32=33,37=38,42=43,49=50.......
I think that would be possible use DUP, but this is only detector, but I don't know, how to join DUP with some cutting function.
Any ideas. :thanks:
foxyshadis
3rd October 2005, 00:56
No, this is definitely not a dup-solvable problem. You need something like FDecimate (http://neuron2.net/fdecimate/fdecimate.html), which is much smarter than pure decimate, and you need to figure out what the real fps is by counting dups and dividing by your current fps.
If this only happens on some parts of the video, or if the actual frame rate varies significantly over the course of the video, you're out of luck (audio will desync if you use different decimations) and you just have to do what you can. Older films, especially silent ones, are often like that.
If these are capture-dropped frames, it might look worse to just cut them out, and the only way to restore smoothness would be to motion-estimate the duplicate frame between the two real frames.
AI
3rd October 2005, 04:23
JnZ
for "1=2,8=9,13=14..."
i.e duplicate frame every 7 frames
SelectEvery(7,0,1,3,4,5,6) (or SelectEvery(7,0,2,3,4,5,6))
But if 0=1,7=8.... (because first frame is "0")
then SelectEvery(7,0,2,3,4,5,6) or (SelectEvery(7,1,2,3,4,5,6))
---------------------
Add Later
if dup frames is not regularly
try GetDups by Fizick
if GetDups misunderstand lengh of dups frames =1 possible work:
Interleave (Last,Last,Last).GetDups(mode=0)
foxyshadis
3rd October 2005, 08:08
JnZ
for "1=2,8=9,13=14..."
i.e duplicate frame every 7 frames
SelectEvery(7,0,1,3,4,5,6) (or SelectEvery(7,0,2,3,4,5,6))
But if 0=1,7=8.... (because first frame is "0")
then SelectEvery(7,0,2,3,4,5,6) or (SelectEvery(7,1,2,3,4,5,6))
I was going to suggest something similar, but I noticed that some of the duplicates were 5 frames away (even one 2!), which is why I suspect it's a weird framerate conversion, or a bad capture. Your script would work fine for the first few cycles and then just cause more problems afterward; it really needs adaptive decimation.
I'll look into getdups, that sounds interesting.
JnZ
3rd October 2005, 09:35
No, this is definitely not a dup-solvable problem. You need something like FDecimate (http://neuron2.net/fdecimate/fdecimate.html),...
I've tried FDecimate,but not working well. So my idea is clear that duplicate frames in whole film and after that sync it to 23.976fps. (Never mind,that velocity of the film little change. Audio sync is no problem. I change it.
There is only duplicate frames, no missed frames. I only remark,that this is maybe bad captured HD video. I have some more, but only this is weird.
Other videos have duplicate frames every 5 frames, so Decimate() can restore it.
EDIT: I found some missed frames. So i must try FDecimate.
EDIT2: Fizicks GetDups returns only one of duplicate frame. :mad:
AI
4th October 2005, 04:27
EDIT2: Fizicks GetDups returns only one of duplicate frame. :mad:
I dont undestant you.
do You want delete duplicate frames?
PS My english is bad too ;)
foxyshadis
4th October 2005, 07:11
To simply get rid of every duplicate regardless of sync, try DeDup (http://students.washington.edu/lorenm/src/avisynth/dedup/). It's similar to dup but drops them instead of copying them across. It will output a timecode file, but you can always just ignore that if you're going to manually resync everything.
FDecimate will remain periodic, so if you clip really is squirrelly this might be the best way to get it. My dream filter is to a merged fdecimate, tdecimate w/vfr, and dedup, but that's not likely to happen. :p (Although I might be able to mod dedup to read tdecimate's output, saving me a pass.)
JnZ
4th October 2005, 21:00
Thx all for help,
but I think that this is no solution. This vido is realy crap. Some frames are double and some is missing.
I try DeDup, works fine, removes duplicate frames, but video is still jerky. (missing frames).
Ahyone thx all.
Guest
5th October 2005, 00:07
This line is off-topic for this thread. Please start a new one. Thank you.
Fizick
3rd January 2007, 15:14
neuron2 and sh0dan,
It seems that latest Dup v2.2.1 has a bug: mode blend=true does not work properly (nothing is blended really).
Result is not differ from blend=false.
(it was reported by smash94 at Russian forum)
Simplest script:
Dup(blend=true)
Older Dup v2.20b1 binary works fine.
I try complile them from source codes.
Compiled v2.20b1 (and v2.21) with VC6 provided project settings does not work too.
I tried look to source code, but is rather complex, so I have no ideas what is wrong.
But I found workaround. It works fine if optimisation (/O2) disabled or if compiler switch /Ot used instead.
VC7 (toolkit) works fine too.
May be you used different SDK library.
Please look.
Guest
4th January 2007, 04:31
* Fixes the broken blend=true mode. Stupid Microsoft compiler couldn't handle the code! I had to use the Intel compiler.
* Fixes crashes upon close of the application that opened the Avisynth script. That happened only when a log file was not defined.
http://neuron2.net/dup/dupnew.html
Fizick
4th January 2007, 11:41
Thanks for update.
But the same very active user smash94 :) also discovered second problem.
v2.20b1 and new 2.2.2 (after fixing a bug) have a little strange feature or bug.
Two-frame duplicate sequence is not really blended,
and generally for N frame sequence, only N-1 frames are blended.
Very first (original) frame of such sequence is not used for blending.
My suggestion is to change curent algorithm. All similar frames must be blended.
Suggested code patch to v2.22:
in GetFrame:
line 490: int c_div=32768/(planesY+1); // add 1 for normalization
line 503: int c_div=32768/(planesUV+1); // add 1
in mmx_average_planes function:
line 1157: if (planes<0) return; // (was plane<=0) to not skip very first frame
line 1189: jns kernel_loop; // (was jnz kernel_loop) to not skip very first frame
Opinions?
Fizick
19th January 2007, 21:47
May be I used wrong language?
Suppose we have similar (duplicate) frames 10 and 11. Other frames (9, 12) are different.
It is typical condition for anime.
The current version 2.22 (and 2.20) of Dup works so way:
It detects that frames 10, 11 are similar,
but does NOT blend them (but put message about blending in show mode).
Guest
19th January 2007, 23:54
The problem is that sh0dan low-level optimized my original C code and I don't have the knowledge of what he did (or the time to analyze it) to determine if your changes are valid. Can you PM him about it?
Fizick
20th January 2007, 02:16
Thanks for your answer, now I understand (will try PM him).
Do you have original C version (probably v2.0 or 2.0.1) to compare?
The question is: did you have an intention to skip (do not blend) first frame in sequence (which may be lesser quality)?
For my noisy anime it is not a case trough.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.