AviSynth 2.5.8 [Dec 30th] - Release! (was RC-5 [Dec 27th])

[IanB]

Okay RC-5 has gone live!

Get AviSynth_258.exe (http://downloads.sourceforge.net/avisynth2/Avisynth_258.exe) and Avisynth_258_src.zip (http://downloads.sourceforge.net/avisynth2/Avisynth_258_src.zip) from Sourceforge.

For the bandwidth conservative this release is the same as RC-5 (+1 Russian Doco updates)

Changelist with respect to 2.5.7:

Additions:

* Added Czech doc translation.
* Added Polish doc translation (by Slim, Krismen & Co).
* Updated Japanese documentation [20080813] (Niiyan).
* Added Japanese translation (by niiyan).
* Installer standalone option for putting avisynth.dll, etc into install directory and NOT updating registry.
* Blankclip added audio channels= and sample_type= arguments.
* ConvertAudio(cii) available to plugins via env->Invoke().
* Added font aspect, rotation and alpha to text routines.
* Added /* xxx */ block comments.
* Added [* [* xxx *] *] nestable block comments.
* SetMemoryMax(0) to just return current Memory Max value.
* Added planar YV12 color format to Compare() [Fizick].
* ColorKeyMask: Allow independant tolerance levels for each channel.
* Added Tweak Hue/Saturation range limiting.
* Added AudioLevels and Color2 modes to Histogram.
* Adding global OPT_UseWaveExtensible=True to your script enables WAVE_FORMAT_EXTENSIBLE audio output.
* Added ShowTime() script verb, like ShowSMPTE() but with milliseconds.
* Added BlackmanResize() and Spline64Resize().
* Modified DeleteFrame()/DuplicateFrame() to process multiple arguments.
* Added Min()/Max() script functions.

Bugfixes:

* Fixed ShowFiveVersions() YV12 chroma position in bottom half. Regression.
* Fixed DirectShowSource() grey frames after end of stream + 30 frames.
* Fixed Histogram() Classic mode restore graph brightness. Regression.
* Fixed Compare() graph pixel values exceeding YUV limits.
* Fixed AddBorders() args negative value clamping.
* Fixed AviSource() decoding to RGB24 logic regression.
* Added workaround for HuffYUV, Xvid reading past end of input buffer.
* Fixed current_frame value in nested runtime script invocations. (Gavino)
* Fixed Dissolve overlap arg range checking. (gzarkadas)
* Fixed OpenDMLSource() multithreading race problem. (QuaddiMM)
* Fixed unsaved variableName string in ConditionalReader.
* Fixed Parser FunctionTable::TypeMatch() missing compulsory arguments. Dissolve bug (Various).
* Fixed DirectShowSource() QueryId() use CoTaskMemAlloc for returned value (Dean Pavlekovic).
* Fixed DirectShowSource() use GraphBuilder object for media control (Avery Lee).
* Fixed DirectShowSource() remove PulseEvent calls (Avery Lee).
* Fixed DirectShowSource() QueryAccept() modifying VideoInfo in running script (Haali).
* Fixed Blankclip clip= argument parsing.
* Fixed trashed GPF report, i.e reading 0x0 at 0x0 exception reporting.
* Fixed and refactored Overlay RGB<->YUV conversion routines.
* Fixed ImageReader incompletely inited videoInfo.
* Fixed Layer RGB32 100% alpha implementation, use level=257 (new default).
* Fixed avisynth_c.h avs_is_parity_known().
* Fixed C++ ConvertAudio::Saturate_int32() rounding.
* 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:

* DirectShowSource() convertfps=true add 0.5ms rounding to expected sample time. Improves performance with millisecond based DS spliters.
* DirectShowSource() FPS detection as last attempt tries getting the duration of 1st frame.
* DirectShowSource() convertfps=true rely only on sample start time.
* Refactor horizontal planar resizer, no width restrictions or 2 byte overwrite.
* Provide a simple and fast text writing primatives, see info.h
* Make audio cache actually functional.
* Tweak() speed improvements.
* Subtract() speed improvements.
* Tuneup Overlay() ISSE Convert444ChromaToYV12 and also provide MMX version.
* PokeCache internal interface implemented.
* Cache and Memory management enhancements.

Changes:

* Initial Memory Max value clamped to 512MB.
* Default Memory Max value restored to quarter of Free memory. Minimum 16Mb. Same as per 2.5.7.
* Test VFB data buffer for NULL malloc's, if so then Throw!
* Installer Start menu shortcut names translated.
* Test for UTF-8 and Unicode BOM prefixes and issue a useful warning.
* Removed useless current_sample from runtime script environment.
* Added critical section to CAVIFileSynth class.
* Enable Installer multi language support [Need volunteers to do translations].
* FunctionTable::Lookup() now considers named arguments in making its selection.
* ImageWriter supports negative values as -count for End argument.
* ChanegFPS() use floor instead of round in source frame number calculation.
* Update usage of correct (updated) Rec.709 coefficients.
* Add TCPDeliver.map and DirectShowSource.map to releases.
* Convert to Dynamic Assembled rgb to yuy2 code.
* Avisynth_c.h boolean functions return 1 for true instead of arbitrary non-zero.
* Internal RGB2YUV() now copies Alpha top byte through.
* CoUninitialize() done immediately for S_FALSE CoInitialize() returns, i.e we do not hold a COM use count.
* Pfc, Softwire and SoundTouch updated and added as dependency projects.
* UPX updated to version 2.03 (2006-11-07).
* 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 (http://sourceforge.net/project/showfiles.php?group_id=57023&package_id=72557&release_id=650255).
Enjoy! :cool:

Special thanks to the installer translation contributors.

[unskinnyboy]

Yay! Upgraded! :thanks:

[Terranigma]

Thanks Heaps. :cool:

[superuser]

thnxs, will give it a try ....

had couple of questions:

- are there are any filters which have been deprecated ?
- Is multi threading (MT plugin) support native to avisynth or will we should use MT? If not, is MT plugin available for this release candidate (sorry should ask this is in MT thread)

Cheers !

[IanB]

@superuser, Lets read the change list, Hmmmm, Additions ... Nope, Bugfixes ... Nope, Optimizations ... Nope, Changes ... Nope!

[smok3]

:thanks:

[ticapix]

Is that possible to have a tarball of the source used to build this release ?
Or to have a svn/cvs command to checkout the code corresponding to this release ?

Thanks

[Wilbert]

@IanB,

Some other changes i collected since v2.58a2 (which i think are not in the list above):
* Save variableName buffer in ConditionalReader
* Overlay: fixed and refactored RGB<->YUV conversion routines.
* TCPDeliver/DSS: Output a map in release builds.
* Usage of correct Rec.709 coefficients.
* Fix trashed GPF report, fix 0x0 at 0x0 exception reporting.
* cache: Trap NULL PVideoFrames, i.e. Don't crash, Winge!
* DSS: get convertfps=false logic right, fix Flush task interlock.

[fyo]

I really needed the range limiting on the tweak filter, so I tried upgrading to 2.58... now I cannot load my dv avi files anymore. Other codecs seem to work fine.

NOTE: I run AviSynth under Wine... Hasn't been a problem before.

I get the following error: "Could not open video stream in any supported format".

Any ideas?

[IanB]

@fyo,

What VFW DV codec do you have installed?

If you are using Cedocide what are the decode settings?

[fyo]

What VFW DV codec do you have installed?

I'm using a panasonic dv codec (psdvcodec.dll).

I'm not sure I understand why a change in AviSynth would break compatibility with the panasonic dv codec, but I just tried changing to a Main Concept dv codec I got with some old software once. It seems to work fine! (I'll continue using it for now, although I *think* there was a reason I switched to the Panasonic codec in the first place).

That at least allowed me to play around with the new and improved tweak filter... long enough to find a bug ;-)

The brightness variable doesn't conform to the hue limits set by startHue and endHue.

[Wilbert]

That at least allowed me to play around with the new and improved tweak filter... long enough to find a bug ;-)

The brightness variable doesn't conform to the hue limits set by startHue and endHue.
That's not a bug, but that's how it is designed :) :
startHue (default 0), endHue (default 360): (both from 0 to 360; given in degrees.). The hue and saturation will be adjusted for values in the range [startHue, endHue] when startHue<endHue.
Perhaps this will be added in v2.6.

I'm using a panasonic dv codec (psdvcodec.dll).

I'm not sure I understand why a change in AviSynth would break compatibility with the panasonic dv codec
Yes, that's strange. Is this also the case for older v2.58 versions (v2.58 a1/a2)?

[IanB]

@ticapix,

