Avisynth+

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

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

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]

Originally Posted by ultim

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]

Originally Posted by ryrynz

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. It also affects more filters than just those mentioned in the issue, many of them relatively popular.

[ultim]

Originally Posted by chainik_svp

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

Originally Posted by chainik_svp

this isn't all the truth

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]

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

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.

Originally Posted by chainik_svp

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

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]

Originally Posted by ultim

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]

Originally Posted by chainik_svp

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]

Originally Posted by ultim

One of the largest issues with Avs+ in MT mode is discussed in issue 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]

Originally Posted by ultim

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

Originally Posted by ultim

MT-enabled AviSynth+ triggers a latent bug in AvsPmod. Until a new version of AvsPmod is officially released, use this 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 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.