AviSynth 2.5.8 Alpha 2 [September 19th] - Release!

[Wilbert]

The changelog of the most recent version (v2.58a2) can be found here.

AviSynth 2.5.8 Alpha [May 18th] - Release!

Changelist with respect to 2.5.7:

Additions:

* ColorKeyMask: Allow independant tolerance levels for each channel.
* Added Tweak Hue/Saturation range limiting (ported from 2.6).
* Added AudioLevels and Color2 modes to Histogram (ported from 2.6).
* Adding global OPT_UseWaveExtensible=True to your script enables WAVE_FORMAT_EXTENSIBLE audio output.
* Added ShowTime() script verb, like ShowSMPTE() but with milliseconds (ported from 2.6).
* Added BlackmanResize() and Spline64Resize().
* Modified DeleteFrame()/DuplicateFrame() to process multiple arguments.
* Added Min()/Max() script functions.

Bugfixes:

* Fixed WriteFile(), Now remembers absolute path to file.
* Fixed Info() frame pitch, reports pitch of input frame.
* Fixed Invert() right edge memory overrun/corruption.
* Fixed Histogram() Classic mode pixel values exceeding YUV limits.
* Fixed Histogram() chroma plane initialization to 128.
* Fixed Conditional reader/writer illegally saving IScriptEnvironment pointer.
* Fixed YV12 Blur()/Sharpen() right edge pixel corruption with non-writable input frames.
* Fixed MMX Blur()/Sharpen() code to full 8 bit precision.
* Fixed IsAudioFloat()/IsAudioInt() script functions.
* Fixed Cache memory oversubscription of SetMemoryMax() limit.

Optimizations:

* Make audio cache actually functional.
* Tweak speed improvments.
* Subtract speed improvments.
* Tuneup Overlay() ISSE Convert444ChromaToYV12 and also provide MMX version.
* PokeCache interface implemented.
* Cache and Memory management enhancements.

Changes:

* AVISource/WavSource map WAVEFORMATEXTENSIBLE back to equivalent WAVEFORMATEX.
* DirectShowSource() now recognises incorrect AM_MEDIA_TYPE subtype for WAVE_FORMAT_EXTENSIBLE audio and corrects the data and accepts it.
* DirectShowSource() now attempts to use partial graph from failing RenderFile call.
* DirectShowSource() now detects and handles non 32 bit aligned picture lines from dud codecs.
* Crop(align=true) tests actual alignment in each GetFrame call.
* Relax YV12 resizer width restriction, now mod 2 was mod 4.
* .AVSI failures during env->CreateScriptEnvironment() are now available to the GetError() interface.
* SetCacheHints(CACHE_RANGE, n) will now surrender frames to satisfy SetMemoryMax().
* CoInitialize()/CoUninitialize() now done as part of ScriptEnvironment creation/deletion.
* Much code from 2.6 base included. Typically IsYV12() changed to IsPlanar().

As usual download from Sourceforge.

Enjoy!

[Leak]

Originally Posted by Wilbert

Changelist with respect to 2.5.7:
[...]
* PokeCache interface implemented.
* Cache and Memory management enhancements.

Ummm... exactly what does PokeCache do?

For my update to the ffdshow AviSynth filter I could really use a NukeAllCaches function to, well, nuke all caches (from orbit, if need be) to make sure nothing is reused after the input video stream has been seeked in...

Of course, a "ForgetAllMetricsYouCalculatedAhead" would be nice too, but it's a bit late to retrofit that into old filters...

So on the other hand, I guess I'll have to live with seeking ahead a lot of (not-really-existing) frames to get filters to start calculating metrics anew and dodge cached frames.

np: Hug - Birds (Heroes)

[Terranigma]

Nice. An update. Thanks A Lot!

Does anyone know if This still hold true?
Would Spline36 be the more efficient resizer to use over Spline64 or... ?
Nvm, I read the resizer doc, so it still seems to be the same.

[Warpman]

There is no function named SetCacheHints

i used
SetCacheHints(510, 10)

Avisynth 2.5.8 verified with version()

[foxyshadis]

It's an internal function, made for dll filters, not useful as part of an avisynth script. It allows a filter to tell avisynth that there's no need to cache more than n frames around it.

[J-Wo]

does 2.5.8 support multithreading? I recall reading a while ago a recommendation to use one of Tritical's avisynth binaries since they were more "memory friendly", but according to his website they are now out of date. Just wondering if people recommend 2.5.7 final, the latest 2.5.8 alpha, or an older 2.5.7 RC build from Tritical's website. thanks!

