Avisynth+

[turbojet]

No, we didn't touch it. How much slower and what's the test script/source?

Nevermind, dss itself isn't slower.


Filters that cannot be multithreaded efficiently won't magically become threaded. TDecimate is one of the most complex cases and it most likely won't benefit much if at all.

TDecimate's developer has said a few lines of openmp (what nnedi3 uses) might work but maybe it was tried without luck.

[TurboPascal7]

TDecimate's developer has said a few lines of openmp (what nnedi3 uses) might work but maybe it was tried without luck.
Nnedi3 does not use openmp, eedi3 does. In any case it does not have anything to do with the core since openmp usage is an implementation detail of a particular plugin. The core will only provide frame-level threading plus maybe some thread pool api just like avstp does.

[ultim]

LSFMod script which is here : http://forum.doom9.org/showthread.php?t=142706

Video is anything (using in conjunction with ffdshow raw as post processing filter, no other settings checked in ffdshow raw, just avisynth)

Cheers ;-)

I already checked LSFMod right after your initial report and it worked without problems. I asked for a complete script and video in the hope of maybe reproducing the problem that way. If uploading the video is not an option, at least tell me your exact video resolution and color space (and full script ofc).

[Groucho2004]

Here (http://www.mediafire.com/download/9jqpn1748qvm9nw/AVSMeter173_x64.rar) is a 64 Bit version of AVSMeter to be used with Avisynth+ 64 Bit. Unfortunately, I only have 4G of RAM so I could not test it beyond that. For you guys with 8, 16 or even 32 G - have a go and let me know if the memory usage that it reports is correct.
A script like this:
setmemorymax(8000)
n = 10000
colorbars(width = n, height = n, pixel_type = "yv12").killaudio().assumefps(24000, 1001)

spline36resize(width() - 64, height() - 64).turnleft()
spline64resize(width() + 64, height() + 64).turnright()

temporalsoften(4,4,8,15,2)
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)

should make Avisynth use plenty of memory if you increase "n" to 15000 or more.

[real.finder]

Here (http://www.mediafire.com/download/9jqpn1748qvm9nw/AVSMeter173_x64.rar) is a 64 Bit version of AVSMeter to be used with Avisynth+ 64 Bit. Unfortunately, I only have 4G of RAM so I could not test it beyond that. For you guys with 8, 16 or even 32 G - have a go and let me know if the memory usage that it reports is correct.
A script like this:
setmemorymax(8000)
n = 10000
colorbars(width = n, height = n, pixel_type = "yv12").killaudio().assumefps(24000, 1001)

spline36resize(width() - 64, height() - 64).turnleft()
spline64resize(width() + 64, height() + 64).turnright()

temporalsoften(4,4,8,15,2)
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)

should make Avisynth use plenty of memory if you increase "n" to 15000 or more.

nice :)

I'll try it as soon as I receive the new server with 16G ram :)

and I will start with the real encoding

thank you :)

[Wilbert]

- tp7 and innocenat have finished porting all built-in filters to compiler intrinsics.
Just curious. I don't know much about compiler intrinsics. Why compiler intrinsics instead of yasm, nasm or softwire? Can you use those compiler intrinsics on other platforms (once the porting is done)?

[TurboPascal7]

Just curious. I don't know much about compiler intrinsics. Why compiler intrinsics instead of yasm, nasm or softwire? Can you use those compiler intrinsics on other platforms (once the porting is done)?

