Avisynth+

[mkver]

Are you telling me I should use MaskTools instead of Levels (I have already thought about it, but I wanted to know whether this is a bug in Levels or not first)? Or are you thinking that Levels is part of MaskTools?
Anyway, thanks for answering.

[MysteryX]

Sorry I didn't read correctly and mixed things up when you mentioned LUT. Forget what I said. I'll leave Pinterf answer.

If it uses a LUT table, however, it's likely it might use a similar logic.

[TheFluff]

Levels always uses a LUT currently. There's a comment (https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/filters/levels.cpp#L159) in the code that says runtime evaluation is todo for 32-bit float input.

The reason it eats so much memory with dithering enabled is that enabling dithering multiplies the LUT size by 256; see line 179 (https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/filters/levels.cpp#L179) and the subsequent allocation on line 195 (https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/filters/levels.cpp#L195).

[mkver]

Thanks for pointing to the source. And what's the logic that makes a 10bit LUT use the same memory as a 16bit LUT? Is it because of the "garbage" (https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/filters/levels.cpp#L199) mentioned here? (Garbage means that the most significant bits aren't necessarily zero, although they should be, or?)
And because IsYUV is true for Y8-Y16, line 193 (https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/filters/levels.cpp#L193) and line 203 (https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/filters/levels.cpp#L203) imply that a chroma LUT is created for monochrome formats.

[tebasuna51]

I found a difference between Avs+ and AviSynth 2.60 behaviour.

This script with Avs+:

WavSource("16-bit-int.wav")
SSRC(44100)

don't work with Avs+ and show a error: Input audio sample format to SSRC must be float.

Work fine with AviSynth 2.60 and output a Float wav like be expected by documentation (http://avisynth.nl/index.php/SSRC) :

"Audio is always converted to Float."

Please, instead show the error, do the conversion automatically.

[qyot27]

I found a difference between Avs+ and AviSynth 2.60 behaviour.

This script with Avs+:

WavSource("16-bit-int.wav")
SSRC(44100)

don't work with Avs+ and show a error: Input audio sample format to SSRC must be float.

Work fine with AviSynth 2.60 and output a Float wav like be expected by documentation (http://avisynth.nl/index.php/SSRC) :

"Audio is always converted to Float."

Please, instead show the error, do the conversion automatically.
That change was done deliberately (https://github.com/AviSynth/AviSynthPlus/commit/d40f4a2e833998199dec0e0e4737cf69c4607b6c), and is a long-acknowledged difference in behavior, because it was a conscious choice to enforce that AviSynth+ won't do implicit conversions between formats. Erroring out here isn't any different from other errors regarding filters not supporting X pixel format for video. You have to use ConvertTo there if you try giving a filter the wrong format, if you have int audio and want to give it to SSRC, then use ConvertAudioToFloat on it first. Either that, or the SSRC filter itself should be extended to actually support int audio input.

This should instead be mentioned in the AviSynth+ page on the wiki, since you can't expect other AviSynth+ changes to be true for 2.6's doc entries either, save for Plus revisions to be explicitly noted (there are some places it is, right?). I thought the 'no implicit conversions' decision was mentioned on the AviSynth+ page at some point, but may have gotten lost in the updates and that page getting split up.

[tebasuna51]

I can't understand for what introduce unnecesary differences with the standard Avisynth behavior.

Is only a way to obtain bug reports, like mine.

I think I read all Avs+ docs and don't see nothing about it.

[manolito]

I totally agree with tebasuna. The "+" in AVS+ stands for "Everything which standard AVS has, and then plus a lot of other things". At least this is how it should be.

Breaking backward compatibility is a BAD thing, and it's even worse if it is not a bug, but a deliberate design decision. Even if you think that the standard AVS design is wrong, you cannot just change it because of the huge installed standard AVS user base. If you want to change the design then do something completely different like VapourSynth.


Cheers
manolito

[Sharc]

Agree, +1

[TheFluff]

If you want bug-for-bug compatibility with Avisynth 2.5.8 until the heat death of the universe, then maybe what you want to use is... Avisynth 2.5.8? But then again, adding an explicit ConvertToFloat call is hardly back-breaking labor for any of you, now is it? In fact, I'd wager it's less work than downgrading to 2.5.8. I mean, yeah, it should be documented that it doesn't implicitly convert anymore, but the presence of implicit conversions has a far greater potential for Surprise and Confusion than removing them does. Yes I know you're used to the old behavior but that doesn't mean it's any less confusing for new users.

I totally agree with tebasuna. The "+" in AVS+ stands for "Everything which standard AVS has, and then plus a lot of other things". At least this is how it should be.

Breaking backward compatibility is a BAD thing, and it's even worse if it is not a bug, but a deliberate design decision. Even if you think that the standard AVS design is wrong, you cannot just change it because of the huge installed standard AVS user base. If you want to change the design then do something completely different like VapourSynth.

If people actually consistently applied this logic then Avs+ would never have happened, because like it or not it is a substantial design departure from OG Avisynth in many respects. It maintains a user interface that is mostly similar, but even that is not the same.

Either way though, "once you've got a design that a lot of people use you can't ever change it" is a fundamentally brain damaged position to take in software design.

[stax76]

There is always something between black and white..., like a option both on system and file level.

[vcmohan]

To satisfy both, may be, have a separate section in doom9 forum like vapoursynth has.

[Motenai Yoda]

iirc the strict check about variables type was introduced with 2.6 vanilla branch

[raffriff42]

That change was done deliberately, and is a long-acknowledged difference in behavior, because it was a conscious choice to enforce that AviSynth+ won't do implicit conversions between formats. Erroring out here isn't any different from other errors regarding filters not supporting X pixel format for video.Makes sense to me. If the conversion must be made, do so explicitly.

[LigH]

An explicit conversion may be necessary for newer AviSynth versions; but at least it doesn't break compatibility to older versions.

[MysteryX]

An explicit conversion may be necessary for newer AviSynth versions; but at least it doesn't break compatibility to older versions.
If you have an old script that was doing an implicit conversion, it will break.

Same as here.

I see no difference.

In both cases you need to do explicit conversion.

[LigH]

I just meant, you don't need explicit for one version and implicit for the other; only explicit for all. Be a good example, be verbose. ;) Sorry, I started learning serious programming with Pascal, I am used to be a bit more explicit, due to the stricter type checks. At least I don't rate a small one-line addition as desaster. Incompatibilities between PHP versions 4.x, 5.2, 5.4 and 5.6 are a lot worse (e.g. HTML entity conversion functions silently returning an empty string when one character is in the wrong character set, instead of throwing an error, which you can avoid by explicitly stating the character set, which is incompatible to earlier PHP versions not knowing this parameter).

[manolito]

Sorry I do not understand this whole fuss about explicit converttoflow or do it automatically..

SSRC is a filter which is integrated into AviSynth, but which is basically separate code which is not related to AviSynth. SSRC happens to require float input. If the input is not float then it must be converted to float somehow, I don't care if Avisynth does the conversion or if SSRC does it. Since the user obviously wants SSRC, it is safe to assume that he just forgot to do the conversion explicitly. Instead of throwing an error (which is the equivalent of telling the user that he is stupid), why can't SSRC (or AviSynth) do this conversion automatically? It has worked this way for many years, nothing about it is confusing, it just makes my life easier AND IT WORKS! The most important principle for software development is to make it easy to get working results, not to teach the developer about correct programming habits.

If Fluffy calls this a "brain damaged approach", I couldn't care less. He can apply his principles when he does Bible studies, there is no room for such principles in the real word.


Cheers
manolito

[StainlessS]

it is safe to assume that he just forgot to do the conversion explicitly

Yep, dont matter whether intentional or otherwise, the output IS gonna be Float (assuming it succeeds) so throwing error if input
not of type float is just a nuisance and of zero benefit at all, but will for sure break some scripts.

EDIT: I cannot think of any positive result coming from being pernickety here.

[raffriff42]

Yep, dont matter whether intentional or otherwise, the output IS gonna be Float (assuming it succeeds) so throwing error if input not of type float is just a nuisanceThis would prevent SSRC (or TimeStretch (http://avisynth.nl/index.php/TimeStretch)) from supporting any new audio format in the future -- like SuperEQ (http://avisynth.nl/index.php/SuperEQ) does, which now accepts 16-bit in addition to Float. To make that happen, auto-convert had to go.

EDIT correction, SuperEQ does not accept 16-bit.

[StainlessS]

OK, I accede to your wisdom [no need to look so smug about it Douglas] :)

You look so so smug in every single pic of you:- https://www.google.co.uk/search?q=&tbm=isch&tbs=rimg:CSJIstBG2cOwIjggUE5UMpFKMz0T4UmMLj0CfXMF0VZGVfdXxpr40SvOptEd_16D6Za4dHHg0W9c6hcnV1vfisq_1gsioSCSBQTlQykUozEW7zY36NY5E3KhIJPRPhSYwuPQIRSiX2oCo2BjAqEgl9cwXRVkZV9xFKRTZf8CfsGyoSCVfGmvjRK86mEctSbu_1_1iM_16KhIJ0R3_1oPplrh0RtshhNBBhseUqEgkceDRb1zqFyRFTSE4t9zOIVCoSCdXW9-Kyr-CyEeiwTK8XA2o2&tbo=u&sa=X&ved=0ahUKEwj667rz4fHUAhWKWhQKHaK5AakQ9C8IHw&biw=1280&bih=821&dpr=1

[tebasuna51]

This would prevent SSRC (or TimeStretch (http://avisynth.nl/index.php/TimeStretch)) from supporting any new audio format in the future -- like SuperEQ (http://avisynth.nl/index.php/SuperEQ) does, which now accepts 16-bit in addition to Float. To make that happen, auto-convert had to go.

Don't have sense for me.

SSRC, TimeStretch and SuperEQ need work internally with float samples, to accept other format need convert the input to float.

Like AviSynth support 8, 16, 24 and 32 bit int need the 4 conversions in each plugin. For what don't use the already exist conversions inside AviSynth?

And what do at end?

1) Reconvert the float to input precission?
Lossy conversion to 8 or 16 bits?
Upsample to 32 bits int?
Normalize if some peaks go over 0dB?
Thats need a lot of duplicated rutines in all plugins.

2) Or output the float samples?
That is also a problem, the user supply a format and recover other without notice.
It is not a good purist software.

The user must know the change like is informed when read:

"Audio is always converted to Float"

The "AVS+ no conversion is performed. Accepts 16-bit or Float audio (although Float is recommended)" behavior is usseless.
If audio is 8, 24 (frequently) or 32 bits int we need explicit conversion.

And, what is the output format?

[hello_hello]

This would prevent SSRC (or TimeStretch (http://avisynth.nl/index.php/TimeStretch)) from supporting any new audio format in the future -- like SuperEQ (http://avisynth.nl/index.php/SuperEQ) does, which now accepts 16-bit in addition to Float. To make that happen, auto-convert had to go.

I'm struggling with that one a little. Maybe I'm being dumb but why would you want SSRC or TimeStretch to support 16 bit input if they support 32 bit float and Avisynth always converts to float?

If you want bug-for-bug compatibility with Avisynth 2.5.8 until the heat death of the universe, then maybe what you want to use is... Avisynth 2.5.8? But then again, adding an explicit ConvertToFloat call is hardly back-breaking labor for any of you, now is it? In fact, I'd wager it's less work than downgrading to 2.5.8. I mean, yeah, it should be documented that it doesn't implicitly convert anymore, but the presence of implicit conversions has a far greater potential for Surprise and Confusion than removing them does. Yes I know you're used to the old behavior but that doesn't mean it's any less confusing for new users.

It's a bit over the top to describe what was obviously a design choice as a bug, and none of that tells me why the new way is better.

As a user I'd expect the lack of implicit conversion to mean the output will be the same as the input. Will that be the case if I use multiple plugins that accept 16 bit audio? For a 16 bit input will the audio be converted to float and back by each plug-in? Is there an argument to prevent that? ie SuperEQ(OutputConversion=false) or how does it work? I'm confused if not surprised.

Personally I think a better idea would be to keep the old method and have AVS+ automatically convert the output to the same format as the input as long as ConvertAudioTo() wasn't used in a script, although even then many lossy encoders accept 32 bit float, so it'd probably still require user input to prevent an unnecessary conversion at times.
Another method might be to always output the same format as the input when the audio isn't being processed, and to always output a particular format when it is..... oh..... wait a minute....

What's the worst that can result from an automatic conversion to float, which I don't think happens anyway unless the audio is being processed in some way. Sometimes having to add ConvertAudioTo() to a script?

[TheFluff]

It's a bit over the top to describe what was obviously a design choice as a bug
A bug is really no more than undesired or unintended behavior. If you change what is desired or intended (like Avs+ did) without changing the code, then you have (by definition) created a bug, which you can then fix. I called the OG Avisynth behavior a bug because I think the Avs+ intent is better, and that's all there is to it.

none of that tells me why the new way is better.
Is this really that hard to understand? At the very least it should be easy to see that it's inconsistent with everything else in Avisynth.

As a user I'd expect the lack of implicit conversion to mean the output will be the same as the input. Will that be the case if I use multiple plugins that accept 16 bit audio? For a 16 bit input will the audio be converted to float and back by each plug-in? Is there an argument to prevent that? ie SuperEQ(OutputConversion=false) or how does it work? I'm confused if not surprised.
In OG Avisynth, if you pass a 16-bit int audio clip to SSRC you will get a clip back with your new sample rate as desired, but it will also be converted to 32-bit float. It's kinda like if you called BicubicResize(1280,720) on a standard 8-bit YV12 clip but along with the resizing you also got your video upconverted to 16-bit YUV444. Which is fine if that's what you wanted, but it might not've been, and I certainly would not expect it.

If you pass 16-bit to SuperEQ in Avs+ I believe you will get 16-bit back.

Personally I think a better idea would be to keep the old method and have AVS+ automatically convert the output to the same format as the input as long as ConvertAudioTo() wasn't used in a script
This possibly the most backwards thing I've read in several months. You want two implicit conversions instead of one?

What's the worst that can result from an automatic conversion to float
If your input is 32-bit int you're gonna suffer a (usually meaningless) precision loss, because 32-bit float only has 24 bits of mantissa.

The problem here though isn't actually the conversion to float itself since nobody ever actually inputs anything but 16-bit int audio anyway, and upconverting that to float is relatively harmless. The problem is that it's directly opposite to what the video filters do (where nothing does implicit format conversion, for reasons that are apparently less hard to understand when it's video). There are even video filters that do temporary conversions to some special internal format for processing (see: Overlay) but even those do not come with an output conversion as a side effect. Consistency is nice, y'all.

[qyot27]

Just to put this in perspective, as well: the change in question occurred nearly four years ago. It was one of the earliest things that got committed to the nascent fork; I can't remember if the project had even accepted the 'AviSynth+' name yet, that's how old this is. And in all that time and now-89 pages of this thread, the 'no implicit conversion' behavior has been brought up only three or four times, and this latest time is the only one that's involved a heated back-and-forth.

Why do I think there's been an obvious silence on the issue?
A) After hearing the explanation for the change, users agreed that the new behavior is correct and adapted their scripts accordingly.
B) They weren't doing anything that would bring them into contact with the new behavior, because they were already working with float audio. WAVSource is the most likely place to hit this issue, because FFMS2 and LSMASHSource both output whatever libavcodec's decoder for the audio format decodes to. Which in the case of AAC (and who knows what other common formats*), is single precision float, not int. So users just didn't see it, because there was nothing for SSRC to complain about.

*MP3 still decoded to 16-bit integer the last time I checked, but that was a few months ago. I've not checked most of the other ones I come across more often, because I usually don't use those inside video files.

[hello_hello]

A bug is really no more than undesired or unintended behavior. If you change what is desired or intended (like Avs+ did) without changing the code, then you have (by definition) created a bug, which you can then fix. I called the OG Avisynth behavior a bug because I think the Avs+ intent is better, and that's all there is to it.

I think you'd have to be fairly self absorbed to equate changing a default behaviour to fixing a bug simply because the new behaviour is your personal preference.
If I add ConvertAudioToFloat() to a script am I introducing a bug or changing the default behaviour?.

Is this really that hard to understand? At the very least it should be easy to see that it's inconsistent with everything else in Avisynth.

Not really, because the video analogy doesn't work for me. There's a huge difference between changing audio bitdepth and changing video format.

In OG Avisynth, if you pass a 16-bit int audio clip to SSRC you will get a clip back with your new sample rate as desired, but it will also be converted to 32-bit float. It's kinda like if you called BicubicResize(1280,720) on a standard 8-bit YV12 clip but along with the resizing you also got your video upconverted to 16-bit YUV444.

You're not feeding a plugin PCM and having it output DSD.
It might be like resizing a standard 8 bit YV12 clip and having the resizer output 16 bit YV12 (or P016 or whatever it's called).

If you pass 16-bit to SuperEQ in Avs+ I believe you will get 16-bit back.

This possibly the most backwards thing I've read in several months. You want two implicit conversions instead of one?

If super EQ converts to 16 bit float internally, please explain the difference. I only suggested two implicit conversions, one to float if the audio is being processed and one back to the original format for the final output unless I specify something else, but do you really want every plugin to be doing it?

If your input is 32-bit int you're gonna suffer a (usually meaningless) precision loss, because 32-bit float only has 24 bits of mantissa.

If the audio is going in and out without being processed nothing is converted. If it is, how many plugins/filters wouldn't require a conversion to 32 bit float?

The problem here though isn't actually the conversion to float itself since nobody ever actually inputs anything but 16-bit int audio anyway, and upconverting that to float is relatively harmless.

I might find myself disputing that because I assumed most decoders would decode lossy audio to float or the highest bitdepth possible, so unless you're converting everything to 16 bit wave files first.....
I'm a GUI kind of guy and I actually don't use Avisynth for processing audio much, but Avisynth says this is 16 bit:

LoadPlugin("C:\MeGUI\tools\avisynth_plugin\NicAudio.dll")
RaWavSource("D:\audio.wav")

And this is 32 bit:

LoadPlugin("C:\MeGUI\tools\avisynth_plugin\NicAudio.dll")
NicMPG123Source("D:\audio.mp3")

The problem is that it's directly opposite to what the video filters do (where nothing does implicit format conversion, for reasons that are apparently less hard to understand when it's video). There are even video filters that do temporary conversions to some special internal format for processing (see: Overlay) but even those do not come with an output conversion as a side effect. Consistency is nice, y'all.

I'm the first to complain about inconstancy, but I can distinguish between a change of format and a change of bitdepth.

It just seems logical to me. Once you move up in bitdepth, you stay there till the bitter end or as long as possible, whichever comes first. If a plugin is going to move you up in bitdepth, it doesn't seem an issue to me if it's expected behaviour, and I assume all audio filters/plugins do for AVS? Having to manually convert to float at the beginning and back to integer at the end of a script to prevent a succession of filters up-converting and down-converting doesn't seem like a better idea.

I have no idea how high bitdpeth video processing works for AVS+. I've only had experience with the AVS hack, and there manually specifying bitdepth changes is unavoidable, but in a high bitdepth environment if it's upconverted once wouldn't you want to keep it that way until the final output?

[wonkey_monkey]

Okay, so... is SSRC like an internalised plugin that comes with AviSynth, right? And was it Avisynth itself which was making a special case out of it by looking out for calls to SSRC and converting audio to float beforehand? Or was it in the internal version of SSRC itself which was converting audio?

[raffriff42]

SSRC, TimeStretch and SuperEQ need work internally with float samples, to accept other format need convert the input to float.There is a bug in SuperEQ that I missed:
As tebasuna51 points out, SuperEQ works with float samples only, but unlike SSRC and TimeStretch, does not check the input sample type -- and crashes with non-Float input. Tested w/ r2489, r2506.

So SuperEQ does not actually accept 16-bit. Not sure how my 16-bit test didn't fail before (I have a clue though)

EDITwas it Avisynth itself which was making a special case out of it by looking out for calls to SSRC and converting audio to float beforehand? Yes (ssrc-convert.cpp line 56)

[tebasuna51]

Just to put this in perspective, as well: the change in question occurred nearly four years ago. It was one of the earliest things that got committed to the nascent fork; I can't remember if the project had even accepted the 'AviSynth+' name yet, that's how old this is. And in all that time and now-89 pages of this thread, the 'no implicit conversion' behavior has been brought up only three or four times, and this latest time is the only one that's involved a heated back-and-forth.

Why do I think there's been an obvious silence on the issue?
A) After hearing the explanation for the change, users agreed that the new behavior is correct and adapted their scripts accordingly.
I'm a new Avs+ user and is the first time I know the change after read Avs+ docs.

B) They weren't doing anything that would bring them into contact with the new behavior, because they were already working with float audio. WAVSource is the most likely place to hit this issue, because FFMS2 and LSMASHSource both output whatever libavcodec's decoder for the audio format decodes to. Which in the case of AAC (and who knows what other common formats*), is single precision float, not int. So users just didn't see it, because there was nothing for SSRC to complain about.

Yes, all (or most of them) lossy decoders output float samples without issues with SSRC.

The problem is with lossless decoders (FLAC, DTS-MA, TrueHD, ... or WAV input) most the times with 24 bit int samples.
Even is not normal need a SSRC over these sources.

I detected the behavior change (I was thinking a bug) when a user try a SSRC(48000) over a already 48000 source and MeGUI crash.

At least I hope than first verify if the resample is needed before than send the format error.

[raffriff42]

At least I hope than first verify if the resample is needed before than send the format error.Actually it does not!
https://github.com/pinterf/AviSynthPlus/blob/master/plugins/Shibatch/ssrc-convert.cpp#L175

[Zathor]

I am using r2508 (32bit) with an 10-bit input file and FFMS2 2.23.1 and getting an error:
ConvertToRGB: conversion is allowed only from 8 bit colorspace


source = "C:\TEMP\bug_890\clip10s.avi"
LoadPlugin("D:\MEGUI\tools\ffms\ffms2.dll")
V = FFVideoSource(source, fpsnum=30, fpsden=1, threads=1).Lanczos4Resize(1280, 720)
A1 = FFAudioSource(source, track=1).AmplifyDB(10) #.Normalize(volume=1.0, show=false)
A2 = FFAudioSource(source, track=2).Normalize(volume=1.0, show=false)
commentary = MonoToStereo(A1, A1) #.AmplifyDB(1.5)
audio = MixAudio(commentary, A2, 0.9, 0.1)
AudioDub(V, audio)
return last

The strange thing is I had the error from the beginning with this sources and then I played a bit with it (to narrow down which function is returning the error) till it vanished. And now also the exact same avs from the beginning does not throw the error anymore. While the error was there VirtualDub with AVS 2.6 (vanilla) did not throw this error.

Another user reported a similar thing:
https://sourceforge.net/p/megui/bugs/888/

Any thoughts what may causing this?

[sneaker_ger]

Vanilla AviSynth does not support >8 bit natively so ffms2 dithers down to 8 bit automatically. Then there's no error, of course. High bitdepth was only added in ffms2 2.23.1. So if you have older version or different source filter it will probably not happen either. (VirtualDub won't add ConvertToRGB() which I think is a MeGUI "feature". But VfW support for high bitdepth YUV ... ).

[raffriff42]

ConvertToRGB: conversion is allowed only from 8 bit colorspaceRGB24 & RGB32 are 8bit only in AviSynthPlus. For >8bit (high bit depth) RGB processing, you normally use:## source=YUV
ConvertBits(16) ## bits=10,12,14,16,32 (always upconvert bits *before* RGB<>YUV conversion)
ConvertToPlanarRGBA (http://avisynth.nl/index.php/Convert#RGB_planar)(matrix="Rec709")
Most >8bit RGB formats are planar (http://avisynth.nl/index.php/Planar).

If you need >8bit interleaved (http://avisynth.nl/index.php/Interleaved), you have 16bit RGB48 and RGB64:## source=YUV
ConvertBits(16)
ConvertToRGB64 (http://avisynth.nl/index.php/Convert#RGB_interleaved)(matrix="Rec709")

If you want to downconvert to 8bit RGB, use:
ConvertBits(8, dither (http://avisynth.nl/index.php/ConvertBits#dither)=0) ## (dither is optional)
ConvertToRGB32

[ajp_anton]

If we make SSRC convert to float automatically, we also need some way to show "warnings" to the user, which would say that SSRC has converted the audio. In this case with SSRC it would be safe, because either you convert or you get an error. But the user should be aware of this, because the output format might not be what you expect.

[tebasuna51]

If we make SSRC convert to float automatically, we also need some way to show "warnings" to the user, which would say that SSRC has converted the audio. In this case with SSRC it would be safe, because either you convert or you get an error. But the user should be aware of this, because the output format might not be what you expect.

No problem, seems the audio AviSynth behaviour is don't know very well.

AviSynth always downconvert float audio to 16 int at output.

Unless you use (v2.57):

global OPT_AllowFloatAudio=True

The users than add this global variable know very well than SSRC always convert audio to float.

Using MeGUI or BeHappy is not needed that
global OPT_AllowFloatAudio=True
because a special interface with AviSynth: AvisynthWrapper.dll

But MeGUI/BeHappy always convert the output samples to the best precission suported by the encoder than go after.
The users don't need care about it.

-----------------------------

I can accept a diferent behaviour betwen AViSynth and Avs+ but the first improvement than audio management need is:

Replace the audio property nchannels by maskchannels.
In AviSynth.h instead:

int audio_samples_per_second; // 0 means no audio
int sample_type; // as of 2.5
__int64 num_audio_samples; // changed as of 2.5
int nchannels; // as of 2.5

int audio_samples_per_second; // 0 means no audio
int sample_type; // as of 2.5
__int64 num_audio_samples; // changed as of 2.5
int maskchannels; // New

where nchannels can be calculated easily with maskchannels.
Now decoders, than know maskchannels, can pass that value to AviSynth.

[qyot27]

No problem, seems the audio AviSynth behaviour is don't know very well.

AviSynth always downconvert float audio to 16 int at output.

Unless you use (v2.57):

global OPT_AllowFloatAudio=True
It only downconverts to 16-bit automatically or require OPT_AllowFloatAudio when serving through ACM. The docs need to be updated to be more precise about that.

>cat test.avs
ColorBars()

>ffmpeg -i test.avs
ffmpeg version r86337 git-39c8e0dd8e Copyright (c) 2000-2017 the FFmpeg developers
built on May 31 2017 19:37:35 with gcc 7.1.0 (GCC)
libavutil 55. 63.100 / 55. 63.100
libavcodec 57. 96.101 / 57. 96.101
libavformat 57. 72.101 / 57. 72.101
libavdevice 57. 7.100 / 57. 7.100
libavfilter 6. 90.100 / 6. 90.100
libavresample 3. 6. 0 / 3. 6. 0
libswscale 4. 7.101 / 4. 7.101
libswresample 2. 8.100 / 2. 8.100
libpostproc 54. 6.100 / 54. 6.100
Guessed Channel Layout for Input Stream #0.1 : stereo
Input #0, avisynth, from 'test.avs':
Duration: 01:00:00.00, start: 0.000000, bitrate: N/A
Stream #0:0: Video: rawvideo (BGRA / 0x41524742), bgra, 640x480, 29.97 fps, 29.97 tbr, 29.97 tbn, 29.97 tbc
Stream #0:1: Audio: pcm_f32le, 48000 Hz, stereo, flt, 3072 kb/s
At least one output file must be specified
This is true of classic AviSynth 2.6 as well as AviSynth+.

If we make SSRC convert to float automatically, we also need some way to show "warnings" to the user, which would say that SSRC has converted the audio. In this case with SSRC it would be safe, because either you convert or you get an error. But the user should be aware of this, because the output format might not be what you expect.
Already exists:
http://avisynth.nl/index.php/AviSynth%2B#Logging_Facility

But it still depends on the filter/plugin emitting those warnings and other informational messages, which almost nothing does because it wasn't historically possible to do this.

[tebasuna51]

It only downconverts to 16-bit automatically or require OPT_AllowFloatAudio when serving through ACM. The docs need to be updated to be more precise about that.

Like was designed AviSynth initially. You still can see the behaviour with VirtualDub, wavi, ...

The question here is:

A automatic conversion to float is not a problem, if serving through ACM there are a downconvert to 16 int, other modern soft like MeGUI, BeHappy, ffmpeg, avs2pipemod, ... can manage float samples without lose precission downconverting the samples to initial format.

[Zathor]

RGB24 & RGB32 are 8bit only in AviSynthPlus.

Thank you very much. MeGUI - or to be more specific the AvISynthWrapper.dll - does a
res = pstr->env->Invoke("ConvertToRGB24", AVSValue(&res, 1));
for each script which will be serviced within MeGUI. This has been done way before my time so I had to search a bit. I assume the reason is that then the function to return a single video frame bitmap returns something which can be easily used in MeGUI:
PVideoFrame f = pstr->clp->GetFrame(frm, pstr->env);
if (buf && stride)
{
pstr->env->BitBlt((BYTE*)buf, stride, f->GetReadPtr(), f->GetPitch(), f->GetRowSize(), f->GetHeight());
}

[LigH]

As just an AviSynth user, not a developer, I care little about whether audio gets converted to float samples implicitly for filters which need that; I just need this feature to be both reliable and well documented, and optimally with verbose and specific enough error messages if my script doesn't fulfill the requirements. As already said: I am used to be forced to adapt existing scripts upon updates in a much worse way by PHP. How bad can it get with AviSynth, knowing that you developers out there care so much about us users?

[qyot27]

Like was designed AviSynth initially. You still can see the behaviour with VirtualDub, wavi, ...
Like I said, ACM. But that is not 'default' behavior, it's just a compatibility hack for a Microsoft media framework because IanB didn't want to start throwing WAVE_FORMAT_IEEE_FLOAT around back then due to a presumed lack of support for float audio in receiving programs (in 2017 this should now be a minority, even if it was true in 2006); just because ACM access was the most likely way of a program accessing AviSynth 10+ years ago is irrelevant when not only is it now a lot more common for programs to talk to the library directly without the ACM go-between, but it honestly wouldn't surprise me if Microsoft phases out ACM entirely at some point.

It has nothing to do at all with how AviSynth as a library behaves (or any media library behaves), and I'm certain that's why anything using direct access to AviSynth as a regular library is not subject to this and never has been.

A automatic conversion to float is not a problem, if serving through ACM there are a downconvert to 16 int, other modern soft like MeGUI, BeHappy, ffmpeg, avs2pipemod, ... can manage float samples without lose precission downconverting the samples to initial format.
So suddenly start forcing modern software that access AviSynth directly to invoke a pointless downconversion with inherent rounding errors just to satisfy people that want it to behave like ACM is sitting between them when it isn't?

FFmpeg is likely going to be that standard bearer now, considering the number of media software projects that utilize libavformat for their file format support, and so anything that uses libavformat potentially has access to AviSynth. FFmpeg will automatically reject any patch that introduces a downconversion like that, guaranteed.

[tebasuna51]

So suddenly start forcing modern software that access AviSynth directly to invoke a pointless downconversion with inherent rounding errors just to satisfy people that want it to behave like ACM is sitting between them when it isn't

Is not the same than I say before?

I don't want than SSRC, TimeStrech, etc. accept 16 bit, convert to float and after downconvert to 16 bit to be transparent to the user.

And, for what introduce a problem when is clear in AviSynth docs?

"Audio is always converted to Float"

Point.

[qyot27]

Is not the same than I say before?

I don't want than SSRC, TimeStrech, etc. accept 16 bit, convert to float and after downconvert to 16 bit to be transparent to the user.
Then you're at a fundamental disagreement with AviSynth+. The idea that users should be ignorant of format changes being done without their explicit consent is flatly and absolutely rejected. It's been like that from the start.

The output behavior isn't something AviSynth+ did, all I did was point out that OPT_AllowFloatAudio and the downconvert were not absolute. If I had my druthers, we'd do away with OPT_AllowFloatAudio entirely so that ACM behavior matches direct library access. In 2017 most programs should not have issues taking Float audio, and in the rare case one does, that should be the user's responsibility to make the script comply with it, not make the correct behavior an opt-in because some vague notion of undisclosed program names 10 years ago maybe couldn't handle Float audio.

Direct library access is the proper and preferred method to use AviSynth (explicitly so for AviSynth+, but classic AviSynth had been moving in that direction for years). It's not a bug that direct library access has only ever output the final processed format rather than forcing a downconversion. The docs not being clear about that isn't AviSynth+'s fault.

[hello_hello]

What's the logic behind the formats some audio filters accept, and why isn't 16 bit converted to float for processing?

http://avisynth.nl/index.php/Amplify
"8bit and 24bit audio is converted to float; the other audio formats are kept as they are."

Is that what actually happens, or is it misleading and every format is converted to float, but for 16 bit integer it's automatically converted back?

When it comes to audio bit depth, I'm not sure I'd care about converting to a higher bitdepth automatically. You don't lose quality, and a higher bit depth output generally wouldn't be a problem. If the output is being converted to a lossy format and float is acceptable, (why is LAME still limited to 24 bit?) the user gets to be ignorant of no harm having been done.
If AVS did convert to float when a filter needed it, there's a possibility user intervention would be being required at the output stage rather than prior to the filter, but if it doesn't, user intervention is required each time a similar filter is used.
.
Automatically converting video from one type to another is one thing, but I'm not sure converting "type" and converting "bit depth" necessarily have to follow the same rules. If I was ruler of the world, the law would require the same bit depth in and out when there's no processing involved, and float when there is, as all filters would be required to accept float.

How does an all high bit depth video environment work? I had imagined in a perfect world you'd open a video of any bitdepth and it'd be upsampled to the highest bitdepth possible for processing, and only converted to the original/user specified bit depth at the output stage. It's probably not that simple for AVS+ at the moment, but wouldn't the ideal be for AVS+ to upsample all video automatically to be processed with native 16 bit filters/plugins, and only require the user to permit/specify a change of bitdepth when loading a legacy 8 bit plugin, or at the final output stage?

[qyot27]

What's the logic behind the formats some audio filters accept, and why isn't 16 bit converted to float for processing?
When a filter is written, the formats it supports are based on how the methodology of the algorithm it uses to do the processing was written. Fixed-point (integer) math is often fastest, especially because there's a lot more useful SIMD instructions designed for fixed-point than there are for floating point. This is true for audio or video filters.

Is that what actually happens, or is it misleading and every format is converted to float, but for 16 bit integer it's automatically converted back?
No, the filter doesn't support processing in 8 or 24 bit, so it converts the file's depth in order to process in 16 bit. Some filters support both 16 bit or Float, in which case it probably prefers 16 bit if the file is already integer, but keeps it in Float if it was Float. Most of the audio filters in the core support all the formats, which implies there are codepaths for each format to be processed natively.

How does an all high bit depth video environment work? I had imagined in a perfect world you'd open a video of any bitdepth and it'd be upsampled to the highest bitdepth possible for processing, and only converted to the original/user specified bit depth at the output stage. It's probably not that simple for AVS+ at the moment, but wouldn't the ideal be for AVS+ to upsample all video automatically to be processed with native 16 bit filters/plugins, and only require the user to permit/specify a change of bitdepth when loading a legacy 8 bit plugin, or at the final output stage?
Filtering should be done at the same bit depth as the input to actually be efficient speed-wise and quality-wise. There's some technicalities when dealing with bit depths between 8 and 16 bit and how that gets arranged in addressing; upsampling for processing and then downsampling on output is avoided to prevent rounding errors introduced later. It's just not necessary to do that filtering in the highest bitdepth first.

[Wilbert]

@qyot27, i changed the online documentation to reflect the actual behaviour.

[hello_hello]

Filtering should be done at the same bit depth as the input to actually be efficient speed-wise and quality-wise. There's some technicalities when dealing with bit depths between 8 and 16 bit and how that gets arranged in addressing; upsampling for processing and then downsampling on output is avoided to prevent rounding errors introduced later. It's just not necessary to do that filtering in the highest bitdepth first.

So for video plugins that currently use the LSB hack to support 16 bit processing with AVS, is that basically a waste of time if your input is 8 bit and the output will be the same? I thought the idea was to process with greater precision, even if the video is dithered down to 8 bit in the end.
Not the I use the 16 bit hack much, but I thought that was the main point of it.

On the audio thing.... if a filter supports both 16 bit int and float, are you still better off converting to float first, precision-wise?

Thanks.

[qyot27]

So for video plugins that currently use the LSB hack to support 16 bit processing with AVS, is that basically a waste of time if your input is 8 bit and the output will be the same? I thought the idea was to process with greater precision, even if the video is dithered down to 8 bit in the end.
Not the I use the 16 bit hack much, but I thought that was the main point of it.
That...depends. Supersampling is generally understood more in the vein of 'resize up, filter at the higher resolution, then resize back down', but that's staying inside of the same bit depth. Running filters on high bit depth input might provide a smoother gradient scale, and you might be able to retain *some* of that when you dither back down to 8 bit and use a lossy encoder on it, but it may also be possible to get similar results without processing it in >8bit. That's why the LSB hack is typically intended to be input to programs that can stitch it back into a proper high bit depth stream, since at least then it can keep the same >8bit gradient scale.

There's also the question of how much CPU and memory all of that would eat and whether whatever benefit you do end up seeing is worth it, or whether keeping it all in the same bit depth is faster for the same general perceptual quality (and a lot of that is naturally subjective).

On the audio thing.... if a filter supports both 16 bit int and float, are you still better off converting to float first, precision-wise?
The only thing I've ever really heard about the benefit of processing in float vs. integer is the claim that float processing prevents clipping. How true that is in practice, I don't know. Also whether you'd even need to worry about clipping, depending on what filter(s) you're using.

If there's no obvious difference in quality, whichever is faster.
If neither is distinctly faster, use what the encoder you're giving it to supports.

Regarding the encoder part, if you're dealing with something like ffmpeg, ffmpeg as a command line program is distinct from the libavcodec encoders you'd be feeding the stream to. For instance, with MP3: LAME supports multiple formats including 16-bit integer, 32-bit integer, and float, whereas libshine only supports 16-bit integer. So optimally, even though ffmpeg has no problems opening float audio (and will perform the conversion prior to handing it to the encoder), if you wanted to encode with libshine, it would be more streamlined to output 16-bit int from AviSynth, so ffmpeg wouldn't have to convert it first. But if you were going to use LAME, you could use any of the three formats it allows.

@qyot27, i changed the online documentation to reflect the actual behaviour.
Thanks.

[hello_hello]

qyot27,
Thanks for the info.

Previously when I asked why LAME is still limited to 24 bit, I appear to have put myself in the completely wrong category.

When foobar2000 creates a LAME encoder preset itself, it sets 24 as the maximum input bit depth, and I would've bet copious amounts of money I'd tested that, but I tried setting the maximum input bitdepth to 32 (which I assume is always float for foobar2000) and had no problem encoding with LAME. I'll have to ask about it in the foobar2000 forum.
(Edit: I asked and apparently 32 bit float support was added to LAME with version 3.99)

Thanks for the info regarding high bitdepth processing of 8 bitdepth video. As processing in 16 bit is very slow using my old PC and I'd not seen much visible benefit compared to 8 bit, or realistically any benefit at all most of the time, I've not bothered filtering in 16 bit. I'd assumed "technically" it'd still be better, even if in practice it often appears not to be.

So I guess "preventing clipping" would be the only remaining argument for always converting audio to float for processing, especially when multiple filters are daisy-chained. I assume that's why foobar2000 always converts to float when a DSP is used, which seems reasonable (at least that's my understanding).
I'd be close to admitting I was wrong when it comes to the implicit vs explicit conversion of bit depth, except for the possibility of clipping avoidance. To my way of thinking if converting to float prevents it, it should be prevented, and if a filter is capable of inducing clipping, processing the audio in anything but float seems like a bad idea, and therefore accepting anything but float as the input would also be less good.
It doesn't eliminate the need for checking for clipping at the output stage, but at least you don't have to worry about it until then.

Cheers.

[tebasuna51]

The only thing I've ever really heard about the benefit of processing in float vs. integer is the claim that float processing prevents clipping. How true that is in practice, I don't know.

Float values can't have clipping because support volume values over 0dB, the clip occurs when are converted to int samples and any value over 0dB are truncated.

Precission of float 32 values is equivalent (more or less) to 24 bit int because 32 float have 24 bits for mantissa (+ 8 for exponent).
Downsample to 16 bits int lose precission, and the average human ear can distinguish up to 20-bit differences.

Math operations must be do always in float format to preserve precission even with low values.
Int maths:
(3/2)x2 = 2
float maths:
(3.0/2.0)x2.0= 3.0

[pinterf]

Thanks for pointing to the source. And what's the logic that makes a 10bit LUT use the same memory as a 16bit LUT? Is it because of the "garbage" (https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/filters/levels.cpp#L199) mentioned here? (Garbage means that the most significant bits aren't necessarily zero, although they should be, or?)
And because IsYUV is true for Y8-Y16, line 193 (https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/filters/levels.cpp#L193) and line 203 (https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/filters/levels.cpp#L203) imply that a chroma LUT is created for monochrome formats.
Yes, because of the possible garbage.
Anyway, Levels was among the first filters that was ported and the code is probably a bit messy and not finished (float support).
Nor did I benchmark that a safety check on over-10-bits garbage before applying LUT (and thus allowing smaller 10 bit LUT tables) has any significant effect on execution time. Sure, Levels is on my todo list.