See Anonymous CVS Access (http://sourceforge.net/cvs/?group_id=57023)

And Browse CVS Repository (http://avisynth2.cvs.sourceforge.net/avisynth2)

You want to look in avisynth/src and avisynth/distrib


@Wilbert,

Oops, yes we have been slack in keeping the changelist up to date :o

[niiyan]

@AviSynth developers
I still work for Japanese translation of AviSynth documentaions.
But the progress is very slow.
Only 68 pages of corefilters were finished.
I would like to add Japanese translation to AviSynth 2.5.8 Final, but I don't seem to be in time for it.

So, can I add Japanese/English hybrid version of documentations to the next version after 2.5.8 (I mean 2.5.9 or 2.6.0)?
If possible, I'll try to finish translation of all corefilters pages (not all pages) and syntax.htm, etc.

* Enable Installer multi language support [Need volunteers to do translations].

Could you explain how to add other language to installer or where can I get the documentation of it?

[IanB]

@niiyan,

If you have a doco tree that you are happy with, zip it up and send it to me. PM me with some details, we can also discuss adding you to CVS or you can just keep sending us updates if CVS is to hard.
* Enable Installer multi language support [Need volunteers to do translations]. Could you explain how to add other language to installer or where can I get the documentation of it?We use the "Nullsoft Install System (http://nsis.sourceforge.net/)". Turning on their multi language was easy. Apart from writing the language texts, I am unclear how to implement making those texts in the install script also language dependant, hence the "Need volunteers ...".

[FlimsyFeet]

Yes, that's strange. Is this also the case for older v2.58 versions (v2.58 a1/a2)?
FWIW, I remember having a problem with the Panasonic DV codec in one of the 2.5.8 alhpa versions sometime last year. Error said something like "no compatible output format". 2.5.7 was OK.

[niiyan]

@IanB

If you have a doco tree that you are happy with, zip it up and send it to me. PM me with some details, we can also discuss adding you to CVS or you can just keep sending us updates if CVS is to hard.

Japanese translation of AviSynth docs
http://translation.avisynth.info/index_en.html

Here is a temporal version of Japanese translation.
I also added Japanese/English hybrid version today.
But only 66 pages are in Japanese.

Note: it is now based on the documentation distributed with AviSynth 2.5.7.

We use the "Nullsoft Install System (http://nsis.sourceforge.net/)". Turning on their multi language was easy. Apart from writing the language texts, I am unclear how to implement making those texts in the install script also language dependant, hence the "Need volunteers ...".

I don't know much about NSIS, but I found the following pages:


Creating language files and integrating with MUI - NSIS (http://nsis.sourceforge.net/Creating_language_files_and_integrating_with_MUI)
Scripting Reference (http://nsis.sourceforge.net/Docs/Chapter4.html#4.10) (Example (http://nsis.sourceforge.net/Examples/languages.nsi))


I hope it will help you.

[sidewinder711]

Thanks a lot to IanB and all others, who are involved in the development of this great tool! I'm looking forward to check out/test the new features. :thanks: :)

[Ajax_Undone]

WOW Works great just downloaded it... AVS Editor is missing its C# Project side of its code in SVN JSYK...

Tried Compiling it earlyer today... :-)

[IanB]

@niiyan,

Thanks for the NSIS research, "LangString" was the piece of the puzzle I had been missing. :D

I'll open a new thread to collect translations of the Installer texts now I know how to use them.

I will import your avisynth_docs_ja_temporal.zip into the docs tree.

I can diff new versions with avisynth_docs_ja_20080529.zip to apply updates as you do them.

Just PM Wilbert or me when you have updates or with any other issues.

[niiyan]

@IanB

I will import your avisynth_docs_ja_temporal.zip into the docs tree.

Is that mean Japanese documentation will be included in AviSynth 2.5.8 Final? Or in the later version than 2.5.8 (2.5.9 or 2.6.0)?


I can diff new versions with avisynth_docs_ja_20080529.zip to apply updates as you do them.

Just PM Wilbert or me when you have updates or with any other issues.

I see. Thanks.

[Octo-puss]

Ooh, development wasn't dead :)

[IanB]

AviSynth 2.5.8 RC2 [June 22nd] - Release! (http://sourceforge.net/project/showfiles.php?group_id=57023&package_id=105994&release_id=608595)

Changelist with respect to 2.5.8-RC1:

Additions:

* Added Japanese translation (by niiyan).

Bugfixes:

* Fixed current_frame value in nested runtime script invocations. (Gavino)
* Fixed Dissolve overlap arg range checking. (gzarkadas)
* Fixed OpenDMLSource() multithreading race problem. (QuaddiMM)
* Fixed unsaved variableName string in ConditionalReader.

Changes:

* Test for UTF-8 and Unicode BOM prefixes and issue a useful warning.
* Removed useless current_sample from runtime script environment.
* Added critical section to CAVIFileSynth class.

[Ajax_Undone]

Nice thanx IanB your proj is the base of my digital world...

[ankurs]

upgrade :D ! :thumbup:

[tacman1123]

NOTE: I run AviSynth under Wine... Hasn't been a problem before.



I don't see Avisynth in the Wine AppDB, but I do see that an old version of MediaEncoder is (which since 2006 has supported Avisynth).

Were you able to get it to run only the native Wine dll's (that is, not needing a licensed copy of Windows)? If so, now that Wine has been officially released using it may be an acceptable solution for people looking for a way to run Avisynth under Linux. I'm not holding my breath for Avisynth 3 and the Linux port, but if it runs under Wine that's certainly worth knowing.

Currently searching for 'linux' on the avisynth wiki yields very little, one tiny mention of avs2yuv on http://avisynth.org/mediawiki/FAQ_frameserving. Would you consider modifying that page with a question/answer in the format

Q: Does Avisynth run under linux?

A: Not as a native application, but to run Avisynth with Wine, do the following:

Thx,

Tac

[tacman1123]

Added font aspect, rotation and alpha to text routines.

Does this mean to the C routines, or to Avisynth calls such as Subtitle()?

I see that 2.5.8 now allows Subtitle() to have accented characters (UTF8), that's great, so now

ColorBars.Subtitle("¿En qué año nació?")

works as expected -- thanks!

Tac

[IanB]

@tacman1123,

Avisynth is not an application it is a library, as such you need a host application to run it under.

There should be no real issues under wine per se, it has no UI component and just needs an msvcrt.dll plus minimal system support from kernell.dll, etc.

However AVISource() needs the full VFW infrastructure plus DirectShowSource need the full DirectShow environment as well and these can be problematic licensing wise i.e. you need a donor windows for these components. Other functions like SubTitle need the appropriate font files.

Any contributions to documentation about Wine issues will be gratefully accepted, PM Wilbert or Myself.



And about Subtitle(), sorry no it is still uses ANSI encoding. Looks like you just managed to get your codepage settings correct.

[kandrey89]

delete plz.

[TheFluff]

Avisynth is not an application it is a library, as such you need a host application to run it under.

There should be no real issues under wine per se, it has no UI component and just needs an msvcrt.dll plus minimal system support from kernell.dll, etc.

However AVISource() needs the full VFW infrastructure plus DirectShowSource need the full DirectShow environment as well and these can be problematic licensing wise i.e. you need a donor windows for these components. Other functions like SubTitle need the appropriate font files.

Any contributions to documentation about Wine issues will be gratefully accepted, PM Wilbert or Myself.
Currently, Avisynth works quite well under Wine. While you might run into problems with avisource() or directshowsource(), ffmpegsource() works just fine and supports most common stuff. Output to native Unix applications works just fine with avs2yuv. I've tested with mencoder and it works fine provided that you tell it to cache a bit.

[Revgen]

I don't know if this is the appropriate thread, but here it goes.

Why can't avi's with no sound and avi's with sound be combined with avisource?

I basically had to go into Nero WaveEditor create a null wav file and add it to my noaudio avi using AudioDub to trick avisynth into combining the 2 avi's. Can there be a audio=null option to insert a null audio track automatically?

[IanB]

The restriction is actually in Splice. AviSource() automatically UnAlignedSlice()'s all the files provided. The restriction being all the files must be compatible, i.e. same Height, Width, Colour space and Audio format. If the files are incompatible then the script author must provide the knowledge to resolve the incompatibility and join the disparate clips together.

In your case you could have used the Audio=False option for the videos streams and sourced the Audio track separately and then AudioDub()'d it laterAviSource("FileA.avi", "FileB.avi", Audio=False)
AudioDub(WavSource("FileA.avi"))else you could AviSource each clip separately, add a blank audio track the clip without audio and then splice them.A=AviSource("FileA.avi")
B=AviSource("FileB.avi") # No audio stream
A ++ AudioDub(B, BlankClip(A))

[Revgen]

The restriction is actually in Splice. AviSource() automatically UnAlignedSlice()'s all the files provided. The restriction being all the files must be compatible, i.e. same Height, Width, Colour space and Audio format. If the files are incompatible then the script author must provide the knowledge to resolve the incompatibility and join the disparate clips together.

In your case you could have used the Audio=False option for the videos streams and sourced the Audio track separately and then AudioDub()'d it laterAviSource("FileA.avi", "FileB.avi", Audio=False)
AudioDub(WavSource("FileA.avi"))else you could AviSource each clip separately, add a blank audio track the clip without audio and then splice them.A=AviSource("FileA.avi")
B=AviSource("FileB.avi") # No audio stream
A ++ AudioDub(B, BlankClip(A))

I don't use blankclip much. I assumed it was a command used for video instead of audio. So basically Blankclip(A) gives the noaudio AVI a null audio stream with properties (khz, samplerate, etc) similar to the AVI with sound? If so, then thanks. This will be usefull the next time I try use it.

[Wilbert]

So basically Blankclip(A) gives the noaudio AVI a null audio stream with properties (khz, samplerate, etc) similar to the AVI with sound? If so, then thanks.
Yes, indeed. I will add this example to the documentation.

[IanB]

More correctly the "AudioDub(B, BlankClip(A))" does.

[Revgen]

^Okay, well, in that case whenever somebody tries to combine a video with no audio and a video with audio, instead of an error message saying "AVIsource can't combine these files", it should say "One of your clips contains no audio. Use Blankclip to add a blank audio stream" or something of that sort.

[IanB]

@Revgen,

:confused: What version are you running? "AVIsource can't combine these files" is not a current message. The validation code for splice is :- if (vi.HasVideo() ^ vi2.HasVideo())
env->ThrowError("Splice: one clip has video and the other doesn't (not allowed)");
if (vi.HasAudio() ^ vi2.HasAudio())
env->ThrowError("Splice: one clip has audio and the other doesn't (not allowed)");
...
if (vi.width != vi2.width || vi.height != vi2.height)
env->ThrowError("Splice: Frame sizes don't match");

if (!vi.IsSameColorspace(vi2))
env->ThrowError("Splice: Video formats don't match");
...
if (fabs(fps_v1-fps_v2) > 0.000001)
env->ThrowError("Splice: Video framerate doesn't match");
...
if (vi.AudioChannels() != vi2.AudioChannels())
env->ThrowError("Splice: The number of audio channels doesn't match");

if (vi.SamplesPerSecond() != vi2.SamplesPerSecond())
env->ThrowError("Splice: The audio of the two clips have different samplerates! Use SSRC()/ResampleAudio()");

[weaker]

In the changelist I can't find information regarding greyscale/Y8 support. The early alpha version had some support for it, does the RC2 still have it or was it delayed to another milestone?

[RedDwarf1]

What is avsrecursion.dll and how does it relate to AVISynth? After installing this release I am getting an error in multiple applications saying avsrecursion.dll cannot be found. Uninstalling it does not fix it either.

[Wilbert]

In the changelist I can't find information regarding greyscale/Y8 support. The early alpha version had some support for it
No it didn't. v2.6 will have Y8 support.

What is avsrecursion.dll and how does it relate to AVISynth? After installing this release I am getting an error in multiple applications saying avsrecursion.dll cannot be found.
avsrecursion (http://home.arcor.de/kassandro/AvsRecursion/AvsRecursion.htm) is not an AviSynth plugin. It should be in your system folder.

[weaker]

Sorry, I was thinking of 2.6.0 pre-alpha. Mixed things up. Thanks Wilbert for clarification.

[RedDwarf1]

No it didn't. v2.6 will have Y8 support.


avsrecursion (http://home.arcor.de/kassandro/AvsRecursion/AvsRecursion.htm) is not an AviSynth plugin. It should be in your system folder.

Thanks Wilbert for the link. After I put that into my system directory, all the encoding appz now run. But it's very strange why it should be needed as I am not using any of the plugins that require that dll. Maybe the windows CD that I prepared got a bit messed up when I prepared it. That is the only thing it can be as I the same thing happened with 2.5.7 after I restored a backed up DVD of windows.

[foxyshadis]

You may have downloaded a new version of AvsTimer, RemoveGrain, ReduceFlicker, or RemoveDirt, all of which require avsrecursion now. If they're in your autoload plugins, then they'll always load with every script, thus erroring every one.

[stax76]

I wonder how near the final is? Need to know planning StaxRip release schedule.

[IanB]

A few weeks, we are just polishing the installer with some foreign language support and catching up the doco language translations. So unless someone reports a show stopper, RC3 (same core as RC2 +1 fix and latest Docs) will ultimately become the Released version.

[Didée]

Issues/suggestions from the hop of my tead:

* Bob():
- chroma displacement with YV12 input (!!)
- resets field order always to BFF, instead of keeping the original parity

We've got used to those behaviours, but frankly, it's just embarrassing.


* Blur()/Sharpen():
what about some sort of "chroma" or even better "plane" parameter. Sure, you can always MergeChroma/Luma() afterwards, but it's inefficient. If one wants to sharpen only luma, you have to: first actually let the filter process the chroma planes, then copy the respective planes back from one clip to another. That's more work than to do just *nothing* to those planes. And with e.g. HD input and/or very complex scripts, every little bit counts.
Since RGB does not have "chroma" as such, the most convenient way (probably) would be to have Y,U,V parameters (with R,G,B aliases) like in MaskTools.

[Wilbert]

* Another issue:

http://sourceforge.net/tracker/index.php?func=detail&aid=1944770&group_id=57023&atid=482673

It's strange that it doesn't crash in VDub directly when scrolling to the second frame.

[IanB]

@Didée,

I will change the behaviour of Bob() for 2.6. The chroma displacement is configurable in the 2.6 resizer core, so this needs to be visited anyway.

I have on my 2.6 to-do list, "make planar planes as Y8 with zero cost", they currently get bitblt'd, soMergeLuma(ConvertToY8().Sharpen(0.2))will do what you ask when implemented.

@Wilbert,

That file http://www.quyo.de/~mfie/foo/avisynth_crash.avi does not crash for me with any version of avisynth. Does it crash for you? What VFW Huffyuv decoder are you using?

[Wilbert]

That file http://www.quyo.de/~mfie/foo/avisynth_crash.avi does not crash for me with any version of avisynth. Does it crash for you? What VFW Huffyuv decoder are you using?
I tried both the original version and huffyuv_ccesp-patch_025 (see Doom9's download section). Which one are you using?

[IanB]

@Wilbert,

The huffyuv_ccesp-patch_025 from Doom9's download section.

So it does crash for you? or not?

[squid_80]

It crashes for me (huffyuv_ccesp, not with ffdshow decoding), only when loading via avisynth. It dies in huffyuv when decoding the last few symbols from the compressed frame. Huffyuv reads up to 4 bytes ahead in the input frame when decoding, it's this load instruction that's crashing:
02C14C58 mov edx,dword ptr [esi+ebx*4]
02C14C5B mov ebx,dword ptr [esi+ebx*4+4] <- FAULT
02C14C5F shld edx,ebx,cl ;pack input bits
The problem is huffyuv is trying to read beyond the end of the input frame, but the input buffer matches the size of the input frame exactly, with no slack allocated. Unfortunately I don't have a build environment setup for avisynth at the moment so I can't provide a definite patch. I did try enlarging dwSuggestedBufferSize by hex-editing the avi file but it had no effect. I'm guessing avisynth checks the index and allocates the input buffer based on the largest frame-size; the fact that in this case that size is exactly divisible by 32 might be part of the problem. In fact if 32 is added to the frame size (1535968), it's cleanly divisible all the way up to 2^12.

[Wilbert]

@Wilbert,

The huffyuv_ccesp-patch_025 from Doom9's download section.

So it does crash for you? or not?
Yes, as squid_80 says. I didn't try ffdshow decoding yet.

[IanB]

Still can't get an Avisynth to crash but I got an old VirtualDub to crash. So I can see what the problem is. It's a HuffYUV bug as Squid found in huffyuv_a.asm@632, in the HUFF_DECOMPRESS macro. It simply runs of the end of the input buffer.

A simple workaround is to add some guard bytes to the file read buffer in AVISource::DecompressFrame(). This code need 4 extra bytes but I decided to add 15 in case there are other smartarse codecs pulling the same trick but doing a read into an XMM reg.

Watch for an AviSynth_080712.exe or latter in the Installer texts language translations thread.

[squid_80]

This code need 4 extra bytes but I decided to add 15 in case there are other smartarse codecs pulling the same trick but doing a read into an XMM reg.While I think of it, xvid does the same thing when decoding b-frames but even worse - it checks ahead for a resync marker and if it finds one, attempts to continue decompression using data following the marker. The likelihood of an erroneous resync marker being found is low but not impossible, virtualdub's "display decompressed output" (http://forums.virtualdub.org/index.php?act=ST&f=15&t=15076) option has a high likelihood of setting it off. So even though I've never seen it cause a crash with avisynth it might be a good idea to fill the bytes immediately following the input data with 0xA5 (or whatever bitstring you choose) before passing the buffer to the codec.

[IanB]

Okay, I will fill with 0xA5's and 1 0x00

[RedDwarf1]

You may have downloaded a new version of AvsTimer, RemoveGrain, ReduceFlicker, or RemoveDirt, all of which require avsrecursion now. If they're in your autoload plugins, then they'll always load with every script, thus erroring every one.

Ah, thanks. That must of been the reason. I did try AvsTimer on one occasion and still had it in the plugins folder as I do tend to copy the plugins folder to new windows installs.

After deleting AvsTimer from the plugin folder it worked fine.

[Revgen]

@Revgen,

:confused: What version are you running? "AVIsource can't combine these files" is not a current message. The validation code for splice is :- if (vi.HasVideo() ^ vi2.HasVideo())
env->ThrowError("Splice: one clip has video and the other doesn't (not allowed)");
if (vi.HasAudio() ^ vi2.HasAudio())
env->ThrowError("Splice: one clip has audio and the other doesn't (not allowed)");
...
if (vi.width != vi2.width || vi.height != vi2.height)
env->ThrowError("Splice: Frame sizes don't match");

if (!vi.IsSameColorspace(vi2))
env->ThrowError("Splice: Video formats don't match");
...
if (fabs(fps_v1-fps_v2) > 0.000001)
env->ThrowError("Splice: Video framerate doesn't match");
...
if (vi.AudioChannels() != vi2.AudioChannels())
env->ThrowError("Splice: The number of audio channels doesn't match");

if (vi.SamplesPerSecond() != vi2.SamplesPerSecond())
env->ThrowError("Splice: The audio of the two clips have different samplerates! Use SSRC()/ResampleAudio()");

That wasn't the exact message, it was one of the ones in your example above. Basically it said that a clip with audio and a clip without audio couldn't be combined. I couldn't remember the exact message at the time.

[squid_80]

I recently upgraded my ram from 2 gigs to 8 gigs and there seems to be a problem somewhere in the core with memory addresses higher than 0x80000000. If I watch task manager, I get this message right before the memory usage reaches 2GB:
CAVIStreamSynth: System exception - Access Violation at 0x4a548612, writing to 0x0

As a workaround I can use setmemorymax(1500) (or some other value below 2048), but that doesn't seem like it guarantees any memory allocated will be below 0x80000000.

[IanB]

@Squid,

I think you will find you have simply exhausted the 2GB address space. Avisynth is absolutely crawling with code that does malloc's and does not check the result before trying to use it.

However I would expect some failures should be from env->NewVideoFrame() which does check, and should return "NewVideoFrame: Returned 0 image pointer!" or "NewPlanarVideoFrame: Returned 0 image pointer!" but no-one ever seems to see these messages.

:Edit: Yes I guess they won't because we should be checking vfb->GetWritePtr() which had the big malloc.

I have already clamped the initial SetMemoryMax to 1GB for the next RC (get a sneak peak from the Installer Translation thread).

And I guess you are now in a position to check if Avisynth survives life in a 3GB enabled host app. I believe the 1.8.* VDub's can be made 3GB aware quite easily.

[AnnaFan777]

after installing 2.58 RC2, I can't use avisource to open my DV files (ntsc).

"could not open video stream in any supported format"

not i can only open them with directshowsource.

windows98, sonydv codec.

any suggestions?

[squid_80]

Indeed, when using virtualdub compiled with /LARGEADDRESSAWARE the memory usage peaks around 2100M with no crash. I should have known since I've had avisynth64 chew up over 5G of memory before, but that's still mostly 2.55 code.

Reading up on GlobalMemoryStatus(), the MSDN documentation seems a bit lacking so I might run some tests. It worries me slightly that -1 is meant to indicate an overflow, but last time I looked a SIZE_T was unsigned.

[IanB]

@AnnaFan777,

Yes there is a bug with opening RGB24 decoded output format. I will fix it for RC3.

In the meantime you could try installing cedocida 2.0 (http://neuron2.net/misc/cedocida020.zip)

[IanB]

Changelist with respect to 2.5.8 RC2: See 1st post for full change list.

Additions:

* Added Polish doc translation (by Slim, Krismen & Co).

Bugfixes:

* Fixed AviSource() decoding to RGB24 logic regression.
* Added workaround for HuffYUV, Xvid reading past end of input buffer.

Changes:

* Test VFB data buffer for NULL malloc's, if so then Throw!
* Initial Memory Max value clamped to 1GB.
* Installer Start menu shortcut names translated.

As usual download from Sourceforge (http://sourceforge.net/project/showfiles.php?group_id=57023&package_id=105994&release_id=616887).
Enjoy! :cool:

Special thanks to the installer translation contributors.

[squid_80]

IanB: I tried out RC3 with virtualdub and the memory max clamp does it's job, but there's a small catch: when virtualdub's play input/play output buttons are used, it seems to open another copy of the input which subsequently chews up another 1Gb. When the total memory used reaches approx. 2Gb vdub freezes and I have to kill it.

Not sure if steps should be taken to fix this, because:
It's easily mitigated by using SetMemoryMax()
It only happens during preview, so a 30 hour encode won't be ruined by the last X frames being replaced with the "System Exception" message

[IanB]

@Squid,

This simple script should prove/disprove the multiple open theory :-BlankCLip()
WriteFileStart("ABC.txt", """Time("%c")""", True)This memory management issue needs some hard thinking. Maybe I should add an env->malloc() call to the API, but the how do you make filter authors use it in preference to the standard calls.

[smok3]

'portable' install seems to be gone?

[IanB]

Select the type of install: "Standalone"

[smok3]

ups, i missed that the first 3 times :/

[squid_80]

Looks like there's something else going on... the script you gave doesn't indicate multiple opening, but there's definitely something strange happening. Scrubbing the timeline shows memory usage increasing up to the setmemorymax value, then previewing increases it to 2x the setmemorymax value (freezing if it reaches 2Gb).

While researching I came across this: _set_new_handler (http://msdn.microsoft.com/en-us/library/a45x8asx.aspx). Whether it's usable or not (to flush/shrink the cache when a malloc fails and subsequently retry), I'm unsure.

[Blue_MiSfit]

I tried RC3 and noticed that Histogram() seems borken...

I reverted to 2.5.7 and it works fine. :D

~MiSfit

[IanB]

@Squid,

Unfortunately _set_new_handler is process global and Avisynth, being a library, should not change such things. Well I could flip it in the AviFile entry and restore it in the exit code, but that does not help the apps that do direct access via IScriptEnvironment.

Does a simple Colorbars() only script exhibit this behaviour? i.e. only has 1 VFB total.

Is this a memory leak outside of the SetMemoryMax controlled scope?



Histogram() seems borkenA little more detail might be nice. Added AudioLevels and Color2 modes to Histogram.
Fixed Histogram() Classic mode pixel values exceeding YUV limits.
Fixed Histogram() chroma plane initialization to 128.

Putting on my psychic hat, I intuit you are complaining about the brightness of the histo points. Previously they started at 0 and ramped up to 255 for a total populaton count of 64 and greater. counts less than 4 were ultra black and counts greater than 59 were ultra white. Now the values are between 16 and 235 proportional to the population.
> const int S2 = ((235-16) << 16) / (vi.width-256);
...
< p[x*2+vi.width*2-512] = min(255, hist[x]*4);
> p[x*2+vi.width*2-512] = max(min(235, ((hist[x]*S2)>>16) + 16), 16);

Might have been nice to discuss when it was first done, instead of waiting until we are doing release candidates :(

[Blue_MiSfit]

@IanB:

You're absolutely right I should have given you some more details. Sorry :)


MPEG2Source("I:\BluRay Rips\Girlgasmic\gg.d2v", cpu=0)

Histogram


Here's what I see with 2.5.7:
http://img507.imageshack.us/img507/7798/257hu9.jpg

And again with 2.5.8 RC3:
http://img511.imageshack.us/img511/9766/258bw6.jpg

FYI - the source is MPEG-2 1440x1080 anamorphic from a BluRay. In both images, the same frame is being decoded, but I fail to see the usefulness of histogram() in 2.5.8 RC3. Perhaps I need to set a parameter to get the "old" behavior of histogram()?

~MiSfit

[halsboss]

Just a lowly wondering ... is an MT http://forum.doom9.org/showthread.php?t=94996 version of v2.5.8 being considered in some way, aligning with this great work ?

[Seraphic-]

Is it recommend to use AviSynth 2.5.8 RC3 or should you still use AviSynth 2.5.7 for now? Thanks

[IanB]

@Seraphic-,

Unless someone finds a show stopper bug, RC3 will be renamed 2.5.8 official. So you had better test it, find and report any unliveable bugs you need fixed.

@Blue_MiSfit,

If you want Histogram fixed you need to find a bug worthy of me doing a RC4. I have significantly enhanced the brightness and scaling of the Histogram graph in the 2.6 stream. I need a more prominent bug before I can consider porting the new code back into the 2.5 stream.

[josey_wells]

I want to propose a change to the way that AviSynth allocates memory. I am running a computer with 8GB of memory running Windows Server 2008 x64. Windows Server will cache a lot of files in memory if available and report a lower free memory available then is really available. I would like to propose that available memory be based on amount of memory in computer, i.e Total Physical Memory.

For example from the V2.5.7 code

int ScriptEnvironment::SetMemoryMax(int mem) {
MEMORYSTATUSEX memstatusex;
__int64 mem_limit;

GlobalMemoryStatusEx(&memstatusex);
memory_max = mem * 1048576i64; // mem as megabytes
if (memory_max < memory_used) memory_max = memory_used; // can't be less than we already have
mem_limit = (__int64)memstatusex.ullTotalPhys - 5242880i64;

...
}

and from script environment

MEMORYSTATUSEX memstatusex;
GlobalMemoryStatusEx(&memstatusex);
// Minimum 16MB, otherwise available physical memory/4, no maximum
if (memstatusex.ullTotalPhys > 64*1024*1024)
memory_max = (__int64)memstatusex.ullTotalPhys >> 2;
else
memory_max = 16777216i64;
}

GlobalMemoryStatusEx was used instead of GlobalMemoryStatus since the non-ex problem supposedly has problems with memory above 4GB according to MSDN documentation

thoughts?

[IanB]

@josey_wells,

What you propose would be suicidal. Increasing the default to 50% of dwAvailPhys, when more than 256MB was available in 2.5.8, caused problems with 32bit processes readily exhausting the 2GB address space. I now clamp the initial default to 1GB. SetMemoryMax() can set the limit higher for those who think they know what they are doing.

I have previously experimented the using dwAvailVirtual instead of dwAvailPhys to restrict SetMemoryMax() calls and it always ended in tears. Either a crash or severe page faulting. Much of the code in Avisynth that does malloc's, foolishly does not check the return pointer for NULL. This inevitably leads to Null pointer exceptions in the least up to severe corruption at the worst. So any change in strategy to reduce protecting users from themselves also needs a fair amount of effort to seek and destroy all the unchecked malloc's that currently infest the code.

SetMemoryMax() sets the limit for the VideoFrameBuffer pool allowed for caching. It does not control or consider memory malloc'd for other uses within Avisynth, the plugins or the hosting application. For the cache to be useful at least 1 GetFrame call somewhere must request a given frame number more than once. If a recalcitrant script needs more memory in its GetFrame chain it will be given whatever it needs above the SetMemoryMax() imposed limit, possibly dieing in the attempt.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

For a library used with 32bit application GlobalMemoryStatus is preferred over GlobalMemoryStatusEx because it does clamp values based on the address space limits for a 32bit process i.e. 2GB (3GB with 4 GT RAM Tuning enabled).

Hint: When using GlobalMemoryStatusEx you must set MEMORYSTATUSEX statex; statex.dwLength = sizeof (statex); before your call.

[josey_wells]

IanB, thank for the explanation. The reason for the post was I kept getting Out Of Memory errors from AviSynth when running scripts with blu-ray processing, i.e. 1920*1080. I tried SetMemoryMax to no avail also.

My solution which seems to be working thus far is to disble large system file cache via a registry entry which frees available memory for programs. This seems to be working thus far.

But something is still amiss since I was getting failures when the program calling the AviSynth was approaching 1.3 GB of usage even though I have plenty more memory still available. I am using AviSynth 2.5.8 RC3 at the moment.

[IanB]

@josey_wells,

Are you explicitly getting this exception?ThrowError("GetFrameBuffer: Returned a VFB with a 0 data pointer!\n"
"size=%d, max=%I64d, used=%I64d\n"
"I think we have run out of memory folks!", size, memory_max, memory_used);Or are you getting some other error. Either way please report all the information.

At 1.3GB you are probably suffering from fragmentation. i.e there is 700Mb free and you want a 3Mb chunk but the biggest free chunk is only 2.9Mb but the good news is that there are 241 of them. This happens when varying size memory blocks are being malloc'd and then only some are free'd. Avisynth tries to avoid this by saving and reusing everything it malloc's, but not all the code adheres to this policy and 3rd party filter mostly do not.

:script: YV12 HD Frames are 3Mb, RGB32 HD Frames are 8Mb. Although inconveniently large L1/L2 cache wise, you still get a lot of them per GB. If you are using MVTools, complain in it's thread. It mallocs hugh amounts of memory for it's idx cache and this is well beyond Avisynth control. Best advice I can offer is to set SetMemoryMax to a lower value and pray.



@All,

Maybe I should revert to the old value, 25% of dwAvailPhys, for the initial SetMemoryMax, at 50%, there seems to be a lot of stuff crashing out.

.

[squid_80]

For a library used with 32bit application GlobalMemoryStatus is preferred over GlobalMemoryStatusEx because it does clamp values based on the address space limits for a 32bit process i.e. 2GB (3GB with 4 GT RAM Tuning enabled).

I did some checking and this isn't always the case. It's true if the pc has between 2Gb and 4Gb of ram but if the machine has >4Gb, the values are clamped to 2^32-1. (This was tested with LARGEADDRESSAWARE:NO explicitly set.)

So 25% of dwAvailPhys would be 1Gb... Same as current RC.

[IanB]

@squid_80,

So are you suggesting I clamp at 512MB as well as restore the init value to 25%.

[josey_wells]

@josey_wells,

Are you explicitly getting this exception?ThrowError("GetFrameBuffer: Returned a VFB with a 0 data pointer!\n"
"size=%d, max=%I64d, used=%I64d\n"
"I think we have run out of memory folks!", size, memory_max, memory_used);Or are you getting some other error. Either way please report all the information.

If you are using MVTools, complain in it's thread. It mallocs h
uge amounts of memory for it's idx cache and this is well beyond Avisynth control. Best advice I can offer is to set SetMemoryMax to a lower value and pray.

Maybe I should revert to the old value, 25% of dwAvailPhys, for the initial SetMemoryMax, at 50%, there seems to be a lot of stuff crashing out.


Yes that was the error message that I was getting. Since disabling the large system cache I have not had this error. Which indicates that too small of buffer was originally allocated because of low free memory.

MVTools - It wouldn't do me any good to complain in that post since I am the one working on an update multithreaded version. :) I have been replacing places in the code were several thousand news were performed with a single new. This should greatly help memory fragmentation.

IMO - I am in agreement with 25% of Available physical memory use the EX function for memory.

[squid_80]

@josey_wells: The LargeSystemCache registry key does not have any affect on x64 versions of windows. Also the cache lives in the kernel's virtual address space, not user space.

[josey_wells]

@josey_wells: The LargeSystemCache registry key does not have any affect on x64 versions of windows. Also the cache lives in the kernel's virtual address space, not user space.

By golly you are correct. Looks like Microsoft has deprecated the registry entry.

However, if I launch the application before a large amount of caching has taken place, i.e. high free memory reported, no problem. However, I haven't had a crash in a while since making a large amount of memory management problems in MvTools.

IMO - I still lean toward the proposed change.

[squid_80]

@squid_80,

So are you suggesting I clamp at 512MB as well as restore the init value to 25%.
Clamp availPhys to 2Gb and init to 25% - yes, same thing.

That's where my vote currently stands, although only because it seems to be the safest all-round fix. What sort of problems did using dwAvailVirtual cause? It would be nice if the cache could shrink/grow somehow based on the curent memory usage.

[IanB]

... problems did using dwAvailVirtual cause?Basicly there was no protection against insane memory_max values. You could always max out the address space with cache buffers, assuming you had enough disk space to VM your way there.

I am now thinking of limiting the default to an even lower value, like 300Mb. Most everyday scripts cannot really make use of even that much cache.

And in addition to the current constraints, I will also limit SetMemoryMax() calls to 75% of dwAvailVirtual, just to be sure. This will limit the total address space usage due to the Avisynth cache to 2.25GB on a 3GB aware application, (1.5GB normally).

As the current infrastructure is, we really need to stay well away from risking exhausting the address space.

[squid_80]

Ah right. I forgot about VM.

Something rather unrelated: Would there be an easy way to make avisource cache implicitly decoded frames? I think this is how it currently works, correct me if I'm wrong: if frame 5 (a delta frame) is requested and frame 3 is the nearest previous keyframe, frames 3, 4 and 5 are all decoded but only 5 is added to the cache. Subsequently if frame 4 is requested, 3 and 4 are decoded again. How feasible would it be to add an avisource parameter (bool recurse or some such) that executed recursive avisource calls back to the previous keyframe, caching each frame as it was decoded?

Failing that idea I guess it could be done with a custom plugin working from an index file created by prescanning the avi. Speed gains from using ICDECOMPRESS_PREROLL would be lost but they're normally negligible anyway (thanks a lot, packed bitstream mode).

[IanB]

Unfortunatly a child pclip cannot poke data into the parent cache pclip and xxxSource's are always at the end of the GetFrame chain.

You need a proxy filter to fetch the requisite frames through a cache instance. Currently I abuse ChangeFPS(last, last, True) to deal with linear access issue, but it is only good for upto 10 frame hops.

[Quark.Fusion]

But something is still amiss since I was getting failures when the program calling the AviSynth was approaching 1.3 GB of usage even though I have plenty more memory still available. I am using AviSynth 2.5.8 RC3 at the moment.
Look how much virtual memory was allocated — used physical memory is usually lower for avisynth, but crash will ocur when trying to allocate more that 2GB of virtual memory.

[Quark.Fusion]

Unfortunatly a child pclip cannot poke data into the parent cache pclip and xxxSource's are always at the end of the GetFrame chain.

You need a proxy filter to fetch the requisite frames through a cache instance. Currently I abuse ChangeFPS(last, last, True) to deal with linear access issue, but it is only good for upto 10 frame hops.

Hmm i don't know about that trick :) Always failing in chaining multiple avisynths with linear source.

What about making OutOfProcess() filter, that will call another avisynth process and process child filter/script there?
Like process=CreateNewProcess("""
clip1=ParentProcessSource(1)
clip2=ParentProcessSource(2)
param=GetParentProcessVar("somevar")
clip=SlowAndMemoryHogFilter(clip1, clip2, param)
EndOutOfProcess(clip)
""")
OutOfProcess(process, clip1, clip2)

result=ConcurrentOOP(process1=process, source1a=clip1, source1b=clip2, \
process2=process, source2a=clip1, source2b=clip2, \
process3=process, source3a=clip1, source3b=clip2, \
process4=process, source4a=clip1, source4b=clip2)
clip1=OOPextract(result, 1)
clip2=OOPextract(result, 2)
clip3=OOPextract(result, 3)
clip4=OOPextract(result, 4)


process=ImportAsNewProcess(avsfile)
clip1=SelectEvery(4,0)
clip2=SelectEvery(4,1)
clip3=SelectEvery(4,2)
clip4=SelectEvery(4,3)
result=ConcurrentOOP(process1=process, source1a=clip1, \
process2=process, source2a=clip2, \
process3=process, source3a=clip3, \
process4=process, source4a=clip4)
clip1=OOPextract(result, 1)
clip2=OOPextract(result, 2)
clip3=OOPextract(result, 3)
clip4=OOPextract(result, 4)
Interleave(clip1, clip2, clip3, clip4)

[Gavino]

Changelist with respect to 2.5.7:
Bugfixes:
* Fixed Parser FunctionTable::TypeMatch() missing compulsory arguments.

Is this the same thing that you are talking about here:
I recently enhanced the parser to handle overloaded function definitions based on the named argument, previously it only used the argument type pattern (ignored the arg names).
This might have a bearing on a problem I am investigating.

[IanB]

@Quark.Fusion,

:search: Posts by squid_80 and IanB discussing calling 32bit plugins from 64bit Avisynth.

@Gavino,

* Fixed Parser FunctionTable::TypeMatch() missing compulsory argumentsThis was a bug where a filter arg definition would declare arg 3 is mandatory, but a script calling the filter without 3 args would slip through unchallenged and crash the filter. I think it was Fizick who reported the bug. Review the CVS history to see what was done.

I recently enhanced the parser to handle overloaded function definitions based on the named argument, previously it only used the argument type pattern (ignored the arg names).Previously for filter arg definitions that only differed in the named arguments, only the 1st definition in memory could not be accessed. i.e for "tom", "cii[dick]" and "tom" "cif[harry]" the "harry" arg version was inaccessible.

This might have a bearing on a problem I am investigating.Don't hoard bugs, share them around. ;)

[Gavino]

Previously for filter arg definitions that only differed in the named arguments, only the 1st definition in memory could not be accessed. i.e for "tom", "cii[dick]" and "tom" "cif[harry]" the "harry" arg version was inaccessible.
...
Don't hoard bugs, share them around. ;)
Unfortunately, it's a problem reported in my own plugin. :(
It works OK on Avisynth 2.58 but not on 2.57, hence my interest in possibly-related changes.
It would make me feel better if I could blame it on a parser bug :devil: (especially a fixed one).

I have a nasty feeling it's related to the issue I raised here and the fix I came up with, which is similar to your "harry" example.

[IanB]

@Gavino,

Post 1174023, "MPEG-4 Encoder GUIs" -> "RipBot264 v1.10.5 - Simple and easy to use GUI -> IPOD . PSP . CONSOLES . BLURAY" #2317 by duramaximus discussing ripping m2ts streams. :confused:

Thread 139206, "Avisynth Development" -> "Calling internal function from plugin with same name" discussing monkey patching. :confused:

Neither issue was a classic "bug". With the first as long as the user called the function correctly there was no problem, if the arg list was incomplete then it didn't complain as expected. With the 2nd I removed a restriction that has always been present.

[Gavino]

Post 1174023 ... :confused:
Whoops, sorry, it should have been 1174203. I've edited the link now.

It seems the approach I took to enable my 'monkey-patching' relies on your parser extension. I didn't realise this was a recent change, so foolishly assumed without retesting that it would work on older versions of Avisynth. :o

[Zep]

But something is still amiss since I was getting failures when the program calling the AviSynth was approaching 1.3 GB of usage even though I have plenty more memory still available. I am using AviSynth 2.5.8 RC3 at the moment.

wow I wish I read this sooner. I see the exact same behavior in 2.5.7 and 2.5.8. When I reach around 1.3 GB things start to go crazy (crashes or freeze or Vdub just instantly quits) even though I have at least 700 megs free of the 2 gig address space (using XP 32 with 4 gig total physical ram) of that VDub process.

[Zep]

@josey_wells,

Are you explicitly getting this exception?ThrowError("GetFrameBuffer: Returned a VFB with a 0 data pointer!\n"
"size=%d, max=%I64d, used=%I64d\n"
"I think we have run out of memory folks!", size, memory_max, memory_used);Or are you getting some other error. Either way please report all the information.

At 1.3GB you are probably suffering from fragmentation. i.e there is 700Mb free and you want a 3Mb chunk but the biggest free chunk is only 2.9Mb but the good news is that there are 241 of them. This happens when varying size memory blocks are being malloc'd and then only some are free'd. Avisynth tries to avoid this by saving and reusing everything it malloc's, but not all the code adheres to this policy and 3rd party filter mostly do not.

.


so there is no way to get access to that 700 in continuous block? I thought most OS had some sort of cleanup call that defrags the memory. I know OSX does with handles i.e. a process uses handles which is a pointer to a pointer so blocks can move since your handle is always pointing to the correct address. if you need speed you can defrag the space then lock down the block(s) the handle(s) point to and deref the handle and access the block as if you have a direct pointer. This lets you do clean up when ever you want by unlocking everything. making a cleanup call then locking everything back down then use deref handles for speed etc...

anyway wish I read this thread sooner :)

[Leak]

so there is no way to get access to that 700 in continuous block?
That's not an OS problem, but a language/runtime problem. C/C++ and MSVC runtime hand out pointers to all memory they allocate, so compacting free memory is a sure-fire way to crash your program.

Java, Managed C++ and a boatload of other languages does Garbage Collection, though, but since AviSynth is C++ no can do.

[Zep]

That's not an OS problem, but a language/runtime problem. C/C++ and MSVC runtime hand out pointers to all memory they allocate, so compacting free memory is a sure-fire way to crash your program.

Java, Managed C++ and a boatload of other languages does Garbage Collection, though, but since AviSynth is C++ no can do.

It is an OS problem. If an OS does not supply low level managers then all dev tools/languages end up using a non standard way of doing things and their own libs and thus you get the exact problem we have on XP. On OSX all languages have access to handles because it is OS basic functionally. (memory manager is at kernel level of the OS and all request for memory are sent to it) There is no "C++ no can do" which is just crazy.

As for crashing of course if memory content moves and your pointers are made bogus you crash lol Why do you think I brought up handles? :)

[squid_80]

If you do a malloc on OSX you get a pointer returned (if successful), same as on windows. How is this any different?

[Leak]

It is an OS problem.
It's not an OS problem, as memory fragmentation only happens inside a program's address space - an x86 OS only hands out memory in pages (usually 4 kB in size) which don't have any fragmentation issues.

It's up to each application and/or library to support the memory management it wants/needs - but usually it's just malloc()/free() and that's that.

Java or C#/.NET CLR on any platform will garbage collect/compact memory without a hitch, but for C/C++ your program and all libraries it uses need support for doing that.

Usually it's just garbage collection and no memory compaction since that needs knowledge where the pointers in your objects are *AND* a mechanism to make sure nothing accesses the objects you're compacting while the compaction is being done...

But unless your OS is 100% managed (like MS's Singularity (http://en.wikipedia.org/wiki/Singularity_(operating_system))) it's up to the applications/runtime libraries to support all this, not the OS itself.

[josey_wells]

I recently pulled down V2.5.8 RC3 and tried to compile. I successfully got it to compile but there were >600 compiler warnings.

One could argue whether the secure versions of the library functions are really needed or whether some of the typecast are needed - IMO some of them are. But there were also a significant number of variable scoping problems.

Below is source code and diffs to sourceforge version.

http://rapidshare.com/files/140234230/AviSynth_V2.5.8.rar.html

http://rapidshare.com/files/140234231/AviSynth_Compare.rar.html

Also, there does not seem to be a debug version of the devil.lib included.

Heopfully some of these changes will improve this already great product.

[Gavino]

Java or C#/.NET CLR on any platform will garbage collect/compact memory without a hitch...
Garbage collection does have its downsides - mysterious bugs.

Long ago, I worked on an Algol68 compiler whose garbage collector started collecting itself. Talk about disappearing up your own backside... :eek:

[@IanB: Sorry for going off-topic]

[IanB]

The other part about running out of address space at 1.3GB usage is that Windows is a Virtual Memory environment. You really should be checking the amount of VM allocated to the process as well. And do not forget, in that 2Gb of available address space also lives the code, data and stack segments. 1.3GB is an incredible amount of memory. To get some context it is room for 170 high definition rgb32 frames or 2700 standard definition YV12 frames. The most temporally demanding filters may need upto 15 frames from the cache. Unless a given frame is requested more than once in a script the cache can offer no performance increase.

And talking about garbage collection and compaction environments here is off topic, this thread is about problems with version 2.5.8 Release Candidates, currently number 3. Please open new threads to discuss all these other interesting but off topic subjects.

Also release candidate means we are in Mortein/Baygon* the last few bugs just before we push the product out the door mode. We do not make radical changes like switch compilers or start using the "safe" libraries.


* - Bug spray products.

[josey_wells]

Also release candidate means we are in Mortein/Baygon* the last few bugs just before we push the product out the door mode. We do not make radical changes like switch compilers or start using the "safe" libraries.


* - Bug spray products.

No problem, these can be queued for V2.5.9.

[IanB]

Changelist with respect to 2.5.8 RC3: See 1st post for full change list.

Additions:

* Updated Japanese documentation [20080813] (Niiyan).

Bugfixes:

* Fixed DirectShowSource() grey frames after end of stream + 30 frames.
* Fixed Histogram() Classic mode restore graph brightness. Regression.
* Fixed Compare() graph pixel values exceeding YUV limits.
* Fixed AddBorders() args negative value clamping.

Changes:

* Initial Memory Max value clamped to 512MB.
* Default Memory Max value restored to quarter of Free memory. Minimum 16Mb. As per 2.5.7.

As usual download from Sourceforge (http://sourceforge.net/project/showfiles.php?group_id=57023&package_id=105994&release_id=623171).
Enjoy! :cool:


If we do not find any show stopper problems this could become the official 2.5.8 release. ;)

[Fizick]

IanB, I try translate changes.
What is difference: "Initial Memory Max value" (< 512 MB) versus "Default Memory Max value" (quarter of free, >16 MB)?
It is same parameter?

EDIT: So, what is (memory) changes "with respect to v2.57" ?

[IanB]

I try translate changes.
What is difference: "Initial Memory Max value" (< 512 MB) versus "Default Memory Max value" (quarter of free, >16 MB)?
It is same parameter?Yes, they are the same thing.EDIT: So, what is (memory) changes "with respect to v2.57"?The "quarter of free, Minimum 16MB" is the same as 2.5.7 again.

The Maximum of 512MB is new, i.e. on a Vista64 with 4GB free 2.5.7 would start with a 1GB MemoryMax and could possibly crash out the 2GB address space limit, now 2.5.8rc4 limits to 512MB.

Earlier 2.5.8's used 50% of the free and crashed out the 2GB address space limit even easier.

All this just effects the Default or Initial MemoryMax value.

:devil: Users can still use SetMemoryMax() to set higher or lower limits to get themselves into trouble. :devil:

[Fizick]

IanB,
1. Thanks.
2. May be you (we) can somehow summarize some of the 2.5.7 to 2.5.8 changes for releasenotes.htm?
To provide the most important changes here.
Now it simply duplicates the changelist.htm
Similar to "DirectShowsource improvements,..."

Thoughts ? :)

3. Your sourceforge link is https instead of http :)

[LoRd_MuldeR]

2. May be you (we) can somehow summarize some of the 2.5.7 to 2.5.8 changes for releasenotes.htm?

http://forum.doom9.org/showpost.php?p=1142622&postcount=1

[Wilbert]

That's not a summary :)

[IanB]

3. Your sourceforge link is https instead of httpFixed! Damn those sourceforge https junkies.

Yes the release notes are a bit tatty but ...

[Fizick]

Ian, not related to summary, but please do not skip: I make some small changes (mostly typos of russian doc) at CVS

[IanB]

@Fizick,

So I take this as a request to make a 2.5.8 RC4a. I'll find some time latter this week.


Anybody else got some last minute doco/language type updates? Squeak now!

[Fizick]

I do not asked for it :)
But I ask somebody look to uptated description of ConditionalFilter (I do not use it much) at CVS http://avisynth2.cvs.sourceforge.net/avisynth2/docs/english/corefilters/conditionalfilter.htm?r1=1.6&r2=1.7 and wiki
http://avisynth.org/mediawiki/ConditionalFilter

[Wilbert]

What's the difference between a filter and a function in this case?

[Fizick]

IMO, AverageLuma(clip) and similar expressions with numeric result are not filters, but functions (in ConditionalFilter).
Filter must return filtered clip (in ScriptClip).

Previous text used "filter" and "function" in not consistant manner.
There were also some other non-clear fragments like this for ConditionalFilter:


The string filter can be any internal filter, but also some filters which are predefined (the Runtime Functions).


What internal filter may be alone used in ConditionalFilter?
Why internal and predefined only? What about plugin or user script functions?

The right changes are not obvious for me, it is hard topic for me, and proper English too, that is why I ask for discusssion. :)

[Gavino]

I ask somebody look to uptated description of ConditionalFilter (I do not use it much) at CVS http://avisynth2.cvs.sourceforge.net/avisynth2/docs/english/corefilters/conditionalfilter.htm?r1=1.6&r2=1.7 and wiki
http://avisynth.org/mediawiki/ConditionalFilter
I have taken the liberty to update the wiki. I hope this is OK.

This was before I saw Fizick's conversation with Wilbert, but I think that just confirms what the issue was, and I agree with Fizick.

[Fizick]

Gavino,
O.K.
I also added current_frame to list (see wiki).
Waiting for comments from Wilbert (and others), then shall update CVS.

[Gavino]

I have further updated the same wiki page to state explicitly that line breaks may be used in the ScriptClip string.

[Wilbert]

The changes are fine with me.

[Fizick]

Adding show="true" will display the actual values on the screen.)

What is usefulness of "show" parameter in ScriptClip?

[Gavino]

What is usefulness of "show" parameter in ScriptClip?
I imagine it's for debugging. Particularly if the filter string is constructed dynamically (eg by string concatenation which is a common approach inside functions).

It's curious that 'show' in ScriptClip (and FrameEvaluate) disables the actual filtering (it just returns the input clip) whereas in ConditionalFilter it acts in addition to the normal function.

[Fizick]

OK, I uploaded the updated text to CVS.
I hope that new text is fine not only with Wilbert, but with Avisynth code too :)

[IanB]

Changelist with respect to 2.5.8 RC4 [080831] :

Changes:

* Updated Russian documentation (Fizick).

Note : Other contents are the same as AviSynth_080831.exe


Changelist with respect to 2.5.8 RC3: See 1st post for full change list.

Additions:

* Updated Japanese documentation [20080813] (Niiyan).

Bugfixes:

* Fixed DirectShowSource() grey frames after end of stream + 30 frames.
* Fixed Histogram() Classic mode restore graph brightness. Regression.
* Fixed Compare() graph pixel values exceeding YUV limits.
* Fixed AddBorders() args negative value clamping.

Changes:

* Initial Memory Max value clamped to 512MB.
* Default Memory Max value restored to quarter of Free memory. Minimum 16Mb. As per 2.5.7.

As usual download from Sourceforge (http://sourceforge.net/project/showfiles.php?group_id=57023&package_id=105994&release_id=625750).
Enjoy! :cool:


If we do not find any show stopper problems this could become the official 2.5.8 release. ;)

[Quark.Fusion]

TCPsource/TCPserver sometime lost connection and broke my encode, also AviSynth crash a lot when I run script with TCPsource second time. (not tested with today's build)
Why TCPsource not tries to reconnect?

[IanB]

@Quark.Fusion,

TCPsource/TCPserver are unchanged from 2.5.7

[Fizick]

IanB,
sorry, but I made litle changes of doc again :)
(more compact look of overview.htm, english and russian)

[Fizick]

and again :)

[tacman1123]

Not sure if this is the right place to report possible bugs for RC4, if not, please let me know where is a better place.

I installed RC4, and the sound came out slower, a much lower frequency. I replaced DirectShowSource.dll with an older one


12/24/2006 05:12 AM 24,576 DirectShowSource.dll


and it started working again. Script was fairly trivial, but I'd be happy to post it (and my avi) if someone would like it. My AVI files have been somewhat problematic, especially in regard to sound (I have another thread here detailing that issue), so it's certainly possible that it's a bad avi, but since it is working with an older DirectShowSource.dll, I thought I'd mention it.

Tac

[Fizick]

tacman1123, of course, please provide link to your previous thread (post), and may be some Avi fragment.

[IanB]

@tacman1123,

Post the log from DirectShowSource(... , logfile="tac.log", logmask=-1) for both d..s..s...dll version!

[tacman1123]

cool, I'll do that! (The avi file is very big). Of course, now I'm having a hard time replicating the problem. Question: if I rename the dll in my plugins directory, is it definitely using the new version when the script runs? Or might it be caching a version? Is there a way I can force my script to use one over the other? I tried simply renaming the dll and calling it with that name, but that didn't work.

[IanB]

Use the {dllname}_{functionname} form of access the functions. i.e. DllA_DirectShowSource() and DllB_DirectShowSource()

And the logfile has a version stamp as the 1st line.

[Fizick]

small doc update again :)
(SetMemoryMax according to http://forum.doom9.org/showthread.php?p=1177819#post1177819 )

[Wilbert]

Someone reported:
My AviSynth is version 2.58, build date Aug 30, 2008. I have tried "ntsc_video" several times & I always get the same error message.
... being "ntsc_video" not recognized.

[Gavino]

Someone reported ... "ntsc_video" not recognized.
No, the error message he reported was "Video framerate doesn’t match" when importing into DVD slideshow GUI, which makes me suspect the fault lies with that program.

Further evidence is that he also got the same error for
AssumeFPS(30000,1001,true).

[DeathTheSheep]

Ever since 2.5.8 alpha 2, directshowsource with convertfps is terrible. The resultant video is very choppy. All I'm doing is converting an mkv's framerate from 24000/1001 to 23.976. I've tried every release up until RC4a, and all have the same glaring bug. Going back to alpha 1 [070518] works perfectly. I've reported this bug before and was told simply that directshowsource was hopelessly b0rked. Well, over a year's worth of releases, and getting to a late 'release candidate' stage... the bug's still here. ;)

Great work nonetheless!

[IanB]

@DeathTheSheep,

Seems you have made 3 posts alluding to the subject, 12th November 2007, 03:38, 28th March 2008, 07:50 and 28th March 2008, 09:15. None really form a concise bug report with any evidence, logs or supporting material.

CVS history of directshow_source.cpp----------------------------
revision 1.28
date: 2008/06/12 04:17:26; author: ianb1957; state: Exp; lines: +46 -7
Remember Allocator given in NotifyAllocator(), return it for GetAllocator();
GetAllocatorRequirements() E_NOTIMPL.
----------------------------
revision 1.27
date: 2008/05/26 22:22:17; author: ianb1957; state: Exp; lines: +106 -47
Add TID + PrintState to log, nuke PulseEvent + Use IGraphBuilder (Avery Lee),
Fix QueryId() need CoTaskMemAlloc (Dean Pavlekovic),
Fix QueryAccept change VideoInfo (Haali).
----------------------------
revision 1.26
date: 2007/10/08 23:09:39; author: ianb1957; state: Exp; lines: +14 -6
get convertfps=false logic right, fix Flush task interlock.
----------------------------
revision 1.25
date: 2007/09/11 06:43:04; author: ianb1957; state: Exp; lines: +122 -18
Refactor GetFrame, ConvertFPS now only relies on get_sample.GetSampleStartTime,
fix jitter problems with recent M$ asf spliter giving bogus SampleEndTime values.
----------------------------
revision 1.24
date: 2007/05/01 05:49:58; author: ianb1957; state: Exp; lines: +6 -1
support WAVE_FORMAT_EXTENSIBLE
----------------------------I guess you are complaining vaguely about the changes at version 1.25/26 2007 Sep 11 & Oct 08. I completely rewrote the GetFrame code to only use the DirectShow sample start times and not use the stop times at all. The previous code used the DirectShow sample stop time and failed miserably when it was not correctly provided. A few recent splitters seem to be not setting this value correctly.

The algorithm I implemented is to calculate the start time of the requested frame number. Compare this value with the DirectShow sample start time of the next sample, for as long as the value is strictly less than, keep returning copies of the current frame. I have extensively tested the code and it does exactly as intended.

I have to assume the algorithm is not what you require, but you have not offered any suggestion for an alternate algorithm.

One issue I am aware of that may be affecting your results is timecode rounding that a few splitters seem to do. For a CFR 23.976 fps stream, we would expect timecodes to be :-

--- 0, 4170837, 8341675, 12512512, 16683350, 20854187, 25025025, ..., 95929262, 100100100, 104270937, ...

but a splitter might give something like this :-

--- 0, 4200000, 8300000, 12500000, 16700000, 20900000, 25000000, ..., 95900000, 100100000, 104300000, ...

This results in returned samples being 0, 0, 2, 3, 3, 4, 6, ..., 23, 24, 24, ... not exactly what one might find useful.

You can limp around this particular issue by doubling the request framerate and selecting the odd samples, i.e.DirectShowSource(... , fps=23.967*2, convertfps=true).SelectOdd()But the bottom line is you need to understand your material and the Directshow software you are using and script accordingly.

[Fizick]

Directshow si never will be finished complitely :)
In any case, Directshowsource is a plugin and may be updated later (if needed), as an small independent upgrade to Avisynth 2.5.8.
Also for same reason DeathTheSheep can use older (alpha 1) DirectshowSource if he do not want provide a log ;).