Just read part 5 of the second guide on this page (http://www.agner.org/optimize/). It has a nice list of pros and cons of using intrinsics. In short: more portable, easier to write and support, but you don't have the full control over your asm (like instruction ordering or register allocation), which means lower possible performance in the best case. In general though, you'll be getting better performance unless you really know what you're doing and prepared to spend hours and hours for optimizing your external asm code.

[TheFluff]

Intrinsics was a terrible idea with VC6 because VC6 ended up generating terrible code from the intrinsics (Avery Lee's blog has a lot of gory details if you are curious). Fortunately nobody is using VC6 anymore (RIGHT?) and current compilers do the Right Thing so intrinsics code is mostly insignificantly slower than writing your own assembler.

[Groucho2004]

Fortunately nobody is using VC6 anymore (RIGHT?)
I could name a few who still use it including myself. I still have a bunch of legacy programs that I wrote ages ago for my employer which were VC5/6 with MFC. I simply don't have the time to port the code to a newer compiler. Also, they just work even though they are built with that "terrible" compiler.

[TurboPascal7]

I could name a few who still use it including myself. I still have a bunch of legacy programs that I wrote ages ago for my employer which were VC5/6 with MFC. I simply don't have the time to port the code to a newer compiler. Also, they just work even though they are built with that "terrible" compiler.

Of course there are programs like that. It does not mean that using VC6 for anything new is reasonable these days.

[wOxxOm]

... let me know if the memory usage that it reports is correct.Tried setmemorymax(12000) n = 20000, got a 12-13gb mem usage, correctly reported, checked against processhacker/procexp.

[Groucho2004]

Tried setmemorymax(12000) n = 20000, got a 12-13gb mem usage, correctly reported, checked against processhacker/procexp.
OK, thanks for testing.

[Groucho2004]

@AVS+ devs
Any chance you could change the version string (from internal.h) to something more useful?
The build date and time should probably be moved to the change log.
I'm thinking more of a version string that clearly identifies the version (or build number) and whether it's a 64 or 32 bit build.

[ultim]

@AVS+ devs
Any chance you could change the version string (from internal.h) to something more useful?
The build date and time should probably be moved to the change log.
I'm thinking more of a version string that clearly identifies the version (or build number) and whether it's a 64 or 32 bit build.

I'll add the architecture (x86/x64) to the version string, but for now I'd like to keep using dates as actual version numbers. The reason is, choosing any "traditional" numbering scheme makes little sense. Should we call it 0.x or 1.0? That would confuse people thinking it is older than 2.6. Should we call it 2.6? Not good because Avs+ is evolving much faster right now than classic Avs. 3.0? 4.0? Those have already been used in Avs. For anything larger, we didn't even have that many releases yet.

Of course one can argue that Avs+ is a totally separate project from Avs and thus Avs's historic numbering scheme shouldn't affect our versioning. You might even be right, but those who don't live on these forums (unlike us) might still mistake Avs+ for Avs and vice versa, at least initially. Also, even if, when do we increment the main version? Every time when a major feature is added (which according to the wish-list will be more than a few)? Or we can go the Linux way for libraries that only reaches 1.0 when the API is stable.

Of course all the above questions can be decided upon arbitrarily, but the different answers would make different amount of sense to different people, depending upon how you try to interpret the version numbers. IMHO using the release date as the version avoids such interpretation ambiguities, because if you see "2013-11-25" nobody will try to give it a special meaning, aside from the fact that it was released on that date. Which version is older or newer still remains clear, even compared to classic Avisynth. And as an added benefit, it also makes it easier to search for the corresponding release post on the forums, or for the appr. Git commit if tagging is ever forgotten.

[qyot27]

'4.0' is AvxSynth, not the original project (and I wouldn't really expect anyone to bring that into the discussion because I really don't know how widespread the knowledge that AvxSynth calls itself '4.0' is; even so, anyone who does know that probably also realizes that AvxSynth was based on 2.5.8 and probably considers the '4.0' to be irrelevant to the topic). And 3.0 never really went anywhere; it stalled and died in development hell before it ever became useful. All I really want to say is that my objection to '4.0' isn't because of it already being used by AvxSynth, it's because I think '4.0' is an excessively large jump.

A '3.1' would be enough to distinguish it from the old AVS3.0, IMO. Or it could go like the classic one did and jump from 2.0->2.5 - no one mistakes AviSynth 2.5 for 2.0. 3.5 wouldn't get mistaken for 3.0, but like '4.0', I still think that's a bit much to suddenly jump to. The angle that it's distinctly referred to as AviSynth+ would mean that the following version number would be attributed to the project name that came before it - AviSynth+ 3.1 =/= AviSynth 3.0 (for one, AVS3.0 was going to be implemented in Ruby). If it does increment with every new major feature, then it would quickly gain a much higher version number and there'd definitely be little chance of getting Classic and Plus mixed up. It could also be counted retroactively: 3.0 for the initial fork, 3.1 for 64-bit (maybe?), and so on. Git's tagging feature can come in handy whenever a change on this does happen (whatever it ends up being).


That kind of argument aside, I'd say sequential revision numbers are even more preferable than a date (not the build time displayed in the output of Version(), the use of the date in the revision), since you can build an earlier revision at a later date, but you can never build an older revision with a newer revision number (barring Git branch trickery; but for this purpose, let's assume the use of master). Git can generate this information with 'git rev-list --count branchname'. The X.X version can be used alongside it for 'stable' releases (like x264 or FFmpeg do), but the sequential revision is always incrementing upward and it's easy to tell how many commits separate any two revisions taken at random. If you want to isolate it to only those commits unique to AviSynth+, then have a 'trunk' branch that only consists of the commits from 2.6's CVS and use ^ notation to subtract them: 'git rev-list --count master ^origin/trunk'

[turbojet]

Why not keep it simple and version 1, 2, 3, etc. like x264/x265 does?

Also avisynth dll's have always been difficult to tell the difference in without naming it manually. This could easily change.

[Jeroi]

Why not keep it simple and version 1, 2, 3, etc. like x264/x265 does?

Also avisynth dll's have always been difficult to tell the difference in without naming it manually. This could easily change.

I second this. The 3.0 and 4.0 was ridicolous already because one was more like planned version of avs and second was linux port by some company.

I would like to see Avisynth+ start from 1 when it gets first stable release. Until that there could be 0.0.0 versions for development.

[qyot27]

Why not keep it simple and version 1, 2, 3, etc. like x264/x265 does?
You're not being clear.

x264 0.140.2377+29 8d4d435
(libswscale 2.5.101)
(libavformat 55.21.100)
(ffmpegsource 2.19.0.0)
built on Nov 11 2013, gcc: 4.8.2
configuration: --bit-depth=8 --chroma-format=all --disable-opencl
x264 license: Non-Free
libswscale/libavformat/ffmpegsource license: GPL version 3 or later
WARNING: This binary is unredistributable!
The version number in this case is 0.140, which is analogous to AviSynth(+) using '2.6' or whatever. The 2377+29 is the revision number, which is actually what I was just suggesting with the use of git rev-list --count. Under that model, avsplus would be:

Counting all revisions to the master branch, including those from classic AviSynth:
git rev-list --count master = r1545

Counting only the unique AviSynth+ revisions:
git rev-list --count master ^trunk = r292


Just to put something in perspective here, 292 revisions back from the 2.6 CVS trunk is commit efe6aa3f1b95647c2301df6e503622d8d51b4ba3, from Tue Jul 1 07:08:59 2008 +0000 - which if I'm not mistaken, was during 2.5.8's development cycle (2.5.8 was released at the end of 2008). There have been as many commits to AviSynth+ in the last 2½ months as there have been to classic AviSynth in the past 5½ years.

[qyot27]

But to add a different idea about versioning, how about something like this:

0.6.1.2.1545 (or 292)

this translates to:

0 = a quasi-standard non-1 major version, similar to x264
6 = the value of AVISYNTH_INTERFACE_VERSION (currently it's still 5, but there's been talk of bumping it to 6)
1 = the value of a hypothetical AVSPLUS_INTERFACE_VERSION
2 = MINOR_VERSION, for bugfixes or other non-API-breaking stuff, perhaps on some sort of monthly or commit-valued schedule
1545 (or 292) = REVISION_NUMBER based on total commits or only commits to AviSynth+

This way, the versioning reflects actual versions that developers need to take into consideration. One rather baffling thing about the advertised versions in classic AviSynth is that they don't match up with the value of AVISYNTH_INTERFACE_VERSION. '2' was pre-2.5.6 or 2.5.7 (can't remember), 3 was through 2.5.8, 4 was unused, 5 was the 2.6 alphas, and either 5 or 6 might be the final one for 2.6.

