AviSynth+ thread Vol.2

[jpsdr]

Warning : There is 2 things :
- The OS supported by the compiler : Where you can install it.
- The targets supported by the compiler, what you can build for, not the same. Be sure to not mix them.

But what bothers me in my tries, is why the avisynth i've build is not working, when my plugins are, both being build with the exact same compiler...
And the x265.exe i've also build with the same compiler is working under Windows 7.

I'm totaly lost...

There must be something i'm not seeing in the options...?

[DTL]

"why the avisynth i've build is not working, when my plugins are, "

Possibly because AVS+ is designed differenly to your plugins. So it mean it starting to lost compatibility with old versions of windows. Sadly it not make compiler warnings or errors and simply fail to load in Win7 ? Or may be as large project as AVS+ have most of warnings and non completely critical stop-errors disabled to make building easier. But it may cause such issues on target operating systems. The debug build also not loads ? Or debug run not tested ?

[FranceBB]

Originally Posted by DTL

It looks AVS+ starting to lost compatibility not only with WinXP but with Win7 too.

Nah, it will be something like: MSVC version compatible with literally everything and then Clang/LLVM version compatible only with the "latest and greatest" version of Windows and Windows Server.

To be fair, I don't see MSVC builds going away anytime soon and as long as they're gonna be there, people will have a choice.

[DTL]

I mean internal design of AVS+ may starting to lost compatibility with Win7. It may be no one day process but someday even MSVC builds will no loads at Win7.

As you see with jpsdr example - some simple software like small plugins still can be built with llvm and run at Win7 and AVS+ as much complex software set already fails.

[FranceBB]

Originally Posted by DTL

As you see with jpsdr example - some simple software like small plugins still can be built with llvm and run at Win7 and AVS+ as much complex software set already fails.

I too use his plugins and it's indeed very weird that they work while the AVS core doesn't.
I mean, there must be a reason, surely.

[pinterf]

Originally Posted by FranceBB

I too use his plugins and it's indeed very weird that they work while the AVS core doesn't.
I mean, there must be a reason, surely.

Many things happen when loading a DLL with lots of classes, setting global variables, static initialization, which can be different among compilers.
Even before the any part is run from our written code.
E.g. LLVM clang-cl is trying the keep the same ABI as Microsoft.
And they made it more compatible than Microsoft themselves, when they broke their own ABI
https://clang.llvm.org/docs/MSVCCompatibility.html
"Thread-safe initialization of local statics: Complete. MSVC 2015 added support for thread-safe initialization of such variables by taking an ABI break. We are ABI compatible with both the MSVC 2013 and 2015 ABI for static local variables."
Avisynth initialization sequence is a "bit" more serious than most of the plugins'.

So it is not weird at all that plugins work, but Avisynth doesn't.

Or simply there is indeed a rare bug which happens only in special circumstances.

[pinterf]

Avisynth+ 3.7.3 test 8 (20230315 - r3958)
Sporting with a good old friend: audio cache. I hope it won't introduce new problems. Basically the same as in classic Avisynth 2.6.
And a fix of a bug introduced in test7 (AvsPMod F5 refresh), thanks Asd-g for the report.

[FranceBB]

You nailed it, Ferenc, as always!
Sox magically started to work as you predicted.
And indeed, now I finally have a meaningful way to go from Stereo 2.0 to 5.1 thanks to the good old Avisynth upmix functions:

[kedautinh12]

Avs+ r3958
https://gitlab.com/uvz/AviSynthPlus-Builds

Originally Posted by kedautinh12

Avs+ r3958
https://gitlab.com/uvz/AviSynthPlus-Builds

Not another one...

I will try both, hopefully no issues, this time.

EDIT:- r3958 LLVM is working for me

[flossy_cake]

Sorry to keep asking for things, but is there any possibility the Normalize filter could be modded to support Normalize2's "store the peak level value in an external file and uses a lookup table to do the actual normalizing (for speed)"

[jpsdr]

