AviSynth+ thread Vol.2

[tebasuna51]

Now decoders like ffms2, LSMASHSource and BestAudioSource can use the new https://github.com/AviSynth/AviSynth...ude/avisynth.h (it is the last?) and store the image_type with the Channel mask

[real.finder]

Originally Posted by kedautinh12

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

this make dither tools not working

colorbars(pixel_type="yv12")
Dither_convert_8_to_16()
ditherpost(mode=-1)

edit: anything newer than Avisynth+ 3.7.3 test 7 (20230223) will give same error

[StvG]

Originally Posted by real.finder

this make dither tools not working

colorbars(pixel_type="yv12")
Dither_convert_8_to_16()
ditherpost(mode=-1)

edit: anything newer than Avisynth+ 3.7.3 test 7 (20230223) will give same error

Updated dither - 1.28.1.1 x64 from Asd-g: updated to 2.6 plugin, added support for passthrough frame properties

[real.finder]

Originally Posted by StvG

Updated dither - 1.28.1.1 x64 from Asd-g: updated to 2.6 plugin, added support for passthrough frame properties

thanks, that work but will all other 2.5 plugins will not work? there are some of them even close source

[StvG]

Originally Posted by real.finder

thanks, that work but will all other 2.5 plugins will not work? there are some of them even close source

Probably. There is also this comment.

[tebasuna51]

A new version of LSMASHSource.dll to test in https://github.com/HomeOfAviSynthPlu...orks/issues/35

For me work fine with some samples ac3, eac3 and dts, the correct channel mask is created (without SetChannelMask() ) and VirtualDub2 save the correct WAVE_FORMAT_EXTENSIBLE output.

Now we need at least ffmpeg read that info. http://trac.ffmpeg.org/ticket/10473

[qyot27]

AviSynth+ 3.7.3 has been released

- Add "bold"=true (linux/NO_WIN_GDI: false), "italic"=false, "noaa"=false parameters to
  "ShowFrameNumber", "ShowCRC32", "ShowSMPTE", "ShowTime" filters.
  As noted below, "italic" and "noaa" parameters are ineffective in NO_WIN_GDI builds (e.g. Linux)
- Add "noaa" parameter to SubTitle and Info. Setting it true will disable antialiasing.
  Useful when someone would use "VCR OSD Mono" as-is, without beautifying the outlines,
  as it as mentioned in https://forum.doom9.org/showthread.php?t=184627
- Address #358, plus "noaa"
  - add "bold", "italic" and "noaa" boolean parameters to "SubTitle" and "Info"
  - add "italic" and "noaa" boolean parameter to "Text" ("bold" already existed)
    "italic" and "noaa" is provided only to match the parameter list with SubTitle.

  SubTitle: to mimic former working method, defaults are "bold"=true, "italic"=false, "noaa"=false
  Text: "bold"=false (as before); "italic" is not handled at all, either true or false, it does not affect output.
        "italic" and "noaa" parameters exist only because on non-Windows systems "Subtitle" is aliased to "Text"
        (Each Subtitle parameter must exist in "Text" as well)
- Fix #360: plane fill wrongly assumed that pitch is rowsize, which is not the case after a Crop
  It would result in crash e.g. in HistogramRGBParade
- Enhancement: much quicker YV24 to RGB32/RGB24 conversion when AVX2 instruction set is supported. (+50% fps at i7-11700)
- UserDefined2Resize got an 's' parameter (to the existing b and c): support, default value = 2.3
  (following DTL2020's addition in jpsdr's MT resizer repo, UserDefined2ResizeMT filter)

  Now, as we have already three variable parameters to the optional chroma resamplers in ConvertToXX
  converters, ConvertToXX family got a new float 'param3' parameter which is passed to UV resizer as
  's', if "userdefined2" is specified as chroma resampler.
  If param3 is not used in a resizer but is defined, then it is simply ignored.
  Such as "ConvertToYV24" parameter signature: c[interlaced]b[matrix]s[ChromaInPlacement]s[chromaresample]s[param1]f[param2]f[param3]f
  e.g.: ConvertToYV24(chromaresample="userdefined2", param1=126, param2=22, param3=2.25)

  see also description at **test6**, which was updated with this parameter as well.

  s (support) param - controls the 'support' of filter to use by resampler engine. Float value in valid range from
  1.5 to 15. Default 2.3. It allows to fine tune resampling result between partially non-linear but more sharper and less
  residual ringing (at low b and c values) and more linear processing with wider 'peaking' used. Setting too high
  in common use cases (about > 5) may visibly degrade resampler performance (fps) without any visible output changes.
  Recommended adjustment range - between 2 and 3.

  Examples:
  b=126 c=22 - medium soft, almost no ringing.
  b=102 c=2 - sharper, small local peaking.
  b=70 c=-30 s=2 - sharper, thinner 'peaking'.
  b=70 c=-30 s=2.5 - a bit softer, more thick 'peaking'.
  b=82 c=20 - sharp but lots of far ringing. Not for using.

