AviSynth+ thread Vol.2

[pinterf]

Finally, in 37 minutes from switching on, my PC has happily loaded avs+ source. OMG, so slow, I've got no SSD in this machine.
Intel(R) Core(TM) i7 860, it has SSE4.1 at most.
This PC features with a VS 2019 with LLVM 12.0. Made a debug build. Run it. No problem :(

[pinterf]

So do llvm build environment have some settings to force disable emitting AVX and later instructions ? Or these builds can be only marked as AVX(2) minimum ?

Users may still have some second-hand multicore multi-chips Xeons systems capable of AVS processing but noAVX even.
Yep, use MSVC build. Simple as that. Maybe it is even quicker than llvm, llvm alone is not a magic wand.
(but the problem is interesting, very interesting, I can say. And may have other reasons, this is why I put in days to investigate)

[pinterf]

Ehh...

First of all, this slow machine makes me mad. 13 minutes for a simple cmake install. 17 minutes after starting VS2022 until Avisynth project is loaded. But then! BUT THEN! :)

Debug build was not failing.
Release with debug build did it. Yeah.

Strange.

It would really run avx code on my pre-avx machine.
This is what happened.

convert_bits_avx2.cpp includes "convert_bits.h"
https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/convert/intel/convert_bits_avx2.cpp#L54

convert_bits.h contains static initialization of the dither structures:
https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/convert/convert_bits.h#L89

like this:

// repeated 8x for sse size 16
static const struct dither2x2a_t
{
const BYTE data[4] = {
0, 1,
1, 0,
};
// cycle: 2
alignas(16) const BYTE data_sse2[2 * 16] = {
0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1,
1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0
};
dither2x2a_t() {};
} dither2x2a;
The illegal instruction came from
dither2x2a_t() {}
which triggered the static initialization.

Unfortunately, this initialization was requested from an AVX2 module.

Though the failure happened at the first struct initialization, there are other predefined dither structs, they would all fail as well:

I'm going to stop putting such active codes into common header files. They must be moved out to a hpp and be included into both the _sse2 and the _avx2 source. I wonder what happens if I do that change. Will it recognise that the static initialization of an AVX2 compiled code is forbidden?

Disassembly - for the records.