With the above scheme, some numbers are always incrementing (minor version and revision number), while others stay the same until something big happens and breaks the API, upon which the MINOR_VERSION is set back at zero (REVISION_NUMBER always climbs).

Of course, omitting the 0 and just using INTERFACE_VERSION for the MAJOR_VERSION would also make sense. Even though that'd mean versioning would be 5.whatever for AVISYNTH_INTERFACE_VERSION, at least the number would have a distinct meaning. If the rationale was just 'let's go higher than AvxSynth to avoid confusion' it'd be perpetuating that problem. If the rationale is to make the internal and external versions consistent, then I don't object.

[ryrynz]

The only problem I have with that is I think you'll forever be x.6.x.x.xxxx, there just aren't enough commits to Avisynth for it to be worth it basing Avisynth+'s version numbering off of it.
It should just have it's own version numbering system, this can happen whenever Ultim prefers to switch to it.

[ultim]

I'm still not convinced that any of these alternatives is better than dates (maybe with the exception that the build date does not necessarily equal the commit date). But there seems to be a consensus here and even on IRC that version numbers are better than dates (for whatever unnamed reason). Also the whole versioning "issue" is really not that important to me, so, fine, let's change it. But at least let's keep it simple and avoid "0.6.1.2.1545"-hell. If you're fine with it, I'd propose rXXXX-style sequence numbers (based on git rev-list --count master), tagging official releases x.x(.x)-style too.

