View Full Version : AviSynth 2.5.8 Alpha 2 [September 19th] - Release!
Wilbert
18th May 2007, 14:53
The changelog of the most recent version (v2.58a2) can be found here (http://forum.doom9.org/showthread.php?p=1046774#post1046774).
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 (http://sourceforge.net/project/showfiles.php?group_id=57023).
Enjoy!
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 (https://sourceforge.net/tracker/?func=detail&atid=867362&aid=1676882&group_id=173941) 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... :D
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
18th May 2007, 20:53
Nice. An update. Thanks A Lot! :D
Does anyone know if This (http://forum.doom9.org/showpost.php?p=967060&postcount=164) 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
18th May 2007, 23:11
There is no function named SetCacheHints
i used
SetCacheHints(510, 10)
Avisynth 2.5.8 verified with version()
foxyshadis
19th May 2007, 01:07
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.
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!
@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. :confused: 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
19th May 2007, 05:21
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?
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
19th May 2007, 08:50
can you also shed some light about blackmanresize()
can you also shed some light about blackmanresize()
There was some discussion that ultimately lead to it being added to AviSynth here (http://forum.doom9.org/showthread.php?p=957735#post957735) in case you're interested... :)
np: Adult. - You Don't Worry Enough (Why Bother?)
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
19th May 2007, 15:26
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
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
19th May 2007, 18:06
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.
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... :D
np: Mikkel Metal - Dromos (Brone And Wait)
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 (http://leak.no-ip.org/AviSynth/VS2005/).
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)
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 :confused: 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, 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... :rolleyes:
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
20th May 2007, 01:45
can Soundtouch be converted to DLL? with non-compiler version-dependent calls from avisynth (LoadLibrary, .....)
like devil.dll
Ebobtron
20th May 2007, 03:21
@Ianb
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.My ideas are posted in that or another thread, I have nothing to add. I was just checking to see if a particular issue was the same as before. That being will it (as written) always un-initialize.
"CoInitialize()/CoUninitialize() now done as part of ScriptEnvironment creation/deletion."
I really don't know what that means. My guesses suck normally but if I must, it got moved out of dll main.
Thanks anyway professor.
Version string :confused: I haven't checked Wilbert build, but it should just have 8 instead of 7 and a new date. Will check.
Sorry, I was kidding, it is only a few pixels longer.
Thanks
Rob
Basically for each "open" of an AVS script you get a CoInit and for each "close" you get a CoUnInit instead of one global CoInit when avisynth.dll loads and one global CoUnInit when avisynth.dll unloads (possibly from a different thread and when all the other dll's/resources have been (are being) released and the process global lock is asserted).
Not sure if it is going to help or hurt, but this is why we try these things in prerelease builds. As I said if you have thoughts or problems please post them in the appropriate thread.
And the wink icon ; ) is for making jokes about a few pixels wider ;)
And Soundtouch etc as .dll's is a double edge sword. Which .dll has the user currently got active? Really these routines should be separate plugins so if they screw up it doesn't kill the core. And yes static linking against the matching .lib is pretty dumb, using LoadLibrary etc is much more controlled and safer and you get to print a helpless error message but you have search path problems hmmm fft.dll!
Fizick
20th May 2007, 08:43
other possible solution with Soundtouch is to put (integrate) its needed sources to Avisynth CVS tree, with or without intermediate lib production.
It is no joke ;)
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.
Well, after looking at the sourcecode some more I think I'll retract my request - yeah, clearing the cache et al wouldn't be too hard, but I've found that nothing really keeps track of all filter instances that are being used in a ScriptEnvironment, so asking them all to forget their calculations with regard to future frames (without destroying and recreating the ScriptEnvironment, which often takes too long for realtime use depending on the filters being used) is quite impossible now, and I don't think retrofitting everything to be able to do that is worth it - at least not for my purposes, where I can just make up new frame numbers for the source frames that are off far enough that any caching and pre-calculation that may have happened isn't an issue.
Of course, if there's some other use for clearing the caches I'm all for adding it... :)
np: The Go Find - Everything Is Low (Stars On The Wall)
tin3tin
29th June 2007, 23:35
With this version I get a much slower playback on even simple avisynth transitions like a dissolve(in DVD slideshow GUI). The previous version almost played it realtime. :confused:
IanB
30th June 2007, 05:33
:script: How much slower are we looking for?
tin3tin
30th June 2007, 08:41
The script is the generated script in DVD slideshow GUI. What I've noticed is with ex. 32 slides 2.5.7 slows down with 0.2 fps and 2.5.8 slows down with 5-10 fps in dissolve transitions when previewing in Media Player Classic. So it is quite visible.
DVD slideshow GUI can export to .avs. However the scripts is very dependent on a installed DVD slideshow GUI folder structure, so if you want to see the slow down, the easiest thing is to install it and export to avs(Avisynth 2.5.7 included, but you can cancel it).
You can download from here:DVD slideshow GUI (http://download.videohelp.com/tin2tin/download.html)
IanB
30th June 2007, 08:49
No! I want your script!
tin3tin
30th June 2007, 12:25
Okay, here's my script. MyScript.avs (http://download.videohelp.com/tin2tin/MyScript.avs)
But you will need a lot of files (automatic generated by DsG) to see the slow down. Ex. 36 different eBmp files (720x576)ect.
I hope you will find it useful.
Fixed Cache memory oversubscription of SetMemoryMax() limit.The default SetMemoryMax() is not high enough for your script. As from 2.58 it is enforced, ruthlessly!
Maybe we need a bigger default now? Thoughts?
tin3tin
2nd July 2007, 01:23
Okay, I'll test that.
Just a thought - it would be great if it also would be possible to set the memory limit as chosen procentage of the available physical and virtual memory. :)
[EDIT: ... Yes, if SetMemoryMax() is set high enough it runs fine. Can it be set too high? Will that have any bad influence on the playback?]
Myrsloik
7th August 2007, 22:33
Would it be possible to use LoadLibraryEx for loading plugins when it's available (xp and later)?
Doing so would make it possible to add the directory the plugin is stored in to the search path and avoid most trouble when dealing with plugins that have multiple files.
IanB
7th August 2007, 23:42
Doing so would make it possible to add the directory the plugin is stored in to the search path and avoid most trouble when dealing with plugins that have multiple files.Not sure I understand your premise, adding the .DLL directory to the path is already the current solution to the problem.
Also problems usually occur when plugins try to dynamicly load there support files and don't implement an adequate search proceedure for their own LoadLibrary calls. Changing this will not help in this case at all. This will only effect loading .DLL's staticly linked against a matching .LIB, which I am not aware has caused any problems.
You select these optional behaviors by setting the dwFlags parameter; if dwFlags is zero, LoadLibraryEx behaves identically to LoadLibrary.
DONT_RESOLVE_DLL_REFERENCES
LOAD_LIBRARY_AS_DATAFILE
LOAD_WITH_ALTERED_SEARCH_PATH
LOAD_IGNORE_CODE_AUTHZ_LEVEL
LOAD_LIBRARY_AS_IMAGE_RESOURCE
LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE
..., the search order is as follows: The directory from which the application loaded.
The current directory.
The system directory. Use the GetSystemDirectory function to get the path of this directory.
The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key.
..., the alternate search order is as follows: The directory specified by lpFileName.
The current directory.
The system directory. Use the GetSystemDirectory function to get the path of this directory.
The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key.If I have missed a point here, please spell it out.
There is a SetWorkingDir script function that is intended to resolve these problems, perhaps it need some care and feeding.
Myrsloik
8th August 2007, 00:54
The point was, as you suspected, dlls statically linked with a matching lib. I mostly suggested it because I've seen a couple of posts suggesting that all files of FFmpegSource should be dumped in system32 to "make it work".
I know there are other ways like stabbing the ignorant until they learn how to modify the PATH but LoadLibraryEx with LOAD_WITH_ALTERED_SEARCH_PATH just seemed like a simpler solution that shouldn't break anything. Or at least not that many things...
foxyshadis
8th August 2007, 04:47
Another option is for avisynth to internally add the avisynth plugin folder, as well as every (unique?) folder it encounters in the script's loadplugin calls. The environment is always per-process, after all, unless you export it; you can walk environ from stdlib.h until you get to path and add to it, from then on everything inherits from it. (putenv and setenv are global, unfortunately.) Edit: Oh, here's what I was looking for, screw that C cruft: SetEnvironmentVariable (http://msdn2.microsoft.com/en-us/library/ms686206.aspx).
As long as we're bitching and moaning, is there any good reason LoadPlugin can't check for the virtualdub or C/stdlib export name and hand off the loading appropriately? And by extension enable autoloading of C plugins?
IanB
8th August 2007, 13:40
We can't autoload VDub or VFAPI plugins because you have to manually name the the function and set the preroll. Interestingly the auto load code does LoadPlugin(*.dll) and then LoadPlugin(*.vdf). Hmmmmm!
We don't autoload C plugins because we can't tell one's which need to be loaded by avisynth_c.dll and ones which will load directly. I will be able to fix this for 2.6 C plugins, they are gonna get a new entry point name. And yes old one will still load the same as now.
The recommend proceedure is to explicitly load them in an .AVSI.
Also during autoloading of plugins the Current directory is the plugin directory. Any plugins that change the CWD will screw it for the remaining plugins.
And during a script Import the Current directory is the scripts directory. Any SetWorkingDir() calls get popped.
It might be possible to also set the current directory to the plugins directory during the LoadLibrary call, I would have to put it back for the PluginInit2 call to maintain current behaviour. However this would break the use of SetWorkingDir() calls anyone is using to manage this issue. Thoughts?
Fizick
19th August 2007, 07:21
I met some bug in v2.5.8 with any script.
Take version.avs
Play it with windows media player (mplayer2.exe, not MPplayerClassic) by right click - play (or by open).
Video is playing fine.
Stop playing and close player (file-exit).
I have crash with Windows Media Player messagebox:
error found, application will be closed.....
Send to Microsoft...
AppName: mplayer2.exe AppVer: 6.4.9.1125 ModName: quartz.dll
ModVer: 6.5.2600.2749 Offset: 000398b2
on debug - unhandled exception in quartz.dll,
0xC0000005 - access violation
Config: XP SP2
v2.5.7 works fine.
GrofLuigi
19th August 2007, 13:36
I met some bug in v2.5.8 with any script.
Take version.avs
Play it with windows media player (mplayer2.exe, not MPplayerClassic) by right click - play (or by open).
Video is playing fine.
Stop playing and close player (file-exit).
I have crash with Windows Media Player messagebox:
error found, application will be closed.....
Send to Microsoft...
AppName: mplayer2.exe AppVer: 6.4.9.1125 ModName: quartz.dll
ModVer: 6.5.2600.2749 Offset: 000398b2
on debug - unhandled exception in quartz.dll,
0xC0000005 - access violation
Config: XP SP2
v2.5.7 works fine.
Yes, I get (a different?) error too with version.avs :
ActiveMovie Window: mplayer2.exe - Application Error ( <- this is the title bar )
The instruction at "0x748498d0" referenced memory at "0x75f41508". The memory could not be "read".
Click on OK to terminate the program
Click on CANCEL to debug the program
All other players (and I have many :) ) play it fine.
GL
* edit: mplayer2.exe version is the same, quartz.dll is 6.5.2600.3024. OS is XPSP2
Zarxrax
2nd September 2007, 20:24
I'm getting an odd error here with AssumeFPS with the preset parameter.
If I explicitly name the parameter like so:
AssumeFPS(preset="ntsc_film")
I get an invalid argument error.
Simply doing it like this works fine though:
AssumeFPS("ntsc_film")
foxyshadis
2nd September 2007, 22:34
It's not documented as using a named argument, so I assume it isn't supposed to. (No quotes around the argument name in the docs.)
Zarxrax
3rd September 2007, 00:56
Ah, really. I had assumed every argument for every filter was named.
Ebobtron
3rd September 2007, 01:25
Nope there are alot of unnamed arguments in many of the internal filters.
The one or ones in question return the following
Reported by AviSynth:
AssumeFPS In -{ cc[sync_audio]b }-
AssumeFPS In -{ cc[sync_audio]b }-
AssumeFPS In -{ cc[sync_audio]b }-
AssumeFPS In -{ cc[sync_audio]b }-
I am assuming here that AviSynth can't tell the difference between AssumeFPS and AssumeFPS, I know I can't. :)
From the docs:
AssumeFPS (clip, float fps, bool "sync_audio")
AssumeFPS (clip, int numerator [, int denominator], bool "sync_audio")
AssumeFPS (clip1, clip2, bool "sync_audio")
AssumeFPS (clip, string preset, bool "sync_audio")
as compared to
AVIFileSource In -{ s+[audio]b[pixel_type]s[fourCC]s }-
AVIFileSource (string filename [, ...], bool "audio" = true, string "pixel_type" = YV12, [string fourCC])
these strings, s+[audio]b[pixel_type]s[fourCC]s, are what is reported by AviSynth when you ask.
FilmCutter can display them all for you
Wilbert
3rd September 2007, 18:45
It's not documented as using a named argument, so I assume it isn't supposed to. (No quotes around the argument name in the docs.)
A quoted argument has a default value, and bracket [] one is optional. So you can't see which arguments are named ones.
At least that's how i thought it was, if not, then we have some correcting to do :)
Fizick
3rd September 2007, 19:29
quoted agruments is named arguments, it is not dependent on default values.
Wilbert
3rd September 2007, 20:12
Then many of the lines in quick_ref.htm are wrong and should be corrected. RGBAdjust is an example, but there are many more ...
Fizick
3rd September 2007, 22:26
I wold like to have almost all argument named...
IanB, please :)
IanB
5th September 2007, 00:51
@F, Naming arguments makes them optional, this means more coding effort in the creator code i.e. not working with the API.
@W, As I interpreted it, for the documentation, quoted names means optional named argument i.e. int "name" means it's an int, it is optional and it is called name.
Unquoted names are for documentation reference only, and the inclusion of [...] implies optionality i.e. clip Src1[, clip Src2] means arg1 is a clip, arg2 is an optional clip. See Src1 and Src2 in the documentation for an explanation of their function.
Yes much of our documentation is inconsistant. I think we need a page "How to read this Avisynth documentation", and we need to make all the documentation conform to this.
@E, Yes there is a deficiency retrieving duplicate function entries. Perhaps somebody has ideas how to design around this.
masscamp24
6th September 2007, 15:38
I notice a problem with Avisynth 2.5.8 alpha. Since reading this post I tried it and when the source is played through windows media player, it played ok, but at the end of play and when WMP closed I get an error message (the normal windows error message when a program is not closed properly). Therefore I revert back to 2.5.7 and the problem went away. That's the only problem I notice with 2.5.8 so far and thought I should report it.:helpful:
Wilbert
15th September 2007, 22:15
@IanB,
Regarding the latest v2.58 CVS and Subtitle (default values). A bit of the displayed stuff is chopped off at the right hand side (i guess at the top too). See attachment.
IanB
16th September 2007, 03:18
@Wilbert,
edit: Test Subtitle("2 2 2 2 2 2 2 2\n2 2 2 2 2 2 2 2\n2 2 2 2 2 2 2 2", Lsp=1) :edit
Yes on the surface it does not look right, but it is obeying the algorithm as I understand it. Perhaps you can review the code changes for sanity. I have made the assumption that the algorithm should have been fully symetrical, the original was clearly not.
One point that is apparent is the algorithm might be improved by considering the effects of Gamma. At present the assumtion is brightness is linear, and the brightness results are only [0..64], we count lit pixels in an 8x8 grid. The halo aggregates weight from the distance from the edge to the nearest lit pixel.
The relevant code is this. Code I thought was wrong is in Red :-for(i=0; i<=8; i++) {
cenmask |= (BYTE)(((long)-src[srcpitch*i ])>>31);
cenmask |= bitexl[src[srcpitch*i-1]];
cenmask |= bitexr[src[srcpitch*i+1]];
}
mask1 = mask2 = cenmask;
for(i=0; i<8; i++) {
mask1 |= (BYTE)(((long)-src[srcpitch*(-i)])>>31);
mask1 |= bitexl[src[srcpitch*(-8+i)-1]];
mask1 |= bitexr[src[srcpitch*(-8+1)+1]];
mask2 |= (BYTE)(((long)-src[srcpitch*(8+i)])>>31);
mask2 |= bitexl[src[srcpitch*(8+i)-1]];
mask2 |= bitexr[src[srcpitch*(8+i)+1]];
tmasks[i] = mask1;
bmasks[i] = mask2;
}
for(i=0; i<8; i++) {
alpha2 += bitcnt[cenmask | tmasks[7-i] | bmasks[i]];
}
I changed to this, corrected code in Blue, there are now short cut case, which need verifying as well.
if (alpha1) {
// If we have any lit pixels we fully occupy the cell.
alpha2 = 64;
}
else {
// No lit pixels here so check the neighbours
BYTE cenmask = 0, mask1, mask2;
// Check left and right neighbours for lit pixels
for(i=0; i<8; i++) {
cenmask |= bitexl[src[srcpitch*i-1]];
cenmask |= bitexr[src[srcpitch*i+1]];
}
if (cenmask == 0xFF) {
// If we have hard adjacent lit pixels we fully occupy this cell.
alpha2 = 64;
}
else {
mask1 = mask2 = cenmask;
for(i=0; i<8; i++) {
// Check the 3 cells above
mask1 |= bitexl[ src[srcpitch*(-1-i)-1]];
mask1 |= (BYTE)(((long)-src[srcpitch*(-1-i) ])>>31);
mask1 |= bitexr[ src[srcpitch*(-1-i)+1]];
// Check the 3 cells below
mask2 |= bitexl[ src[srcpitch*(8+i)-1]];
mask2 |= (BYTE)(((long)-src[srcpitch*(8+i) ])>>31);
mask2 |= bitexr[ src[srcpitch*(8+i)+1]];
// Strength of occupancy based on neighbours distance
alpha2 += bitcnt[ mask1 | mask2 ];
}
}
}
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.