[DeathTheSheep]

It's embarrassing to admit this, but I have no idea what/where the avisynth log is. I will happily provide it if I came upon this information. ;)

Cheers!

PS: I'm using Haali's splitter on what appears to be a fixed framerate mkv.
PPS: Though I have no suggestion for an "alternate" algorithm, I'd suggest preliminarily that both behaviors be retained, with the option to choose "convertfps=stoptimes" to use the older behavior.

[Fizick]

DirectShowSource(avifile,.., logfile="mylog.log")
http://avisynth.org/mediawiki/DirectShowSource
;)

[IanB]

PS: I'm using Haali's splitter on what appears to be a fixed framerate mkv.The solution I proffered above is specifically for mkv container conversion.... this particular issue by doubling the request framerate and selecting the odd samples, i.e.DirectShowSource(... , fps=23.967*2, convertfps=true).SelectOdd()If you look carefully the old version DSS, using stop time, does not get the VFR conversion right. With mkv containers the problem is less pronounced as the predicted stop times are the ceiling value, but this causes a problem whenever frame duplication is required, the next frame is repeated instead of the current one.

As I said :-But the bottom line is you need to understand your material and the Directshow software you are using and script accordingly.

[Wilbert]

One issue I am aware of that may be affecting your results is timecode rounding that a few splitters seem to do. For a CFR 23.976 fps stream, we would expect timecodes to be :-