AviSynth.dll!_GLOBAL__sub_I_convert_bits_avx2.cpp(void):
00007FFBF987F4E0 mov dword ptr [dither2x2a (07FFBF9B03620h)],10100h
00007FFBF987F4EA vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+10h (07FFBF9A3CF60h)]
00007FFBF987F4F2 vmovups ymmword ptr [dither2x2a+10h (07FFBF9B03630h)],ymm0
00007FFBF987F4FA mov dword ptr [dither2x2 (07FFBF9B03650h)],1030200h
00007FFBF987F504 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+30h (07FFBF9A3CF80h)]
00007FFBF987F50C vmovups ymmword ptr [dither2x2+10h (07FFBF9B03660h)],ymm0
00007FFBF987F514 vmovaps xmm0,xmmword ptr [__xmm@02060307040005010307020605010400 (07FFBF991D470h)]
00007FFBF987F51C vmovaps xmmword ptr [dither4x4a (07FFBF9B03680h)],xmm0
00007FFBF987F524 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+50h (07FFBF9A3CFA0h)]
00007FFBF987F52C vmovups ymmword ptr [dither4x4a+10h (07FFBF9B03690h)],ymm0
00007FFBF987F534 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+70h (07FFBF9A3CFC0h)]
00007FFBF987F53C vmovups ymmword ptr [dither4x4a+30h (07FFBF9B036B0h)],ymm0
00007FFBF987F544 vmovaps xmm0,xmmword ptr [__xmm@050d070f09010b03060e040c0a020800 (07FFBF991D480h)]
00007FFBF987F54C vmovaps xmmword ptr [dither4x4 (07FFBF9B036D0h)],xmm0
00007FFBF987F554 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+90h (07FFBF9A3CFE0h)]
00007FFBF987F55C vmovups ymmword ptr [dither4x4+10h (07FFBF9B036E0h)],ymm0
00007FFBF987F564 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+0B0h (07FFBF9A3D000h)]
00007FFBF987F56C vmovups ymmword ptr [dither4x4+30h (07FFBF9B03700h)],ymm0
00007FFBF987F574 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+0F0h (07FFBF9A3D040h)]
00007FFBF987F57C vmovups ymmword ptr [dither8x8a+20h (07FFBF9B03740h)],ymm0
00007FFBF987F584 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+0D0h (07FFBF9A3D020h)]
00007FFBF987F58C vmovups ymmword ptr [dither8x8a (07FFBF9B03720h)],ymm0
00007FFBF987F594 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+170h (07FFBF9A3D0C0h)]
00007FFBF987F59C vmovups ymmword ptr [dither8x8a+0A0h (07FFBF9B037C0h)],ymm0
00007FFBF987F5A4 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+150h (07FFBF9A3D0A0h)]
00007FFBF987F5AC vmovups ymmword ptr [dither8x8a+80h (07FFBF9B037A0h)],ymm0
00007FFBF987F5B4 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+130h (07FFBF9A3D080h)]
00007FFBF987F5BC vmovups ymmword ptr [dither8x8a+60h (07FFBF9B03780h)],ymm0
00007FFBF987F5C4 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+110h (07FFBF9A3D060h)]
00007FFBF987F5CC vmovups ymmword ptr [dither8x8a+40h (07FFBF9B03760h)],ymm0
00007FFBF987F5D4 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+190h (07FFBF9A3D0E0h)]
00007FFBF987F5DC vmovups ymmword ptr [dither8x8 (07FFBF9B037E0h)],ymm0
00007FFBF987F5E4 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+1B0h (07FFBF9A3D100h)]
00007FFBF987F5EC vmovups ymmword ptr [dither8x8+20h (07FFBF9B03800h)],ymm0
00007FFBF987F5F4 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+1D0h (07FFBF9A3D120h)]
00007FFBF987F5FC vmovups ymmword ptr [dither8x8+40h (07FFBF9B03820h)],ymm0
00007FFBF987F604 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+1F0h (07FFBF9A3D140h)]
00007FFBF987F60C vmovups ymmword ptr [dither8x8+60h (07FFBF9B03840h)],ymm0
00007FFBF987F614 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+210h (07FFBF9A3D160h)]
00007FFBF987F61C vmovups ymmword ptr [dither8x8+80h (07FFBF9B03860h)],ymm0
00007FFBF987F624 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+230h (07FFBF9A3D180h)]
00007FFBF987F62C vmovups ymmword ptr [dither8x8+0A0h (07FFBF9B03880h)],ymm0
00007FFBF987F634 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+330h (07FFBF9A3D280h)]
00007FFBF987F63C vmovups ymmword ptr [dither16x16a+0E0h (07FFBF9B03980h)],ymm0
00007FFBF987F644 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+310h (07FFBF9A3D260h)]
00007FFBF987F64C vmovups ymmword ptr [dither16x16a+0C0h (07FFBF9B03960h)],ymm0
00007FFBF987F654 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+2F0h (07FFBF9A3D240h)]
00007FFBF987F65C vmovups ymmword ptr [dither16x16a+0A0h (07FFBF9B03940h)],ymm0
00007FFBF987F664 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+2D0h (07FFBF9A3D220h)]
00007FFBF987F66C vmovups ymmword ptr [dither16x16a+80h (07FFBF9B03920h)],ymm0
00007FFBF987F674 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+2B0h (07FFBF9A3D200h)]
00007FFBF987F67C vmovups ymmword ptr [dither16x16a+60h (07FFBF9B03900h)],ymm0
00007FFBF987F684 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+290h (07FFBF9A3D1E0h)]
00007FFBF987F68C vmovups ymmword ptr [dither16x16a+40h (07FFBF9B038E0h)],ymm0
00007FFBF987F694 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+270h (07FFBF9A3D1C0h)]
00007FFBF987F69C vmovups ymmword ptr [dither16x16a+20h (07FFBF9B038C0h)],ymm0
00007FFBF987F6A4 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+250h (07FFBF9A3D1A0h)]
00007FFBF987F6AC vmovups ymmword ptr [dither16x16a (07FFBF9B038A0h)],ymm0
00007FFBF987F6B4 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+430h (07FFBF9A3D380h)]
00007FFBF987F6BC vmovups ymmword ptr [dither16x16+0E0h (07FFBF9B03A80h)],ymm0
00007FFBF987F6C4 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+410h (07FFBF9A3D360h)]
00007FFBF987F6CC vmovups ymmword ptr [dither16x16+0C0h (07FFBF9B03A60h)],ymm0
00007FFBF987F6D4 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+3F0h (07FFBF9A3D340h)]
00007FFBF987F6DC vmovups ymmword ptr [dither16x16+0A0h (07FFBF9B03A40h)],ymm0
00007FFBF987F6E4 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+3D0h (07FFBF9A3D320h)]
00007FFBF987F6EC vmovups ymmword ptr [dither16x16+80h (07FFBF9B03A20h)],ymm0
00007FFBF987F6F4 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+3B0h (07FFBF9A3D300h)]
00007FFBF987F6FC vmovups ymmword ptr [dither16x16+60h (07FFBF9B03A00h)],ymm0
00007FFBF987F704 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+390h (07FFBF9A3D2E0h)]
00007FFBF987F70C vmovups ymmword ptr [dither16x16+40h (07FFBF9B039E0h)],ymm0
00007FFBF987F714 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+370h (07FFBF9A3D2C0h)]
00007FFBF987F71C vmovups ymmword ptr [dither16x16+20h (07FFBF9B039C0h)],ymm0
00007FFBF987F724 vmovups ymm0,ymmword ptr [__xmm@0f80800e80800d80800c80800b80800a+350h (07FFBF9A3D2A0h)]
00007FFBF987F72C vmovups ymmword ptr [dither16x16 (07FFBF9B039A0h)],ymm0
00007FFBF987F734 vzeroupper
00007FFBF987F737 ret

