Avisynth+

[ultim]

A second bugfix release is available. Besides proudly wielding the version number "0.1 (r1555)", the most important changes are:

A fix for the autoload issue reported here (http://forum.doom9.org/showthread.php?p=1655169#post1655169).
A fix for TemporalSoften which potentially resulted in crash.
A fix for some filters not loading under specific circumstances. Discovered on WriteFileStart.
A fix for the "return" script statement not returning from the current function if used inside if/while/for etc.

This release is a nice opportunity for you to try out AviSynth+ if you didn't already. Unless some major issue pops up, the next release will bring larger changes.

There is a slight change in behavior in r1555, made necessary by the fix for the autoload issue. Previously, plugin autoloading started automatically if forced by the AutoloadPlugins() function, or if an unknown(=external) function was found. Beginning with this release there is also a third condition, autoloading will also happen if any LoadPlugin() is issued, and it will happen right before the LoadPlugin() is executed. This was necessary to preserve compatibility with scripts for classic AviSynth.

Anyway, enjoy our latest and greatest release. Download (http://www.avs-plus.net/) from the homepage.

[ultim]

In other news, there is a GitHub organization (https://github.com/AviSynth) now for AviSynth. If you're the developer of an open source plugin, script or utility related to AviSynth, join the organization so that all avs-related code can be found in one place. Of course you still preserve full admin privileges over your repository upon joining, but visitors will be able to find all AviSynth related projects at a glance, which is good for both your code, for AviSynth, and for the visitor/community.

If you're already a GitHub user, joining is easy, you just need to tell me or TurboPascal7 that you'd like to join, and let us know your GitHub username. If you're not using GitHub already, I strongly recommend you create an account. Not (only) because of the (1) organization, but because (2) it will greatly simplify accepting contributions from others (be it code or feedback), and (3) GitHub will also make it much easier for you to host your code and binary releases.

So, fellow Avs Devs, join the AviSynth organization on GitHub (https://github.com/AviSynth).

[Gavino]

A fix for the "return" script statement not returning from the current function if used inside if/while/for etc.
I can understand why you might consider the old behaviour to be a bug, but I made GScript work that way because that was what already happened with a 'return' inside a try/catch block (exit only from current block). With this change, Avisynth+ is now inconsistent with Avisynth in this respect.

[ultim]

I can understand why you might consider the old behaviour to be a bug, but I made GScript work that way because that was what already happened with a 'return' inside a try/catch block (exit only from current block). With this change, Avisynth+ is now inconsistent with Avisynth in this respect.

We acknowlege this small inconsistency, but we believe that there almost no scripts affected, and so the advantages greatly outweight the downsides of this small deviation from AviSynth.

[Mystery Keeper]

Since you now let user customize plugins path, would you please add separate path for .avsi scripts?

[TurboPascal7]

Since you now let user customize plugins path, would you please add separate path for .avsi scripts?
What for?

[Mystery Keeper]

To not copy them across 32 and 64 bit folders and keep them separated from the binaries.

[real.finder]

hi, what AutoloadPlugins() function do?

Did not mention here (http://forum.doom9.org/showpost.php?p=1646315&postcount=67)

[ultim]

hi, what AutoloadPlugins() function do?

Did not mention here (http://forum.doom9.org/showpost.php?p=1646315&postcount=67)

It simply forces autoloading at the point it is called. Not usefull for scripts, it was meant to support editors like AvsPmod.

[Groucho2004]

I have been testing the 32 bit AVS+ version on XP64 with the following script to drive the memory usage above 2G:
setmemorymax(16384)
n = 9000
colorbars(width = n * 2, height = n, pixel_type = "yv12").killaudio().assumefps(24000, 1001)
trim(0,19)
pointresize(width() - 64, height() - 64).turnleft()
pointresize(width() + 64, height() + 64).turnright()
a=selectevery(3, 0).addborders(0,0, 16,0).crop(0,0, -16,0)
b=selectevery(3, 1).addborders(0,0, 32,0).crop(0,0, -32,0)
c=selectevery(3, 2).addborders(0,0, 64,0).crop(0,0, -64,0)
interleave(a, b, c)

Results with the "normal" Avisynth 2.6 Alpha5:
Frames processed: 20 (0 - 19)
FPS (min | max | average): 0.24 | 0.25 | 0.25
CPU usage (average): 25%
Thread count: 2
Physical Memory usage (peak): 2330 MB
Virtual Memory usage (peak): 2324 MB
Time (elapsed): 000:01:21.186


And with the latest AVS+ (x86):
Frames processed: 20 (0 - 19)
FPS (min | max | average): 0.53 | 0.61 | 0.60
CPU usage (average): 25%
Thread count: 2
Physical Memory usage (peak): 3030 MB
Virtual Memory usage (peak): 3022 MB
Time (elapsed): 000:00:33.140

AVS+ is obviously much faster but also uses a lot more memory. This might be an isolated case but I thought it might be worth reporting.

[ultim]

What eats memory are the resize functions. If you remove them, memory consumption sinks drastically.

setmemorymax(16384)
n = 9000
colorbars(width = n * 2, height = n, pixel_type = "yv12").killaudio().assumefps(24000, 1001)
trim(0,19)
turnleft()
turnright()
a=selectevery(3, 0).addborders(0,0, 16,0).crop(0,0, -16,0)
b=selectevery(3, 1).addborders(0,0, 32,0).crop(0,0, -32,0)
c=selectevery(3, 2).addborders(0,0, 64,0).crop(0,0, -64,0)
interleave(a, b, c)

Frames processed: 20 (0 - 19)
FPS (min | max | average): 1.38 | 1.65 | 1.59
CPU usage (average): 12%
Thread count: 4
Physical Memory usage (peak): 1201 MB
Virtual Memory usage (peak): 1214 MB
Time (elapsed): 000:00:12.605

[Gavino]

We acknowlege this small inconsistency, but we believe that there almost no scripts affected, and so the advantages greatly outweight the downsides of this small deviation from AviSynth.
I agree the new semantics are more useful.
Perhaps IanB could be persuaded that the way Avisynth currently handles 'return' in try/catch is a bug, and should be fixed.

Looking at the changes to the Avisynth+ source code, I believe there is a flaw in the way 'return' has been implemented.
You have put the code to handle the new ReturnExprException into ScriptEnvironment::Invoke(). This will catch a 'return' from both script level and from a user function, but not from run-time scripts (eg in ScriptClip()), since the run-time filters call the parser directly and do not use Invoke(). I haven't actually tried it, but I think you will now get an unhandled exception if you use 'return' in a run-time script.

Conceptually, Invoke() also feels like the wrong place to handle this, as this exception is really just a parser thing and it would be cleaner to handle it fully inside the parser code.

My preferred solution would be to introduce a new Expression subclass 'ExpRoot' which the parser would use for the root of the expression tree (in ScriptParser::Parse()) and for function bodies (in ScriptParser::ParseFunctionDefinition). The ReturnExprException could then be caught in the Evaluate() of this new subclass.

[ultim]

I agree the new semantics are more useful.
Perhaps IanB could be persuaded that the way Avisynth currently handles 'return' in try/catch is a bug, and should be fixed.

Looking at the changes to the Avisynth+ source code, I believe there is a flaw in the way 'return' has been implemented.
You have put the code to handle the new ReturnExprException into ScriptEnvironment::Invoke(). This will catch a 'return' from both script level and from a user function, but not from run-time scripts (eg in ScriptClip()), since the run-time filters call the parser directly and do not use Invoke(). I haven't actually tried it, but I think you will now get an unhandled exception if you use 'return' in a run-time script.

Conceptually, Invoke() also feels like the wrong place to handle this, as this exception is really just a parser thing and it would be cleaner to handle it fully inside the parser code.

My preferred solution would be to introduce a new Expression subclass 'ExpRoot' which the parser would use for the root of the expression tree (in ScriptParser::Parse()) and for function bodies (in ScriptParser::ParseFunctionDefinition). The ReturnExprException could then be caught in the Evaluate() of this new subclass.

Correct. I will hotfix it tonight and edit this post when done. Thank you!
EDIT: The release is up. Contains a fix for the issue pointed out by Gavino, and also an installer fix as well as some visual update.

[jpsdr]

What eats memory are the resize functions.


Maybe in that case the question should be "Why...?".
Why the resize functions in avisynth+ use more memory ?

[TurboPascal7]

Maybe in that case the question should be "Why...?".
Why the resize functions in avisynth+ use more memory ?

I described it here (http://forum.doom9.org/showpost.php?p=1655121&postcount=300) in part 9.
Now, current implementation is less memory efficient than it could be and this will get fixed some time soon. But we won't go back to the old way of doing it so avs+ resizers will always eat more memory than original.

[jpsdr]

Ok, thanks for the information.

[hector40]

Hi, this script crash avspmod.

BlankClip(length=1000, width=720, height=480, pixel_type="yv12", fps=23.976)
a=last
crop(718, 0, -0, -0)
Repair(blur(1.0).AddBorders(718,0,0,0), last.AddBorders(718,0,0,0),1)
crop(718, 0, -0, -0)
overlay(a, last, mode="blend", opacity=1.0, x=718)

[wOxxOm]

Hi, this script crash avspmod.yeah it does crash avs+ here too, so I simplified the script, the essential code is: BlankClip(1000,720,480,"yv12")
overlay(last)
callstack:> avisynth.dll!convert_yv24_chroma_to_yv12_sse2(unsigned char * dstp, const unsigned char * srcp, int dst_pitch, int src_pitch, int dst_width, const int dst_height) Line 309 C++
avisynth.dll!Convert444ToYV12::ConvertImage(Image444 * src, PVideoFrame dst, IScriptEnvironment * env) Line 410 C++
avisynth.dll!Overlay::GetFrame(int n, IScriptEnvironment * env) Line 277 C++
avisynth.dll!Cache::childGetFrame(int n, IScriptEnvironment * env) Line 356 C++
avisynth.dll!Cache::GetFrame(int n, IScriptEnvironment * env) Line 557 C++
avisynth.dll!avs_get_frame(AVS_Clip * p, int n) Line 170 C++

On this line (https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/filters/overlay/444convert.cpp?source=c#L309) dst_width==360 for the chroma plane which is not mod16, so _mm_store_si128 crashes.
Should be an unaligned store which is also used in other functions:
_mm_storeu_si128(reinterpret_cast<__m128i*>(dstp+dst_width-16), avg);

[zerowalker]

Is it possible to add Wave64 (or rather Wave over 4gb) support?

It´s now possible to open it, but the time will incorrect, it will stop at some point before the actual end (Probably when it reaches the 4gb limit).

There is a workaround to use plugins, but most of the time Directshowsource does the work best.

[real.finder]

hi

About MT and setmtmode and the old closed Source filters

It would be better if setmtmode applied only on those filters

Because there are some filters will be slow with setmtmode, no matter mode were used

will be slower than without setmtmode, such as ffms2, especially with large files

So it would be good to apply setmtmode automatically with the proper mode on those filters only

And after one filter with setmtmode enabled, if there a filter with a different setmtmode mode will be changed automatically to that mode

in this case, avs+ will need a particular directory for those filters that will be used with setmtmode and the proper mode for each one of them

Otherwise, setmtmode will be cancel by the default

But the problem is the cancellation, setmtmode 5 and setmtmode 6 not good for this

Because I tried them with ffms2 and the speed was reduced, and of course I can use mp_pipeline to overcome such a problems, but it better to have a mechanism to stops setmtmode in the same script

----


For open source and the modern filters, they will use an internal MT

or running setmtmode with the proper mode into avs script, and cancel it if the next filter not need setmtmode

or it better to be a new and safe mt between the avs and the filters to be used in those cases away from setmtmode


thanks :)

[wOxxOm]

real.finder, instead of the outdated ffms2 can you please test L-SMASH Source (http://forum.doom9.org/showthread.php?t=167435)'s LSMASHVideoSource (for mp4/mov) and LWLibavVideoSource (for everything) in your avs mt workflow? If it isn't affected then maybe there is no problem to solve, just switch to L-S...

[real.finder]

real.finder, instead of the outdated ffms2 can you please test L-SMASH Source (http://forum.doom9.org/showthread.php?t=167435)'s LSMASHVideoSource (for mp4/mov) and LWLibavVideoSource (for everything) in your avs mt workflow? If it isn't affected then maybe there is no problem to solve, just switch to L-S...

I mentioned ffms2 for example only

There may be other filters do not like setmtmode, and this known thing

in the past, I tested put setmtmode before mp_pipeline and make the process slower too

[jpsdr]

I've quickly tested QTGMC v3.33 (just try to open file and view a few frames) under Windows XP64 SP2, with r1555.

Seems to works fine with VDub x86.

Not working with VDub x64, error message :

Cache Filter returned invalid response to CACHE_GETCHILD_CACHE_MODE. 78312696
.../plugins64/QTGMC.avsi line 784
.../plugins64/QTGMC.avsi line 387
.../Deinterlace_v2.avs line 2


Line 784 :
diff = mt_makediff( Ref, Input, U=3,V=3 )
Line 386 :
repair0 = (IsClip(srchClip) || Rep0 == 0) ? binomial0 : binomial0.QTGMC_KeepOnlyBobShimmerFixes( bobbed, Rep0, (RepChroma && ChromaMotion) )

My script :

AVISource("File.avi")
QTGMC(EdiMode="nnedi3",ChromaEdi="nnedi3",blocksize=8,overlap=4,search=5,searchparam=4,EdiThreads=6,ChromaMotion=false)
SelectEven()


Of course, this was working with avisynth64_4-16-10.

[real.finder]

you need mt_masktools-26.dll compile with new avs interface

Available in x86 by now, not for x64 until now, At least I didn't see one for 64 until now

Many filters need to have 64 ver.

[jpsdr]

I have the x64 version of v2.0a48 for avs 2.6... Another new one is required ?

[TurboPascal7]

I have the x64 version of v2.0a48 for avs 2.6... Another new one is required ?

Yes. I will publish a fork of masktools some time soon.
It doesn't mean that you'll be able to safely run QTGMC though since there are many more filters used.

[real.finder]

I have the x64 version of v2.0a48 for avs 2.6... Another new one is required ?

avs 2.6 interface changed in alpha 4, So it need to recompiling with it, there is x86 by now only (http://tmod.nmm-hd.org/Misc/mt_masktools-26-for-2.6alpha4.7z) as I said

official mt_masktools-26.dll will not work with avs 2.6 alpha 4 and up

Of course avs+ also

you can use mt_masktools-25.dll but make sure there is no other mt_masktools in plugins autoload folder dir

[jpsdr]

I've try to compile the project (VS2010) (source taken from v2.0a48)... Without succes. I've installed yasm according the description in the readme (vysasm.exe in "../VC/Bin" and props/target/xml in "../v4.0/BuildCustomizations").

When i try to generate project, i've the following error :

1>------ Début de la génération*: Projet*: common, Configuration*: release-avs26 Win32 ------
1>F:\PRG\Visual_2010\masktools-v2.0a48\common\build\yasm.targets(73,5): error MSB4023: Impossible d'évaluer la métadonnée d'élément "%(Extension)". Impossible d'appliquer la métadonnée d'élément "%(Extension)" au chemin d'accès ""Win32\release-avs26\\_functions.obj"". Caractères non conformes dans le chemin d'accès.
2>------ Début de la génération*: Projet*: masktools, Configuration*: release-avs26 Win32 ------
2>F:\PRG\Visual_2010\masktools-v2.0a48\masktools\build\yasm.targets(73,5): error MSB4023: Impossible d'évaluer la métadonnée d'élément "%(Extension)". Impossible d'appliquer la métadonnée d'élément "%(Extension)" au chemin d'accès ""Win32\release-avs26\\_functions.obj"". Caractères non conformes dans le chemin d'accès.
========== Génération*: 0 a réussi, 2 a échoué, 0 mis à jour, 0 a été ignoré ==========

Translation is something like :

1>------ Start generation*: Project*: common, Configuration*: release-avs26 Win32 ------
1>F:\PRG\Visual_2010\masktools-v2.0a48\common\build\yasm.targets(73,5): error MSB4023: Impossible to evaluate the metadata "%(Extension)". Impossible to apply the metadata "%(Extension)" to acces path ""Win32\release-avs26\\_functions.obj"". Characters not conform in the acces path.
2>------ Start generation*: Projet*: masktools, Configuration*: release-avs26 Win32 ------
2>F:\PRG\Visual_2010\masktools-v2.0a48\masktools\build\yasm.targets(73,5): error MSB4023: Impossible to evaluate the metadata "%(Extension)". Impossible to apply the metadata "%(Extension)" to acces path ""Win32\release-avs26\\_functions.obj"". Characters not conform in the acces path.
========== Génération*: 0 success, 2 failed, 0 updated, 0 ignored ==========

[Groucho2004]

I've try to compile the project (VS2010) (source taken from v2.0a48)... Without succes.
How is this related to AVS+?

[jpsdr]

Because... ... euh... after being able to compile the original source, i wanted to try to compile with the new avisynth.h from AVS+ ? ... not good...?
Ok sorry...

[TurboPascal7]

As I told you I will publish a fork of masktools some time soon. If you want to build it right now for whatever reason, feel free (https://github.com/tp7/masktools). But you'll need VS2012 for that.

[jpsdr]

Ok, thanks.

[ultim]

hi

About MT and setmtmode and the old closed Source filters

It would be better if setmtmode applied only on those filters

Because there are some filters will be slow with setmtmode, no matter mode were used

will be slower than without setmtmode, such as ffms2, especially with large files

So it would be good to apply setmtmode automatically with the proper mode on those filters only

And after one filter with setmtmode enabled, if there a filter with a different setmtmode mode will be changed automatically to that mode

in this case, avs+ will need a particular directory for those filters that will be used with setmtmode and the proper mode for each one of them

Otherwise, setmtmode will be cancel by the default

But the problem is the cancellation, setmtmode 5 and setmtmode 6 not good for this

Because I tried them with ffms2 and the speed was reduced, and of course I can use mp_pipeline to overcome such a problems, but it better to have a mechanism to stops setmtmode in the same script

----


For open source and the modern filters, they will use an internal MT

or running setmtmode with the proper mode into avs script, and cancel it if the next filter not need setmtmode

or it better to be a new and safe mt between the avs and the filters to be used in those cases away from setmtmode


thanks :)

In AVS+, SetMTMode (with a different name) is implemented similarly to your idea, with minor differences. The way it works is instead of specifying the MT mode for all the filters that follow, AVS+'s setmtmode accepts the filter's name as its first parameter, and it then applies to all instances of that filter, and only to that filter. So basically it is what you have said, in that you can set the mt-mode for each filter once, and AVS+ will switch between mt modes automatically.

This has a couple of nice advantages:

First, obviously, your scripts don't need to be modified in their middle. There is no need to insert dozens of setmtmode calls all over a script, and you can keep the actual script logic and setmtmode calls separate cleanly.
Second, this approach allows you to move the setmtmode calls for all of your installed plugins into one script that contains nothing but all the setmtmode calls, which you can then include in your other scripts. Meaning you'll only need to maintain one set of setmtmode calls.
Even better than my previous point, you don't even need to include the setmtmode specifications in all of your scripts, you can just let it autoload like any other .avsi script. In AVS+, setmtmode is not what enables parallel processing, so you can safely call setmtmode in any script even if you don't want to run it multithreaded. Multithreading is enabled by a different call that you can add to only those scripts that use MT-capable plugins. (setmtmode merely specifies how to multithread a filter if MT is enabled at all)


Miscellaneous notes:

In AVS+, "SetMTMode" is actually called "SetFilter(MT)Mode". This is partially to differentiate scripts written for AVS+ from scripts written for AVS-MT, and also to more clearly indicate that this call does not set the MT mode globally, but only for a particular filter.
However, the same call can also be used to set the default MT mode for all filters that have no other MT mode set.
Plugins can also indicate to AVS+ which MT mode they need over their API. If this is specified by a plugin, it will normally take precedence over the mode set by the script, because it is more likely to be correct (a user's manual setting can easily be out-of-date, or just simply incorrect). If a plugin specifies the MT mode for itself, there is no need to specify it in scripts at all.
SetFilterMTMode also has a second, boolean "force" parameter, optional and defaulting to false. If this is set to true in a script, that mode will take precedence over any other calls for the same filter where "force" was false. It will then also take precedence over the mode specified by the plugin internally.


The priority scheme of setfiltermode calls may sound complex, but it is really simple. To summarize:

If a filter has a forced mode set, it will use that.
Otherwise, it will use a non-forced mode, if it has any.
If it does not have any mode set, it will use the default mode for all filters.
Mode setting does not have any effect until MT is actually enabled (so it is still safe to set even the default mode in any script).


---------------------------

What I have described above is already done and implemented, except for filters being able to indicate their MT mode on their own to AVS+. However, due to some other reasons related mostly to caching, the MT-version of AVS+ isn't ripe enough yet, which is why it isn't included in the public builds currently.

[ultim]

Cache Filter returned invalid response to CACHE_GETCHILD_CACHE_MODE.

For future reference, if anybody sees the message above, it means the plugin is not compatible with AviSynth 2.6a4. For clarification, Avs+ uses the 2.6a4 interface.

What you can do at this point, is look in the forums if anybody has published an updated build of the same plugin, or recompile the plugin yourself.

Recompiling a 2.5 plugin for 2.6a4 will need some modifications to the plugin's source, but only very simple things. If you're a developer, it will definitely be easy (given that the pre-2.6a4 version can be recompiled, which for some plugins will be much harder than the actual porting to 2.6a4).

[ryrynz]

Looking forward to seeing MT in action, will it follow the same logic and performance as SEt's MTmodes?
If there is possibly no need to specify modes in scripts at all if the filter overrides it, will you provide a message stating this on runtime so it can be removed by the user? I'd rather not have unecessary lines in the script.
I was hoping to see a MT build soon, probably next month now?

[real.finder]

The only thing that makes me use SEt's build in my encoding by now and don't use avs+ is mt

So I also wait avs+ MT build

[ultim]

Looking forward to seeing MT in action, will it follow the same logic and performance as SEt's MTmodes?
Not sure what you mean by "same logic". It will have the same MT modes 1-3 as SEt's version.


If there is possibly no need to specify modes in scripts at all if the filter overrides it, will you provide a message stating this on runtime so it can be removed by the user? I'd rather not have unecessary lines in the script.

Maybe, in the future, but not right at the start. Those "unnecessary" lines should not disturb you as they will not have any effect, and if you autoload the setfiltermode lines they won't pollute your scripts.


I was hoping to see a MT build soon, probably next month now?
I was planning originally to release in november, but RL stepped in to prevent that. So no guarantees, but I do hope I'll get more opportunities to work on it in the holiday season. Rest assured, MT is coming, and more features will after that.

[jpsdr]

I have somehow just a little question.
I'm trying to port to x64 nnedi3 v0.9.4. My first step is to put on external asm files all the _asm inside. I've just begun (here (https://github.com/jpsdr/NNEDI3)), it's going slowly, but i'm progressing. When done and tested, my second step will be to convert the asm file to x64. But, for now, during the first step, i'm begining to think of the second step, and i've noticed something different from what i'm used to in VDub (i've made personnaly several filters for VDub, but asm was always in asm files, never inline, so updating to x64 was less less difficult).
In VDub, all pointer related data (offset/pitch) are in ptrdiff_t, which allow an excellent portability x86/x64, specialy when you write asm functions, and pass pitch parameters which are used directly to compute on address data.
I've noticed, in the code of nnedi3, and after taking a look at avisynth.h, that in avisynth these parameters are int. Int is 32 bits even on x64... In the process of updatind and making avisynth more portable for x64, don't you think it could be interesting to think about having offset/pitch pointer parameters of avisynth picture data in ptrdiff_t ? It's the same thing as int on x86 (32 bits signed), but they will be 64 bits signed on x64, more logical for pointer offset data.
Well, it's just my little thought.

[ultim]

You are not the first to suggest that some data types should be changed, but we cannot do so without breaking existing x64 filters.

Either way, offset/pitch being only ints isn't really a problem. Offset merely stores the displacement of a frame's plane from it's base pointer, so this is not a problem since your planes will be lot less smaller than 2GBs. Similarly, pitch is the displacement from the beginning from one line to the next, and since a single row of samples will rarely hit 2GBs in size, this doesn't pose any realistic limitation. So offset/pitch aren't pointers, both are offsets from pointers within a single frame, hence I don't see how this is a portability issue. It won't even cause a problem with pointer arithmetic in C. You might need to take special precautions in ASM to get correct results out of pointer math, but I'm not the expert in that area.

[TurboPascal7]

If you plan on going external asm, please consider using x264 abstraction thingy over simply changing the code to be x64-only. It's always better to have a single source that can compile to both x64 and x86 instead of two different codebases. You can find example usage in x264 or vapoursynth.

[jpsdr]

Typical could be :
In .cpp file :

extern "C" void fn(void *ptr,ptrdiff_t pitch);


x86 asm file :

fn proc ptr:dword,pitch:dword

public fn

push ebx

mov ebx,ptr
mov ecx,pitch.
mov eax,dword ptr[ebx+ecx]
.....


x64 asm file :

fn proc public frame

push rbx
.pushreg rbx
.endprolog

mov rbx,rcx
mov rcx,rdx
mov eax,dword ptr[rbx+rcx]
....

Note : In x64 the 3 first parameters are passed in registers rcx (ptr) and rdx (pitch) and r8d but not here because there is only 2 parameters.

Will work without issue for positive and negative pitch in both x86 and x64.

If you have this instead :
In .cpp file :

extern "C" void fn(void *ptr,int pitch);


x86 asm file :

fn proc ptr:dword,pitch:dword

public fn

push ebx

mov ebx,ptr
mov ecx,pitch.
mov eax,dword ptr[ebx+ecx]
.....

No change, still working.

x64 asm file :

fn proc public frame

push rbx
.pushreg rbx
.endprolog

mov rbx,rcx
xor rcx,rcx
mov ecx,edx
mov eax,dword ptr[rbx+rcx]
....

Will not work on negative pitch !!!

Issue can be with negative value in asm functions. If you pass in x64 mode to an asm function a pointer (on 64 bits) and a pitch but on 32 bits for it, it will work only on positive value.
In VDub pitch can be negative. If in avisynth pitch is always positive, issues may not occurs.

[jpsdr]

If you plan on going external...
My purpose is to try to do the same thing i've already done with my VDub filters : One cpp file working for both x86 and x64, 2 asm files (one x86 and one x64).
Will i success ? That's another story.

[TurboPascal7]

My purpose is to try to do the same thing i've already done with my VDub filters : One cpp file working for both x86 and x64, 2 asm files (one x86 and one x64).
Will i success ? That's another story.

Why two asm files when you can do this in one, simply abstracting register names and maybe some other things?
But whatever works for you, I guess.

[foxyshadis]

Some x64 asm can definitely benefit from the extra registers, but so few that the maintenance cost of two asm functions usually outweighs it. Even more so when you start optimizing for various architectures (SSE2, SSSE3, AVX) and 16-bit depth. x86inc is SO useful, and x86util does handy work papering over some more differences. You really should consider using them, you might be surprised.

[ajp_anton]

Could you make so imagesource returns the original colorspace, e.g. jpeg images encoded in 4:2:0 or 4:4:4, instead of converting them to RGB?
Perhaps with the argument pixel_type="original", if you want to keep it compatible with old scripts that assume RGB.

[ultim]

x64 asm file :

fn proc public frame

push rbx
.pushreg rbx
.endprolog

mov rbx,rcx
xor rcx,rcx
mov ecx,edx
mov eax,dword ptr[rbx+rcx]
....

Will not work on negative pitch !!!


You could just sign extend your edx into rcx to solve this "problem". For example (untested):

fn proc public frame

push rbx
.pushreg rbx
.endprolog

mov rbx,rcx
movsxd rcx,edx
mov eax,dword ptr[rbx+rcx]
....

This should work for x64 with both positive and negative pitches, and even requires less assembly lines.

[ultim]

Could you make so imagesource returns the original colorspace, e.g. jpeg images encoded in 4:2:0 or 4:4:4, instead of converting them to RGB?
Perhaps with the argument pixel_type="original", if you want to keep it compatible with old scripts that assume RGB.

The current image library (DevIL) in use by AviSynth doesn't allow that, so no. Neither it is possible with many other generic image decoder libraries, as still images are usually composed on RGB surfaces. If anybody knows a still image library that can do that, I'd be happy to have a closer look at it. On the other hand, if it is only possible with format-specific decoders, then I'd only have it as a separate external plugin.

[qyot27]

FFMS2 can be used for stills (see the FFImageSource function in FFMS2.avsi), and it returns the original's colorspace. I just tested it, and it returned 4:2:0 and 4:2:2 directly.

[ultim]

FFMS2 can be used for stills (see the FFImageSource function in FFMS2.avsi), and it returns the original's colorspace. I just tested it, and it returned 4:2:0 and 4:2:2 directly.

Does it really return the original image data unchanged? Or maybe it gets RGB data internally from the format's lib, then ffmpeg converts back to planar on its own?

[jackoneill]

My purpose is to try to do the same thing i've already done with my VDub filters : One cpp file working for both x86 and x64, 2 asm files (one x86 and one x64).
Will i success ? That's another story.

I already converted nnedi3's asm into an external file that you can assemble with yasm. It works for both 32 and 64 bit. If Avisynth(+) doesn't allow negative strides, you can probably use it without any changes.

https://github.com/dubhater/vapoursynth-nnedi3