--- 0, 4170837, 8341675, 12512512, 16683350, 20854187, 25025025, ..., 95929262, 100100100, 104270937, ...

but a splitter might give something like this :-

--- 0, 4200000, 8300000, 12500000, 16700000, 20900000, 25000000, ..., 95900000, 100100000, 104300000, ...

This results in returned samples being 0, 0, 2, 3, 3, 4, 6, ..., 23, 24, 24, ... not exactly what one might find useful.
Is there any easy way to find out when this is happening (without creating the log file)?

[Wilbert]

@IanB,

I will receive the Czech translation very soon, and I will add it in the coming days.

[Archimedes]

Standalone installation doesn’t work for me. A simple AviSource("video.avi") in the program directory of AviSynth doesn’t work.

http://img150.imageshack.us/img150/9559/avisyntherrorml4.jpg (http://imageshack.us)

[Fizick]

Archimedes,
1. what about version() script?
2. previous v2.5.7 works fine?

[Archimedes]

Same thing with Version(). Normal Installation works fine.

[IanB]

Install the main files in the Product directory (Nonfunctional non-Admin install) ...The Standalone installation is not intended to be functional out of the box. It just unpacks all the distribution files into your product directory. You are then responsible for manually updating the AviFile registry entries.

It is for cases where you cannot run the normal installer with admin privileges, but you have a backdoor to get the AviFile registry entries updated or you have an application that can use avisynth.dll directly without needing the AviFile registry keys.