[IanB]

@Leak,

PokeCache currently is internal only, it is intended to jam a message at all the cache instances. Currently the memory manager uses it to say "I have run out, give some back". Adding a hook to tell all the caches to run in CACHE_NONE mode would be a no brainer. For your ffdshow purposes a reset all caches hook might be more useful to you, that way temporal filters could still use the cache between resets. Have a look at the current CVS code and start a thread to discuss it some more.

@Terranigma,

It is still the original 4 node Spline64 I originally implemented. Maybe you should start a Dev thread to discuss the parameters for this resizer.

@J-Wo,

No multithreading yet, probably not until 2.6.0.

The intent is to make this version obey SetMemoryMax(). A shortcoming in the cache code allowed cache buffers to be locked indefinitly, all 2.5.6 and 2.5.7 releases suffer this problem, Triticals mods helped a little but didn't solve the problem.

If you have a problem, run 2.5.8, reproduce the problem and REPORT IT!

[foxyshadis]

Can PokeCache be used in a filter? So that if a filter itself attempts to malloc or new something internal (not that I think I've ever seen C++ allocation in an avisynth filter...), and hits an out-of-memory condition, it can partially flush the cache and try again? Right now crashing makes as much sense as anything, because hey, what else are you going to do without a working space?

[IanB]

If needed I could add access thru a new key for the env->ManageCache() interface. However doing so would not solve this problem. The cache never Free's/delete's memory, this new hook just unlocks/unprotects VFB's so that env->NewVideoFrame() can reuse an existing frame from the pool instead of allocating a brand new one.

Bring on all your worst memory hog scripts and see how they behave now.

[techreactor]

can you also shed some light about blackmanresize()

[Leak]

Originally Posted by techreactor

can you also shed some light about blackmanresize()

There was some discussion that ultimately lead to it being added to AviSynth here in case you're interested...

np: Adult. - You Don't Worry Enough (Why Bother?)

[Leak]

Originally Posted by IanB

For your ffdshow purposes a reset all caches hook might be more useful to you, that way temporal filters could still use the cache between resets. Have a look at the current CVS code and start a thread to discuss it some more.

Will do, although I'm wondering if there aren't too many legacy filters already for this to be added now - it's not just the caches, after all, it's also metrics and stuff that's been (pre-)calculated ahead; applying those to totally different images isn't going to be pretty.

That's why I resorted to increase the number of the current frame by 1000 whenever such a break is needed - that should work in almost all cases.

Oh, another thing - wouldn't it make sense to also add the multithreading additions from 2.6? TSP did so for 2.5.6 and 2.5.7 and released his own versions of avisynth.dll, so I guess it shouldn't be too hard to incorporate these changes in 2.5.8 for good...

np: Adult. - Harvest (Why Bother?)

[Ebobtron]

Hello,
@Ianb
Thank you.

The changes to the memory manager seem to work very well. Comparing to 2.57, with a memory hog script using my slide animate function which at 10% of an encode would begin its climb beyond 500 Meg of PF Usage, tests this morning with 2.58 showed no climb above 500 Meg during the entire encode.
Both tests used #SetMemoryMax()

".AVSI failures during env->CreateScriptEnvironment() are now available to the GetError() interface."

This looks really good too.

"CoInitialize()/CoUninitialize() now done as part of ScriptEnvironment creation/deletion."

Can I assume that this does not prevent AviSynth from un-initializing COM when it was initialized prior to loading AviSynth. I see no difference in behavior.

Otherwise all looks very good from my limited point of view, except who was the wise guy that make the version string longer.

Thanks to every one
Rob

[Leak]

Oh yeah, another thing I wanted to ask:

Since I'm using VS2005, would you be interested in a patch for the current CVS code that fixes the errors caused by 2005's tighter scoping? It's all just pulling the loop variables out before for statements, so it should work just as well in VC6.

I'd also have project/solution files for VS2005 that could be put into CVS, like ffdshow does with it's VC6/VS2k5/ICL9 files.

Oh, and distributing MSVCRTD in distrib/bin/debug might be also a good idea, since it doesn't ship with 2005 and devil-d.dll depends on it.

It's not much that needs to be changed to at least make avisynth itself compile, but why not add it to CVS so people don't have to reinvent the wheel every time?

np: The Go Find - Monday Morning (Stars On The Wall)

[squid_80]

Originally Posted by Leak

Oh, and distributing MSVCRTD in distrib/bin/debug might be also a good idea, since it doesn't ship with 2005 and devil-d.dll depends on it.

I don't think you're allowed to distribute MS debug libraries. Probably better to recompile it as static if that's possible.

[Leak]

Originally Posted by squid_80

I don't think you're allowed to distribute MS debug libraries. Probably better to recompile it as static if that's possible.

Oh, great... of course, you could also put a VS2005 build of devil-d.dll in there, but why bother?

Yeah, I could have dug out my VS6 CDs and installed the missing library from there, but you wouldn't believe what just googling for it turns up...

np: Mikkel Metal - Dromos (Brone And Wait)

[Leak]

Okay, so if someone else wants to compile AviSynth with Visual Studio 2005 or would like to commit my changes to CVS - you can find my changes here.

DISCLAIMER: I didn't thoroughly test everything, I simply checked that it would happily run my DVD-IVTC/resize script inside of ffdshow. Also, pretty much all of the changes consist of straight-forward pulling loop variables out of a for-loop. It's also chock-full of warnings, but I think almost all of them can be safely ignored.

I've also replaced lstrcpyW with wcscpy, as the former is both deprecated *and* commented out in it's header file, while the latter is just deprecated and should do the same.

The diff contains all code changes and VS2005 project files (plus some line noise from my local SVN repository), while the ZIP file contains a VS2005 debug and release build of the SoundTouch library.

If the debug version of AviSynth doesn't want to run, you'll probably have to hunt down a copy of MSVCRTD.dll, or throw out your devil-d.dll (and possibly the code that tries to use it).

np: David Sylvian - Ride (Everything And Nothing)

[IanB]

Okay M$ won't let MSVCRTD.DLL be distributed.

devil-d.dll comes from the devIL distribution, we don't build it.

The debug versions of things in CVS are usually pretty useless because they have absolute path references for the symbols, but they linger on.

The CoInitialize()/CoUninitialize() change should only avoid the deadlock from the DllMain exit code (got global lock, CoUninit.. code also needs same lock, etc, etc, ...) The concept is still under review. There is a dormant thread on the issue, read that and contribute any ideas you have in there.

Version string I haven't checked Wilbert build, but it should just have 8 instead of 7 and a new date. Will check.

Leak, thanks for the 2005 updates. Are these really all from compiler warnings, it seems a bit excessive or did you do a global seek and destroy. I am relucant to put any new .vcproj files into CVS (sh0dan already has some) because people tend to update them directly instead of updating the VC6 files and reimporting.

For the lstrcpyW/wcscpy we should be using the function for which the compile generates inline code. Need to check.

Whew, pause, take breath ......

[Leak]

Originally Posted by IanB

Leak, thanks for the 2005 updates. Are these really all from compiler warnings, it seems a bit excessive or did you do a global seek and destroy.

If you mean the changes to loops - those aren't absolutely neccessary, since you can configure VS2005 to fall back to the non-standard behaviour of it's earlier iterations, but that has been violating the C++ standard all along.

I didn't do a seek and destroy, though - I just fixed it everywhere the compiler choked on me. Sure, a few of these could have been fixed by re-declaring the loop variable in for statements further down the code, but I figured just declaring the variable once and reusing it like it's been done before was the way to go.

I am relucant to put any new .vcproj files into CVS (sh0dan already has some) because people tend to update them directly instead of updating the VC6 files and reimporting.

Am I the only one here that thinks VC6 needs to die a quick death, especially since there's Visual C Express Edition? *wonders*

Anyway, the auto-conversion process didn't go totally smooth for DirectShowSource and TCPDeliver at least, both needed some tweaking to compile. That's why I included them...

And the SoundTouch libraries need to be rebuilt with VS2005 to link properly.

For the lstrcpyW/wcscpy we should be using the function for which the compile generates inline code. Need to check.

Argh... looking still a bit closer at this I see that lstrcpyW gets redefined into la-la land in wxutil.h, which is part of DirectShow's base classes...

But rectifying it in wxutil.h in every installation can't be the solution either...

np: David Sylvian - Cover Me With Flowers (Everything And Nothing)

[Fizick]

can Soundtouch be converted to DLL? with non-compiler version-dependent calls from avisynth (LoadLibrary, .....)
like devil.dll