Vapoursynth

[lansing]

I did the test with the vpy script through using the VSimport wrapper, seems that it slows down the speed quite a lot, compared to simply threw the vpy script into virtualdub and ran analysis pass.

with wrapper:
R21 --> 30
test1 --> 35
test2 --> crash


without wrapper:
R21 --> 40
test1 --> 65
test2 --> crash

[Myrsloik]

Originally Posted by lansing

I did the test with the vpy script through using the VSimport wrapper, seems that it slows down the speed quite a lot, compared to simply threw the vpy script into virtualdub and ran analysis pass.

with wrapper:
R21 --> 30
test1 --> 35
test2 --> crash


without wrapper:
R21 --> 40
test1 --> 65
test2 --> crash

If you want to test speed I really suggest you use vspipe as it will almost always have better throughput. It also shows the fps at the end now.

I'll take a serious look at it later tonight. It should be almost as fast as tdecimate at least.

[lansing]

Originally Posted by Myrsloik

If you want to test speed I really suggest you use vspipe as it will almost always have better throughput. It also shows the fps at the end now.

I'll take a serious look at it later tonight. It should be almost as fast as tdecimate at least.

I couldn't find any documentation on using vspipe on your site. I only know the most basic:

vspipe "clip.vpy" - -y4m | x264 --preset fast --demuxer y4m --output "clip.mkv" -

[jackoneill]

Originally Posted by lansing

I couldn't find any documentation on using vspipe on your site.

It prints usage instructions if you run it with no parameters. Use NUL as output file.

[lansing]

Originally Posted by jackoneill

It prints usage instructions if you run it with no parameters. Use NUL as output file.

Thanks, I got it working now

vspipe "clip.vpy" NUL

It's not so user friendly though, as it only showed the fps after the whole process was finished. not during the run.

[Mystery Keeper]

https://bitbucket.org/mystery_keeper...te-vapoursynth
Mature enough, or still needs improvements?

[sl1pkn07]

Hi Mystery Keeper

what is stdbool.h?

http://sl1pkn07.no-ip.com/paste/view/97611430

howto build? "gcc -o templinearapproximate.so main.c -I/usr/include/vapoursynth -I"put here stdbool.h path" ?

greetings

[LoRd_MuldeR]

Originally Posted by sl1pkn07

what is stdbool.h?

Support for the "bool" type as well as the "true" and "false" constants in C language:
http://pubs.opengroup.org/onlinepubs...stdbool.h.html

It's required, because C did not have a "bool" type before C99. Legacy code might still use "bool", "true" and "false" for other purposes, since they were not reserved before C99.

So if you want C++-style booleans in C, you have to include <stdbool.h> or just define those three macros yourself. MSVC still doesn't support C99

[Myrsloik]

Originally Posted by Mystery Keeper

https://bitbucket.org/mystery_keeper...te-vapoursynth
Mature enough, or still needs improvements?

https://bitbucket.org/mystery_keeper...=master#cl-196

The variable frames and planes can be allocated on the stack as an array of size 3. There will never be more than 3 planes in a format.

You should be able to eliminate most other allocations as well using variable length arrays since you went with C99.


https://bitbucket.org/mystery_keeper...=master#cl-208

You should pass input frame n instead of NULL. Otherwise all the existing properties such as colorimetry and times won't be copied over to your output frame.


"planes:int[]: opt:empty;" <- you probably don't want empty there, it's most likely an error if a user wants to filter no planes


https://bitbucket.org/mystery_keeper...=master#cl-114

"tla" should be "TempLinearApproximate". It makes more sense if the name reported when an error happens also matches the function used to create the filter.

That's all I could see. The only other small comment I have that should probably be ignored is that this would be a good function to implement with templates in C++ to avoid repeating it.

[sl1pkn07]

oks, build with

gcc -shared -fPIC -std=c99 -o templinearapproximate.so main.c -I/usr/include/vapoursynth

missing -shared and -fPIC

sorry. i'm not coder

greetings and thanks

[Mystery Keeper]

Originally Posted by Myrsloik

"planes:int[]: opt:empty;" <- you probably don't want empty there, it's most likely an error if a user wants to filter no planes

Actually intentional for testing purpose. Thank you for advices!
Also, silly me. Didn't free write pointers. That would cause a memory leak, so if anyone's already using it - you should update.

Originally Posted by Reel.Deel

And finally, someone started to port RemoveDirt to VS.