[Archimedes]

Thank you. So the registry entries are always needed.

[Fizick]

Sorry, a missed (wrongly interpret) "Standalone" name.
By the way, may be rename it in installer? (I translated it as "partially portable" in Russian installer).
Or may be add some explaining comment to installer.

[IanB]

So the registry entries are always needed.Yes if you want to use the standard Windows AviFile interface to access your script.

Various people have been trying package a semi useful Avisynth for use on crippled SOE machines where they cannot do a standard Admin install. :search: Use search to find the various discussions about this and programs that can directly use Avisynth without any registry access.

[Zach]

The Standalone installation is not intended to be functional out of the box.

Could you expound upon that statement?

Case in point, I'm a fresh install of WinXP right now and was about to install AviSynth. Are you saying that if I go to SourceForge.net (http://sourceforge.net/project/showfiles.php?group_id=57023&package_id=105994&release_id=625750) and download and install AviSynth_080912.exe, it won't work?

Would installing 2.5.7 first and then installing this latest released beta over it be the correct install procedure then?

[Leak]

Are you saying that if I go to SourceForge.net (http://sourceforge.net/project/showfiles.php?group_id=57023&package_id=105994&release_id=625750) and download and install AviSynth_080912.exe, it won't work?
No, he isn't.

You can now choose between "Standard Installation" (or whatever the default is called) and "Standalone Installation" in the installer, and the latter just unpacks everything you choose to the destination folder without trying to register anything, in case you're on a locked-down user account that's not allowed to install new software.

[Zach]

No, he isn't.

You can now choose between "Standard Installation" (or whatever the default is called) and "Standalone Installation" in the installer, and the latter just unpacks everything you choose to the destination folder without trying to register anything, in case you're on a locked-down user account that's not allowed to install new software.

Ah, okay. It's a choice specified during the install process. I get it now. Thanks for clearing that up for me! :)

[Nightshiver]

Are there plans to make 2.5.8 "official" and get it out of RC?

[IanB]

Yes, but I have 2 very minor fixes (YV12 ShowFiveVersions, modified rounding in DSS ConvertFPS=True) and the Czech documentation pending. I just have not had any time to work on it, life is getting in the way of doing it. I hope to do a big push over the Xmas break.

If you don't need the Czech documentation, you might as well be using it. RC4 to RC4a was just some Russian Doc updates. And at this point the Final will have the Czech doc plus a few other general doc updates, with the 2 code fixes.

[Gavino]

Any plans to address the issue of BlankClip and implicit last (actually a general parser issue), reported here?

[IanB]

Yes, but not in this release.

[asarian]

Recently, the matter of AviSynth 2.5.8's downwards compatibility with 2.5.7 came up in this thread:

http://forum.doom9.org/showthread.php?p=1226105#post1226105

Instead of just speculating, or go by hearsay, I figured I might as well just ask the author directly. :)