Eh.. I'm gonna finally sleep well at least. I'll return to it next week.

[LigH]

@DTL: If you had wrapped these lists in a bbCode CODE block, it would have taken less space in scrollable boxes.
_

Oops, missed another page of replies, sorry.

[jpsdr]

@pinterf
Nice you find something, good work as always, :thanks:
Out of curiosity, if you have any idea why Visual Studio build are working but not the others... If you don't, no big deal, at least there is something, and it's in the code, so the "rare bug" case, not compiler related. Means it's eventualy fixable.

[DTL]

I delete that posts as found better way of error reporting via SDE crash log.

[FranceBB]

eheheheh I knew there must have been something else there.

Very nicely spotted, Ferenc!
You're the "Avisynth Grandmaster" after all. :)

[qyot27]

@pinterf
Nice you find something, good work as always, :thanks:
Out of curiosity, if you have any idea why Visual Studio build are working but not the others... If you don't, no big deal, at least there is something, and it's in the code, so the "rare bug" case, not compiler related. Means it's eventualy fixable.
Judging by some of the replies, there are/were functions in headers and the process dispatching that were getting dinged by LLVM and not by MSVC because of the difference* in the way GCC/Clang (and presumably Intel now too, since it uses LLVM) and CL handle enabling intrinsics. And this was causing AVX instructions to be emitted for sources that it shouldn't have been generated for.

That's probably the simplest explanation.