And it's getting close. I've ported it enough that it compiles. I just need the next couple of days to get the ASM ported to intrinsics (and most of it is pretty straightforward so it shouldn't be too hard) then to test it. The only other thing is that kassandro's RemoveDirt script (as of versions .8 and above it's merely a script around some functions in RemoveDirt and RemoveGrain) for Avisynth requires modes 16 and 17 in RemoveGrain. So before it can be used I'll work on implementing those modes for vsremovegrain since it currently doesn't support those modes.

[Reel.Deel]

Hi handaimaoh, welcome to the forum.

Great news about your progress/plans for RemoveDirt.
Regarding SCSelect what's your thoughts about adding functionality to be able to output a scene change log
and also make it compatible so that other plugins can use it as their scene change detector? (Similar to Chikuzen's scenechange plugin)

[Myrsloik]

Originally Posted by Reel.Deel

Hi handaimaoh, welcome to the forum.

Great news about your progress/plans for RemoveDirt.
Regarding SCSelect what's your thoughts about adding functionality to be able to output a scene change log
and also make it compatible so that other plugins can use it as their scene change detector? (Similar to Chikuzen's scenechange plugin)

SCSelect should never be ported. It's trivial to write as a script using FrameEval and PlaneDifference. It only calculates the sum of absolute differences to make its decision.

Note that Chikuzen's scenechange plugin also uses the absolute difference and should produce almost identical results. If you want the relative threshold mode as well just write a feature request Chikuzen.

Yeah, it will likely just get removed. It was only ported over simply for being able to test everything and the fact that it was like 2 minutes of effort since it was pretty simple.

[cretindesalpes]

Originally Posted by Myrsloik

SCSelect [...] only calculates the sum of absolute differences to make its decision.

Does it? The documentation states otherwise, Didée too (here). I have to say that 2nd order differences are much more reliable, from my experience. Anyway, I don’t know if it’s better to compute the scene change using 3 input frames each time (dedicated plug-in) or to save the first order differences on additional temporary frames, wasting memory for these trivial operations.

[Myrsloik]

Originally Posted by cretindesalpes

Does it? The documentation states otherwise, Didée too (here). I have to say that 2nd order differences are much more reliable, from my experience. Anyway, I don’t know if it’s better to compute the scene change using 3 input frames each time (dedicated plug-in) or to save the first order differences on additional temporary frames, wasting memory for these trivial operations.

The relevant code for selecting:

			if( dirmult * olddiff < lastdiff ) goto set_end;
			if( dirmult * lastdiff < olddiff ) goto set_begin;

olddiff and and lastdiff are the absolute difference to the previous/next frame. I suppose that does make it second order but it's still trivial to recreate.

[mastrboy]

There's a speed difference between SCSelect and using Avisynth's built-in runtime functions (xDifferenceFromPrevious/xDifferenceToNext), SCSelect is quite faster, no idea if the same would apply to vapoursynth's internal functions though...

Originally Posted by mastrboy

There's a speed difference between SCSelect and using Avisynth's built-in runtime functions (xDifferenceFromPrevious/xDifferenceToNext), SCSelect is quite faster, no idea if the same would apply to vapoursynth's internal functions though...

Before any final decision is made I'll do some speed tests. If SCSelect is still substantially faster it'll be kept around until something else can replace it. It's not a ton of code as is.

[StainlessS]

SCSelect_Like function in script (behaves identically and not very good) from here:- http://forum.doom9.org/showthread.ph...23#post1644023

Avisource("D:\avs\test.avi")

# RemoveDirt's SCSelect(clip input, clip scene_begin, clip scene_end, clip global_motion, float dfactor, bool debug, bool planar)

Function SCSelect_Like(clip dclip,clip Start,clip End,clip Motion, float "dfactor",bool "debug") {
    # Start, End, Motion MUST all be same, dclip can be other colorspace/size (unlike SCSelect).
    dfactor=Float(Default(dfactor,4.0))
    debug=Default(debug,false)
    Global SCM_A=0.0 Global SCM_B=0.0 Global SCM_SC=0 Global SCM_Prev=-1
    Motion.ScriptClip("""
        NotNext = (current_frame!=SCM_Prev+1)
        Global SCM_A=(NotNext)? RT_LumaDifference(dclip,dclip,n=current_frame-1,n2=current_frame)  : SCM_B
        Global SCM_B=           RT_LumaDifference(dclip,dclip,n=current_frame,n2=current_frame+1)
        # 0 = Start of scene, 1 = End of scene, 2 = Global motion
        Global SCM_SC=(current_frame==FrameCount-1)?1:(SCM_A>dfactor*SCM_B || current_frame==0)?0:(SCM_B>dfactor*SCM_A)?1:2
        (SCM_SC==0) ? Start : (SCM_SC==1) ? End : Last      # Choose Start, End or Motion(ie Last)
        (debug)?RT_Subtitle("%d ] %6.2f %6.2f SC=%d",current_frame,SCM_A,SCM_B,SCM_SC):NOP
        Global SCM_Prev=current_frame
        Return Last
    """,args="dfactor,Start,End,Dclip,debug")          # Needs Grunt for args
    return Last
}

Start=Subtitle("START OF SCENE",align=3,size=30)
End=Subtitle("END OF SCENE", align=1,size=30)
Motion=Subtitle("GLOBAL MOTION",align=5,size=30)
L=SCSelect_Like(Last,Start,End,Motion,debug=true)
R=SCSelect(Last,Start,End,Motion)
StackHorizontal(L,R)