Thanks

[IanB]

@asarian,

I have culled the changes list to things maybe related to your thread. Item 2 could be of most interest as early 2.5.8 releases allocated significantly more cache and this did cause problems, hence returning to 2.5.7 values for the final versions.

Most of the other changes should actually improve problem issues over 2.5.7.

There could of course be latent bugs that people are not reporting here.

Changes:

* Initial Memory Max value clamped to 512MB.
* Default Memory Max value restored to quarter of Free memory. Minimum 16Mb. As per 2.5.7.
* Added critical section to CAVIFileSynth class.
* CoUninitialize() done immediately for S_FALSE CoInitialize() returns, i.e we do not hold a COM use count.
* DirectShowSource() now attempts to use partial graph from failing RenderFile call.
* Relax YV12 resizer width restriction, now mod 2 was mod 4.
* SetCacheHints(CACHE_RANGE, n) will now surrender frames to satisfy SetMemoryMax().
* CoInitialize()/CoUninitialize() now done as part of ScriptEnvironment creation/deletion.

[asarian]

@asarian,

I have culled the changes list to things maybe related to your thread. Item 2 could be of most interest as early 2.5.8 releases allocated significantly more cache and this did cause problems, hence returning to 2.5.7 values for the final versions.

Most of the other changes should actually improve problem issues over 2.5.7.