*a very long-lived known difference that makes GCC very annoying when it comes to using intrinsics and runtime CPU detection and how one has to build the sources. (https://virtualdub.org/blog2/entry_363.html) This is the reason that there's an entire block in avs_core/CMakeLists.txt (https://github.com/AviSynth/AviSynthPlus/blob/master/avs_core/CMakeLists.txt#L45) doing exactly what was described there: keeping separate sources for intrinsics-using code, and then using the build system to slice GCC's and LLVM's intrinsics flags down to just those files that require them to even compile and try to keep them separate from all of the other files in the sources so that it doesn't globally optimize non-intrinsics code for the most recent instruction set and bork the entire purpose of having runtime CPU detection.

(although since the SSE paths were templated a while back, those blocks probably need to be cleaned up since there are no files that would match the query for *_ssse3.cpp or *_sse41.cpp)

I doubt that the builds that crash on non-AVX machines could be made to work with the script declaring SetMaxCPU, but if building with GCC, Clang, or Intel, you would almost certainly be able to see it start working if you turn off SIMD entirely (-DENABLE_INTEL_SIMD:bool=off) and just use the appropriate -march flag in -DCMAKE_CXX_FLAGS to globally optimize for your particular CPU. Probably would take a pretty big theoretical** performance hit, but still.

**theoretical, because on non-x86 CPUs (like the IBM 970MP, ARM Cortex A72, or Apple M1), the core still works fairly well, at least on synthetic tests. It's just that on x86, those same tests get just absolutely stupid numbers because of the intrinsics. Almost comprehensibly meaningless numbers in some cases (Version getting north of 32000 fps vs a much more 'I can understand this' 2000-8000 fps range on the M1 or on a 9th Gen Core i5 with SetMaxCPU("None")). But if a large amount of the testing is on external plugins and not using much or any core functions, it's questionable whether you might see a performance hit at all, or if the thing for 'normal' core use that makes the most difference is not the intrinsics in all of the filters you may never use, but because of the use of the x86-optimized memcpy or bitblt. And just how much of it is down to non-SIMD-related compiler optimizations. I've not tried to do a '-march=native -O3' build on x86 that also has the intrinsics disabled, but that might be pretty enlightening.

[pinterf]

A theoretical fix is up on git, along with

https://github.com/AviSynth/AviSynthPlus/issues/347

Finally I think, this is not the compiler's fault.

Programmers must really take care of statically initialized tables in classes (and not use them) which would occur in other than the base CPU-arch modules.

[jpsdr]

I've made an LLVM build of r3966 and tested, it works.

:thanks:

[kedautinh12]

AviSynthPlus r3973
https://gitlab.com/uvz/AviSynthPlus-Builds

[real.finder]

with yv411 source using LWLibavVideoSource or ffms2 both give _ChromaLocation = 2 and make avspmod, ConvertToRGB or ConvertToYV16 give error

https://i.postimg.cc/hvK2ZK7b/Untitled.png (https://postimages.org/)

[pinterf]

with yv411 source using LWLibavVideoSource of ffms2 both give _ChromaLocation = 2 and make avspmod, ConvertToRGB or ConvertToYV16 give error

https://i.postimg.cc/hvK2ZK7b/Untitled.png (https://postimages.org/)
Probably 0-"left" and 2-"topleft" (they are the same in other-than-4:2:0 formats) could be enabled? I think, this is how it is handled, but since there is no valid choice at 411, using any _Chromalocation hint was disabled until now.

[real.finder]

Probably 0-"left" and 2-"topleft" (they are the same in other-than-4:2:0 formats) could be enabled? I think, this is how it is handled, but since there is no valid choice at 411, using any _Chromalocation hint was disabled until now.

I think maybe it safe to make it if 411 then _Chromalocation could has 0-"left" or 2-"topleft"

[FranceBB]

Avisynth 3.7.3 Beta 9, using the following script:


BlankClip(length=0)


makes ffmpeg go crazy as I described here: https://forum.doom9.org/showthread.php?t=184819

Even AVSPmod mod really doesn't like length=0 in BlankClip():

https://i.imgur.com/JRYAXOC.png

Given that using BlankClip(length=1) produces 1 frame of black, namely frame 0:

https://i.imgur.com/qsczCZ5.png

what is BlankClip(length=0) supposed to output? And why is it making FFMpeg go on forever and AVSPmod mod fail?
I even tried with VirtualDub, it doesn't fail, and although the preview is bogus like this:

https://i.imgur.com/C4QNNlo.png

it does produce a file which is 1 frame long (frame 0) of pure black when I play it back with MPC-HC:

https://i.imgur.com/NDMzxF8.png

I reported the issue to the ffmpeg community, but the more I test the more I think that we (the Avisynth community) might be the one at fault here.
I'm not sure. What do you think, guys?

[poisondeathray]

BlankClip(length=0) makes no sense, but there should be an appropriate error message such as "Not a clip"

[qyot27]

BlankClip(length=0) makes no sense, but there should be an appropriate error message such as "Not a clip"
This. FFmpeg reads video and audio packets separately, and if either reaches EOF, it attempts to read the other one before exiting, because it is easily possible - and not a bug - that either video or audio might be longer than the other, and it shouldn't be truncated.

The error is that length=0 is treated by BlankClip as somehow valid when it isn't, and ends up creating an audio stream of infinite length, which FFmpeg then attempts to read/output. Forcing an output length via the -t parameter would probably demonstrate that it is indeed attempting to write an ever-increasing number of audio samples, until the process is killed.

[FranceBB]

Gotcha.
So... what next? I think we should be throwing an error and display it correctly as an error if length=0 is passed to BlankClip() instead of failing silently.

The good thing is that a new version of Avisynth is being worked on, so perhaps we can include this in 3.7.3 Beta 10 (or one of the next betas before the stable release)?

Anyway, it's just a proposition as I've addressed it in the code at work last Sunday (yes, I rushed to work on Sunday when I saw the server crash eheheheheh). Anyway, as far as my use case is concerned, now if there's a clip of 0 frame, length is forced to 1 as one workaround in the AVS Script that my supply chain generates automatically (and I'll make sure to include the fix in the next public release of FFAStrans, if Steinar approves my pull request). :)