I have to test and check something i just tought when back home.
If i remember properly, the officiel release of 3.7.2 have "big" files -> It's a clang build (and now i know why there was "big" file releases, and pinterf's "small" files releases before), and they worked for me. So i have to check fir the "if i remember properly", and if it's the case, find in the git the exact release point this was built with (maybe there is a point where there is a 3.7.2 tag), try to build myself with my current build process, and :
- If it works, it means the commit wich break things can be identified.
- If it doesn't work, it means that it's the llvm version, an old one worked, not a current one.

Edit:
Don't have to wait...

Is the AviSynthPlus_3.7.2_20220317-filesonly.7z found here https://github.com/AviSynth/AviSynth...ses/tag/v3.7.2 build with clang/llvm ? Files are big enough for, but not sure...

[pinterf]

Originally Posted by jpsdr

Is the AviSynthPlus_3.7.2_20220317-filesonly.7z found here https://github.com/AviSynth/AviSynth...ses/tag/v3.7.2 build with clang/llvm ? Files are big enough for, but not sure...

Size can be bigger, it may contain debug info and labels, despite being a release version.

[pinterf]

And now let's experiment a bit

Avisynth+ 3.7.3 test 9 (20230316 - r3961)

20230316 3.7.3 WIP
------------------
- Add initial audio channel mask support (CPP and C interface, script function)
  It still belongs to V10 changes (there were only tests since then), but it can be discussed if not.
  Technically it is done by using another 18+2 bits in the Clip's VideoInfo.image_type field.
  Due to lack of enough bits in this VideoInfo field, the mapping between the original dwChannelMask 
  and Avisynth's internal values are not 1:1, but all information is kept however.
  This is because not 32 but only 18 (strictly: 18+1) bits are defining speaker locations, so
  the remaining bits of our existing 'image_type' field can be used for this purpose.
  Thus 20 new bits are occupied.
  - 1 bit: marks if channel mask is valid or not
  - 18 bits for the actually defined WAVE_FORMAT_EXTENSIBLE dwChannelMask definitions 
    (https://learn.microsoft.com/en-us/wi...rmatextensible)
  - 1 bit for the special SPEAKER_ALL value

  Programmers can check AvsChannelMask and AvsImageTypeFlags in avisynth.h and avisynth_c.h

  - new C++ interface functions
    - Check for existence:
        bool VideoInfo::IsChannelMaskKnown()
    - Setting:
        void VideoInfo::SetChannelMask(bool isChannelMaskKnown, unsigned int dwChannelMask)
      Re-maps and stores channel mask into image_type, sets the 'has channel mask' flag as well
      Note: this data can be set independently from the actual NumChannels number!
    - Retrieving:
        unsigned int VideoInfo::GetChannelMask()
   
   - new C interface functions
       bool avs_is_channel_mask_known(const AVS_VideoInfo * p);
       void avs_set_channel_mask(const AVS_VideoInfo * p, bool isChannelMaskKnown, unsigned int dwChannelMask);
       unsigned int avs_get_channel_mask(const AVS_VideoInfo * p);
       
       Like when establishing BFF, TFF and fieldbased flags from 'image_type', technically 'image_type' can 
       be manipulated directly. See SetChannelMask and GetChannelMask in Avisynth source for 
       image_type <-> dwChannelMask conversion.
       
       I guess once ffmpeg will support it, it will read (or not read) channel masks such a way.

   - new Script functions
       bool IsChannelMaskKnown(clip)
       int GetChannelMask(clip)
       SetChannelMask(clip, bool known, int dwChannelMask) (parameters compulsory, no names must be set)
       dwChannelMask must contain the combination of up to 18 positions or 0x80000000 for SPEAKER_ALL.

   VfW export rules (included the existing sequence)
     1.) OPT_UseWaveExtensible global variable must be 'true'
         or
         *new*new*new*
         if VideoInfo::IsChannelMaskKnown is true, then fill WAVEFORMATEXTENSIBLE struct
     2.) *new*new*new*
         Is channel mask defined in Avisynth's VideoInfo? (VideoInfo::IsChannelMaskKnown() is true)
         Yes -> return VideoInfo::GetChannelMask()
     3.) No-> (Channel mask not defined in VideoInfo, guess it or set from variable)
     3.1)Guess channel layout:
         For 0 to 8 channels there is a predefined 'guess map':
           #of channels dwChannelMask
           0            0,
           1            0x00004, // 1   -- -- Cf
           2            0x00003, // 2   Lf Rf
           3            0x00007, // 3   Lf Rf Cf
           4            0x00033, // 4   Lf Rf -- -- Lr Rr
           5            0x00037, // 5   Lf Rf Cf -- Lr Rr
           6            0x0003F, // 5.1 Lf Rf Cf Sw Lr Rr
           7            0x0013F, // 6.1 Lf Rf Cf Sw Lr Rr -- -- Cr
           8            0x0063F, // 7.1 Lf Rf Cf Sw Lr Rr -- -- -- Ls Rs
         
         For 9-18 channels: 
           sets first 9-18 bits in dwChannelMask
         Above:
           SPEAKER_ALL (dword msb bit is 1)
      3.2) if OPT_dwChannelMask global variable is defined and is different from 0, then use it.

      E.g. VirtualDub2 is using VfW, so after opening the script, ended with SetChannelMask(true, $0063F),
      one can check the value File|File Info menü, under "compression" line (e.g.PCM, chmask 63f).
      SetChannels does not check against NumChannels, so you can set the 7.1 constant for a stereo
      if you wish. Microsoft's documentation mentions the cases of what can do az application with 
      less or more than necessary defined speaker bits.
      
  - What to do about GetChannels, MixAudio, ConvertToMono? To be discussed.
    KillAudio will call SetChannelMask(false, 0), nevertheless.

