Avisynth+

[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
(My English is bad and reply was slow,sorry)

[innocenat]

Originally Posted by BBA163

load avs in megui it's was crash
(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]

Originally Posted by ajp_anton

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]

Originally Posted by innocenat

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]

Originally Posted by 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?

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

[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]

Originally Posted by 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.

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]

Originally Posted by Gavino

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