I'll let the ffmpeg guy know as well and close the ticket there anyway, since this is not a bug on their end. ;)

[gispos]

Avisynth 3.7.3 Beta 9, using the following script:



makes ffmpeg go crazy as I described here: https://forum.doom9.org/showthread.php?t=184819

Even AVSPmod mod really doesn't like length=0 in BlankClip():

At first I was also surprised that no error 'Not a clip' is output, had to look 2 - 3 times to find the error. Fixed.

Edit:
Avisynth should have returned an error here, but probably does not.

self.src_frame = self.clip.get_frame(frame)
if self.clip.get_error():
Error()
return False

[qyot27]

Now it does:
https://github.com/AviSynth/AviSynthPlus/commit/9c79d295b6917741d99a26bb28eee829223d1d54

[qyot27]

To explain a bit further, I'm now not really sure if it was generating valid audio either, because if I tried to do
ffmpeg -i test.avs -vn -acodec copy output.wav
the output length reported before it errored out was something like -577100 hours. Which would indicate a problem with the integer used to represent the length of the stream. And the AviSynth docs have the following rather useful tidbit when describing audio samples properties:
Returns the number of samples of the audio of the clip (type: int). Be aware of possible overflow on very long clips (2^31 samples limit).
Which made me think there might be an overflow happening for the length of the clip, since 2^31 = 2,147,483,648 seconds / 60 = 35,791,394.133 minutes / 60 = 596,523.235 hours. Like I said, it's not exact (~577100 vs. 596523) but with other kinds of overhead, it's close enough. That may be a completely wrong assumption about what the issue actually was, but it doesn't really matter, since it will error out now if BlankClip is set to less than 1 frame long.

[FranceBB]

Thanks for the fix and the explanation, Stephen! ;)
(also thanks to Gispos for addressing it in AVSPmod mod; I didn't report it in the AVSPmod mod thread only 'cause I thought it should really be Avisynth throwing a proper error anyway, but thanks for addressing it for older version of AVS too in AVSPmod mod :) )

[gispos]

...
(also thanks to Gispos for addressing it in AVSPmod mod; I didn't report it in the AVSPmod mod thread only 'cause I thought it should really be Avisynth throwing a proper error anyway, but thanks for addressing it for older version of AVS too in AVSPmod mod :) )
You can also test it right now:)
https://drive.google.com/drive/folders/1I7yNkFLoYmOush5Olx-jT799GphKcSwX?usp=share_link

[FranceBB]

You can also test it right now:)
https://drive.google.com/drive/folders/1I7yNkFLoYmOush5Olx-jT799GphKcSwX?usp=share_link