- Fix #350 ConvertXXX to accept YV411 clip's frame property _ChromaLocation set to 'left'
  (and 'topleft' and 'bottomleft' which give the same result) instead of giving an error message.
- Fix #348 bitrol/bitror functions return incorrect results when first argument is negative.
  Regression since the asm code of Avisynth 2.6 classic was ported to C in Avisynth+ project.
- "Info": if channel mask exists, then
  - its friendly name
  - otherwise the number of channels and the channel combinations
  is displayed under "AudioLength: x".

  e.g.
  SetChannelMask("stereo") --> "Channel mask: stereo"
  SetChannelMask("stereo+LFE") --> "Channel mask: 2.1"  because the combination resulted in another known channel combo name
  SetChannelMask("mono+LFE") --> "Channel mask: 2 channels (FC+LFE)" because the combination is unknown

- Add SetChannel parameter: channel string syntax: (similar to ffmpeg)
  a channel number followed by "c" for getting the default layout for a given number of channels.
  E.g. SetChannelMask("3c") will set "2.1" because this is the default choice for 3 channels
- Add SetChannel parameter: channel string syntax:
  a simple number is treated as the actual numeric mask.
  E.g. SetChannelMask("3") will set "stereo" because 3=1+2 that is "FL+FR" that is "stereo"
- SetChannelMask string version: If string is other than "" then its set to known. It has a single string parameter.
  SetChannelMask("mono") -> mask is known: "mono"
  SetChannelMask("")  -> mask is unknown
- Add "speaker_all" to accepted layout mask strings

- Fix possible crash of LLVM builds (clang-cl, Intel nextgen) on pre-AVX (SSE4-only) CPUs.
  (Prevent static initialization from avx2 source modules, which cause running AVX instructions on DLL load)
- ConvertToMono, GetLeftChannel, GetRightChannel: sets channel layout AVS_SPEAKER_FRONT_CENTER (mono)
- GetChannel, GetChannels, MergeChannels will set default channel layout if channel count is 1 to 8
  For defaults see VfW section below
- New Script function: SetChannelMask: string version.

    SetChannelMask(clip, string ChannelDescriptor) (parameters compulsory, no names must be set) (test10)

  Accepts predefined channel string or channel layout names or their combination, in ffmpeg style.
  Numerical indexes or channel counts are not allowed.
  String is case sensitive!
  E.g. "stereo+LFE+TC" or "FL+LR" or "5.1(side)"
    "mono",
    "stereo",
    "2.1",
    "3.0",
    "3.0(back)",
    "4.0",
    "quad",
    "quad(side)",
    "3.1",
    "5.0",
    "5.0(side)",
    "4.1",
    "5.1",
    "5.1(side)",
    "6.0",
    "6.0(front)",
    "hexagonal",
    "6.1",
    "6.1(back)",
    "6.1(front)",
    "7.0",
    "7.0(front)",
    "7.1",
    "7.1(wide)",
    "7.1(wide-side)",
    "7.1(top)",
    "octagonal",
    "cube"
    "speaker_all"
  Individual Speaker Channels:
    "FL",  front left
    "FR",  front right
    "FC",  front center
    "LFE", low frequency
    "BL",  back left
    "BR",  back right
    "FLC", front left-of-center
    "FRC", front right-of-center
    "BC",  back center
    "SL",  side left
    "SR",  side right
    "TC",  top center
    "TFL", top front left
    "TFC", top front center
    "TFR", top front right
    "TBL", top back left
    "TBC", top back center
    "TBR", top back right

