AviSynth 2.5.6 RC 2 Release Candidate [October 7th]

[IanB]

Dear all,

Here is the second Release Candidate of my review and refactor work on Avisynth 2.5.6.

A link down to the lastest Release Post (225) (http://forum.doom9.org/showthread.php?p=720959#post720959)

==========================
See below for progressive updates
===========================

Whats being done.

Evil EBX not saved compiler bug CRASH!
GreyScale() YUY2 fixed - others being hunted!

Convert.cpp
Review and refactor is still in progress.
MMX ConvertToYUY2(Matrix="...") support"
Added PC Levels RGB<->YUV [0..255] conversion options (Matrix="PC.601") and (Matrix="PC.709")
Added Rec.709 RGB->YUV conversion options (Matrix="Rec709").
RGB Greyscale(matrix="Average") support for unweighted [ Y=(R+G+B)/3 ] luma.
------------------------------------
Many 2^n MMX width restrictions gone
Fast MMX RGB24 -> RGB32 convertion
Legacy C++ RGB32 -> RGB24 reinstated
RGB Greyscale(matrix="rec709") support for Rec.709 luma weightings.
MMX YUY2 Greyscale()

Unrecognised Exception - Problem
I've given up trying to classify the code that causes this problem and am just sledge hammering the instances I find with a null try/catch. Here is a list of the affected modules found so far :-
- audio.cpp
- avs_soundtouch.cpp
- color.cpp
- field.cpp
- focus.cpp
- fps.cpp
- levels.cpp
- resample.cpp
- source.cpp

Fps.cpp
Added copy FPS from another clip to ConvertFPS and ChangeFPS as per AssumeFPS.

Avi_source.cpp
Fix WavSource() leaving .WAV files open.

Edit.cpp
Correct multi-channel audio fading

Focus.cpp
Full review and refactor of Blur/Sharpen code
Fixed YV12 width<=16 fatal crash
YV12 H MMX code no longer double blurs every 8th pixel
Edge boundaries now processed
Now MMX, not just SSE restricted
Some MMX versions faster
Most 2^n MMX width restrictions gone
When H or V blur==0 now skips that pass

Layer.cpp
Fixed BGR - GBR typo

Please report bugs in these reviewed modules in this thread.

Please post your script!

Regards
IanB

[Mug Funky]

well, no crashes yet, but i don't think i'm testing the right bits :)

i never got unrecognised exceptions, really. i get plenty of access violations, but i've not been able to track these down. i have a suspicion it's both mvtools and a really whacky interpretation of mpeg-2 spec as a source. but i can't be more specific because there's always other plugs involved, and the crashes only happen after a large number of frames, usually at a slow fps with lots of filtering.

[Wilbert]

Great!

I updated the installer (and added the italian documentation):

http://www.arachnotron.nl/permanent/doom9/avs/AviSynth_241104.zip
http://www.geocities.com/wilbertdijkhof/AviSynth_241104.zip
http://bbsrv.imp.leidenuniv.nl/~arachno/pub/avs/AviSynth_241104.zip

edit: geocities is complaining again. Perhaps someone can download it tomorrow and host it for a while?

Some remarks:

"RGB Greyscale(matrix="Average") support for unweighted (equal value) luma." means luma = (r+g+b)/3 I guess ...

Adding PC Levels RGB<->YUV [0..255] conversion options (Matrix="PCLevels")
This means that the RGB [0,255] <-> YUV [0,255] is only possible with Rec.601 coefficients right?

Perhaps you can add it as a new option instead (called pc_range = true / false(default) to keep it consistent with overlay for example). This way you can also implement the conversion with Rec.709 coefficients.

[IanB]

Originally posted by Wilbert

"RGB Greyscale(matrix="Average") support for unweighted (equal value) luma." means luma = (r+g+b)/3 I guess ...

Correct. r=g=b = (r+g+b)/3

This means that the RGB [0,255] <-> YUV [0,255] is only possible with Rec.601 coefficients right?

At the moment. Patients! Patients! The MMX code might be able to do both 601 and 709 with both TV and PC levels, I am still writing it.