It works and it correctly returns an error message. :)

https://i.imgur.com/OA17oQV.png

While this outputted an image without asking any questions about the audio, just like before:

https://i.imgur.com/C7sTaN2.png

[gispos]

It works and it correctly returns an error message. :)

While this outputted an image without asking any questions about the audio, just like before:

If I understand correctly, that's so good ?
But it will probably change when avisynth gives an error on BlankClip(0). Then there is nothing I can do about it.

[FranceBB]

If I understand correctly, that's so good ?


It's fine, it's fine, thanks :)


But it will probably change when avisynth gives an error on BlankClip(0).

Yeah and rightly so. I would rather get a proper error than a memory leak in FFMpeg that takes my whole farm of several servers down and makes me rush back to the office after getting an incident on Spark and a phone call on a Sunday! XD

[gispos]

Yeah and rightly so. I would rather get a proper error than a memory leak in FFMpeg...
My mistake, I thought you use BlankClip(0) in the script for something.
At the second look I recognized it now... The script was only meant as an example... Sometimes it takes longer...:)

[DTL]

Some syntax request for some resizers:

Currently AVS resampling engine also used as convolution filter with resizer's kernel for non-resizing processing. So it required not very nice hacky way of forcing processing using non-zero src_left and/or src_top small float value. Also non-zero non-required shift may more degrade output.

So 2 ideas:
1. Add more param to resizers like force_processing (fp) = 0 (default - no), 1,2,3 (H, V, H+V), or horfp=false/true and verfp=false/true.

2. Add naming aliases with H(V) ending - like standard GaussResize and GaussResizeH/GaussResizeV/GaussResizeHV (conditionless forced H, V or HV processing). It looks like shortest way of script typing.

Mostly needed for resizers with user-adjustable kernel (taps or p or b,c params).

May be other ideas exist how to force resizer processing if width and height not changed ?

[pinterf]