- AudioDub will inherit channel layout setting from the audio clip.
- VfW output channel guess (when ChannelMask is not specified) changed at some points.
  Default number of channels to channel layout guess was modified to match of ffmpeg
    3 channels: Surround to 2.1
    4 channels: Quad to 4.0
    6 channels: 6.1(back) to 6.1
  This follows ffmpeg defaults
  Present rules:
    const   chnls  name    layout
    0x00004 1      mono    -- -- FC
    0x00003 2      stereo  FL FR
    0x0000B 3      2.1     FL FR    LFE
    0x00107 4      4.0     FL FR FC --  -- -- -- -- BC
    0x00037 5      5.0     FL FR FC --  BL BR
    0x0003F 6      5.1     FL FR FC LFE BL BR
    0x0070F 7      6.1     FL FR FC LFE -- -- -- -- BC SL SR
    0x0063F 8      7.1     FL FR FC LFE BL BR -- -- -- SL SR

- Add initial audio channel mask (channel layout) 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/windows/win32/api/mmreg/ns-mmreg-waveformatextensible)
  - 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)
       SetChannelMask(clip, string ChannelDescriptor) (parameters compulsory, no names must be set) (test10)
       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 menu, 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 an application can do 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.

- Set automatic MT mode MT_SERIALIZED to
  ConvertToMono, EnsureVBRMP3Sync, MergeChannels, GetChannel, Normalize, MixAudio, ResampleAudio
- Add back audio cache from classic Avisynth 2.6.
  Believe it or not, audio cache was never ported to Avisynth+
  - Make use of avisynth.h constants: CACHE_GETCHILD_AUDIO_MODE and CACHE_GETCHILD_AUDIO_SIZE:
    Filters are queryed about their desired audio cache mode through their SetCacheHints (similarly to CACHE_GET_MTMODE).
  - Filters can answer CACHE_GETCHILD_AUDIO_MODE with
    CACHE_AUDIO: Explicitly cache audio, X byte cache.
    CACHE_AUDIO_NOTHING: Explicitly do not cache audio.
    CACHE_AUDIO_AUTO_START_OFF: Audio cache off (auto mode), X byte initial cache.
    CACHE_AUDIO_AUTO_START_ON: Audio cache on (auto mode), X byte initial cache.
  - Default value is CACHE_AUDIO_AUTO_START_OFF.
  - Filters can specify the required cache size by returning CACHE_GETCHILD_AUDIO_SIZE.
    Default cache size is 256kB.
  - For custom audio cache querying example see EnsureVBRMP3Sync::SetCacheHints in source.
  How it works:
  - Modes CACHE_AUDIO_AUTO_START_OFF (default) and CACHE_AUDIO_AUTO_START_ON are automatic modes.
    The decision whether the stream benefits caching or not - and how big the cache
    size should be - is made upon continously gathering some statistics on the audio
    stream requests (an internal score is maintained).
    - when strict linear reading is detected. why bother with a cache,
      mode would finally changed to CACHE_AUDIO_AUTO_START_OFF.
    - When the requests are continously skipping chunks - a cache might not help;
      go with CACHE_AUDIO_AUTO_START_OFF as well.
    - When the next sample request is within the cache size, a cache could help:
      if audio cache was swithed off Avisynth would turn it into active caching by changing
      the working mode to CACHE_AUDIO_AUTO_START_ON.
  - Modes CACHE_AUDIO and CACHE_AUDIO_NOTHING are explicitely enable/disable audio cache at a give size.

- Fix Clang build AviSource crash on yuv422p10le UTVideo at specific widths (SSE2 or SSE4.1)
- #340: stop memory leak on propSet / MakePropertyWritable;
  A bit less memory/processing overhead in internal FrameRegistry as a side effect.
- #282: make 32-bit MSVC build to generate both decorated and undecorated export function names for C plugins
  C plugins built with mingw possibly expect decorated names.