[Groucho2004]

If you're fine with it, I'd propose rXXXX-style sequence numbers (based on git rev-list --count master), tagging official releases x.x(.x)-style too.
Works for me. :D

[qyot27]

rXXXX is fine by me - I used that notation in the CLI build guide alongside the output of the date command, and tend to find sequential revisions more informative than point versions most of the time.

My basic point was that a MAJOR.MINOR[.MICRO] type of point version should reflect *something* about the API directly, such as the interface version (if there is/are plans to have a discrete AVSPLUS_INTERFACE_VERSION, that would be the obvious choice).

[turbojet]

I had forgotten x264 had versions other than revision, always seen it referred to as revision number.

Is there any other filters besides resizers that use softwire? Or is there any other filters that may be slower than avisynth on an amd cpu?

Does a pull request for this help out? Or is 'issues' more appropriate?

[TurboPascal7]

Is there any other filters besides resizers that use softwire? Or is there any other filters that may be slower than avisynth on an amd cpu?

Filters that used softwire: Limiter, RGB<->YUV conversions (YV24, Y8, YUY2, BackToYUY2). Don't remember anything else.
Filters that may be slower on an amd cpu: no idea. No one tested.

Does a pull request for this help out? Or is 'issues' more appropriate?
Pull request is when you want to contribute e.g. some code to the project. Issues is more appropriate but there is no need. We played around with it a bit and decided that possible optimizations are not worth it right now. So yeah: for the time being, singlethreaded performance of resample filters will be worse in avs+ on some CPUs (this also affects sandy/ivy bridge afaik).

[turbojet]

Filters that used softwire: Limiter, RGB<->YUV conversions (YV24, Y8, YUY2, BackToYUY2). Don't remember anything else.
Filters that may be slower on an amd cpu: no idea. No one tested.

Would it help development to have these tested on AMD?