[tebasuna51]

Thanks for the audio improvement.
Now decoders must suply that info or we can use the exported variables?

About defaults please use a modern one (and more ffmpeg compatible) showed here.

[FranceBB]

Originally Posted by tebasuna51

Thanks for the audio improvement.

+1
Thanks for the new release, Ferenc!
It's always nice to see the audio getting its well deserved space after spending so much time on video.

Oh and by the way, 3.7.3 test 9 also works on Windows XP just fine, I just tested it before going to bed. (yep it's 1AM over here, ehehehehe).
Tomorrow I'll test on the Windows Server 2019 farm I have at work too.

[jpsdr]

I've tested build the 3.7.2 with LLVM, same behavior, so it's relay compiler related, and not the version. As pinterf said, even if biger, the files provided with the release weren't probably llvm build.

[pinterf]

Originally Posted by jpsdr

I've tested build the 3.7.2 with LLVM, same behavior, so it's relay compiler related, and not the version. As pinterf said, even if biger, the files provided with the release weren't probably llvm build.

As Intel say: "may or may not work".
"Note: These OS distributions are tested by Intel or known to work; other distributions may or may not work and are not recommended."

[pinterf]

Originally Posted by jpsdr

I've tested build the 3.7.2 with LLVM, same behavior, so it's relay compiler related, and not the version. As pinterf said, even if biger, the files provided with the release weren't probably llvm build.

Or related to your machine.

I've freshly installed a Win7 Pro x64 (ISO from 2018) under HyperV VM.
Downloaded official Avisynth+ 3.7.2 (with redistributables)
Copied there latest VirtualDub2, avsmeter and avsmeter64, ffmpeg.

Everything worked. My clang and intel from 3.7.3 test7, latest uvz builds, my freshly compiled clang-cl.

Then installed the latest Visual C++ Redistributables. Same success.

[DTL]

Yes - it looks clang uses some >SSE instructions. The VirtualDub loaded via SDE emulator

set PATH=%PATH%;G:\sde
sde.exe -avx 1 -avx2 1 -emu_fast 1 -fma 1 -sse41 1 -- G:\Distr\VirtualDub-1.10.4-AMD64\veedub64.exe

can load script with x64-clang AVS+ 3.7.3 test7. Slow enough but working. So if it possible to disable AVX and higher usage in clang (also IntelClassic must have switches for it).

May be clang and llvm so visibly faster because they finally start to make use of registerfile of SIMD coprocessor for temporals and function arguments instead of pushing to stack and so on. But old chips do not have registerfile of required size (as AVX it is 256 bytes) and instructions to store and load data from it. So new clang and llvm no more compatible with SSE architecture chips ?