- Expr: Add remaining stack element count to "Unbalanced stack..." error message.
- #306: Add ConvertToYUVA420, ConvertToYUVA422 and ConvertToYUVA444.
  Resulting clip is always YUVA:
  Alpha plane is kept if exists (even from packed RGB formats like RGB32/64),
  otherwise filled with maximum transparency mask value.
  Parameters are the same like in ConvertToYUVYUVxxx versions.
- Update build documentation with 2023 Intel C++ tools. See Compiling Avisynth+
  https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/contributing/compiling_avsplus.html
- CMakeLists.txt: add support for Intel C++ Compiler 2023.
- Enhanced performance in ConvertBits Floyd dither (dither=1) for 10->8, 16->8 and 16->10 bit cases
  by providing special function templates to allow compilers to optimize them much better.
  (Both Microsoft and Intel Classic 19.2 benefits, LLVM based clangCL and IntelLLVM compilers not)
- Fix crash when outputting VfW (e.g. VirtualDub) for YUV422P16, or P10 in Intel SSE2 optimization
  due to aligned SIMD write to an unaligned pointer - did not affect Microsoft builds.
  As seen in https://forum.doom9.org/showthread.php?p=1983343#post1983343

[...trimmed for length...]

[StainlessS]

Wow, somebodies been busy, ta very much

[DTL]

Heh - small fix for UV scale at RGB<->YUV at 'limited/narrow' levels mapping https://forum.doom9.org/showthread.p...18#post1988318 is not included in the 3.7.3 release. Pinterf promised to make a big redesign of all 'convert' core functions with a fix for this issue included (also with better performance) but it looks like it will happen in some 3.7.4testXXX next builds. So currently with 3.7.3 release the same workaround with additional UV scaling is required.

[tebasuna51]

Thanks qyot27 for the new release 3.73 r4003

With VirtualDub2 I can output correct WAVE_FORMAT_EXTENSIBLE audio output using:

global OPT_AllowFloatAudio = true # Use always, if not VfW downsample to 16 bits
LWLibavAudioSource("8w3D.ec3")
#SetChannelMask("22031") # Not needed with last LSMASHSource.dll

Also with:

global OPT_AllowFloatAudio = true # Use always, if not VfW downsample to 16 bits
global OPT_UseWaveExtensible = true # Needed to use global OPT_dwChannelMask=
FFAudioSource("8w3D.ec3")
global OPT_dwChannelMask=FFCHANNEL_LAYOUT

And:

global OPT_AllowFloatAudio = true # Use always, if not VfW downsample to 16 bits
global OPT_UseWaveExtensible = true # Needed to use global OPT_dwChannelMask=
BestAudioSource("8w3D.ec3")
global OPT_dwChannelMask=BASCHANNEL_LAYOUT

Now we need a way to use it with ffmpeg, wavi or avs2pipemod
Also MeGUI and BeHappy need changes.

[FranceBB]

Very nice! I've been testing it on all my servers and so far so good!

[zambelli]

Anyone else having trouble running Neo_FFT3D plugin with AVS+ 3.7.3? After updating from 3.7.2 to 3.7.3 a script that uses it now either takes ages to load or completely stalls.

[StainlessS]

@Z,
U wanna post your mysterious script ?

[FranceBB]

Originally Posted by zambelli

Anyone else having trouble running Neo_FFT3D plugin with AVS+ 3.7.3? After updating from 3.7.2 to 3.7.3 a script that uses it now either takes ages to load or completely stalls.

A simple test with:

video=LWLibavVideoSource("Y:\00_INGEST_MAM\UNR21052_ERROR.mxf")
ch12=LWLibavAudioSource("Y:\00_INGEST_MAM\UNR21052_ERROR.mxf", stream_index=1)
ch34=LWLibavAudioSource("Y:\00_INGEST_MAM\UNR21052_ERROR.mxf", stream_index=2)
ch56=LWLibavAudioSource("Y:\00_INGEST_MAM\UNR21052_ERROR.mxf", stream_index=3)
ch78=LWLibavAudioSource("Y:\00_INGEST_MAM\UNR21052_ERROR.mxf", stream_index=4)
audio=MergeChannels(ch56, ch78, ch56, ch78)


AudioDub(video, audio)