There could of course be latent bugs that people are not reporting here.

Changes:

* Initial Memory Max value clamped to 512MB.
* Default Memory Max value restored to quarter of Free memory. Minimum 16Mb. As per 2.5.7.
* Added critical section to CAVIFileSynth class.
* CoUninitialize() done immediately for S_FALSE CoInitialize() returns, i.e we do not hold a COM use count.
* DirectShowSource() now attempts to use partial graph from failing RenderFile call.
* Relax YV12 resizer width restriction, now mod 2 was mod 4.
* SetCacheHints(CACHE_RANGE, n) will now surrender frames to satisfy SetMemoryMax().
* CoInitialize()/CoUninitialize() now done as part of ScriptEnvironment creation/deletion.

Thank you very much for your clear and helpful answer. :)

[IanB]

Changelist with respect to 2.5.8 RC4 [080831] : See 1st post for full change list.

Additions:

* Added Czech doc translation.

Bugfixes:

* Fixed ShowFiveVersions() YV12 chroma position in bottom half. Regression.

Optimizations:

* DirectShowSource() convertfps=true add 0.5ms rounding to expected sample time. Improves performance with millisecond based DS spliters.

Changes:

* Updated Russian documentation (Fizick).


As usual download from Sourceforge (http://sourceforge.net/project/showfiles.php?group_id=57023&package_id=105994&release_id=649730).
Enjoy! :cool:


I will promote this into the official 2.5.8 release in a few days, unless someone finds a serious issue. ;)