Pull request is when you want to contribute e.g. some code to the project. Issues is more appropriate but there is no need. We played around with it a bit and decided that possible optimizations are not worth it right now. So yeah: for the time being, singlethreaded performance of resample filters will be worse in avs+ on some CPUs (this also affects sandy/ivy bridge afaik).

Thanks for the explanation, I noticed you wrote pull requests were welcome in a reply about the slower performance but I wasn't sure if it was requested towards me.

[TurboPascal7]

Would it help development to have these tested on AMD?
Right now - not really. You're welcome to post your results and we might look into performance drops if there are some significant ones (which I really doubt because all other filters weren't nearly as optimized as resamplers) but we aren't specifically working on optimizing core filters right now since there is a lot of more important things to do.

[Groucho2004]

So yeah: for the time being, singlethreaded performance of resample filters will be worse in avs+ on some CPUs (this also affects sandy/ivy bridge afaik).
Did a quick test with some resizers - it's about 20% slower on my i5 2500K. Possibly worth mentioning, AVS+ uses more memory than the official Avisynth. With a script like this:
colorbars(width = 1920*2, height = 1080*2, pixel_type = "yv12").killaudio().assumefps(24000, 1001)
spline36resize(width() - 64, height() - 64)
spline64resize(width() + 64, height() + 64)
bicubicresize(width() - 64, height() - 64)
sincresize(width() + 64, height() + 64)

AVS+ uses ~150 MB, the official Avisynth ~ 55 MB.

[turbojet]

Right now - not really. You're welcome to post your results and we might look into performance drops if there are some significant ones (which I really doubt because all other filters weren't nearly as optimized as resamplers) but we aren't specifically working on optimizing core filters right now since there is a lot of more important things to do.

OK I'll pass on it for now.

Did a quick test with some resizers - it's about 20% slower on my i5 2500K. Possibly worth mentioning, AVS+ uses more memory than the official Avisynth. With a script like this:
colorbars(width = 1920*2, height = 1080*2, pixel_type = "yv12").killaudio().assumefps(24000, 1001)
spline36resize(width() - 64, height() - 64)
spline64resize(width() + 64, height() + 64)
bicubicresize(width() - 64, height() - 64)
sincresize(width() + 64, height() + 64)

AVS+ uses ~150 MB, the official Avisynth ~ 55 MB.

http://forum.doom9.org/showthread.php?p=1655396#post1655396 what were you benchmarking here? The numbers got me really optimistic.

[Groucho2004]

what were you benchmarking here? The numbers got me really optimistic.
Different script, different resolution, apples and oranges...

[turbojet]

So lanczos is faster but one or more of spline36, spline64, sinc, bicubic, sinc is slower?

[TurboPascal7]

So lanczos is faster but one or more of spline36, spline64, sinc, bicubic, sinc is slower?

It depends on the core size (different resizers), source and destination resolutions, your CPU model and the moon phase. I get 15% better performance on Groucho2004's script btw.

[innocenat]

I will explain problem with resizer slowdown in detail:

1. Larger memory footprint: Due to the new resizers are implemented as ResizeVertical.TurnRight.ResizeVertical.TurnLeft, this unfortunately requires two buffers to hold intermediate transposed frame. These buffers are quite large (frame size) and are the cause of increased memory footprint. But IMO, this is not really significant. If it bothers you, I can try to reduce memory footprint a bit, but it isn't possible to match original memory footprint with this implementation.

2. Performance varies between each resizers: Because without Softwire (a just-in-time assembler), the innermost loop of resizers cannot be unrolled to exact filter size. This loop runs a lot (~35 million times on Spline36Resize upscale from 720p to 1080p) and is very optimized. Loop overhead becomes noticeable here, and is reason why filters with large core size run more slower. Generally, Point > Bilinear > Bicubic = Spline16 > Spline36 = Lanczos3 > Spline64 = Lanczos.