Limiter(min_luma=16, max_luma=235, min_chroma=16, max_chroma=240)

Bob()

neo_FFT3D(sigma=3.0, bt=3, y=3, u=3, v=3)

shows no issues:




a simple check with AVSMeter also shows no issues:

AvsMeter64.exe "\\mibctvan000\Ingest\MEDIA\temp\New File (37).avs"

pause

as always, I suggest getting rid of frame properties to speed things up:

video=LWLibavVideoSource("Y:\00_INGEST_MAM\UNR21052_ERROR.mxf")
ch12=LWLibavAudioSource("Y:\00_INGEST_MAM\UNR21052_ERROR.mxf", stream_index=1)
ch34=LWLibavAudioSource("Y:\00_INGEST_MAM\UNR21052_ERROR.mxf", stream_index=2)
ch56=LWLibavAudioSource("Y:\00_INGEST_MAM\UNR21052_ERROR.mxf", stream_index=3)
ch78=LWLibavAudioSource("Y:\00_INGEST_MAM\UNR21052_ERROR.mxf", stream_index=4)
audio=MergeChannels(ch56, ch78, ch56, ch78)

AudioDub(video, audio)

propClearAll()
AssumeTFF()

Limiter(min_luma=16, max_luma=235, min_chroma=16, max_chroma=240)

Bob()

neo_FFT3D(sigma=3.0, bt=3, y=3, u=3, v=3)

[tebasuna51]

@pinterf, we need a new AviSynthWrapper.dll for MeGUI to support Avs+ 3.7.3 (avs_core_10)?

[real.finder]

Originally Posted by zambelli

Anyone else having trouble running Neo_FFT3D plugin with AVS+ 3.7.3? After updating from 3.7.2 to 3.7.3 a script that uses it now either takes ages to load or completely stalls.

try with Avisynth+ 3.7.3 test 7 (20230223) https://drive.google.com/uc?export=d...B-weg50I_whTEm

[zambelli]

Originally Posted by StainlessS

@Z, U wanna post your mysterious script ?

Originally Posted by FranceBB

a simple check with AVSMeter also shows no issues:

Originally Posted by real.finder

try with Avisynth+ 3.7.3 test 7

I'm so sorry folks, it turned out to be a false alarm. I thought I had done the due diligence last night and narrowed down the problem to neo_FFT3D, but when I reinvestigated the script this morning with fresh eyes - of course it turned out to be an unrelated user error. I should've known better than to try to debug a problem at 1 am!

[FranceBB]

Originally Posted by zambelli

I should've known better than to try to debug a problem at 1 am!

No worries, it happens to everyone, especially with large scripts or with functions with lots of dependencies.
For instance, you have no idea how long it took me to find out an avstp related issue out of my scripts few years ago.
(and just FYI the actual fix Ferenc did back then worked like a charm but we all felt as if it was black magic as we didn't understand why xD).

[flossy_cake]

If I have for example:

plugins64/bwdif (v1.2.0).dll
plugins64/bwdif (v1.2.5).dll

What logic is Avisynth using to choose which one will be used for scripts? Does it check the version number inside the dll and use the newer one? Does this apply to .avsi files as well? In my testing it seems to be using the newer version, but I need to be 100% sure of this.

Also is there any way to check plugin version inside a script? My script won't work properly with certain versions of TFM & BWDIF due to updates in the way they handle field ordering, so the user might look at my dependency list in my readme.md and think "ah yes I already have those plugins" and get broken output and think my script is bad.

I was thinking to workaround this by putting my script and all its dependencies into one folder and then the user can just copy that one folder into /plugins64 and Avisynth might automatically preference any newer version dll's inside that folder - would that work?

[real.finder]

Originally Posted by flossy_cake

If I have for example:

plugins64/bwdif (v1.2.0).dll
plugins64/bwdif (v1.2.5).dll

What logic is Avisynth using to choose which one will be used for scripts? Does it check the version number inside the dll and use the newer one? Does this apply to .avsi files as well? In my testing it seems to be using the newer version, but I need to be 100% sure of this.

IIRC it will load them in alphabetical order, so the "bwdif (v1.2.5).dll" in your example will be used because it load after the 1st one, I think it's a same thing for avsi