[halsboss]

Great ! Any news on what that means in relation to an MT version ? http://avisynth.org/tsp/

[IanB]

Going live, 2.5.8-RC5 [081227] is now 2.5.8 [081230] (http://sourceforge.net/project/showfiles.php?group_id=57023&package_id=72557&release_id=650255) :cool:

Well almost, Fizick, had a last minute translation to the Russian ReduceBy2 help. ;)

[Ajax_Undone]

Congrats IanB and thank you very much for your effort in bringing this to fruition... Thanks all who helped...

[LaTo]

Great!!! :thanks:

[elguaxo]

thanks! :)

[Kurth]

http://img519.imageshack.us/img519/3908/imagemmw0.png

Thanks for the new version :)

Installed the Dec 30th file but the Version command say Dec 22 :p

[buzzqw]

yea!

thanks for all the good work!

BHH

[IanB]

@Kurth,

Yes I did the full build on the 22nd. Niiyan and Fizick had some new texts translated for the installer, so I did a proof cut for them, when they confirmed their texts were okay I put up the RC5 release on the 27th, Fizick fixed his Russian ReduceBy2 help, so I recut the installer on the 30th. The Avisynth contents are the same in all 3 cuts, only the Russian and Japanese texts were corrected slightly.

Ideally the 3 releases would have been identical and all dated the 22nd, but things happened.

[Leak]

Shouldn't the copyright date have been extended to "2000-2008" as well? (Or just way 'til tomorrow and bump it to 2009... :D)

np: Kid606 - Oakland Highsiding (Pretty Girls Make Raves)

[asarian]

Outstanding job! Much appreciated! :)

[IanB]

Shouldn't the copyright date have been extended to "2000-2008" as well? (Or just way 'til tomorrow and bump it to 2009... :D)Damn! Missed one! Ahwell to late now :(

[hajj_3]

just if we could have a new gordian knot pack with this and latest dgmpgdec in, would be alot better.

[leeperry]

is it mandatory to have avisynth.dll in C:\Windows\system32\ ?

I've tried to copy it on my ramdisk & change the path of each avisynth.dll occurence in the registry, but if I don't have it there ffdshow refuses to work :confused:

also regsvr32 refused to register it...

[squid_80]

Why are you trying to store avisynth.dll on a ramdisk?

[leeperry]

Why are you trying to store avisynth.dll on a ramdisk?
to make ffdshow open movies faster :D
it's all on a ramdisk actually(ffdshow/kmplayer/hms+all my decoders)...only that avisynth.dll refuses to cooperate :rolleyes:

[Kurtnoise]

May I ask you to add something to the nsis script installer for the next release ?

WriteRegStr HKLM "SOFTWARE\AviSynth" "CurrentVersion" "${VERSION}" (line ~248)

that would be great...

:thanks:

[Fizick]

Kurtnoise,
what is there are several DLL versions in different folders (e.g. in VitrualDub folder), or DLL is updated by copying?

[Kurtnoise]

by dll, you mean avisynth.dll or the others ? Dunno frankly.

...but my point was to retrieve the avisynth version # somewhere (not via an avs script of course...;)) So, the registry seems fine to store that.

[Fizick]

The version info may be also retreaved from versioninfo structure of avisynth.dll ( I do not remember exact windows SDK function name).

[Kurtnoise]

right...but this implies to know where is located the avisynth lib. :)

[leeperry]

apparently it's mandatory to have it in %SystemRoot%\system32

[Kurtnoise]

or in the SysWOW64 folder...