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 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 and the subsequent allocation on line 195.

[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" 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 and line 203 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 :

"Audio is always converted to Float."

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

[qyot27]

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

"Audio is always converted to Float."

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

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

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

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]

Originally Posted by qyot27

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]

Originally Posted by LigH

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]

Originally Posted by StainlessS

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

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.

EDIT correction, SuperEQ does not accept 16-bit.