Avisynth+

[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=&t...&bih=821&dpr=1

[tebasuna51]

Originally Posted by raffriff42

This would prevent SSRC (or TimeStretch) from supporting any new audio format in the future -- like 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]

Originally Posted by raffriff42

This would prevent SSRC (or TimeStretch) from supporting any new audio format in the future -- like 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?

Originally Posted by 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.

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]

Originally Posted by hello_hello

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.

Originally Posted by hello_hello

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.

Originally Posted by hello_hello

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.

Originally Posted by hello_hello

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]

Originally Posted by TheFluff

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?.

Originally Posted by TheFluff

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.

Originally Posted by TheFluff

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).

Originally Posted by TheFluff

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?

Originally Posted by TheFluff

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?

Originally Posted by TheFluff

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")

Originally Posted by TheFluff

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]

Originally Posted by tebasuna51

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)

EDIT

Originally Posted by davidhorman

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?

Yes (ssrc-convert.cpp line 56)

[tebasuna51]

Originally Posted by 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.

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]

Originally Posted by tebasuna51

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/AviSynthP...nvert.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]

Originally Posted by Zathor

ConvertToRGB: conversion is allowed only from 8 bit colorspace

RGB24 & 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(matrix="Rec709")

Most >8bit RGB formats are planar.

If you need >8bit interleaved, you have 16bit RGB48 and RGB64:

## source=YUV
ConvertBits(16)
ConvertToRGB64(matrix="Rec709")

If you want to downconvert to 8bit RGB, use:

ConvertBits(8, 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]

Originally Posted by 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.

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]

Originally Posted by tebasuna51

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+.

Originally Posted by 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.

Already exists:
http://avisynth.nl/index.php/AviSynt...gging_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]

Originally Posted by qyot27

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]

Originally Posted by raffriff42

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]

Originally Posted by tebasuna51

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.