Avisynth+

[colours]

Creating a 257 GB AVI file just to verify this report would be somewhat difficult for the zero active Avisynth+ developers so don't expect any updates on this end.

Besides, this looks more like an FFmpeg issue. FFmpeg would be able to handle over a hundred million RIFF chunks if only one line (http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/avi.h;h=34da76f715145e976c596459202043b9831ec9e5;hb=HEAD#l32) was changed.

The OpenDML spec doesn't seem to indicate any upper bound on the number of chunks, but I didn't bother reading through it very carefully. It would be pretty weird if there was an artificial 256-chunk limit, though.

[mapg]

As you can see here, there is such limit in ffmpeg (libavformat/avienc.c) ...

if (avi->riff_id > AVI_MASTER_INDEX_SIZE) {
av_log(s, AV_LOG_ERROR, "Invalid riff index %d > %d\n", avi->riff_id, AVI_MASTER_INDEX_SIZE);
return AVERROR(EINVAL);
}Yes, it's certainly weird as none of the most professional video editing software packages add this unfortunate feature.

I will try to forward this issue to ffmpeg team, but I think that AviSynth+ should have a look at this too.

[qyot27]

AVISource relies on the VfW interface to do its parsing (and does so by using VirtualDub's parser, IIRC). If you can open it in VDub but not AviSynth+, then it's an AVISource issue that would need to be resolved by updating AVISource. While FFmpeg might have that limit, it would likely depend on the parser. The DirectShow AVI parser obviously wouldn't have a limit like that if DirectShowSource works. If VDub doesn't like it either, it's probably in VfW and there's little that can be done about it short of finding a third party AVI demuxer for VfW (but honestly, that's probably more trouble than it's worth).

[mapg]

I have tested the issue using FFMS2 and works well, namely there isn't any frozen image once AVI_MASTER_INDEX_SIZE (256GB) is reached.

Definitively the problem is in AVISource from Avisynth+

Mapg

[sl1pkn07]

great news (?)

since wine 1.7.25, can run Avsynth +r1689!

http://sl1pkn07.wtf/bleh56.png

only need in winecfg set msvcr110.dll and msvcp110.dll to 'native,built'

https://bugs.winehq.org/show_bug.cgi?id=17273#c61

greetings

[qyot27]

Also confirmed working with VC2013 builds (msvcp120.dll and msvcr120.dll).

But getting it working in Wine 1.7 requires the workaround I posted earlier (http://forum.doom9.org/showpost.php?p=1663971&postcount=525). Trying to install the 2012 and 2013 runtimes from vcredist_*.exe fails, requiring the user to make sure they get the DLLs themselves and install them (read: copy into system32). The built-in version errors out on the GetConcurrency function, but at least it can actually use the Microsoft runtimes now and operate.

[sl1pkn07]

I tried the 64bits version (with 'win64' winearch) and don't work. tested with 'Windows XP' and 'windows 7' mode

the 32bits only work in 'Windows XP' mode (see the capture avobe). but fail in 'Windows 7' mode

for installation (include vcredis 2012), first need set the wine with 'windows 7' mode, install avs+ r1689 from line0, then back to 'Windows XP' mode and set msvc{r,p}110.dll to native with winecfg

tested with 3 clean prefixes, wine only 32bits (winearch win32), wine only 64bits (winearch win64) and wine mixed (clear winearch variable)

the message is: failed to load avisynth.dll

greetings

[martin53]

I know similar questions have been asked in this forum more than once, but that was before AviSynth+, which released the tight doctrine a bit, and maybe less specific.

Is it possible in general (and worthwile...) that the gurus add a Dictionary element to the VideoInfo interface, together with methods to add and delete a key/item pair, and to get the item for a specific key, and also make the latter methods available to scripts?

Specifically, a pair of functions could then exchange information through this interface.

Say
function 1 prepares a 3d- or 16-bit, or certain colorspace frame so that a standard filter chain, which is older and not 100% compatible, can handle this clip. E.g. 3d side-by-side video could be cropped and interleaved, then processed as double frame rate 2d clip.
Function 2 stands at the end of the filter chain, and will automatically reverse the "tunneling", if it knows that there is need to. Some plugins used "hints" for that, i.e. manipulated certain pixel LSBs, etc; but this is not robust against filtering.

In my imagination, function 1 could call Add(clip, key, string) to add the dictionary entry (key,string) to the clip's VidoInfo, and this would be forwarded through the filter chain like the other clip properties.
Function 2 could call ExistsKey(clip, key), and/or GetKey(clip, key), which would signal, resp. return the string.
This could look like

#Assume Function1 calls MediaInfo to get information about the clip display ratio, which is not width:height ratio, i.e. nonsquare pixels
#Function1 gives the clip this freename property
AddKey("DisplayRatio", string(retrieved_display_ratio))

... #standard filter chain with unchanged width/height
... #deblocking and other filters need unstretched, uncropped input

#function2
GetKey(clip, "DisplayRatio")
\ ? BiCubicResize(...)
\ : last
#as the last filter in the chain, function2 sets the output width/height ratio in order to meet display ratio with square pixels
...
One more example to make it as clear as possible: There is a function 'ConvertBackToYUY2()' which should be used when the clip originally was converted from YUY2 to a different color space. It would be more elegant to attach the property that it was originally YUY2 to a clip - compared to today's script language limits.

EDIT: here (http://forum.doom9.org/showthread.php?p=1709612#post1709612) is another example for the usefulness of arbitrary clip properties ('tunneled' in this case)

[qyot27]

Time for a test build, I guess:

AviSynth+ r1718 (http://www.mediafire.com/download/f3egmdgdkwy8dmf/avisynthplus_r1718-20150301.7z)

Basically, I merged in most of the 22 commits that make up 2.6 RC1. Some are mostly applied 1:1 (including the 7 HTML docs commits), others are adapted (a couple of them heavily cut down from their original form). Four of the commits were outright rejected because they're irrelevant for AviSynth+.

This is also probably a better option than continuing to rely on r1689, since there were some MT fixes applied after r1689.


Built with Visual Studio 2013, and it includes both 32-bit and 64-bit .dlls (no 64-bit DirectShowSource because I didn't feel like trying to get the SDKs lined up first). Note that I do not have access to a 64-bit Windows install, so those of you that do, please confirm that the 64-bit .dlls work.

[burfadel]

Thanks, been looking forward to an update!

However, the download doesn't work. It tries to download then fails (tried different browsers). Any chance of another mirror?

EDIT:
Kept trying, then Mediafire showed the 'repair download' screen. After that it worked.

[ultim]

All changes from 2.6rc1 have been pulled into AviSynth+. Normally I would publish a new build, but qyot has already done so and there are only very insiginifcant differences to his build. I will now look at the memory leak reported by chainik and the audio issue. At that point Avs+ will be good to go for a new official release that is stable in single-threaded mode. I still wouldn't recommend the MT-modes for production, but everything else should be alright. And of course, anything else you find, report it, so that it can be fixed timely. Sorry for the hiatus.

[nixo]

Excellent news, thank you.

@qyot27
The 64-bit .dlls work fine for me. Thanks!

[Sparktank]

This is intriguing news, indeed!

Great work, guys.

[aegisofrime]

All changes from 2.6rc1 have been pulled into AviSynth+. Normally I would publish a new build, but qyot has already done so and there are only very insiginifcant differences to his build. I will now look at the memory leak reported by chainik and the audio issue. At that point Avs+ will be good to go for a new official release that is stable in single-threaded mode. I still wouldn't recommend the MT-modes for production, but everything else should be alright. And of course, anything else you find, report it, so that it can be fixed timely. Sorry for the hiatus.

Great news, good to see you back! I have been holding off on switching to Avisynth 2.6 because of how well Avs+ works for me!

[burfadel]

Do the crashes only affect when using MT? I don't use that. I have been using the 1718 build without issue. This includes a backlog of stuff I wanted to encode, so encoding dozens of shows (with very 'tight' x264 settings etc) over the last couple of days, non-stop. Haven't had any issues :).

[jpsdr]

At that point Avs+ will be good to go for a new official release that is stable in single-threaded mode.
Thanks, and it's nice to see you back.

[ryrynz]

I just wanna see something that can actually replace SEt's MT builds :P
Welcome back to the land of development.

[ultim]

I just wanna see something that can actually replace SEt's MT builds :P
Welcome back to the land of development.

One of the largest issues with Avs+ in MT mode is discussed in issue 37 (http://github.com/AviSynth/AviSynthPlus/issues/37). It also affects more filters than just those mentioned in the issue, many of them relatively popular.

[ultim]

[for every frame]
{
VideoFrame *frame = it->second;
if (frame->vfb->refcount == 0)
delete frame->vfb;

delete frame;
}

why "if (frame->vfb->refcount == 0)" ??
vfb->refcount decremented in VideoFrame destructor so it can be (and it IS) >0
and ~VideoFrame doesn't delete vfb but just releases it

=====
Fixed it, see https://github.com/AviSynth/AviSynthPlus/issues/49

Is there any chance to include this fix to the main branch and release a new official build?

It's not that simple. As you see, in that loop all frames get deleted. Each such deletion of a VideoFrame will decrease the refcount on the corresponding vfb. Since vfb's are only referenced by VideoFrames, when the last VideoFrame referencing that vfb gets deleted, the condition with "(frame->vfb->refcount == 0)" will get triggered and the vfb will get deleted too. Hence after enough VideoFrames have been deleted, eventually the vfb will too, even if the "zero-condition" wasn't true at first.

The proposed solution in the issue tracker won't work well. You cannot delete the vfb every time a VideoFrame is destroyed, because due to subframes, vfbs can be shared among multiple VideoFrames. Of course you could check for the zero-refcount-condition and only delete it when no one else is using it, but that is basically what the ScriptEnvironment's destructor is already doing, except your proposed solution would destroy caching the vfbs, negatively affecting performance.

EDIT: You might probably be thinking, because the refcount is decremented in VideoFrame's destructor, if I want to check for the last reference, I should be checking for refcount==1 instead of refcount==0. The reason this is not the cases, is because all explicit references to VideoFrames will be released along the destruction of the filter chain. Because releasing a videoframe will also decrement the associated vfb's refcount, vfb refcounts will decrement to zero (except for those used by subframes) even before the videoframes are destructed. So to sum it up, the error that you are making is to assume that vfb::Release is only called in VideoFrame's destructor.

[ultim]

this isn't all the truth :D

if the filter was instantiated - it'll never be deleted...

in other words if you'll write some filter doing something like this:

SomeFilter::SomeFilter()
{ buffer = new BYTE[1000000000]; }

SomeFilter::~SomeFilter()
{ delete[] buffer; }

than you'll end with 1 GB of memory stolen cause it'll never be freed :)

Not quite true. Filters are only referenced by each other, except for the top-level clip, which is referenced by the hosting application. Hence when the host application releases his own filter reference (PClip), that will trigger the destruction of the whole filter chain (when a filter's reference reaches zero, it gets deleted as per IClip::Release). In the end every filter will be destroyed.

This is also true about the other supposed "problem" you have found about not destroying the Prefetcher. The Prefetcher is just a filter, so it also get destroyed during the destruction of the filter chain, as explained above. Sure, ScriptEnv also has a reference to it, but it never incremented its refcount, so this extra reference won't prevent its timely destruction when the host app releases the chain.

To sum it, I see no memory leak yet in any of the three cases you have documented so far. Please elaborate more if you think I have missed something.

[chainik_svp]

ultim
I believe theory is great :)

But how many times in real life you actually checked what is going on at script destruction?
I know it's not a usual case. Most people will never face any problems related to script destruction.

BUT it's important for real-time processing inside ffdshow when AVS script can be reloaded many times while watching the same movie.
It isn't very hard to make SVP "compatible" with AVS+. If you're interested I can share a few files (actually it's just one file) to make it work.
As an alternative you can just write any simplest script inside ffdshow and check and uncheck "avisynth" checkbox.

And the truth is every script reloading with AVS+ makes visible step in the Task manager's memory usage graph.
So the memory _is_ leaking. And after my fix it is not.

I'm not telling the fix is 100% correct, but at least it can point you to the right direction.

But if you insist I can point you to exact lines of code that break your theory ;)

In fact there's no point for arguing, just try it yourself :)

[ultim]

ultim
I believe theory is great :)

But how many times in real life you actually checked what is going on at script destruction?
I know it's not a usual case. Most people will never face any problems related to script destruction.

BUT it's important for real-time processing inside ffdshow when AVS script can be reloaded many times while watching the same movie.
It isn't very hard to make SVP "compatible" with AVS+. If you're interested I can share a few files (actually it's just one file) to make it work.
As an alternative you can just write any simplest script inside ffdshow and check and uncheck "avisynth" checkbox.

And the truth is every script reloading with AVS+ makes visible step in the Task manager's memory usage graph.
So the memory _is_ leaking. And after my fix it is not.

I'm not telling the fix is 100% correct, but at least it can point you to the right direction.

But if you insist I can point you to exact lines of code that break your theory ;)

In fact there's no point for arguing, just try it yourself :)

I think you misunderstand me. I'm not saying there is no memory leak. In fact, I have also seen memory leaking myself. I'm just saying it has other reasons than the ones you explained. I am still trying to pinpoint the exact reason though.

But how many times in real life you actually checked what is going on at script destruction?
LOL, you think all I do is make up theories? Believe me when I say I checked it in multiple scenarios. I know something is leaking, I was just saying the problem is not what you think it is.

[chainik_svp]

ultim
I was just saying the problem is not what you think it is

Yeah, ok, whatever :D

Last time I was heard this - I was forced to go deep into Avisynth code and make my own build, with completely replaced 'distributor' and modified cache.
And I really don't want to go into this [shit] one more time.

If you can make AVS+ useful - that would be great, cause I really like how it works with the memory and with CPU threads in MT version.

But now isn't useful at all :(

[chainik_svp]

To sum it, I see no memory leak yet in any of the three cases you have documented so far. Please elaborate more if you think I have missed something.

Is it enough to put additional printf in my filters's destructor and see that it was never called?
Or may be put that printf into ~Prefetcher() ?

[ultim]

But if you insist I can point you to exact lines of code that break your theory ;)

The .avs script that is leaking memory and a part of the source video (some frames of it but with same compression and video format) should help a lot to reproduce. With simple scripts I tested, there are no leaks ATM, so I will probably need to use the same filters as you do to see it.

[jmac698]

- Script language extensions, with support for multiline conditionals and loops.
This is something I've always wondered about. Where is it documented? Can you give an example of these new script commands? Is it something like gscript?

Also, is there any need to use official avisynth now? If not, have the two authors considered a merge?

[ryrynz]

One of the largest issues with Avs+ in MT mode is discussed in issue 37 (http://github.com/AviSynth/AviSynthPlus/issues/37). It also affects more filters than just those mentioned in the issue, many of them relatively popular.

What are the options? Not professing to know anything about the issue but can you just do whatever AvisynthMT does? Or use a compatibility list and address specific requirements for the filters based on that?

My thoughts are as long as the solution provides at least the same performance as AvisynthMT it's a win regardless of how hacky it may seem.

[martin53]

latest release: 2014. Jan. 02.
avisynth+ features for users
[…]
- support for multiple ("shadow") plugin directories
- autoloading of c-plugins
- script language extensions, with support for multiline conditionals and loops.
- improved still image support and timestretch
[…]
compatiblity to avisynth
avisynth+ tries to provide a superset of avisynth's features while staying compatible to existing code […]


I feel sorry to ask this question here, since from quick reading the thread, it becomes clear that there was (and hopefully is) put much effort in this creditable modernization.

That said, my question is: where is the documentation of the cited new features? I may be too stupid to find it. After Avisynth+ install, I compared the doc folder trees with BeyondCompare and can only find same docs, or files where AviSynth 2.6 is more up to date (even if Avisynth+ file date is newer!). The folder 'german' should be renamed 'french', or better removed, if it is neither complete nor updated. Also, I found nothing on the homepage (http://avs-plus.net/) and at most hints in this thread.

EDIT: reading my own text, I feel I should maybe offer to contribute. Would that be welcome, even at a low level, and which prerequisites do I need (e.g. I din't have experience with git)?

[martin53]

MT-enabled AviSynth+ triggers a latent bug in AvsPmod. Until a new version of AvsPmod is officially released, use this (http://files.line0.in/builds/AvsPmod-2.5.1-r426-x86-04874ed.7zl) build. A thousand thanks to vdcrim for the fix.
Unfortunately, the file does no longer exist. Can it please be published again?

EDIT 2015-03-09: link updated in original post, and also here

[martin53]

With both the r1576 and the r1718 build as x86 under a X64 windows 7, this function lister script (http://forum.doom9.org/showthread.php?p=1712503#post1712503) freezes after debug output 'ImageSeq_ImageWriter', even if call to all ImageSeq_ functions is avoided. Maybe the following function doesn't even like to be checked by RT_PluginFunctions().
With the given set of pre-captured (i.e. not called) functions (line #58 ff), the same script runs fine with Avisynth 2.6 ST and MT.

Supplement: Avisynth 2.6 MT shows GetMTMode and SetMTMode as internal functions. With Avisynth+ I don't see them in the list.

[ultim]

This is something I've always wondered about. Where is it documented? Can you give an example of these new script commands? Is it something like gscript?

It is mostly like GScript. In fact, GScript has been used as the starting point for the implementation in Avs+, and changes compared to GScript are not visible to the user (e.g. only important for Avs+ core developers). Two notable differences are between GScript and Avs+:

In Avs+ there is no need to use GScript(""" and """) to encompass your GScript-specific code parts. The language extensions became native to Avs+ and can be used transparently like classic Avisynth syntax.
The "return" statement has been slightly changed to not only exit the inner-most code block, but to terminate the whole function (or script), as anybody with even the slightest scripting experience would expect. This is one of the very few incompatible changes compared to classic Avisynth.


Also, is there any need to use official avisynth now?
Even though the many changes, Avisynth+ is still highly compatible to classic Avisynth, with respect to both scripts and plugins - with only very few exceptions. Unless you find a bug in Avisynth+ that isn't there in Ianb's version, you should be able to use Avs+ as a complete replacement for Avs. If you do find a bug in Avs+ that is unique to it, I'd be happy if you reported it so that we can fix it, instead of just silently switching back to the old Avs.

If not, have the two authors considered a merge?
A proposed merge was the first thing Avs+ has started out as. Only after it failed did Avs+ become a separate project. Communication with "upstream" went south early in the beginning, and I am to blame too. Nevertheless, upstream has been unresponsive since then even while we were trying to contribute, so I guess a full-blown merge is pretty much out of the question as things are right now.

[ultim]

What are the options? Not professing to know anything about the issue but can you just do whatever AvisynthMT does? Or use a compatibility list and address specific requirements for the filters based on that?

My thoughts are as long as the solution provides at least the same performance as AvisynthMT it's a win regardless of how hacky it may seem.

Various options are being considered of course, each with their own advantages. MT is not forgotten, but I do admit I am currently focusing on the single-threaded scenario for the next release. MT will have to wait until then. Due to all the historic baggage Avisynth has, it is very hard to introduce invasive changes like MT correctly without breaking old stuff.

[ultim]

I feel sorry to ask this question here, since from quick reading the thread, it becomes clear that there was (and hopefully is) put much effort in this creditable modernization.

That said, my question is: where is the documentation of the cited new features? I may be too stupid to find it. After Avisynth+ install, I compared the doc folder trees with BeyondCompare and can only find same docs, or files where AviSynth 2.6 is more up to date (even if Avisynth+ file date is newer!). The folder 'german' should be renamed 'french', or better removed, if it is neither complete nor updated. Also, I found nothing on the homepage (http://avs-plus.net/) and at most hints in this thread.

Nah, it's really not your fault. There is no centralized documentation so far. All features have been documented in this thread as they were released (some from the start might also be in the classic Avisynth thread), but people are - very unfortunately - left to find these posts on their own. So it is not your fault. At one point we will have to collect all these scraps of information, make proper html of it, and ship it as part of the documentation in the installer. That would be ideal, but nobody yet took the time for it. Me too, I'd rather code, fix bugs and introduce new features, than spend hours on documenting - bad habit for most programmers.

This is an area where non-programmers among you could help out (writing docs), and these contributions too would be more than welcome.

[martin53]

[...]documentation[...]is an area where non-programmers among you could help out (writing docs), and these contributions too would be more than welcome.

Your response overlapped with my edit. Could you please post a guide what to install and how to merge the edits - probably with git, like the sources itself?

[ultim]

Unfortunately, the file does no longer exist. Can it please be published again?

I now updated the link in the original post. Please try again and thanks for letting me know.

[chainik_svp]

ultim
The .avs script that is leaking memory and a part of the source video (some frames of it but with same compression and video format) should help a lot to reproduce. With simple scripts I tested, there are no leaks ATM, so I will probably need to use the same filters as you do to see it.

You won't see those leaks while running any script.
http://forum.doom9.org/showthread.php?p=1697682#post1697682
enter simple script into ffdshow:
SetFilterMTMode("",2)
SetFilterMTMode("ffdShow_source",3)
ffdShow_source()
BilinearResize(3000,1500)
BilinearResize(1920,1080)
Prefetch(10)


and then just check and uncheck "Avisynth" check box while looking at Task Manager memory graph

[ultim]

With both the r1576 and the r1718 build as x86 under a X64 windows 7, this function lister script (http://forum.doom9.org/showthread.php?p=1712503#post1712503) freezes after debug output 'ImageSeq_ImageWriter', even if call to all ImageSeq_ functions is avoided. Maybe the following function doesn't even like to be checked by RT_PluginFunctions().
With the given set of pre-captured (i.e. not called) functions (line #58 ff), the same script runs fine with Avisynth 2.6 ST and MT.

Created ticket, and will look at it soon:
https://github.com/AviSynth/AviSynthPlus/issues/55

Supplement: Avisynth 2.6 MT shows GetMTMode and SetMTMode as internal functions. With Avisynth+ I don't see them in the list.
That is normal. GetMTMode() ans SetMTMode() are not part of Avisynth+, as Avisynth+ uses other functions to achieve multithreading.

[ultim]

Your response overlapped with my edit. Could you please post a guide what to install and how to merge the edits - probably with git, like the sources itself?

I will try to today, give me some time.

[jmac698]

Ultim,
Thanks for your response. It is good news. I remember I hesitated at first to use GScript because it required an extra plugin, but I thought it should be added to Avisynth anyhow. Now my wish has come true :)

[qyot27]

After Avisynth+ install, I compared the doc folder trees with BeyondCompare and can only find same docs, or files where AviSynth 2.6 is more up to date (even if Avisynth+ file date is newer!). The folder 'german' should be renamed 'french', or better removed, if it is neither complete nor updated. Also, I found nothing on the homepage (http://avs-plus.net/) and at most hints in this thread.

EDIT: reading my own text, I feel I should maybe offer to contribute. Would that be welcome, even at a low level, and which prerequisites do I need (e.g. I din't have experience with git)?
That would be an installer issue if the French docs are being put in the German folder. In the source tree, the German docs are in the German folder.

There shouldn't be any cases where 2.6's docs are more up-to-date than avsplus'. If you're comparing r1576 to 2.6 RC1, then there's an obvious reason: r1576 is from December 2013. The docs changes that were part of RC1 (7/22 of the commits that comprise the difference between Alpha 5 and RC1) were merged to avsplus' Git repository with the rest of the RC1 integration about a week ago.

[ultim]

With both the r1576 and the r1718 build as x86 under a X64 windows 7, this function lister script (http://forum.doom9.org/showthread.php?p=1712503#post1712503) freezes after debug output 'ImageSeq_ImageWriter', even if call to all ImageSeq_ functions is avoided. Maybe the following function doesn't even like to be checked by RT_PluginFunctions().
With the given set of pre-captured (i.e. not called) functions (line #58 ff), the same script runs fine with Avisynth 2.6 ST and MT.

I can run the script to the end just fine, both with GScript as well with the native language syntax in Avs+. For reference, here is my output (http://pastebin.com/UVVH9zx6). So I guess it really has to do something with that specific plugin that "doesn't like to be checked", at least not in combination with Avs+. Can you figure out which plugin it is? Then send me the plugin please so that I can investigate further.

Edit: As a side note, your script doesn't work well perfectly if some functions have the same name but different argument list. In that case it will always list the same variant. That is the same though under classic Avisynth too, not specific for Avs+ .

[ultim]

That would be an installer issue if the French docs are being put in the German folder. In the source tree, the German docs are in the German folder.

Actually, I've been meaning to remove non-english docs. They are out of date anyway, and it is unlikely they will ever have the same kind of maintenance as the english docs.

[qyot27]

Actually, I've been meaning to remove non-english docs. They are out of date anyway, and it is unlikely they will ever have the same kind of maintenance as the english docs.
That works too. Users can always consult the avisynth.ru docs mirror, or the Wiki on avisynth.nl (which would also be a reason to slice the externalfilters/ stuff out of the English docs, or at least spin the RST versions of them off into a separate repository).

[martin53]

I can run the script to the end just fine [...] Can you figure out which plugin it is? [...]
I'll gladly do, just working on it.

Edit: As a side note, your script doesn't work well perfectly if some functions have the same name but different argument list. In that case it will always list the same variant. That is the same though under classic Avisynth too, not specific for Avs+ .

Interesting. I always wondered why identical function_parameter lines appeared more than once. If Groucho2004 extended the AVSInfoTool to display the parameter lists, we'd probably know if it's a bug in AviSynth or in RT_Stats. Actually, I re-included a check that prevents similar lines also for internal functions, not only for plugins (updated my post in RT_Stats thread) though I understand it would be better to list the functions with their multiple parameter lists.

[martin53]

Can you figure out which plugin it is?
The behavior appears to be non reproducible. List diff here (http://www.mediafire.com/download/scsyp3fhbbc3fio/AllFunctionsDiffReport.html.zip).
I installed Avisynth+ r1576 again (previously had done an uninstall that reactivated 2.6 MT) and ran the script with freeze once in AvsPmod. Then looked into the script to could add another RT_DebugF() output and then noticed that's nonsense because all functions are retrieved at once into a string and the current debug output is just in the right place. After that, I ran the script successfully several times in AvsPmod and once in VDub portable. But freeze after "F2" in VDub. Next time again freeze in AvsPmod, when defreq_DeFreq was called. This was also the freezing plugin in the first run.
An explanation why it differs from my ealier post is that I then listed the plugins in reverse order (so the line 'plugin_function' comes first and I can reject the similar line 'function' without 'plugin_' prefix). Meanwhile I changed the rejection method and can also reject 'function' if it comes before 'plugin_function'.

EDIT: Reproduced freeze during DeFreq (http://avisynth.org.ru/defreq/defreq.html)call. %PATH% includes AviSynth plugins directory (which is actually a NTFS symbolic link to another partition so I include it in the backup of that partition) and Defreq-required FFTW3.dll with date 06-21-2010 and 1.46MB is there.
But after DeFreq is removed, AvsPmod freezes in DePanEstimate.
I get more and more the feeling that it is a string/memory issue, not a plugin issue. Changed the script accordingly to following code, now always freezes. As it seems, all my FFT plugins trigger it. I remove one, the next one triggers the freeze. My suspicion is they allocate much memory, but why is that not either succesful or fails with an error, but instead enters an endless loop?
Try {RT_Version()} catch (msg) {assert(false,"This script requires the RT_Stats plugin.")}
Try {GEval("")} catch (msg) {assert(false,"This script requires the GScript plugin.")}

#============================================================================
Filename=RT_FSelSaveAs(title="Save Filter list",dir="",filt="Text files|*.txt",fn="_AllFunctions.txt",debug=true)
Assert(FileName.IsString(), "Please provide a file name to save the filter list")

#============================================================================
RT_WriteFile(Filename, VersionString(), Append=false)
#WriteInternalFunctionsSyntax(RT_InternalFunctions(), Filename)
WritePluginFunctionsSyntax(RT_PluginFunctions(), Filename)
WritePluginFunctionsSyntaxBackward(RT_PluginFunctions(), Filename)
WritePluginFunctionsSyntax(RT_PluginFunctions(), Filename)
WritePluginFunctionsSyntaxBackward(RT_PluginFunctions(), Filename)
BlankClip().subtitle("Function info is complete.",align=5)

#============================================================================
function WriteInternalFunctionsSyntax(string fu_list, string Filename) {
GScript("""
done=""
while(fu_list != "") {
i = FindStr(fu_list+" ", " ")
fu_name = LeftStr(fu_list, i-1)
fu_list = MidStr(fu_list, i+1)
params = RT_PluginParam(fu_name)
if (FindStr(done, fu_name+params)==0) {
done = done + " "+fu_name+params
RT_WriteFile(Filename, "internal %s ( %s ) -> %s", fu_name, params, GetReturnType(fu_name, params), Append=true)
}
}
""")
}
#============================================================================
function WritePluginFunctionsSyntax(string fu_list, string Filename) {
GScript("""
done=""
while(fu_list != "") {
i = FindStr(fu_list+" ", " ")
fu_name = LeftStr(fu_list, i-1)
fu_list = MidStr(fu_list, i+1)
i = FindStr(fu_name, "_")
if (i>0) {
params = RT_PluginParam(fu_name)
if (FindStr(fu_list, "_"+fu_name)==0 && FindStr(done, "_"+fu_name+params)==0) {
done = done + " _"+fu_name+params
RT_WriteFile(Filename, "plugin %s ( %s ) -> %s", fu_name, params, GetReturnType(fu_name, params), Append=true)
}
}
}
""")
}
#============================================================================
function WritePluginFunctionsSyntaxBackward(string fu_list, string Filename) {
GScript("""
done=""
fu_list = RevStr(fu_list)
while(fu_list != "") {
i = FindStr(fu_list+" ", " ")
fu_name = RevStr(LeftStr(fu_list, i-1))
fu_list = MidStr(fu_list, i+1)
i = FindStr(fu_name, "_")
if (i>0) {
params = RT_PluginParam(fu_name)
if (FindStr(fu_list, "_"+fu_name)==0 && FindStr(done, "_"+fu_name+params)==0) {
done = done + " _"+fu_name+params
RT_WriteFile(Filename, "plugin %s ( %s ) -> %s", fu_name, params, GetReturnType(fu_name, params), Append=true)
}
}
}
""")
}
#============================================================================
#function GetReturnType(string fu, string params) { return "?" }
#============================================================================
function GetReturnType(string fu, string params) {
GScript("""
RT_DebugF("Fu=%s %s", fu, params, name="GetReturnType")
if (MidStr(fu,3,1)=="+") {fu = LeftStr(fu,2)+MidStr(fu,2)}
if (MidStr(fu,2,1)=="+") {fu = LeftStr(fu,1)+fu}
else if (fu=="Assert") {return "conditional halt"}
else if (FindStr(fu, "avss_26_DSS2")>0) {return "clip"}
else if (FindStr(fu, "ImageSeq_")>0) {return "clip"}
else if (FindStr(fu, "LoadCPlugin")>0) {return "void"}
else if (FindStr(fu, "LoadVirtualdubPlugin")>0) {return "void"}
else if (FindStr(fu, "MDepan")>0) {return "clip"}
else if (FindStr(fu, "MSCDetection")>0) {return "clip"}
else if (FindStr(fu, "ResampleAudio")>0) {return "clip"}
else if (FindStr(fu, "Resize")>0) {return "clip"}
else if (FindStr(fu, "RT_Debug")>0) {return "clip"}
else if (FindStr(fu, "RT_FSel")>0) {return "."}
else if (FindStr(fu, "Source")>0) {return "clip"}
else {
bc = BlankClip(width=8,height=8,length=1,pixel_type="YV12")
fp = LeftStr(params,2)=="cc" ? "(bc,bc)"
\ : LeftStr(params,2)=="cf" ? "(bc,0.1)"
\ : LeftStr(params,3)=="cci" ? "(bc,bc,0)"
\ : LeftStr(params,5)=="ciiii" ? "(bc,0,0,0,0)"
\ : LeftStr(params,4)=="ciii" ? "(bc,0,0,0)"
\ : LeftStr(params,3)=="cii" ? "(bc,0,0)"
\ : LeftStr(params,2)=="ci" ? "(bc,0)"
\ : LeftStr(params,1)=="c" ? "(bc)"
\ : LeftStr(params,2)=="ff" ? "(0.1,0.1)"
\ : LeftStr(params,1)=="f" ? "(0.1)"
\ : LeftStr(params,2)=="ii" ? "(0,0)"
\ : LeftStr(params,1)=="i" ? "(0)"
\ : LeftStr(params,2)=="ss" ? "("+chr(34)+"1"+chr(34)+","+chr(34)+"1"+chr(34)+")"
\ : LeftStr(params,2)=="si" ? "("+chr(34)+"1"+chr(34)+",1)"
\ : LeftStr(params,1)=="s" ? "("+chr(34)+"1"+chr(34)+")"
\ : "()"
Try {
r = Eval("current_frame=0 "+fu+fp)
r = r.IsBool ? "bool" : r.IsClip ? "clip" : r.IsInt ? "int" : r.IsFloat ? "float" : r.IsString ? "string" : "?"}
catch (msg) { Try {r = r.IsBool ? "bool" : r.IsClip ? "clip" : r.IsInt ? "int" : r.IsFloat ? "float" : r.IsString ? "string" : "?" } catch(msg) {r = "?"}
}
if (r=="?") {
bc = BlankClip(width=8,height=8,length=1,pixel_type="RGB32")
fp = LeftStr(params,2)=="cc" ? "(bc,bc)"
\ : LeftStr(params,2)=="cf" ? "(bc,0.1)"
\ : LeftStr(params,3)=="cci" ? "(bc,bc,0)"
\ : LeftStr(params,5)=="ciiii" ? "(bc,0,0,-0,-0)"
\ : LeftStr(params,4)=="ciii" ? "(bc,0,0,0)"
\ : LeftStr(params,3)=="cii" ? "(bc,0,0)"
\ : LeftStr(params,2)=="ci" ? "(bc,0)"
\ : "(bc)"
Try {
r = Eval("current_frame=0 "+fu+fp)
r = r.IsBool ? "bool" : r.IsClip ? "clip" : r.IsInt ? "int " : r.IsFloat ? "float" : r.IsString ? "string" : "?"
} catch (msg) {
r = "?"
}
}
if (r=="?" && LeftStr(params,1)=="c") {r="clip?"}
return r
}
""")
}

[Wilbert]

or the Wiki on avisynth.nl (which would also be a reason to slice the externalfilters/ stuff out of the English docs
Will move them out.

[ultim]

Your response overlapped with my edit. Could you please post a guide what to install and how to merge the edits - probably with git, like the sources itself?

Exactly, with Git, just like you would handle the source itself. Actually, Git doesn't (and cannot really) differentiate between sources and docs at all.

First, you'll need a GitHub account. Then get GitHub for Windows (https://windows.github.com/), which will be your offline GUI to Git. Then you just follow this (https://guides.github.com/activities/forking/) process while editing the docs with your text editor/html-viewer. If you will be working on the docs and not on the sources, there aren't any more tools you'll need.

[ultim]

Changed the script accordingly to following code, now always freezes.

I checked the new script. True this one "freezes", more exactly it keeps running forever by never stopping to output. It outputs all functions A-Z, then backwards Z-A, then again A-Z, then Z-A, and seems to keep on doing this forever. Judging by this regular output pattern, are you sure it is not a bug in your script? See output here (http://pastebin.com/6Svj5TnL).

Edit: After letting it run loooong enough, it actually finished execution! Is it normal to output everyhting A-Z-A-Z-A a couple of time?

[ultim]

You won't see those leaks while running any script.
http://forum.doom9.org/showthread.php?p=1697682#post1697682

I tried it now with ffdshow (http://sourceforge.net/projects/ffdshow-tryout/?source=typ_redirect)(in MPC-HC) and your script. Only difference is I used 5 instead of 10 threads as I have a 4-core CPU. Toggled the AviSynth-option in ffdshow on and off at least a dozen of times, and memory consumption was always about 330Mbytes in task manager when switched on. Said differently, I see no obvious memory leak.

I looked at the date when you originally reported this, and it was in oct.2014. Given that the last release is from 2013, I think this bug might have been corrected since then. There has been a LOT of fixes since that release, and it would explain why you see this bug and I don't. Anyway, I'll publish a new test binary of Avs+ in a couple of days, and let me know if the problem still pertains.

[Octo-puss]

Oh the development is back. Very nice!