3. Performance drop compared to original Avisynth: This is where things get really weird. All resizers run faster than original on Nehalem CPUs, but it look like they run slower on almost every other CPUs (including Intel's newer CPUs like Sandy Bridge). On older CPUs, it may caused by branch predictor cannot predict the innermost loop perfectly (the cycles require to run innermost loop is smaller than branch predictor penalties on most CPUs), but tests has confirmed that this is not a case for newer CPUs. There are some extra instruction generated by compiler in pre-innermost loop, which unfortunately is intrinsics limitation compared to pure asm.

tl;dr situation is weird and no one currently know what is actually happening.

[Groucho2004]

I will explain problem with resizer slowdown in detail:

1. Larger memory footprint: Due to the new resizers are implemented as ResizeVertical.TurnRight.ResizeVertical.TurnLeft, this unfortunately requires two buffers to hold intermediate transposed frame. These buffers are quite large (frame size) and are the cause of increased memory footprint. But IMO, this is not really significant. If it bothers you, I can try to reduce memory footprint a bit, but it isn't possible to match original memory footprint with this implementation.

2. Performance varies between each resizers: Because without Softwire (a just-in-time assembler), the innermost loop of resizers cannot be unrolled to exact filter size. This loop runs a lot (~35 million times on Spline36Resize upscale from 720p to 1080p) and is very optimized. Loop overhead becomes noticeable here, and is reason why filters with large core size run more slower. Generally, Point > Bilinear > Bicubic = Spline16 > Spline36 = Lanczos3 > Spline64 = Lanczos.

3. Performance drop compared to original Avisynth: This is where things get really weird. All resizers run faster than original on Nehalem CPUs, but it look like they run slower on almost every other CPUs (including Intel's newer CPUs like Sandy Bridge). On older CPUs, it may caused by branch predictor cannot predict the innermost loop perfectly (the cycles require to run innermost loop is smaller than branch predictor penalties on most CPUs), but tests has confirmed that this is not a case for newer CPUs. There are some extra instruction generated by compiler in pre-innermost loop, which unfortunately is intrinsics limitation compared to pure asm.

tl;dr situation is weird and no one currently know what is actually happening.
Actually, with "normal" scripts like simply scaling from 720p to 1080p or vice versa, the speed and memory usage differences are marginal. In some cases, AVS+ is even faster.

So, this is a rather insignificant issue. It's much more important that things work and people don't have to restart their process after 20 hours because Avisynth MT crashed for some reason.

[qyot27]

Not that I'm asking about its relevance to the resizer situation*, but if SoftWire was a JIT assembler, does that mean AviSynth used it for roughly the same reason that Schrödinger uses the Oil Runtime Compiler? The description for ORC seems rather similar to what it looks like SoftWire did.

*namely because it's stupid slow to build on anything not recent

EDIT: haha, apparently it got brought up a couple years ago in here (http://forum.doom9.org/showthread.php?t=162385).

[ultim]

A part of the increased memory consumption is also the result of the plugin manager. That is however just as planned, and the difference will depend on the amount of plugins (meaning it is constant, and will not increase with encoding time or script size/complexity).

As for some filters being best optimized currently for Nehalem, I might add the reason is because (as far as I've gathered but I'm not totally sure) all the plugin devs have Nehalem CPUs, so that is where they can test the most.

As for dynamic compilers, my personal opinion is that today it is best (most future proof) to go with LLVM. There is a related idea for Avs+ for GSoC, but not for the resizers. I wouldn't make the core dependent on *any* compiler library though, such functionality if anyone works on it will come as a separate plugin.

[jpsdr]

I've just installed/tested the actual release under Windows XP64 SP2.
The few tests i've made seems ok.
One thing to report about the installer, it doesn't create a menu.
Is it normal ?

Otherwise, thanks for your work at all the guys who are in this project.
Finaly, a properly x64 version is on the way.

[ultim]

I've just installed/tested the actual release under Windows XP64 SP2.
The few tests i've made seems ok.
One thing to report about the installer, it doesn't create a menu.
Is it normal ?

Otherwise, thanks for your work at all the guys who are in this project.
Finaly, a properly x64 version is on the way.

Thanks, in the name of everybody who worked / is working on the project. :D

About the Start Menu entries, yes they are not created by the current installer. Start Menu entries will come in a future release.

[zerowalker]

Does Avisynth+ have problems with using VirtualDub plugins?
I am getting errors here and there, though not sure if it´s Avisynth+ or not, haven´t tried using others yet.

Here are the errors, they come and go and it well, can be used in some way but it can also crash the decoder for the script (Avspmod often just produces errors, Virtualdub will crash if i give it the script 2 times in a row, and i think it fails to decode properly anyway).

Exception WindowsError: 'exception: access violation reading 0x0C412C00' in <bound method PIScriptEnvironment.__del__ of <avisynth.PIScriptEnvironment instance at 0x034DD828>> ignored

An out-of-bounds memory access (access violation) occurred in module 'VirtualDub'...
...reading address 069D2C00.


LoadVirtualDubPlugin("E:\Virtualdub\32 bit - Stable\plugins\addframenumber.vdf", "addframenumber",1)

That is the plugin i am using: http://www.neuron2.net/guest/

Well may be something totally else, and if so it´s off topic


EDIT:

Okay i got rid of it after testing all kinds of stuff, it had something to do with MixAudio being used after the VirtualPlugin, so probably just som incompatibility,
but i just changed the order and now it seems to work, made no sense having it after the Plugin anyway. So i guess it was just a False Alarm from my side.

[jpsdr]

I've installed a few days ago avisynth+ on Windows XP64 SP2 to test (and use) the x64 version.
The only functions i've used in my scripts for now are AviSource, WavSource, AudioDub, Spline36Resize, PointResize (which was not working on last avisynth64 release) and DGSource.
I've run several process of several hours with VDub64, no issue encounter.
I've run encodes of several hours with x264 (x64 version, of course, .avs file feed directly, but only AviSource used in that case), no issue encounter.
I've not tested a lot of avisynth functions, but at least, it seems to work properly with applications, and doesn't seem to have, at least for the few i've tested, any stability issue.
Good work, guys !
:thanks:

[aegisofrime]

Hi Guys,

I just tried Avisynth+ for the first time on my encoding rig, and I have been having some strange problems getting it to work.

I have the following script:

LoadPlugin("C:\DGIndex\DGDecode.dll")
DGDecode_mpeg2source("I:\Test\Test.d2v", info=3)
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\avisynth_plugin\ColorMatrix.dll")
ColorMatrix(hints=true, threads=0)
QTGMC(Preset="Slower")
crop(4, 0, -4, 0)
#resize
Spline64Resize(720,480)
#denoise


Pretty simple QTGMC script. Now, the problem is that the script can be opened by some applications but not by others:

MeGUI: Stuck at opening script (preview window doesn't open), just keeps loading and loading. No errors thrown.

x264 input: Just says cannot open Test.avs

Virtualdub: Works :confused:

Lord Mulder's Simple x264 Launcher: Provides the most information of the bunch, says:

error: Cannot load file 'C:/DGIndex/DGDecode.dll'

Unless the loadplugin syntax was changed in Avisynth+, I have no idea what's wrong here. :confused:

Hope some of you can provide some wisdom here... Thanks!

[vivan]

Probably it's this issue: http://forum.doom9.org/showthread.php?p=1655169#post1655169

[real.finder]

Hi :)

I have a suggestion

Function to change the path of autoload folder temporarily in the script


something like:-

PluginsDir("new plugins path will be here")

and for + Plugins

PluginsPlusDir("new plugins+ path will be here")


in the top of script, like:-

PluginsDir("D:\plugins")
PluginsPlusDir("D:\plugins+")
MPEG2Source("C:\Documents and Settings\user\Desktop\video.d2v")
Tfm()

Would be a wonderful thing for users who without authority of admin :)

--------


On the other hand, I'm still waiting for MT support in order to use avs+ mainly in my encoding


thanks :)

[innocenat]

PluginsDir("new plugins path will be here")

and for + Plugins

PluginsPlusDir("new plugins+ path will be here")


try AddAutoloadDir("C:\path\to\dir")

You don't need separate folder --- the command only works in Avs+ which can load either anyway,

[real.finder]

try AddAutoloadDir("C:\path\to\dir")

You don't need separate folder --- the command only works in Avs+ which can load either anyway,

aha, so it's already exist :)

find it here (http://forum.doom9.org/showpost.php?p=1646315&postcount=67)

thank you

[aegisofrime]

Probably it's this issue: http://forum.doom9.org/showthread.php?p=1655169#post1655169

Thanks for the reply, however it doesn't seem to be the case since the script works in Virtualdub, and anyway my LoadPlugin is before the DGDecode call... :confused:

[StainlessS]

@aegisofrime, does Info() at end of script show anything of interest in VD ?
NOTE, VD has it's own decoders/colorspace converters.

EDIT: Empty plugins directory temporarily (except for any necessary plugs).
EDIT: Although problem seems directory related for DGDecode.
EDIT: You could verify DGIndex load as cause using below


RT_Debug("Loading DGIndex")
LoadPlugin("C:\DGIndex\DGDecode.dll")
RT_Debug("DGIndex Loaded")


And view output in DebugView (google) (RT_Debug requires RT_Stats plug).

[aegisofrime]

@aegisofrime, does Info() at end of script show anything of interest in VD ?
NOTE, VD has it's own decoders/colorspace converters.

EDIT: Empty plugins directory temporarily (except for any necessary plugs).
EDIT: Although problem seems directory related for DGDecode.
EDIT: You could verify DGIndex load as cause using below


RT_Debug("Loading DGIndex")
LoadPlugin("C:\DGIndex\DGDecode.dll")
RT_Debug("DGIndex Loaded")


And view output in DebugView (google) (RT_Debug requires RT_Stats plug).

I took your advice of cleaning out my plugins folder, and moved back the important ones for QTGMC. It works now, so it seems there was an offending filter in my admittedly messy plugins folder. The strange thing is that the same plugin collection works on my Windows 8 laptop without a hitch. :confused:

If I have time I will track down and see what's the filter that's causing this issue.

[StainlessS]

I had some problems some time ago with Avisynth ffmpegSource() and Vdub Plugins32 FFImputDriver.vdplugin
and the ffdlls directory in VDub plugin32, the presence of ffdlls in vd plugs dir caused some kind of conflict
with avisynth, cant remember exactly what the problem was, but seemed related to ffmpegSource and/or
FFImputDriver versions.
Might want to check out by restoring original plugins but without the suspect plugins in AVS/VD plugs dir.
I think the problem was something to do with directory search order being changed, it may have nothing to do with the
problem, but would be first thing I would try out.

[qyot27]

I had some problems some time ago with Avisynth ffmpegSource() and Vdub Plugins32 FFImputDriver.vdplugin
and the ffdlls directory in VDub plugin32, the presence of ffdlls in vd plugs dir caused some kind of conflict
with avisynth, cant remember exactly what the problem was, but seemed related to ffmpegSource and/or
FFImputDriver versions.
Might want to check out by restoring original plugins but without the suspect plugins in AVS/VD plugs dir.
I think the problem was something to do with directory search order being changed, it may have nothing to do with the
problem, but would be first thing I would try out.
That would have to do with the really really early builds of FFmpegSource 1.x that relied on shared versions of the FFmpeg libraries. The builds switched to including those statically somewhere in the middle of the 1.x dev cycle (back in like, 2008 or something) and it's never been done as shared for Windows builds of FFMS2.