Avisynth+

[sl1pkn07]

http://avisynth.nl/index.php/AviSynth%2B#Latest_Release (?)

[vcmohan]

That explains it. VC++ 2010 express relies on the SDK 7.1 to provide the x64 compilers. (The SDK has traditionally come with command-line compilers since the 90's.) SDK 8.1 removed all compilers because they're all built into VC++ 2013 community now, so no more access in any VS version. You can have SDK 7.1 and 8.1 side-by-side, but honestly it'd be less work to switch to 2013 (or even 2015 RC, which already seems just as stable as previous versions).
I have been using vs2013 community edition and compiled several avs+ plugins in 64 bit. I did not notice that the 2013 community edition was a one month trial edition and I need to pay over $6800 to continue working. This amount I can not afford. So far whichever plugins are compiled are at my down load page. In future I will switch back to 2010 edition possibly.

[Sparktank]

I have been using vs2013 community edition and compiled several avs+ plugins in 64 bit. I did not notice that the 2013 community edition was a one month trial edition and I need to pay over $6800 to continue working. This amount I can not afford. So far whichever plugins are compiled are at my down load page. In future I will switch back to 2010 edition possibly.

Users in the comment section (bottom of page) have said to just sign-in again into your Micro$oft account and ignore any promotions. After that, you're good to go again for another year or so without hassle.
http://blogs.msdn.com/b/quick_thoughts/archive/2014/11/12/visual-studio-community-2013-free.aspx

[MysteryX]

Any idea when will be the next release of the MT version? The latest release doesn't sync audio and video when playing videos with SVP, and crashes with NNEDI3. Apparently there is a somewhat stable version but it's not yet public.

[Groucho2004]

In my tests the 32 bit r1825 (have not tested 64 bit) slows down continuously with QTGMC, no matter if single threaded or multi threaded.
There is something odd with the memory management in the newer builds, they use much less memory than r1576 or 2.6 but it seems that this is exactly what causes the slowdown. Just a hunch.
Importing the AVSMeter performance data into a spread sheet program shows the issue with r1825 slowing down continuously quite nicely.

Script:
SetMemoryMax(1024)
LWLibavVideoSource("src\test.m2v")
AssumeTFF()
QTGMC(Preset="slow")


Result with r1576 x86:
http://s1.postimg.org/c20lkxnof/1576.png

Result with r1825 x86:
http://s7.postimg.org/s1hv5tyob/1825.png

[vcmohan]

Users in the comment section (bottom of page) have said to just sign-in again into your Micro$oft account and ignore any promotions. After that, you're good to go again for another year or so without hassle.
http://blogs.msdn.com/b/quick_thoughts/archive/2014/11/12/visual-studio-community-2013-free.aspx

thanks.

[stax76]

@Groucho2004

I didn't know r1576 don't has the slowdown issue, for StaxRip this don't help unfortunately because several StaxRip features rely on ffmpeg and last time I tried ffmpeg with r1576 an error was returned by ffmpeg stating that AviSynth r1576 is too old.

[Groucho2004]

last time I tried ffmpeg with r1576 an error was returned by ffmpeg stating that AviSynth r1576 is too old.
Yes, FFMPEG and some plugins require Avisynth interface version 6, r1576 is still 5.
Let's hope development picks up again and the issue(s) will be fixed.

[vcmohan]

Thanks for pointing that out, it's fixed now.

-------


Most plugins by V.C. Mohan (http://www.avisynth.nl/users/vcmohan/) .
I have converted most of my plugins to 64bit using avisynth+ header file. I have tested them with virtual dub (and not yet with avsmeter). All of these are MT_NICE mode. Only those that require visual examination viz: frequency spectrum are serialized.

[ryrynz]

Thought I'd give Avisynth+ MT another shot after a year or so

The following script runs fine with 1576

Loadplugin("C:\Program Files (x86)\AviSynth+\plugins+\masktools2.dll")
Import("C:\Program Files (x86)\AviSynth+\plugins+\psharpen.avs")
ffdshow_source()
Psharpen(100)

installed 1825, updated to this and get an system exception access violation error.

SetFilterMTMode("DEFAULT_MT_MODE", 3)
Loadplugin("C:\Program Files (x86)\AviSynth+\plugins+\masktools2.dll")
Import("C:\Program Files (x86)\AviSynth+\plugins+\psharpen.avs")
ffdshow_source()
Psharpen(100)
Prefetch(2)

Are things still that broken with MT?

[Groucho2004]

This script works fine for me on r1825, x86:
SetFilterMTMode("DEFAULT_MT_MODE", 2)
colorbars(width = 1280, height = 720, pixel_type = "yv12").killaudio().assumefps(50, 1)
Psharpen(100)
Prefetch(4)

DEFAULT_MT_MODE 3 either crashes or has no performance impact.

Have not tried ffdshow.

[ryrynz]

This script works fine for me on r1825, x86:

DEFAULT_MT_MODE 3 either crashes or has no performance impact.

Have not tried ffdshow.

Tried mode 3 for compatibility and to strip the source line out, I had also set mode 2 as default and mode 3 for source and also had the same issue. Disappointing, 64 bit Avisynth+ and ffdshow would hopefully gain me some performance, guess we're not there yet. Looks like SEt's MT is still the way to go for real-time work for now.

[LigH]

You would probably need a 64-bit ffdshow to use a 64-bit AviSynth+ as a realtime post-processing filter. Which is not quite the purpose AviSynth was made for, anyway.

[ryrynz]

You would probably need a 64-bit ffdshow to use a 64-bit AviSynth+ as a realtime post-processing filter. Which is not quite the purpose AviSynth was made for, anyway.
Yup, aware of that. Been using 32 bit, need to have that working before I even attempt 64.

[RenderGuy2]

Yup, aware of that. Been using 32 bit, need to have that working before I even attempt 64.

I have used ffdshow rev4533 x64 raw video filter with mpc-hc x64. As I mentioned in an earlier post, Avisynth+ r1779 works well, however r1825 doesn't work (at least not on my systems).

Perhaps someone more knowledgeable than me would know what changed between r1779 and r1825 that would make it incompatible with ffdshow.

[ryrynz]

I have used ffdshow rev4533 x64 raw video filter with mpc-hc x64. As I mentioned in an earlier post, Avisynth+ r1779 works well, however r1825 doesn't work (at least not on my systems).

Perhaps someone more knowledgeable than me would know what changed between r1779 and r1825 that would make it incompatible with ffdshow.

Oh yah, I remember seeing aegisofrime's post about the access violation error a while back. Thanks, I'll hopefully get this running today.

[ryrynz]

Thanks, I'll hopefully get this running today.

Yeah.. MT obviously isn't stable. Just trying to run a single line awarp4 with nnedi3 results in green screens, quarter screens and garbage depending on how many threads I give it. Looks like 2.6 MT is still the way to go for real time work, shame that.

I guess I'll look at this again once another phase of development has occurred, hopefully some time next year.

[Elegant]

Importing the AVSMeter performance data into a spread sheet program shows the issue with r1825 slowing down continuously quite nicely.

Script:
SetMemoryMax(1024)
LWLibavVideoSource("src\test.m2v")
AssumeTFF()
QTGMC(Preset="slow")


Result with r1576 x86:
http://s1.postimg.org/c20lkxnof/1576.png

Result with r1825 x86:
http://s7.postimg.org/s1hv5tyob/1825.png

I might make some time for this issue. This issue should not necessarily require a full understanding of AviSynth+. All that should be needed is the ability to compile AviSynth+ and test it with AVSMeter. Then just check a series of revisions and narrow it down until you find the one commit where it goes south and if possible, revert the change.

Now if it happens to degrade over each revision then I can't help fix it but I can see a few commits on GitHub that make me question if that might be the cause.

[Groucho2004]

Now if it happens to degrade over each revision then I can't help fix it but I can see a few commits on GitHub that make me question if that might be the cause.
I think this started somewhere in build 17xx. I'm not certain though...

[Reel.Deel]

I have a few different r17xx test builds by ultim, when I get home I'll do some testing to see if any of those revisions show the same behavior.

---

Ok I finally finished testing...

So it seems something went wrong after r1765; it's still slightly slower than r1576 but at least the FPS is consistent. I only tested the 32-bit version for now, hopefully I'll have time later to test the 64-bit versions. Thanks to Groucho2004 for reporting this issue and also for his nifty AVSMeter :).

Script:

SetMemoryMax(1024)
LWLibavVideoSource("test.m2v")
AssumeTFF()
QTGMC(Preset="slow")

Clip info:

Number of frames: 43596
Length (hh:mm:ss.ms): 00:12:07.327
Frame width: 720
Frame height: 480
Framerate: 59.940 (60000/1001)
Colorspace: YV12



AviSynth+ r1576
[Runtime info]
Frames processed: 43596 (0 - 43595)
FPS (min | max | average): 6.934 | 171.0 | 24.55
Memory usage (phys | virt): 1048 | 1070 MB
Thread count: 26
CPU usage (average): 9%
Time (elapsed): 00:29:35.825

http://s18.postimg.org/r0w7jeyq1/Avi_Synth_r1576.png


AviSynth+ r1689
[Runtime info]
Frames processed: 43596 (0 - 43595)
FPS (min | max | average): 6.617 | 170.8 | 22.27
Memory usage (phys | virt): 178 | 184 MB
Thread count: 39
CPU usage (average): 10%
Time (elapsed): 00:32:37.568
http://s8.postimg.org/ec4wbuy1h/Avi_Synth_r1689.png


AviSynth+ r1765
[Runtime info]
Frames processed: 43596 (0 - 43595)
FPS (min | max | average): 5.686 | 170.4 | 22.23
Memory usage (phys | virt): 178 | 184 MB
Thread count: 39
CPU usage (average): 11%
Time (elapsed): 00:32:41.305
http://s3.postimg.org/mdoxion6r/Avi_Synth_r1765.png


AviSynth+ r1779
[Runtime info]
Frames processed: 43596 (0 - 43595)
FPS (min | max | average): 3.793 | 112.9 | 11.70
Memory usage (phys | virt): 193 | 199 MB
Thread count: 39
CPU usage (average): 9%
Time (elapsed): 01:02:06.727
http://s18.postimg.org/l9egv8ifd/Avi_Synth_r1779.png


AviSynth+ r1825
[Runtime info]
Frames processed: 43596 (0 - 43595)
FPS (min | max | average): 5.607 | 116.3 | 12.31
Memory usage (phys | virt): 193 | 200 MB
Thread count: 39
CPU usage (average): 10%
Time (elapsed): 00:59:00.326
http://s13.postimg.org/6fogsu047/Avi_Synth_r1825.png


AviSynth 2.6 (just for validation)
[Runtime info]
Frames processed: 43596 (0 - 43595)
FPS (min | max | average): 7.780 | 174.3 | 18.85
Memory usage (phys | virt): 1055 | 1077 MB
Thread count: 26
CPU usage (average): 10%
Time (elapsed): 00:38:33.056
http://s11.postimg.org/fhgdfyfrn/Avi_Synth_2_6.png

[jpsdr]

Absolute winner is...... avs+ 1576 ! :D

[Reel.Deel]

Absolute winner is...... avs+ 1576 ! :D

Yes indeed. I hope this issue can be resolved. KNLMeans and even FFmpeg (http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2015-March/170699.html) requires AviSynth+ r1779 or greater (or any version with the latest header) :(.

[Groucho2004]

Ok I finally finished testing...
I don't get such a big difference between 2.6 and AVS+ r1576. What processor did you run this on?

[Reel.Deel]

I don't get such a big difference between 2.6 and AVS+ r1576. What processor did you run this on?

Intel core i7 4930k (http://ark.intel.com/products/77780/Intel-Core-i7-4930K-Processor-12M-Cache-up-to-3_90-GHz) on 64-bit Windows 7. I'll test 2.6/AVS+ r1576 on another processor to see if I get similar results.

I also added this issue to GitHub: https://github.com/AviSynth/AviSynthPlus/issues/63

[Groucho2004]

Intel core i7 4930k (http://ark.intel.com/products/77780/Intel-Core-i7-4930K-Processor-12M-Cache-up-to-3_90-GHz) on 64-bit Windows 7.
Hm. I ran this on my i5-2500K on XP. The only difference between XP and Win7 that could be relevant here is that Win7 supports AVX intrinsics. However, I'm not aware of any AVX intrinsics in AVS+. Maybe one of the plugins is using them?

Edit: Which nnedi3 are you using?

[Reel.Deel]

I don't get such a big difference between 2.6 and AVS+ r1576. What processor did you run this on?

Here's the results with an i7-4770k (http://ark.intel.com/products/75123/Intel-Core-i7-4770K-Processor-8M-Cache-up-to-3_90-GHz) also on Windows 7; more or less the same as the previous results. Out of curiosity I might test this with my old computer (Q6600 / XP).

AviSynth+ r1576:
[Runtime info]
Frames processed: 45338 (0 - 45337)
FPS (min | max | average): 10.25 | 218.7 | 32.83
Memory usage (phys | virt): 1046 | 1068 MB
Thread count: 18
CPU usage (average): 15%
Time (elapsed): 00:23:00.899
http://s16.postimg.org/ia6tliuyt/Avi_Synth_r1576_i7_4770k.png


AviSynth 2.6:
[Runtime info]
Frames processed: 45338 (0 - 45337)
FPS (min | max | average): 6.128 | 222.0 | 27.15
Memory usage (phys | virt): 1053 | 1074 MB
Thread count: 18
CPU usage (average): 15%
Time (elapsed): 00:27:49.653

http://s17.postimg.org/ln4g7b0jj/Avi_Synth_2_6_i7_4770k.png


Which nnedi3 are you using?
I'm using jpsdr's nnedi3 (SSE4.2). Both AVS/AVS+ are using the the exact same plugins.

[qyot27]

While it was mentioned in the issue on Github, the drastic difference in memory consumption between r1576 and newer builds of avsplus is because r1576 still uses the old cache system that 2.6 does, just bugfixed and tweaked a bit with the rest of the performance boosts that were already present in 0.1. But the MT branch (which is where *all* post-r1576 builds come from, since there weren't any public builds made available prior to r1689, IIRC) has a redesigned cache system, leading to the much-reduced memory consumption and different thread count numbers. It's a bit of comparing apples to oranges there.

So more correctly, the drop-off in performance after r1765 is a regression that was introduced late in the cycle for the new cache system. I may go in and do some builds so we can try to bisect this, once I have access to my VS2013 build environment again.

[Boulder]

The performance issue aside, is r1825 generally safe to use for MT purposes or are there other issues still lurking?

[jpsdr]

Yes indeed. I hope this issue can be resolved. KNLMeans and even FFmpeg (http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2015-March/170699.html) requires AviSynth+ r1779 or greater (or any version with the latest header) :(.

Stupid thought : Can't the r1576 just be compiled with the latest header ?

[Groucho2004]

Stupid thought : Can't the r1576 just be compiled with the latest header ?
You mean having avisynth.dll pretend to support AVISYNTH_INTERFACE_VERSION 6?
That would almost certainly crash if a plugin tries to use for example the updated Avisynth_C API.

[Reel.Deel]

Can someone please make an AviSynth+ changelog (or list) that contains revision numbers and the corresponding commit hash? Since AviSynth+ uses revision numbers for it's releases is kinda hard to find the corresponding commit unless it's been tagged. I'm not familiar with GitHub so I'm not sure how to accomplish this.

[qyot27]

That's actually impossible, because the commit count can change during merges because git slips commits into the history by date (and in fact, this is exactly what happened when the Sphinx docs were merged). This is expected git behavior. The reason some projects don't have this as an issue is because they don't do merges, and apply patchsets through git am.

The revision numbers are more akin to plain commit counts than static revision numbers like in Subversion. In fact, the method by which the number is generated is 'git rev-list --count HEAD'.

The better option (although it wouldn't do anything to existing commits), would be to have the abbreviated commit hash visible in the output of Version().


The dumb way of doing it is to simply do 'git rev-list HEAD', and then open it in a spreadsheet so you can look at the row numbers or generate them in a column. But like I said, that only shows which commits were in those positions at the time you perform the operation, not forever.

[Reel.Deel]

Thanks for the info qyot27. If I'm understanding correctly does that mean that AviSynth+ rxxxx actually means the commit count rather than the revision number?

[qyot27]

Pretty much, yes. Revision numbers are a form of commit counts, even in Subversion. The difference is that where Subversion's are static numbers and thus the revision number is always true for X commit, in normal git usage the number is only representative of the latest commit on the branch you're on (and since the most common usage for the numbers is as a constantly tracking upward number of commits, it works well enough). Like I said, some projects - x264, for instance - don't do merges and force git to keep a strictly linear history, in which case the revision numbers and commit hashes would be static and pretty much just like in Subversion. But those would definitely be the exceptions for projects using git, not the rule.

For AviSynth+, the revision numbers are really just a shorthand, and the only ones that might pack extra meaning are those that are shown in the Version() output for an official point release. That's why 'AviSynth+ r1576' is treated as synonymous with the official release of 'AviSynth+ 0.1'. Otherwise, the numbers are more for seeing how much activity has occurred between builds (or in relation to classic AviSynth; currently, avsplus is about 500 commits ahead or so). Whatever the number happens to be when 0.2 gets tagged and released will have the same popular association to it.

[LigH]

It is certainly similar for x265 which uses Hg (Mercurial), a kind of git variant. There are version "milestones" and additional patch counts. But it seems not to progress as sequentially as expected either; I remember a point when the "stable" branch got merged into the "default" branch and should have raised the count of patches by about half a dozen, I expected, but it increased only by one... So I am not sure if only the patches in the "default" branch count, or if there are "meta patches" which don't increase the number after the version milestone. Only the hash pattern is sufficient as identification.

[foxyshadis]

Tagging specific builds/releases makes the most sense, then a changelog for the tagged revision will be the same forever. Tags are a lot easier to find visually than hashes.

[qyot27]

Okay, here's a pack of 4 different snapshots so that we can start narrowing down where in the last 100 commits this regression appeared:
http://www.mediafire.com/download/ajfnwwvpebr3ppm/avsplus_bisect_test.7z

I also included the git hash in the directory names so we know what the exact commits are.

[Groucho2004]

Okay, here's a pack of 4 different snapshots so that we can start narrowing down where in the last 100 commits this regression appeared:
http://www.mediafire.com/download/ajfnwwvpebr3ppm/avsplus_bisect_test.7z
I also included the git hash in the directory names so we know what the exact commits are.
Thanks for building these. r1727 and r1770 are OK, everything above (r1779, 1783, ...) is not.

A script for quickly checking if the dll exhibits the "fps deterioration":
SetMemoryMax(1024)
colorbars(width = 640, height = 480, pixel_type = "yv12").killaudio().assumefps(25, 1).trim(0, 49999)
AssumeTFF()
QTGMC(Preset="Super Fast")
Running this through AVSMeter you'll see after 3000~5000 frames whether the FPS is stable or not.

[qyot27]

Thanks for building these. r1727 and r1770 are OK, everything above (r1779, 1783, ...) is not.
Okay, that narrows it down to 13 commits that need to be checked. Better yet is that some of them are clearly not related to this at all, and some of the others only have to do with how filters register themselves as MT or in naming (which probably wouldn't be causing any issues with speed drops after the script starts). Which only really leaves 4 that are highly suspect, and they're all together:
c4972da Fix leaking subframes.
b361e59 Fix #37 by not using filter instances to get their MT mode.
422aae8 At least avoid leaking the VFBs when plugin or host is leaking.
3cb1122 Report invalid param of SelectEvery to user.
I strongly suspect it's either 422aae8 or c4972da that's doing it. Of course, those commits look like they're supposed to fix leaks in the core, so it's either doing it too aggressively, or it may even actually be exposing leaks in the plugins QTGMC uses.

[qyot27]

Round 2:
http://www.mediafire.com/download/f2nvkzwleszaub0/avsplus_bisect_test_round2.7z

This has builds of the four commits I mentioned in the last post.

[Reel.Deel]

r1774 (c4972da) (https://github.com/AviSynth/AviSynthPlus/commit/c4972da35ca1f2803c64d33b372327c468d03cde) is definitely the culprit; it even had this comment:
// TODO: Figure out why uncommenting this line causes problems

Tested using the Groucho's script above.

r1773:
http://s2.postimg.org/f0g3pjz1h/Avi_Synth_r1773.jpg (http://postimg.org/image/f0g3pjz1h/)

r1774:
http://s15.postimg.org/ypicd8fav/Avi_Synth_r1774.jpg (http://postimg.org/image/ypicd8fav/)

I believe this is the issue (http://forum.doom9.org/showthread.php?p=1713107#post1713107) that spawned that/those commit(s).

Edit: old commit that might be relevant to this issue: https://github.com/AviSynth/AviSynthPlus/commit/71b9187abce06c74b1ddd62daff5af7dfab2c1a5

[Thunderbolt8]

I'd like to request the addition of Rec. 2020 support for UHD Blu-rays & corresponding conversion options to compare UHD screenshots with normal Blu-ray screenshots. Otherwise we'd have to do it all manually.

Would be nice if the developers could add this in the future.

[LigH]

This would certainly mean that all probable decoder plugins need to be able to signal source colorimetry metadata to the AviSynth+ kernel as well.

[Elegant]

r1774 (c4972da) (https://github.com/AviSynth/AviSynthPlus/commit/c4972da35ca1f2803c64d33b372327c468d03cde) is definitely the culprit; it even had this comment:


Tested using the Groucho's script above.

r1773:
http://s2.postimg.org/f0g3pjz1h/Avi_Synth_r1773.jpg (http://postimg.org/image/f0g3pjz1h/)

r1774:
http://s15.postimg.org/ypicd8fav/Avi_Synth_r1774.jpg (http://postimg.org/image/ypicd8fav/)

I believe this is the issue (http://forum.doom9.org/showthread.php?t=168856&page=48#post1713107) that spawned that/those commit(s).

Edit: old commit that might be relevant to this issue: https://github.com/AviSynth/AviSynthPlus/commit/71b9187abce06c74b1ddd62daff5af7dfab2c1a5

I did a whole bunch of comparisons between the AVS 2.6 and AVS+ regarding this. Could you test this build (https://www.dropbox.com/s/k2p0a4wakxyzarp/AVS%2B%20Test%20Build%20-%2020150901.7z?dl=0) and see if the issue still occurs? I'll test it myself later when I have access to my PC with my plugins.

[Reel.Deel]

I did a whole bunch of comparisons between the AVS 2.6 and AVS+ regarding this. Could you test this build (https://www.dropbox.com/s/k2p0a4wakxyzarp/AVS%2B%20Test%20Build%20-%2020150901.7z?dl=0) and see if the issue still occurs? I'll test it myself later when I have access to my PC with my plugins.

I get this error with AVSMeter: Exception 0xC0000005
STATUS_ACCESS_VIOLATION

Edit: tried another time with AVSMeter and this time it ran for about 500 frames and then I got the error above. Using VirtualDub to run an analysis pass, the fps drop is very obvious, it goes from 100fps to 2 within 500 frames and then I got this error:

Avisynth read error:
Could not allocate video frame. Out of memory.

[Elegant]

Thanks, looking back at the change I made, that makes sense since I actually forgot to apply it to the rest of file and only fixated on the lines listed in that commit mentioned earlier and assumed the rest of it would work itself out (bad idea!). I'll test it fully at home and hopefully my idea pans out.

I found this comment very interesting as AVS 2.6 utilizes it in the "troubled" area:

// Hack note :- Use of SubFrame will require an "InterlockedDecrement(&retval->refcount);" after
// assignement to a PVideoFrame, the same as for a "New VideoFrame" to keep the refcount consistant.

This comment is made in both AVS 2.6 and AVS+ but AVS+ never utilizes InterlockedDecrement yet we use the refcount with AVS+ as well as InterlockedIncrement. More importantly we use refcount while going through the FrameRegistry list mentioned in the commit where frame is a value in the FrameRegistry:

if (0 == frame->refcount)
{
delete frame;
}

At a glance this looks like a problem. I can't say for certain but I do not like that we never decrement a counter and yet have a condition for when it's 0 to delete it. I thought simply adding that comment to the "troubled" area would fix the problem but I think there are more areas that need an visiting in order for that to work.

EDIT: I did do a build where I reverted that commit and it does rectify the issue but it doesn't seem right to be using it as is...

[raffriff42]

AviSynth+_v0.1.0_r1779.exe
http://avisynth.nl/index.php/AviSynth%2B#DownloadsColorbars(pixel_type="YV12")
return Histogram("audiolevels")
==> "Integer Divide by Zero"

ConvertAudioTo16bit does not help.
v2.60 Jan 14 2013 is OK.

[qyot27]

AviSynth+_v0.1.0_r1779.exe
http://avisynth.nl/index.php/AviSynth%2B#DownloadsColorbars(pixel_type="YV12")
return Histogram("audiolevels")
==> "Integer Divide by Zero"

ConvertAudioTo16bit does not help.
v2.60 Jan 14 2013 is OK.
That seems to be an issue with the tone ColorBars generates. If you kill the audio and replace it with the output of Tone(), Histogram works fine.

[raffriff42]

It's not only ColorBars:Colorbars(pixel_type="YV12")

#[[ choose a source
A=WAVSource("pinknoise.wav") ## mono
A=MonoToStereo(A, A)
## 2 ch, 16 bit, 44100
#][
# A=Tone
# ## 2 ch, float, 48000
#]]
AudioDub(A)

#[[ choose one or more - any of these causes divide-by-zero
# ConvertAudioToFloat
# ConvertAudioTo32bit
# ConvertAudioTo16bit
#]]

Histogram("audiolevels")
Info
return Last
:confused:

[burfadel]

So... Any new post 1825 test builds? I'm particularly interested in the 64-bit version.