I think maybe it safe to make it if 411 then _Chromalocation could has 0-"left" or 2-"topleft"
Opened an issue (https://github.com/AviSynth/AviSynthPlus/issues/350) at github, just for the reference. I had (and maybe will continue to have) busy working weeks, you'll notice a minor slowdown for some days.
Then I can finally have a look at DTL's (old and new) resizer related things.

[kedautinh12]

AviSynthPlus r3982
https://gitlab.com/uvz/AviSynthPlus-Builds

[DTL]

They not provide update log ? So it is not known what changed from old builds ? Do it equal to pinterf 3.7.3_test10 (some version of test10) ? Or some intermediate build before _test10 release ?

[kedautinh12]

They not provide update log ? So it is not known what changed from old builds ? Do it equal to pinterf 3.7.3_test10 (some version of test10) ? Or some intermediate build before _test10 release ?
UVZ's build always up to date base changelog, somtime this build up to date than Pinterf's test build

[DTL]

I see the s-param for UD2 resize is added and working. There exist some addition to the current short documentation of this resizer:

In short description noted that increasing s-param value (over 2.0) decreases sharpness. After more research it was found effect is more complex:

1. Increasing s-value really depresses highest valid frequencies and it cause decreasing sharpness of the finest details. But in typical viewing conditions (about classic system-60 with 60 samples per degree of view) the finest details close to already invisible. So this effect is mostly visible if evaluate 200..400+% enlarged crops and it is not typical use cases of viewing natural images.

2. Increasing s-value cause significant amplification of 'medium' frequencies and it significantly add to real visible sharpness in typical viewing conditions. Also exist some current still non-perfectness of processing: with s>2.0 it started to show some more ringing and aliasing-like distortions at some test-patterns. But in natural imaging it may be still close to invisible issue. May be only 2 members of kernel is not enough to completely fix this issue.

So typically using s-value >2.0 not cause generally visible sharpness decreasing. For example for 2:1 downscale from sharp-video look/makeup to sharp-video look/makeup of 4K downscale to FullHD may be recommended b/c of 80/-20 and default s of about 2.3. With s of 2.0 the somehow comparable sharpness may be reached only with more extreme b/c values of about 70/-30.

[StainlessS]

This. FFmpeg reads video and audio packets separately, and if either reaches EOF, it attempts to read the other one before exiting, because it is easily possible - and not a bug - that either video or audio might be longer than the other, and it shouldn't be truncated.

The error is that length=0 is treated by BlankClip as somehow valid when it isn't, and ends up creating an audio stream of infinite length, which FFmpeg then attempts to read/output. Forcing an output length via the -t parameter would probably demonstrate that it is indeed attempting to write an ever-increasing number of audio samples, until the process is killed.

Now it does:
https://github.com/AviSynth/AviSynthPlus/commit/9c79d295b6917741d99a26bb28eee829223d1d54

env->ThrowError("BlankClip() length must be greater than 0 frames!");


Template=Colorbars()
EmptyClip=Template.BlankClip(Length=0)

Is quite often [EDIT: sometimes/seldom] used to create an empty clip from a template clip, with same properties as template.
I posted a script using that same method a few days ago.
Gavino was also fond of using that method. [EDIT: Methinks that he is the culprit that enticed me into doin' that there thing]

Not a Good idea to kill existing scripts by changing AVS+ functionality, it was implemented that way for good reason.

Wrong use of BlankClip(length=0) is the error.

EDIT: The script I posted a couple of days ago
Current_frame is not available outside of the runtime environment, and dont make much sense there either.
But, (probably not of use in required case) you can hack a one time use (on a single frame) just by setting
it to that frame number, eg


blankclip(length=100,pixel_type="YV12")
C = Last.BlankClip(length=0) # zero len clip, same characteristics as Last clip
For(n=0,FrameCount-1) {
current_frame = n # HACK for below AverageLuma
Y = AverageLuma # access frame n
T = Trim(n,-1)
T = T.Subtitle(String(n) + String(Y," : %f"),align=5)
C = C ++ T # add single frame n, to clip so far : EDIT: Would fail here on 1st iteration unless C = zero len clip, same characteristics as Last clip
}

C # Play C



I'm still using an older version Avs+, so works for me, I presume recent avs+ breaks above script and throws an error for Length=0.

[qyot27]

There happened to be some stuff concerning general timestamps/duration/framecount in FFmpeg during April (and coincidentally after the no zero-length clips commit on our side), and if I had to guess, those commits addressed this from FFmpeg's side without ever touching the AviSynth demuxer, since a reverted version of AviSynth+ no longer seems to trip anything with a script consisting of just BlankClip(length=0) (ffplay doesn't reject it as empty, but that's probably just ffplay being ffplay; it doesn't close regular videos when they finish).

So tentatively, it's been reverted. If it re-emerges, though, it will have to be addressed. Memory overflows are not something I'm willing to roll the dice with just because there's useful edge cases.

[StainlessS]

Memory overflows are not something I'm willing to roll the dice with just because there's useful edge cases.
I guess that there will be not that many scripts reliant upon c.BlankClip(Length=0),
and could be relatively easily scripted around as and when they arise.
[But, it was more useful than might at first appear]
Please do as you will.

[FranceBB]

Wait, so the error is reverted and Avisynth will still provide a clip with using BlankClip(Length=0), but now FFMpeg doesn't go on forever in the new version?

In the meantime, I addressed it in FFAStrans with:

;Check if the input is a 0 frame image and force blankclip to be at least 1 frame in length 'cause 0 would be infinity

If $i_src_vid_frames = 0 Then $i_src_vid_frames = 1

$s_avs_script &= 'audio_null = BlankClip(length=' & $i_src_vid_frames & ', width=' & $src.video.width & ', height=' & $src.video.height & ', color=$000000, channels=1, audio_rate=' & $i_PROC_AUD_SAMPLERATE & ', fps=' & $f_src_vid_fps & ')' & @CRLF

so that I won't be affected anyway.

[SkilledAbbot]

Hello Forum,

As you can see by my join date, I've been here a while but I am still a technewb. The test 9 version of AVS+ does not have an installer or instructions on how to set it up. It's been about 2 decades since I fiddled with encoding and Frameserving with AVS, and now its really lost on me.

I know I should add that dll somewhere in my windows folder, just not sure where.

Any help appreciated.

Cheers

[DTL]

Install any old version with installer to write win-registry values and replace avisynth.dll from old version to new in system32 windows folder (for x64).

[kedautinh12]

I think need replace both avisynth.dll and devil.dll

[FranceBB]

I think need replace both avisynth.dll and devil.dll

Correct, both avisynth.dll and devil.dll in System32.

For x86 systems:

- Go to C:\Windows\System32

swap avisynth.dll and devil.dll from the x86 build

- Go to C:\Program Files\Avisynth+\plugins+

and swap the plugins from the x86 build


For x64 systems:

- Go to C:\Windows\System32

swap avisynth.dll and devil.dll from the x64 build

- Go to C:\Windows\SysWOW64

swap avisynth.dll and devil.dll from the x86 build

- Go to C:\Program Files (x86)\Avisynth+\plugins+

swap the plugins from the x86 build

- Go to C:\Program Files (x86)\Avisynth+\plugins64+

swap the plugins from the x64 build



As a bit of reference, in 64bit systems, system32 hosts the 64bit files, while the 32bit ones are emulated and reside in the SysWOW64 folder.
In 32bit systems, instead, system32 hosts the 32bit (x86) files.
A bit counterintuitive, I know, but blame Microsoft for that.

[pinterf]

I see the s-param for UD2 resize is added and working. There exist some addition to the current short documentation of this resizer:
[...]

Thanks, hopefully I'm gonna be back in May, we are in a race against time since weeks to beat a deadline to fulfill the informatic background for our dear goverment's sudden thoughts.

[SkilledAbbot]

Awesome! Exactly what I needed. Thank you!

That note at the end, too! ha!

Correct, both avisynth.dll and devil.dll in System32.

For x86 systems:

- Go to C:\Windows\System32

swap avisynth.dll and devil.dll from the x86 build

- Go to C:\Program Files\Avisynth+\plugins+

and swap the plugins from the x86 build


For x64 systems:

- Go to C:\Windows\System32

swap avisynth.dll and devil.dll from the x64 build

- Go to C:\Windows\SysWOW64

swap avisynth.dll and devil.dll from the x86 build

- Go to C:\Program Files (x86)\Avisynth+\plugins+

swap the plugins from the x86 build

- Go to C:\Program Files (x86)\Avisynth+\plugins64+

swap the plugins from the x64 build



As a bit of reference, in 64bit systems, system32 hosts the 64bit files, while the 32bit ones are emulated and reside in the SysWOW64 folder.
In 32bit systems, instead, system32 hosts the 32bit (x86) files.
A bit counterintuitive, I know, but blame Microsoft for that.

[kedautinh12]

Awesome! Exactly what I needed. Thank you!

That note at the end, too! ha!

And here is latest ver not test 9
https://gitlab.com/uvz/AviSynthPlus-Builds

[Llawliet]

hi, What is the difference between Clang and IntelLLVM builds of AviSynthPlus?

[LigH]

Which compiler was used to build them. So, marginally, a bit of CPU optimization strategies.

[Llawliet]

Thanks. Considering a notebook, intel i5 4200u, 8gb ram ddr3, ssd sata III, windows 10 ltsc 2021 updated, is it appropriate to conclude that the IntelLLVM option would be generally more optimized than the Clang option for the aforementioned system?

[StainlessS]

Why not speed test them both yourself, you're likely to get a better answer using your own hardware.
(and a typical processing script, that you use, maybe test on 10 minutes clip)
Try with Grouch2004 AvsMeter.

Groucho's Avisynth Stuff:- https://forum.doom9.org/showthread.php?t=173259

[Llawliet]

Thanks, fair point, speed test in the end point of system is a really a helpful advice, it brings forth relevant statistical data at the very end, and using statistical knowledge and tools is possible reach miningful conclusion with good confidence interval

[StainlessS]

You might also find it usefull to do timing where encoding result to eg AVC or HEVC where timings will be much closer together due to encode overhead.