I'll do a pass on the doco when I get the current batch of code finished (unless you beat me to it).

If you have a minute can you please spot check some YUV values for the darker saturated colours I think I might be out by 1 at the black end.

IanB

[sh0dan]

Just PM me when you need me to update the sourceforge alpha.

[Mug Funky]

try this to get wilbert's installer:

http://mugfunky.no-ip.info/AviSynth_241104.zip

you must allow port 8080... some workplace firewalls reject it, so be warned.

i'm an apache n00b :(

oh, btw: this is being hosted off my machine, which means when it gets turned off, the file is gone. i'll leave it on for tonight, and hopefully most of tomorrow, but if the power fails while i'm asleep then there's not much i can do (the grid is pretty unreliable here, too. should be fine for tonight though).

[Wilbert]

Thx! I also added some additional links above.

[IanB]

Also available from http://avisynth2.sourceforge.net/24Nov2004/AviSynth_241104.exe

IanB

[JuanC]

The AudioGraph filter (http://forum.doom9.org/showthread.php?s=&threadid=59412&highlight=audiograph) is crashing (vanishing) virtualdubmod ever since the first AVIsynth 2.56 alpha release.

Could there be anything wrong in the filter? warpenterprises has the filter and source code here (http://www.avisynth.org/warpenterprises/files/audgraph_25_dll_20030813.zip).

[IanB]

Originally posted by JuanC
The AudioGraph filter is crashing (vanishing) virtualdubmod ever since the first AVIsynth 2.56 alpha release.And why didn't you call sooner?

This has exposed a really nasty compiler bug, I begin to appreciate Avery's profanity re Microsloth's compiler bugs. (And he tells me .Net is even worse)

1. In this case the compiler assumed the "ebx" register was preserved across an __stdcall (it's not supposed to) and
2. registers used inside __asm blocks are supposed to be preserved in the entry/exit prologue (well guess what they don't all always get saved). [Starts with F, ends with k, 4 letters]!!! You get the idea ...

I've fixed and tested YUY2 GreyScale() which AudioGraph needs. I'll put an interim checkpoint .dll up tonight for you to test, watch for the EDIT of the 1st post in this thread.

Before I ask Sh0dan to put up a new full package, I'll do a pass through the code over the next few nights to find any more of this evilness.


Could there be anything wrong in the filter? ... http://www.avisynth.org/warpenterprises/files/audgraph_25_dll_20030813.zipYes, the version pointed to above is the "_" to many version. But that is a different problem. Sh0dan has a fixed version.

IanB

[JuanC]

Originally posted by IanB
And why didn't you call sooner? :) It just took me some time to empty my autoload plugins directory and try the filters one by one ... There could be some other problematic filters ...

Originally posted by IanB
I've fixed and tested YUY2 GreyScale() which AudioGraph needs. I'll put an interim checkpoint .dll up tonight for you to test, watch for the EDIT of the 1st post in this thread. Thanks!!! I will be happy to test.

Originally posted by IanB
... ( about AudioGraph ) ... Yes, the version pointed to above is the "_" to many version. But that is a different problem. Sh0dan has a fixed version. I got the one from ShOdan's former website. I didn't notice warpenterprises had the old one. ShOdan is no longer hosting it.

[lark]

I got the one from ShOdan's former website. I didn't notice warpenterprises had the old one. ShOdan is no longer hosting it.

i was looking for it yesterday, but couldn't find (the link in the old post didn't work any more.
could you please direct me to the correct spot?

regards
t :)

[Wilbert]

I'll do a pass on the doco when I get the current batch of code finished (unless you beat me to it).
I updated it last week, but didn't commit it yet.

If you have a minute can you please spot check some YUV values for the darker saturated colours I think I might be out by 1 at the black end.
I will do that if my internet connection works again :)

[sh0dan]

The modified AudioGraph can be downloaded from here (http://beta.zenaria.com/kpo/avisynth/index.html)

[lark]

Originally posted by sh0dan
The modified AudioGraph can be downloaded from here (http://beta.zenaria.com/kpo/avisynth/index.html)

thanks a 1000000
t :)

[Richard Berg]

Originally posted by sh0dan
Just PM me when you need me to update the sourceforge alpha.
It looks like Ian is doing great things for the project, and I don't think I can return anytime soon, so feel free to add him as an admin if you wish. Of course, if anyone needs things done to the website/server, you know where to find me :)

[Wilbert]

I've put up a new release

http://bbsrv.imp.leidenuniv.nl/~wilbert/AviSynth_191204.exe

changelog:

additions:
* Added an "[sse]b" option in Tweak to re-enable the SSE code if required (maybe an AMD might run it faster).
* Added Limiter(show=show_luma/show_luma_grey/show_chroma/show_chroma_grey) shows out of bound luma/chroma; *_grey makes the rest of the pixels grey.
* Added offsets and analyze option (ala ColorYUV) in RGBAdjust.
* Added ColorBars(pixel_type="YUY2").

bug files:
* Fixed Normalize (it was only sampling half of the samples per mouthful; it was ignoring the scaling factor).

optimizations:
* Tweak: added C code, which is now faster than the old iSSE code.
* Reworked some code in some audio filters which uses 64 bit operations (many of the routines are between 2 and 5 times faster).

changes:
* Normalize uses 256K transfer buffer to analyze peaks (should be > 5 times faster now); and displays the frame number of the peak.

I hope I didn't forget anything. Btw, the included docs in the installation are updated.

[sh0dan]

Januar 6th Beta 1 Release:

Great work by Ian:

- ConvertToFloat() fast SSE & SSE2 + Opt output copy.
- ConvertFromFloat() fast SSE2.
- ResampleAudio() support SFLOAT.
- Large amount of stability fixes.
- ShowFiveVersions() YV12 + Grey fill 2 corner rectangles.
- Fast Tweak, RGB Bias+Analyse, Limiter show.
- ChangeFPS/ConvertFPS(clip, ...) as per AssumeFPS
- Correct multi-channel audio fading.
- Optimizations in Merge.


Users with P3 should test the following script:
ColorBars()
ConvertAudioto16Bit()
ConvertAudioto32Bit()
ConvertAudioto16Bit()
histogram("stereo")


As usual download from Sourceforge (https://sourceforge.net/projects/avisynth2/)

[IanB]

@sh0dan,

Ta!

Dear All,

And also in this release...
- Reworked Cache and memory management
Please break out your most evil cache busting scripts and test, test and test more.

Also First Bug! (See I do test my own code) :D

Converting from Float, ConvertAudioTo32Bit() SSE and SSE2, saturate incorrectly in the positive direction. For normalized values >= 1.0f it returns MIN_INT (0x80000000) instead of MAX_INT (0x7FFFFFFF). (Sounds really bad)

Can someone with a 3DNow capable processor please test the following script.ColorBars()
Amplify(1.1) # or more
ConvertAudioTo32Bit()
ConvertAudioTo16Bit() # MaybeThe problem is related to the limited precision available with 32bit floats. The scaled values actually available at the top end are 2147483520 (MAX_INT-127) and 2147483648 (MAX_INT+1). The easy solution is to clamp positive saturation at 2147483520 (0x7FFFFF80).

Anybody Like to suggest some neat SSE(2) code to do the exact positive saturation.

IanB

[Manao]

> - Reworked Cache and memory management

Very interesting, I'll see if the ugly behavior with FuPP's scripts and the old masktools version is still preset or not. Anyway, thanks a lot !

[Arachnotron]

Can someone with a 3DNow capable processor please test the following script
Sounds ok on my Athlon XP 1800+/Asus A7N8X

[Manao]

IanB : Impressive ! the changes you made in the cache seems to work : the script i PMed you some times ago is now functionning as expected :) The speed gain on this particular script is awesome ( from 6 fps to 14 fps )

[tritical]

IanB, I have a question about something in cache.cpp... this might be dumb so bear with me, but I'm wondering about what is happening. This code inside Cache::GetFrame, for the h_policy == CACHE_NOTHING handling:
if (h_policy == CACHE_NOTHING) { // don't want a cache. Typically filters that only ever seek forward.
__asm mov ebx,ebx // Hack! prevent compiler from trusting ebx contents across call
PVideoFrame result = childGetFrame(n, env);
if (result->vfb) env->ManageCache(MC_ReturnVideoFrameBuffer, result->vfb);
return result;
}
Won't the call to env->ManageCache() to return the vfb cause the caches of filters that use CACHE_ALL around a filter that uses the CACHE_NOTHING policy to have frames dropped from their lists that shouldn't necessarily be dropped? I've been testing this script:

mpeg2source()
tfm()
tfmpp()
tdecimate()

while allowing tfm/tfmpp/tdecimate to default to CACHE_ALL, and that one works perfectly. However if I add in a filter that uses CACHE_NOTHING like this:

mpeg2source()
tfm()
tfmpp()
avstimer() <= uses CACHE_NOTHING
tdecimate()

now the caches before tdecimate and tfmpp only store 2 frames in their lists which results in an awful lot of the getframe calls from tdecimate needing frames to be redone from tfm on up.

If I comment out that line from above, or set tfm/tfmpp/tdecimate to use a CACHE_RANGE policy then everything works fine.

[Mug Funky]

Users with P3 should test the following script:

it loads (no vanishing)

i get a 1k tone going between left and centre of the stereo field every second or so. that what you're expecting?

there's no (audible) distortions in the tone, so i'm going to assume the conversions all maintain their integrity.

[edit]

Can someone with a 3DNow capable processor please test the following script

my p3 makes a sound like a buzz. opening the avs in audition (cool! i didn't realise you could do that without an avi wrapper) reveals the positive clipping at negative fullscale, as you said.

[Arachnotron]

my p3 makes a sound like a buzz. opening the avs in audition (cool! i didn't realise you could do that without an avi wrapper) reveals the positive clipping at negative fullscale, as you said.Ok, I misunderstood the purpose :o

On my 3Dnow! capable athlon, the script results in clipping, just as I suppose it should. I loaded the script in vdub and saved a short .wav, which I loaded in audacity. Here (http://www.arachnotron.nl/temp/3dnow_amplify.jpg) is a screendump from a zoomed-in sinus.

[edit]sinus.. er... sine :o

[Mug Funky]

ah! yours is doing the right thing then. mine's flipping the positive clips to the negative side. as you can imagine it sounds pretty bad :)

[Leak]

Originally posted by IanB
- Reworked Cache and memory management
Please break out your most evil cache busting scripts and test, test and test more.

Since you seem to be quite informed when it comes to the cache now, could you (or whoever is well-versed on the topic) perhaps add a bit of documentation for SetCacheHints on AviSynth.org, or how caching works in general?

I guess I'm not the only one here that doesn't really understand it fully, and I guess a reduction of unneeded caching of frames that don't need to be cached can only be beneficial, performance-wise. :)

np: Panasonic - Rutina (Kulma)

[IanB]

@Arachnotron, @Mug Funky,

Thanks guys for the tests (and the screen grab). It's a relief knowing I didn't stuff up the 3DNow code. Not being able to test code paths is a real downer.

@Manao,

Nice to know it make some difference. Your original case was caused by exceeeeedingly long cache chains all pointing at a small number of valid, inuse, VFB's.

@Leak,

Yeah I probably will knock up some info when I get all the bits and pieces integrated. I'm also trying to force myself to write lots of comments in the source.

Originally posted by tritical
IanB, I have a question about something in cache.cpp. I'm wondering about what is happening. This code inside Cache::GetFrame, for the h_policy == CACHE_NOTHING handling: if (h_policy == CACHE_NOTHING) { // don't want ...
_asm mov ebx,ebx // Hack! prevent compiler ...
PVideoFrame result = childGetFrame(n, env);
if (result->vfb)
env->ManageCache(MC_ReturnVideoFrameBuffer, result->vfb);
return result;
}Won't the call to env->ManageCache() to return the vfb cause the caches of filters that use CACHE_ALL around a filter that uses the CACHE_NOTHING policy to have frames dropped from their lists that shouldn't necessarily be dropped?
...
while allowing tfm/tfmpp/tdecimate to default to CACHE_ALL, and that one works perfectly. However if I add in a filter that uses CACHE_NOTHING like this:

I assume you actually have this setup, 2 x avstimer, coz only 1 is useless. I have also marked in the cache instances for clarity.mpeg2source()
-> cache <= CACHE_ALL
tfm()
-> cache <= uses CACHE_NOTHING
avstimer()
-> cache <= CACHE_ALL (maybe absent)
tfmpp()
-> cache <= uses CACHE_NOTHING
avstimer()
-> cache <= CACHE_ALL (maybe absent)
tdecimate()
-> cache <= CACHE_ALL


now the caches before tdecimate and tfmpp only store 2 frames in their lists which results in an awful lot of the getframe calls from tdecimate needing frames to be redone from tfm on up.

If I comment out that line from above, or set tfm/tfmpp/tdecimate to use a CACHE_RANGE policy then everything works fine.Yeap, full points for a bug find. ;)

Avstimer() is a special case, Crop(), etc, are all in the same boat, in that they pass VFB's straight thru unmodified. By telling the cache below it CACHE_NOTHING, that cache dutifully returns all the associated VFB's to the tail of the queue for early reuse. Now when the cache above gets that same PFrame, it's VFB it has already been returned, and will get reused pdq. I think I will be taking that out in the next cut, I need to design a definative way to know a VFB is really unloved before I return it. :devil:

CACHE_RANGE is a lot more aggressive with it's VFB members, it actually bump's their use count while they are in scope, this has 2 effects. a) the VFB can't be stolen, b) all calls to MakeWritable() return a copy (and cost a blit). I tried this logic generally and it can cause severe memory shortage. 640x480 YUY2 VFB's are 600kb each, locking 7 buffers (radius 3) is 4.2Mb per cache instance, 24 cache instances (effectively script lines) and there's 100Mb. And the performance is not as good when strange things are not happening. :D

IanB

[scharfis_brain]

restore24 is not working anymore correctly with AVS 2.5.6 beta1.
(it produces jerky motion and lets blends sneak thru)

but restore24 works very nice using the predecessor, AVS 2.5.6 alpha 19-12-2004

might this be a problem of smartdecimate?
smartdecimate prooved being not very stable in past, unfortunately. but sadly this new AVS-version seems to broke everthing.


I will test this more tomorrow with some minor complex scripts.

[IanB]

Originally posted by scharfis_brain
restore24 is not working anymore ...Got a current link to it, the "Gleitz" link I have say "Not Found" (I think it does, mien Deutch ist nicht zehr gut) ;)

IanB

[Boulder]

I UL'd it here : http://www.saunalahti.fi/sam08/restore24.rar

[scharfis_brain]

updated package here
http://forum.gleitz.info/attachment.php?attachmentid=70159

I still need to test in a less complex environment.
Restore24 is way too complex....

[Wilbert]

I got a report from the german forum that SeparateFields separate the fields of field-based material, although it shoudn't do anything. This is indeed the case with the latest binary. I will look at it.

[stickboy]

neuron2 and I have been complaining about that inconsistency between SeparateFields() and Weave() for a long time. :)

Now, should SeparateFields() on a field-separated clip be a no-op, or should it generate an error? (And likewise, should Weave() on a non-field-separated clip be a no-op, or should it be an error?)

I'm leaning toward error, especially if you're going to be changing behavior that might affect existing scripts.

[Wilbert]

Yes, perhaps it's good to give an error. Saying that you should apply AssumeFrameBased before applying SeparateFields to field-based material.

I didn't check Weave. Does it also do something on frame-based material?

[IanB]

Sh0dan drop the test for already IsFieldBased() between revs 1.4 and 1.5 in the old 2.x branch (prior to the big file shuffle)

My vote is for "errors" when it's inconsistant, i.e. can only Weave() something that IsFieldBased()==True, can only SeparateFields() something that IsFrameBased()==True.

@Wilbert

On IsFrameBased() material :-

DoubleWeave() goes thru some motions and produces 1 same frame and 1 field offset frame.

Weave() goes thru the same motions as above but appears to do nothing. Remember Weave() is implemented as DoubleWeave().SelectEven()

IanB

[Wilbert]

Weave() goes thru the same motions as above but appears to do nothing. Remember Weave() is implemented as DoubleWeave().SelectEven()
Hmm. That complicates it a bit, because DoubleWeave handles field-based and frame-based material. Do you know whether it is possible to throw an exception anyway (using Weave on frame-based material)?

btw, there's still a bug in DoubleWeave and YV12.

[IanB]

Originally posted by Wilbert
Hmm. That complicates it a bit, because DoubleWeave handles field-based and frame-based material. Do you know whether it is possible to throw an exception anyway (using Weave on frame-based material)?Just commited to CVS, Weave() enforces IsFieldBased(), SeparateFields() enforces IsFrameBased(), DoubleWeave() untouched. Now we wait to see what the native think. :p

btw, there's still a bug in DoubleWeave and YV12.Fixed! Was missing offset calc code for Chroma, only had the Luma code. :D

IanB

[Wilbert]

About ShowFiveVersions


AviSource("F:\TestStreams\telecined-clip.avi") # YV12 clip
DoubleWeave()
a = Pulldown(0,2).Subtitle("0,2")
b = Pulldown(1,3).Subtitle("1,3")
c = Pulldown(2,4).Subtitle("2,4")
d = Pulldown(0,3).Subtitle("0,3")
e = Pulldown(1,4).Subtitle("1,4")
ShowFiveVersions(a,b,c,d,e)


resulted in a black clip (YUY2 mode works fine though).

[IanB]

Wilbert,

resulted in a black clip (YUY2 mode works fine though).Most strange :confused: I cannot reproduce it.

Q1. Is the output fully black, including the 2 grey corner blocks, or just the 5 frame elements?

Q2. Is the subtitle text visible or is that black as well?

Q3. Does a SeparateFields() first change the behavior? (Test 1)

Q4. Does a convertToRGB32() (or YUY2) at the end change anything? (Test 2, 3)

Q5. Does a StackHorizontal(a, b, c) suffer the same fate as the Show5? (Test 4)

Q6. Does a YV12 BlankClip() clone behave the same? (Test 5)

Q7. What are you displaying this with? What YV12 display codec are you using? Is it Xvid or DivX? What is the final total width? Is it mod 16? Does a Crop help? (Test 5)

AviSource("F:\TestStreams\telecined-clip.avi") # YV12 clip
# BlankClip(Last, Pixel_type="YV12", Color=$56789A) # Test 5
# SeparateFields() # Test 1
DoubleWeave()
a = Pulldown(0,2).Subtitle("0,2")
b = Pulldown(1,3).Subtitle("1,3")
c = Pulldown(2,4).Subtitle("2,4")
d = Pulldown(0,3).Subtitle("0,3")
e = Pulldown(1,4).Subtitle("1,4")
ShowFiveVersions(a,b,c,d,e)
# ConvertToRGB32() # Test 2
# ConvertToYUY2() # Test 3
# StackHorizontal(a, b, c) # Test 4
# Crop(0, 0, 640, 480) # Test 6

IanB :confused:

[Wilbert]

To summarize all the answers:

ShowFiveVersions(a,b,c,d,e)
BicubicResize(2*720,480)

works. It's DivX 5.1.1 to blame. What YV12 decoder are you using?


ShowFiveVersions(a,b,c,d,e)
BicubicResize(3*720,480)

is black though.

[sh0dan]

Could someone remove "threshold /=100.0f;" in line 419 in conditional_functions.cpp? I'm without CVS access ATM.

It seems like I'm dividing threshold by 100 two times. ;)

[Wilbert]

Could someone remove "threshold /=100.0f;" in line 419 in conditional_functions.cpp? I'm without CVS access ATM.
done

[tritical]

I am having a very strange problem with a build of AviSynth 2.5.6 compiled from cvs source checked out a few days ago. Whenever a script is closed some of the filters in the filter chain are not having their destructors called. For example, if I use this script (with the cache instances inserted):

mpeg2source()
cache()
blur()
cache()
tfm()
cache()
tfmpp()
cache()
blur() *
cache() *

tfm()/tfmpp()'s destructors are never called. In fact, the only filters that have their destructors called are the last two (marked with * above). If I use this script:

mpeg2source()
cache()
blur()
cache()
blur()
cache()
blur() *
cache() *

only the final two have their destructors called. Reverting back to a build from the 6th of january fixed the problem. Was wondering if anyone else has experienced this or if something is royally messed up on my system?

[IanB]

@tritical,

I'm a little short on AviSynth time presently, but I'll have a look the first chance I get.

Wilbert is about to build a new bundle, when it's done test it to see if the problem occurs (if so then it's a bug, if not then it's your build).

IanB

[Wilbert]

February 21st Beta 2 Release:

Great work by Ian:

additions:
- Added options to ShowSMPTE: ShowSMPTE(offset="00:00:00:30", x=360, y=576, font="georgia", size=24, text_color=$ff0000)
- Added Optional FPS=24 parameter to Dissolve and Fade*() for processing audio only clips.
- Added FadeIn0(), FadeOut0(), FadeIO0() variants that don't add an extra frame.
- Added Fractional resampling support in ResampleAudio().
- Added HasVideo() and HasAudio() script functions.
- Added Level option to Tone().
- Added ColorBars(pixel_type="YUY2, YV12").
- Added env->ManageCache() interface in AviSynth.h.
- Added VideoFrameBuffer 16 byte guardband protection/detection in Debug mode.
- Added EBX compiler bug protection/short circuiting to Cache::GetFrame().

fixes:
- Dissolve and Fade*() process audio only clips, assumes 24fps for position calcs.
- Fixed wrong chroma in DoubleWeave() of FrameBased YV12 material.
- Fixed crash from BlankClip() with an audio only clip template.
- Fixed AudioCache corruption on buffer resize.
- Fixed ResampleAudio() clicks/pops due to creeping error.
- Fixed SSE/SSE2 ConvertAudioTo16/32Bit() positive value saturation.
- Fixed ConvertToRGB() src->rowsize==8 crash.
- Fixed Memory leak, deleted VideoFrameBuffers.
- Fixed env->NewVideoFrame() returning short frame buffer.
- Fixed vi.FrameFromAudioSamples() truncation.
- Fixed ShowFiveVersions() unused corner rectangles had random contents. Now grey filled

changes:
- Histrogram: in color_mode - YUY2: Invalid values (below 16 and above 235) will be colored brown/yellow-ish. Made those values more visible.
- Evaluate: Now breaks outs and reports system exceptions instead of reporting the useless "Evaluate: Unrecognized exception!".
- BlankClip() no longer gobbles any implicit last clip as the template clip. You have to explicitly declare you want a template clip i.e. BlankClip(Last). "BlankClip()" now always returns the default blank clip.
- Avisynth.h FrameFromAudioSamples/AudioSamplesFromFrames() now test for divide by zero and return zero when encountered instead of crashing.
- SeparateFields() now throws an exception for an IsFieldBased() source.
- Weave() now throws an exception for an IsFrameBased() source.
- Cache policy CACHE_NOTHING currently no long returns all VFB's. Under review.
- Avisynth.h SetFPS() now test for zero numerator or denominator if found it sets num=0, den=1.

As usual download from Sourceforge (https://sourceforge.net/projects/avisynth2/).

PS:
1) I can't commit anything to CVS atm.
2) The package is a bit larger due to two png pics.

[tritical]

Just wanted to say thanks for the build Wilbert and thanks for the many improvements/fixes IanB :). This build seems to suffer from the same problem I mentioned earlier, the destructors for some filters are not called on exit. I dled and tested the jan 6 beta on sourceforge and it works fine, another build I had from around february 8 or 9 seems to be ok as well so it must a side effect from something changed recently.

[Richard Berg]

With the new alpha, I'm getting a hard quit whenever there's an exception (even a simple syntax error). Same in VDub / VDM / WMP -- the app just closes.

[JuanC]

Originally posted by Richard Berg
With the new alpha, I'm getting a hard quit whenever there's an exception (even a simple syntax error). Same in VDub / VDM / WMP -- the app just closes. I've got the same problem here

[Boulder]

I also got 'memory could not be 'read'' errors when exiting VDubMod. There are none with the earlier beta.