Avisynth+

[ultim]

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

It is extremely rare, but I do think negative pitches exist in Avisynth, for example when some plugin tries to optimize vertical flips away (I faintly remember seeing it somewhere). Anyway, the workaround is really simple, just sign-extend like I have shown a few posts earlier, and it will work for negative pitches too.

[Reel.Deel]

...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.

vsimagereader (https://github.com/chikuzen/vsimagereader) it's able to decode JPEG without converting to RGB. All of the libraries used are listed at the bottom.

[ultim]

vsimagereader (https://github.com/chikuzen/vsimagereader) it's able to decode JPEG without converting to RGB. All of the libraries used are listed at the bottom.

I know, but even VS's support in this respect only applies to jpeg, over the libjpeg(-turbo) library. Which falls under my format-specific point. I'm proposing a new plugin (e.g. JPEGSource) for this purpose.

[Plorkyeran]

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?
libavcodec doesn't even have a way to convert the data to RGB, and I have no idea why you'd expect it to be automatically converting to RGB and back.

[jpsdr]

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

I've already used sometimes movzd in my VDub filters, but haven't searched yet if something else existed.
You spare me time searching, and this will probably work.
Thanks.

[SEt]

I'm proposing a new plugin (e.g. JPEGSource) for this purpose.
Actually I have working very nice JPEG decoder that can be ported to Avisynth. It not just keeps original chroma subsampling, but also supports "reconstruction" that accurately suppresses typical JPEG artifacts and can be done only as part of the decoding stage. Won't be open-source though.

It's currently implemented as plugin (http://plugring.farmanager.com/plugin.php?pid=693) for Far Manager (http://www.farmanager.com/download.php?l=en). It has some documentation, but only in Russian.

[jpsdr]

I think i may have discoverd an issue with x64 version, when trying to port the nnedi3 to x64.
When investigating, i've disable the use of ASM function, and fixed number of cpu (or threads) to 1.

I've the following result, code is around lines 1168.

With this :

else if (vi.IsYV12())
{
for (int i=0; i<ct; ++i)
{
v = new nnedi3(v.AsClip(),i==0?1:0,true,true,true,true,nsize,nns,qual,etype,pscrn,threads,opt,fapprox,env);
env->ThrowError("Ok");
v = env->Invoke("TurnRight",v).AsClip();
// always use field=1 to keep chroma/luma horizontal alignment
v = new nnedi3(v.AsClip(),1,true,true,true,true,nsize,nns,qual,etype,pscrn,threads,opt,fapprox,env);
v = env->Invoke("TurnLeft",v).AsClip();
}

the script stoped with "Ok" error.

With this :

else if (vi.IsYV12())
{
for (int i=0; i<ct; ++i)
{
v = new nnedi3(v.AsClip(),i==0?1:0,true,true,true,true,nsize,nns,qual,etype,pscrn,threads,opt,fapprox,env);
v = env->Invoke("TurnRight",v).AsClip();
env->ThrowError("Ok");
// always use field=1 to keep chroma/luma horizontal alignment
v = new nnedi3(v.AsClip(),1,true,true,true,true,nsize,nns,qual,etype,pscrn,threads,opt,fapprox,env);
v = env->Invoke("TurnLeft",v).AsClip();
}

script stop with "acces violation" error.

With this :

else if (vi.IsYV12())
{
for (int i=0; i<ct; ++i)
{
v = new nnedi3(v.AsClip(),i==0?1:0,true,true,true,true,nsize,nns,qual,etype,pscrn,threads,opt,fapprox,env);
//v = env->Invoke("TurnRight",v).AsClip();
// always use field=1 to keep chroma/luma horizontal alignment
v = new nnedi3(v.AsClip(),1,true,true,true,true,nsize,nns,qual,etype,pscrn,threads,opt,fapprox,env);
env->ThrowError("Ok");
v = env->Invoke("TurnLeft",v).AsClip();
}

script stoped with "Ok" error.

With this :

else if (vi.IsYV12())
{
for (int i=0; i<ct; ++i)
{
v = new nnedi3(v.AsClip(),i==0?1:0,true,true,true,true,nsize,nns,qual,etype,pscrn,threads,opt,fapprox,env);
//v = env->Invoke("TurnRight",v).AsClip();
// always use field=1 to keep chroma/luma horizontal alignment
v = new nnedi3(v.AsClip(),1,true,true,true,true,nsize,nns,qual,etype,pscrn,threads,opt,fapprox,env);
v = env->Invoke("TurnLeft",v).AsClip();
env->ThrowError("Ok");
}

script stopped with "acces violation" error.

and with this :

else if (vi.IsYV12())
{
for (int i=0; i<ct; ++i)
{
v = new nnedi3(v.AsClip(),i==0?1:0,true,true,true,true,nsize,nns,qual,etype,pscrn,threads,opt,fapprox,env);
//v = env->Invoke("TurnRight",v).AsClip();
// always use field=1 to keep chroma/luma horizontal alignment
v = new nnedi3(v.AsClip(),1,true,true,true,true,nsize,nns,qual,etype,pscrn,threads,opt,fapprox,env);
//v = env->Invoke("TurnLeft",v).AsClip();
}
env->ThrowError("Ok");

script stopped with "Ok" error.

So, according the results, i have the feeling it's something related to the x64 version of avisynth, as crash seems to occur during call of internal avisynth functions.

[real.finder]

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



um, existing x64 filters most of them (maybe all) in 2.5

since there is no avs 2.6 x64 around, and 2.6 x64 filters is just a few, actually the existing is:- mask tools 2 and TP7 filters (http://forum.doom9.org/showthread.php?t=169832) and last is LaTo filters, it can be update

so, 2.6 in x64 can be change alone? or it can't?

[steptoe]

I'm trying to work out how to use the updated RGTools.dll in place of the RemoveGrain package, but unsure if its just a case of replacing all calls in the removegrain package with rgtools.dll or if the syntax is different

At its most basic, calling for example RemoveGrain(17) or RemoveGrain(2) would this simply now be RGTools(17) or RGTools(2), and loading RGTools.dll instead of RemoveGrain.dll via the 'loadplugin' command

The docs for the updated plugins for avisynth+ are a bit sparse, and don't really suggest if they are direct drop in replacement or if a bit more work may be needed if the original plugins are called within scripts


Scripts that call various parts of the removegrain package, such as RemoveDirtMC, RemoveNoiseMC or RemoveNoiseMC_SE scripts are giving me a headache trying to update them to use RGTool. These all call different parts of the RemoveGrain package, such as the clense function for temporal noise/grain removal

Thanks

[TurboPascal7]

First of all, you're posting in a wrong thread. This (http://forum.doom9.org/showthread.php?t=169832) is the right one.
First 24 modes of RGTools should be drop-in replacement of the old removegrain plugin. Same goes for repair (24 modes), verticalcleaner (3 modes) an clense (normal, backward, forward). RGTools doesn't have some of the parameters in Clense so you'll have to drop those if you want to use it.

[Zathor]

Besides proudly wielding the version number "0.1 (r1555)"[...]
Thanks for the new version numbers. I am not sure if it is intended, but the information in the dll itself and VersionString() in AviSynth do not match. Currently there is:
VersionString(): AviSynth+ 0.1 (r1561, x86)
FileProperties.ProductName: AviSynth+ 2.6
FileProperties.FileVersion: 2, 6, 0, 5
(and also some others - maybe you also want to change the home page)

[ultim]

I think i may have discoverd an issue with x64 version, when trying to port the nnedi3 to x64.
...

No, it is actually a bug in nnedi3's sources, it is using an avisynth.h that is not x64 compatible. The bug is in AVSValue's Assign() function in nnedi3, you should take the working implementation from Avs+ sources to fix it.

p.s. This is why I am against every plugin having a separate copy of the avisynth header. With possibly all other libraries around the world, if someone wants to compile an extension or application for that lib, they just use the headers from the library's sources by adding the core's public headers path to the compiler include dirs. Why can't AVS plugin devs do that too?

[Gavino]

This is why I am against every plugin having a separate copy of the avisynth header. With possibly all other libraries around the world, if someone wants to compile an extension or application for that lib, they just use the headers from the library's sources by adding the core's public headers path to the compiler include dirs. Why can't AVS plugin devs do that too?
That's my view too, but TurboPascal7 (here) disagrees.

[ultim]

That's my view too, but TurboPascal7 (here) disagrees.

About 2-3 weeks ago I helped him debug one of his sources and that (too) turned out to be caused by a wrong avisynth.h header in the plugin. So he should have first-hand experience about the issues his method is causing. But here is my reflection on his arguments:

1) Avisynth folder might be different on different systems, someone who uses your project file will need to modify that. One might not even have the required version installed. Of course if you're writing closed source plugins or hope to avoid contributors, this is "fine".

Yes, VC++ project files will need to be modified if a stranger tries to compile your plugin. But the compiler will tell you instantly and unambiguously that avisynth.h is not found, and the dev will know right away that the include path needs to be modified. But my argument is not that this is an easy fix. The real argument here is that fixing up the include path is much easier than trying to debug runtime problems caused by mismatched headers. Such runtime problems, as both recent and past experiences show, do happen a lot.

2) It shows you the exact version of avisynth.h used to build a plugin. Just earlier this week I had to fix a plugin that didn't work in x64 mode because it still used AvisynthPluginInit2 even though it came with 2.6 header. This header being included helped me to identify the problem a lot faster than I could do with other methods.
Most times when you are compiling the plugin, you are not interested in which header version was used to compile it earlier. You will most probably have your own idea what AVS version you are compiling for, and that's all. Besides, the scenario described above is kind of like the self-fullfilling prophecy: Had the plugin been forced to correctly update to the latest header, the above mentioned bug wouldn't have happened at all. So frankly, I cannot accept this argument.

Which is kind of the point of always using the header from the avs(+) sources instead of making copies of it: 1) During compilation it will be obvious which Avs the plugin will be compatible with: that whose sources were used. 2) It'd avoid out-of-date headers of old plugins. 3) Plugins would automatically get (after a recompilation) all the fixes that go into the interface upstream. 4) It'd make it a lot less easy to mismatch header version with the intended/commonly used Avs version.

[jpsdr]

No, it is actually a bug in nnedi3's sources, it is using an avisynth.h that is not x64 compatible. The bug is in AVSValue's Assign() function in nnedi3, you should take the working implementation from Avs+ sources to fix it.

Thanks.

Any new release (ei 1576...) scheduled ?

[LoRd_MuldeR]

Yes, VC++ project files will need to be modified if a stranger tries to compile your plugin. But the compiler will tell you instantly and unambiguously that avisynth.h is not found, and the dev will know right away that the include path needs to be modified.

Why not simply use an include path like "$(AVISYNTH_ROOT)\include" in your solution? Then the developer just needs to setup the environment variable AVISYNTH_ROOT properly and the solution file does not need to be modified at all...

[ultim]

Any new release (ei 1576...) scheduled ?

Actually, I was just about to :)

So enjoy r1576. This is the fourth bugfix release in the current stable series, bringing you:

Reduced memory consumption in resizers.
The fix for this (http://forum.doom9.org/showthread.php?p=1657586#post1657586) crash.
A fix for correct detection of AVX capability.
A small "for"-loop change for compatibility with Gavino's original version.
A fix for bad alignment in the crop filter.
A compatiblity fix in BitBlt.
And a fix for a bug that resulted in autoloaded functions sometimes taking precedence over a non-autoloaded version.


Okay, so much for the bugfixes. Boring but at least usefull. If you want something cool though, try out and help me test the new caching system in this experimental build (http://goo.gl/e0VFYn). Make sure you rename the file to "avisynth.dll" if you try it out.

The experimental build is mostly the same as the just released r1576, except that it has the new caches, so if you're doing comparisons, please compare the experimental build to the r1576 release in this post. The new caches have been written from scratch with MT in mind, and although MT is not yet active in this build, the new caches will (or should) provide similar performance to the stable release, but with significantly reduced memory consumption. Let me know your experiences. The sooner I can deem the new caches "good enough", the sooner we'll see MT ;)

[jpsdr]

Bad news... The x64 version of r1576 is broken, i've rolled-back to r1561.
(Good new, is that i've now been able to make my nnedi port working on x64...).

[Groucho2004]

The x64 version of r1576 is broken
That's an amazingly detailed bug report.

Anyway, the 64 Bit dll is a debug build and the correct runtime (msvcp110d.dll) is missing.

[jpsdr]

Any avisynth script will generate an "unknow" error... Anyone who install and test it will see.

[ultim]

Gomen. I updated the binaries with release builds of the x64 version.

[DrZine]

Today I decided to try out avs+ for the first time. Everything seems to be stable so I did some benchmark comparisons. I'm on an AMD system and since hardly any testing is being done with AMD I thought I might share. I also tested out the new caching build just posted a few days ago while I was at it.

My system is a FX8350 @4.4ghz with 8gb of ram @1600mhz running Win7 Pro x64. All builds of avs+ are x86. I ran 2 different scripts with AVSmeter 1.7.4.

The first script I ran was a test script Groucho2004 posted up a few pages back. Going from Alpha5 to avs+ r1576 was a 50% speed increase! I'm guessing this has more to do with the improved core filters than anything else. From r1576 to the new cache build r1595 was a bit of a head scratcher though. The overall speed dropped just a hair while a second thread was created. Is this supposed to happen? As far as the memory usage it dropped by 155MB. Very nice.

[Script]
colorbars(width = 1920, height = 1080, pixel_type = "yv12").killaudio().assumefps(24000, 1001)

trim(0,499)
fadeio(248)
trim(0,499)

spline36resize(width() - 64, height() - 64).turnleft()
spline64resize(width() + 64, height() + 64).turnright()
bicubicresize(width() - 64, height() - 64).fliphorizontal()
sincresize(width() + 64, height() + 64).flipvertical()

a = tweak(hue=33)
u_chroma = blankclip(utoy(a), color=$808080)
ytouv(u_chroma, a.vtoy)
mergeluma(a)
tweak(hue=-33)

temporalsoften(4,4,8,15,2)
limiter(16, 235, 16, 240)
levels(0, 1, 255, 16, 235)
scriptclip("subtitle(string(ydifferencefromprevious))")
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)

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

[General info]
Log file created with: AVSMeter 1.7.4 (AVS 2.6, x86)
Avisynth version: AviSynth 2.60, build:Sep 18 2013 [17:36:36]


[Clip info]
Number of frames: 500
Length (hhh:mm:ss.ms): 000:00:20.854
Frame width: 1920
Frame height: 1080
Framerate: 23.976 (24000/1001)
Interlaced: No
Colorspace: YV12


[Runtime info]
Frames processed: 500 (0 - 499)
FPS (min | max | average): 2.16 | 11.68 | 4.77
CPU usage (average): 12%
Thread count: 1
Physical Memory usage (peak): 467 MB
Virtual Memory usage (peak): 464 MB
Time (elapsed): 000:01:44.901

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

[General info]
Log file created with: AVSMeter 1.7.4 (AVS 2.6, x86)
Avisynth version: AviSynth+ 0.1 (r1576, x86)


[Clip info]
Number of frames: 500
Length (hhh:mm:ss.ms): 000:00:20.854
Frame width: 1920
Frame height: 1080
Framerate: 23.976 (24000/1001)
Interlaced: No
Colorspace: YV12


[Runtime info]
Frames processed: 500 (0 - 499)
FPS (min | max | average): 3.03 | 13.95 | 7.55
CPU usage (average): 12%
Thread count: 1
Physical Memory usage (peak): 485 MB
Virtual Memory usage (peak): 480 MB
Time (elapsed): 000:01:06.221

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

[General info]
Log file created with: AVSMeter 1.7.4 (AVS 2.6, x86)
Avisynth version: AviSynth+ 0.1 (r1595, x86)


[Clip info]
Number of frames: 500
Length (hhh:mm:ss.ms): 000:00:20.854
Frame width: 1920
Frame height: 1080
Framerate: 23.976 (24000/1001)
Interlaced: No
Colorspace: YV12


[Runtime info]
Frames processed: 500 (0 - 499)
FPS (min | max | average): 1.49 | 13.71 | 7.44
CPU usage (average): 12%
Thread count: 2
Physical Memory usage (peak): 330 MB
Virtual Memory usage (peak): 324 MB
Time (elapsed): 000:01:07.238

The second script I did was a bit of random calls to the Dither Package 1.24.0 on a 1080p blu ray rip I've been playing around with. I was just messing around with some resizing and a few basic filter calls on a 16bit stacked clip. Speed stayed basicly the same between all 3 builds in the 21fps range. The big story here is memory usage. 592MB for Alpha5, 714MB for r1576, and 146MB for r1595! :eek: I had to rerun that last one with my system monitor. 146MB is a massive improvement! It was also the fastest test run.

[Script]
LoadPlugin("D:\Installs\Media\Video Encoding\MeGUI_2050_x86\tools\ffms\ffms2.dll")
FFVideoSource("D:\Encodes\Kara no Kyoukai\5\Kara no Kyoukai 5.mkv", threads=1)
Trim(2788, 3938)
Dither_convert_8_to_16()
Dither_resize16(848, 480)
Dither_removegrain16()
Dither_SmoothGrad()
Dither_resize16(1920, 1080)
DitherPost()

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

[General info]
Log file created with: AVSMeter 1.7.4 (AVS 2.6, x86)
Avisynth version: AviSynth 2.60, build:Sep 18 2013 [17:36:36]


[Clip info]
Number of frames: 1151
Length (hhh:mm:ss.ms): 000:00:48.006
Frame width: 1920
Frame height: 1080
Framerate: 23.976 (24000/1001)
Interlaced: No
Colorspace: YV12


[Runtime info]
Frames processed: 1151 (0 - 1150)
FPS (min | max | average): 13.16 | 22.03 | 21.47
CPU usage (average): 27%
Thread count: 13
Physical Memory usage (peak): 592 MB
Virtual Memory usage (peak): 595 MB
Time (elapsed): 000:00:53.622

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

[General info]
Log file created with: AVSMeter 1.7.4 (AVS 2.6, x86)
Avisynth version: AviSynth+ 0.1 (r1576, x86)


[Clip info]
Number of frames: 1151
Length (hhh:mm:ss.ms): 000:00:48.006
Frame width: 1920
Frame height: 1080
Framerate: 23.976 (24000/1001)
Interlaced: No
Colorspace: YV12


[Runtime info]
Frames processed: 1151 (0 - 1150)
FPS (min | max | average): 2.86 | 23.25 | 21.33
CPU usage (average): 25%
Thread count: 13
Physical Memory usage (peak): 714 MB
Virtual Memory usage (peak): 716 MB
Time (elapsed): 000:00:53.966

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

[General info]
Log file created with: AVSMeter 1.7.4 (AVS 2.6, x86)
Avisynth version: AviSynth+ 0.1 (r1595, x86)


[Clip info]
Number of frames: 1151
Length (hhh:mm:ss.ms): 000:00:48.006
Frame width: 1920
Frame height: 1080
Framerate: 23.976 (24000/1001)
Interlaced: No
Colorspace: YV12


[Runtime info]
Frames processed: 1151 (0 - 1150)
FPS (min | max | average): 12.87 | 22.27 | 21.71
CPU usage (average): 26%
Thread count: 13
Physical Memory usage (peak): 146 MB
Virtual Memory usage (peak): 148 MB
Time (elapsed): 000:00:53.016

Besides the tests I ran. All I got to say is great job team with avs+! Barring any stability issues I might run into, I'm going to just keep using the experimental build from now on untill the next build comes along.

[Groucho2004]

My system is a FX8350 @4.4ghz with 8gb of ram @1600mhz running Win7 Pro x64. All builds of avs+ are x86. I ran 2 different scripts with AVSmeter 1.7.4.

The first script I ran was a test script Groucho2004 posted up a few pages back. Going from Alpha5 to avs+ r1576 was a 50% speed increase! I'm guessing this has more to do with the improved core filters than anything else. From r1576 to the new cache build r1595 was a bit of a head scratcher though. The overall speed dropped just a hair while a second thread was created. Is this supposed to happen? As far as the memory usage it dropped by 155MB. Very nice.
Comparing your numbers for the first script with my i5 2500K @ 4GHz:
Avisynth version: AviSynth 2.60, build:Sep 18 2013 [17:36:36]
FPS (min | max | average): 3.72 | 22.39 | 10.54 (+121%)

Avisynth version: AviSynth+ 0.1 (r1576, x86)
FPS (min | max | average): 4.53 | 26.45 | 13.06 (+73%)

Avisynth version: AviSynth+ 0.1 (r1595, x86)
FPS (min | max | average): 2.27 | 26.31 | 13.11 (+76%)

Memory usage was about the same. I did not expect Intel to be so much faster. However, this is just one script scenario and others may differ. Also, AVS+ optimizations seem to be a bit more AMD friendly. :)
One more note - The experimental DLL created 5 threads (well, 4 threads really, 1 is for the calling process, AVSMeter) in my case, not 2. Odd.

[innocenat]

Just a note , but none of the dev have AMD machine, thus most code are optimized for intel processors. Also, Sandy Bridge and later are insanely powerful.

[ryrynz]

Yeah, Intel completely dominates in this area, i7's with hyperthreading enabled using an MT build are most certainly king, I wouldn't buy an AMD machine for Avisynth processing, I highly doubt AMD's 8 cores
could even compete with most i5's let alone i7's and they'd use more energy to accomplish the same task too. That said, I wouldn't mind seeing a thread that compared various scripts on different processors so that would could make
more informed decisions on what hardware to buy.

[ultim]

DrZine, Groucho2004: Yes, those threads are normal. They are threadpool threads from the MT version, but in this particular build they just sleep/idle and do nothing, because this build is only meant to test the caches.

[BBA163]

When you can fix the avs+ load bug in megui or avspmod?
avspmod I try to change the licence ,but it's not work:scared:

[Zathor]

When you can fix the avs+ load bug in megui or avspmod?
avspmod I try to change the licence ,but it's not work:scared:
Can you please describe this avs+ load bug? At least I do not know it.

[Evil_Burrito]

Perhaps BBA163 is referring to, "An official release which will add support for 64-bit AviSynth+ is expected soon." As mentioned on the avisynth+ get started page.

Btw r1595 x86 has generally been working fine for me with avspmod and encoding. Mostly just a few cache_child errors from incompatible filters.

[tObber166]

Everytime I start up AvsPmod I get this error:

"Error parsing plugin string at position 0:"

It doesn't crash or anything, and all my plugins and filter work just fine.

AviSynthPlus-r1576

[DrZine]

The fix for that is here

http://forum.doom9.org/showthread.php?p=1648046#post1648046

[tObber166]

Thanks! ;)

[BBA163]

load avs in megui it's was crash:scared:
(My English is bad and reply was slow,sorry)

[innocenat]

load avs in megui it's was crash:scared:
(My English is bad and reply was slow,sorry)

Please provide more information: script used, etc.

[BBA163]

Just use ffvideosource,can you load avisynth+'s avs file in megui?
If you can…that's my problem

[Zathor]

Yes, I can load such avs files without any problems.

[ajp_anton]

What happened to index.htm in the documentation folder?

[ultim]

What happened to index.htm in the documentation folder?

MIA (by mistake).

ps.: Wow, there *are* some people reading the offline docs. Well good for you, it's about to get updated ;)

[BBA163]

So strange with my PC to load it…

[ultim]

So here is a small update on the status of the MT version of avs+. I'm planning on stabilizing this ASAP now, merging it to my usual main branch this week. This also means that all pull requests and even non-MT work will end up in an MT-enabled build from now on.

I spent most of my development time last weekend hunting down the source of some uninitialized memory, so I got somewhat delayed, but hopefully by the end of this week I'll publish a new experimental build, and for plugin developers most importantly, I'm also pushing the whole work to GitHub. There are only a couple of things left on my to-do list, with one exception (addressing a theoretical deadlock) just build- or performance enhancements.

A slight difference to previous plans is that I'm splitting the current threadpool into two, one for the core threads and one for filter-initiated threads. This is made necessary to avoid the previously mentioned theoretical deadlock, 'coz any other alternative (instead of the threadpool split) that comes to my mind would involve some sophisticated (and error-prone!) locking trickery with questionable benefits. The split will simplify code a lot compared to other fixes, and should not hurt performance.

It would be nice to have the new documentation ready by then, extended with all the Avs+ and new MT-specific stuff, so that interested developers could consult it at once, but that won't be done by this week for sure. That's because even though qyot has done most of the hard work on converting the docs format (oh Lord it's awesome), there is still some left to be done, and coupled with my other to-do items, the weekend just won't be enough.

One way you guys can help me to make MT usable as soon as possible now, is to help collect what MT modes existing filters need. The three supported MT modes are the same as for SEt's version, 1 - no protection needed at all, 2 - multiple filter instances per call (one per thread), and 3 - just one filter for all threads but protected by exclusive area. It'd be our collective interest to collect what each filter needs, or if there is maybe already a list like that, to extend/update it. The rules could ship with avs+ then to make it readily usable. So can I leave you to assemble this list? Maybe on a Wiki page?

Active plugin developers can include the rules for their filters inside their own plugin, so those do not need to be on the list. They will be able to start including the functionality as soon as I push the new avisynth.h this week. Moreover, they can do so while still staying compatible with classic (non-plus) Avs.

[innocenat]

Does this mean new plugin won't work with 2.6a5 anymore?

[ultim]

Does this mean new plugin won't work with 2.6a5 anymore?

It will be compatible. New plugins will still work with 2.6a5. The only limitation is that they will need a 2.6 header, so it won't work with 2.5.

[real.finder]

for me mode 2 work in 90% of filters, Especially in the last SEt builders, by now I use mode 2 only even with tdecimate 2pass vfr Which were not compatible in the past

Waiting for the new header and MT

thanks :)

[MasterNobody]

As I understand due to new way of auto loading plugins (pending them to the later time) avs_function_exists from C-interface fails to find out that DirectShowSource is available. This result in fail to open video files in x264 when you specify as input media file (any mkv file and --demuxer avs to be sure not to use lavf input) and not the avs script file. Is there is way to fix it from AviSynth+ side or what have to be added from x264 side so avs_function_exists will work?

[qyot27]

As I understand due to new way of auto loading plugins (pending them to the later time) avs_function_exists from C-interface fails to find out that DirectShowSource is available. This result in fail to open video files in x264 when you specify as input media file (any mkv file and --demuxer avs to be sure not to use lavf input) and not the avs script file. Is there is way to fix it from AviSynth+ side or what have to be added from x264 side so avs_function_exists will work?
It's actually failing to find any source filters, not just DirectShowSource.
>x264 --preset ultrafast --crf 18 -o test.mkv "Qyot27 - Daybreak [XviD+MP3].mkv" --frames 10 --demuxer avs --verbose
avs [debug]: using avisynth version 2.60
avs [info]: trying FFmpegSource2... not found
avs [info]: trying DSS2... not found
avs [info]: trying DirectShowSource... not found
avs [error]: unable to find source filter to open `Qyot27 - Daybreak [XviD+MP3].mkv'
x264 [error]: could not open input file `Qyot27 - Daybreak [XviD+MP3].mkv'

So I doubt it's related to the C-plugin autoloading (the copy of FFMS2 that failed is a C-plugin). Looking at avs_core/core/PluginManager.cpp, it seems to be under avsplus' new experimental IScriptEnvironment2 class. I think that's more likely to be the issue, but I don't know anything about C++.

[MasterNobody]

Looks like I found the way how to fix it from x264 side by adding invoke of AutoloadPlugins(): patch (http://privatepaste.com/faf965559d)

[ultim]

Avs+ autoloads plugins if any of the following happens:
- AutoloadPlugins() is called
- LoadPlugin() is called
- A yet unknown (non-internal) function is called

avs_function_exists does not find the external source filter in this case because none of the above happened. So MasterNobody's patch is the right thing to do.

[Gavino]

Avs+ autoloads plugins if any of the following happens:
- AutoloadPlugins() is called
- LoadPlugin() is called
- A yet unknown (non-internal) function is called

avs_function_exists does not find the external source filter in this case because none of the above happened. So MasterNobody's patch is the right thing to do.
How about having env->FunctionExists() (which is called by avs_function_exists) autoload plugins if a yet unknown function name is passed? Then it is transparent to client applications.

[ultim]

How about having env->FunctionExists() (which is called by avs_function_exists) autoload plugins if a yet unknown function name is passed? Then it is transparent to client applications.

Hmm, I didn't like the idea at first, but thinking about it some more, it does make sense. The fact that FunctionExists() never autoloads while a function call can do it means that it is possible to call functions for which FunctionExists() returned false. That is not only inconsistent, but it can be argued it is a bug.

On the other hand, the reason I'm not perfectly satisfied with FunctionExists() autoloading is because FunctionExists() has the semantics of a getter function. It is pretty unexpected that it changes the internal state greatly (even if we are talking about non-observable state). I have to conclude though that this rather ideological argument is outweighed by the proposed solution's practical relevance.

So I guess I will correct this in Avisynth+ after all.

[real.finder]

hi

I have two aWarpSharp in autoload folder, aWarpSharp and aWarpSharp2 by SEt

In normal avs if I use


LoadPlugin("C:\Program Files\AviSynth 2.5\plugins\aWarpSharp.dll")
someSource("E:\New.mkv")
aWarpSharp


green border will appear which mean that old aWarpSharp is using

but in avs+ only aWarpSharp2 will be used

I use this method in other cases also