AviSynth+ thread Vol.2

[DTL]

With PDR script,

Windows Logs/Application: 0xc0000374, Heap Corruption.


Faulting application name: VirtualDub64.exe, version: 2.0.0.0, time stamp: 0x5e73f48a
Faulting module name: ntdll.dll, version: 10.0.19041.2788, time stamp: 0x2f715b17
Exception code: 0xc0000374



It looks pinterf fix it now - https://github.com/AviSynth/AviSynthPlus/commit/534d4957be561ad497ad3c960ebf19dbfb06828a . Awaiting next release-build to use. Pinterf found and fix serious memory corruption bug around AVScore/convert and it may cause lots of random crashes with many scripts. It is not known when this bug was introduced ?

Build with VS2019 - https://drive.google.com/file/d/1_tl9hUzO3ST_57OM3SLQAWBGespjLeeA/view?usp=sharing . It finally start to draw some waveform without crash at 256x256 size.

Now can see waveforms draw :
"The internal levels(0,1,255,16,125,false) + ConvertToRGB appears close approximation, but with more gaps than vegas' "

It looks the code values duplicating going from Levels() transform. If put simple
ConvertToRGB(matrix="601:f")

It output also completely linear ramp -

BlankClip(length=1, width=256, height=256, pixel_type="Y8")
mt_lutspa(mode="relative closed", expr="x 255 *")

ConvertToRGB(matrix="601:f")

HistogramRGBParade(width=1.0)

https://i.postimg.cc/Pr1JBfzf/image.png

Same as latest 0.4.1 ver - DecodeYUVtoRGB(gain=64, offset=0, Ybias=0, UVbias=-128, UVgain=0.0)

[flossy_cake]

I was reading up on multithreading modes and I would like to use mode 3 to ensure my ScriptClip is evaluated in linear sequential chronological order ("MT_SERIALIZED: If the filter requires sequential access or uses some global storage, then mode 3 is the only way to go (http://avisynth.nl/index.php/SetFilterMTMode#Choosing_the_correct_MT_mode)"). However I'm not sure how to apply it to my ScriptClip - is it even possible?

I tried:

SetFilterMTMode("ScriptClip", MT_SERIALIZED)


And/or:

SetFilterMTMode("MyFunctionWhichMyScriptClipCalls", MT_SERIALIZED)


But I can't see any change in behaviour - I'm still seeing many frames where current_frame inside the ScriptClip is not equal to previous_frame+1. I count these as "desync" frames and print it out with SubTitle, and the behaviour is unpredictable - sometimes I have no desync frames and other times I get them quite a lot and my ScriptClip won't produce the output frame I want because Avisynth is evaluating it in nonlinear frame order. For example if I'm keeping a counter of how many combed frames in a row there were, the decision making logic is slightly broken since the counter can sometimes increment up like 1-2-5-3-4 instead of 1-2-3-4-5.

Single threading of course avoids the issue but performance is in the toilet. For now I'm keeping multithreading and warning the user with SubTitle error message if they get n desync frames within a 30 second period, but it would be nicer to force my ScriptClip to linear access.

:thanks:

edit: also tried GrunT.dll without improvement (tried local=true as well, which works in GRunT for global variable messaging between frames, unlike stock AVS+). It's weird because realtime playback of the .avs in MPC-HC using LAV (which uses ffmpeg) settles down to 0 desync frames after about 10 seconds of playback, but rendering the .avs to mpeg file with ffmpeg.exe at command line just continues to produce desync frames for the entire duration of the video.

edit: I noticed when desync frames cease during realtime MPC-HC playback, this seems to correlate to a drop in CPU usage, which I'm pretty sure is the multithread prefetch buffer becoming full. So maybe when prefetch buffer gets full then Avisynth starts evaluating ScriptClip in linear order. Whereas rendering the script with ffmpeg.exe, Avisynth never fills the prefetch buffer, probably because CPU is pegged at 100% on all cores busy encoding to h264. If true, then as long as you have some CPU headroom the nonthreadsafe issue seems to resolve itself. Although it seems it can crop up again for a few random frames if CPU suddenly gets very busy, like on certain high contrast line patterns when nnedi3 prescreener switches from bicubic to neural net the CPU usage can suddenly spike causing some desync frames.

[Boulder]

I was reading up on multithreading modes and I would like to use mode 3 to ensure my ScriptClip is evaluated in linear sequential chronological order ("MT_SERIALIZED: If the filter requires sequential access or uses some global storage, then mode 3 is the only way to go (http://avisynth.nl/index.php/SetFilterMTMode#Choosing_the_correct_MT_mode)"). However I'm not sure how to apply it to my ScriptClip - is it even possible?

You could try placing the RequestLinear function from the TIVTC package after the ScriptClip part.

[StainlessS]

Avs internal filters are already internally set/defaulted to optimium mode,
ScriptClip (and other runtime filters) will already be MT_SERIALIZED.
(Nothing else really makes much sense).

[kedautinh12]

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

[guest]

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

Double up :(

https://forum.doom9.org/showthread.php?p=1988143#post1988143

[pinterf]

Avs internal filters are already internally set/defaulted to optimium mode,
ScriptClip (and other runtime filters) will already be MT_SERIALIZED.
(Nothing else really makes much sense).
MT_SERIALIZED only ensures that the filter instance cannot be accessed more than once at a time (e.g. not multithread friendly at all). It does not mean that the call will be strict sequential.

[kedautinh12]

Double up :(

https://forum.doom9.org/showthread.php?p=1988143#post1988143

Someone won't go to there post, i think up here more people will catch it

[flossy_cake]

MT_SERIALIZED only ensures that the filter instance cannot be accessed more than once at a time (e.g. not multithread friendly at all). It does not mean that the call will be strict sequential.

Am I correct in thinking there is perhaps no such concept as multithreading in which calls would be sequential?

The way I'm imagining it in my mind right now, if calls were sequential, then all other threads would have to wait until the previous call was finished before they could do any work, meaning no work could be done in parallel, thus no multithreading?

If true, then I'm left wondering how the heck Avisynth is seemingly becoming sequential once the prefetch buffer becomes full. Example:


ColorBarsHD().Killaudio().ConvertToYV12() #HD video to make some more CPU load. ChangeFPS(60) for more if required.

global desyncCounter = 0
global previous_frame = 0

ScriptClip(last, "CheckSync(last, current_frame)", after_frame=true, local=false)

function CheckSync(clip c, int current_frame){

if (current_frame != 0){

if (previous_frame != current_frame-1){

global desyncCounter = desyncCounter + 1
c = c.SubTitle("Desync", text_color=$FF0000)
}

c = c.SubTitle("\ndesyncCount:" + string(desyncCounter) + "\n" +
\ "current_frame: " + string(current_frame) + "\n" +
\ "previous_frame: " + string(previous_frame)
\ , text_color=$C0C0C0, lsp=10)

}

global previous_frame = current_frame

c
}

Prefetch(8, 8) # may need to increase this on higher spec systems to generate desync frames. Try seeking around too.


edit: after some more testing with ChangeFPS(120) and/or loading up the CPU with QTGMC, the number of desync frames can become entirely unpredictable on my system, even after CPU usage settles to a lower level (indicating the prefetch buffer is full). So that theory of mine would seem to be false and perhaps it's just a pure fluke whether ScriptClip will be evaluated in linear order or not, depending on how the CPU is loaded or what other filters are doing. This makes me wonder how QTGMC can be successful with multithreading if that means QTGMC can't make any guarantee that it will be comparing the current frame to previous frame, in relation to how it "temporally smooths over the neighboring frames using a binomial kernel" if the neighbouring frame order can't be guaranteed due to multithreading.

edit: tried a workaround of using 2 ScriptClips - first one to do the decision making math and is set to Prefetch(1,4). Second ScriptClip does the heavy lifting of rendering the output clip based on previous ScriptClip's decision making and is set to Prefetch(7,4). At first it seemed to work and the first ScriptClip would always be chronologically prior to the second one (based on comparing frame counters between the two ScriptClips) but then as soon as I put any load on the first ScriptClip like doing some YDiffToNext or CFrameDiff I start getting desync frames again.

edit: after more testing of the above it seems that splitting the work into multiple ScriptClips with each of them set to "after_frame=true" does seem to be helping to control the order in which ScriptClip code is evaluated. But it's still a crapshoot and can't be guaranteed. It still seems to be a function of how many cores and prefetch frames I specify with Prefetch(), eg:


# seems to work under all tests - desync frames settle to 0 after n seconds of playback
ScriptClip(last, "GetFrameMetrics()").Prefetch(1, 4)
ScriptClip(last, "ChooseOutputClipBasedOnFrameMetrics()").Prefetch(7, 4)

# works only if CPU is loaded a certain way
ScriptClip(last, "GetMetricsPlusChooseOutputClipBasedOnMetrics()").Prefetch(8, 4)

# works only if CPU is loaded a certain way
ScriptClip(last, "GetMetrics()").Prefetch(1, 8)
ScriptClip(last, "ChooseOutputClipBasedOnMetrics()").Prefetch(7, 8)


edit: it seems this function Preroll (http://avisynth.nl/index.php/Preroll) can mitigate the issue, eg prerolling 1-2 seconds of video on the ScriptClip which you want to evaluate things in linear order.

[StainlessS]

MT_SERIALIZED only ensures that the filter instance cannot be accessed more than once at a time (e.g. not multithread friendly at all). It does not mean that the call will be strict sequential.

I stand corrected, good sir :)

[pinterf]

Avisynth+ 3.7.3 test 11 (20230608 - r3996) (https://drive.google.com/uc?export=download&id=1ZmFSUZ3ndDzfPYuVWp9MQpZ_YqHCoSEO)

Change log (including test9 changes)
20230608 3.7.3 WIP
------------------
**test11**
- 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, when an aligned Crop was immediately followed by a GreyScale().
- 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

**test9**
- 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 are compulsory, dont't use parameter name)
SetChannelMask(clip, string ChannelDescriptor) (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.

[gispos]

Thanks for the new version.

[StainlessS]

Lotsa changes there, yeah dude, thanx P. :)

[tebasuna51]

Thanks pinterf for your effort to manage audio in avs+.

I make some test with 4 ac3 samples:
4a301.ac3 MaskChannels : 15 (FL FR FC LF)
4s211.ac3 MaskChannels : 267 (FL FR LF BC)
4s220.ac3 MaskChannels : 1539 (FL FR SL SR)
4w310.ac3 MaskChannels : 263 (FL FR FC BC) (default for 4 channels)

And a .avs like:
OPT_UseWaveExtensible = true
#
BestAudioSource("4a301.ac3")
#FFAudioSource("4a301.ac3")
#LWLibavAudioSource("4a301.ac3")
#SetChannelMask("15")
to test the 4 files with the 3 decoders, and:

1) The decoders don't fill the MaskChannels and "Info" do not show it.
Using the appropiate SetChannelMask the "Info" show it correctly.

BestAudioSource say than a global variable BASCHANNEL_LAYOUT is created with the MaskChannels, how can use it to SetChannelMask?
The same with FFAudioSource and FFCHANNEL_LAYOUT

2) With the SetChannelMask set manually I output correct WaveFormatExtensible files with VirtualDub2 but the ChannelMask is ignored with MeGUI, mpc-hc or ffmpeg:

ffmpeg -i 4a301.avs 4a301.wav

the output is always the default 263 (FL FR FC BC) for my 4 samples.

EDIT: BeHappy crash with the SetChannelMask("15") active.
Of course old soft like wavi/avspipemod ignore also the internal ChannelMask and put the header and the channelmask with the command line parameters. New versions needed.

[DTL]

Found some temporal solution how to fix precision of PC.709 matrix when converting to narrow-RGB:

ColorBarsHD(640, 480, pixel_type="YV24")
ColorYUV(cont_u=-6, cont_v=-6)
ConvertToRGB32(matrix="PC.709")

Now RGBs are
Y 181,180,15
C 15,180,180
G 16,180,16
M 180,16,180
R 181,16,16
B 15,16,181

It looks internal coefficients for PC.709 matrix need adjustments.

Same correction of UV gain (contrast from mid value) looks also required for PC.2020 matrix.

Addition: Also looks like found the source of a bug - the Digital Y to Digital UV 219/224 additional multiplier (equal for all 3 IUT-R 601/709/2020) was missed at calculation of PC.x matrices. Hope it will be fixed in next build.

[qyot27]

Thanks pinterf for your effort to manage audio in avs+.

I make some test with 4 ac3 samples:
4a301.ac3 MaskChannels : 15 (FL FR FC LF)
4s211.ac3 MaskChannels : 267 (FL FR LF BC)
4s220.ac3 MaskChannels : 1539 (FL FR SL SR)
4w310.ac3 MaskChannels : 263 (FL FR FC BC) (default for 4 channels)

And a .avs like:

to test the 4 files with the 3 decoders, and:

1) The decoders don't fill the MaskChannels and "Info" do not show it.
Using the appropiate SetChannelMask the "Info" show it correctly.

BestAudioSource say than a global variable BASCHANNEL_LAYOUT is created with the MaskChannels, how can use it to SetChannelMask?
The same with FFAudioSource and FFCHANNEL_LAYOUT

2) With the SetChannelMask set manually I output correct WaveFormatExtensible files with VirtualDub2 but the ChannelMask is ignored with MeGUI, mpc-hc or ffmpeg:

ffmpeg -i 4a301.avs 4a301.wav

the output is always the default 263 (FL FR FC BC) for my 4 samples.

EDIT: BeHappy crash with the SetChannelMask("15") active.
Of course old soft like wavi/avspipemod ignore also the internal ChannelMask and put the header and the channelmask with the command line parameters. New versions needed.
Try this build of FFmpeg:
https://www.mediafire.com/file/cdvaed4e5mp23wb/ffmpeg_avschannellayout_test_win64.7z/file

[tebasuna51]

Try this build of FFmpeg
Seems work fine, thanks qyot27.

EDIT:
I found a problem, I think in avs+:

The max maskchannel than run ok is 13839 (FL FR FC LFE SL SR TFL TFC)
With 20543 (FL FR FC LFE BL BR TFL TFR) 7.1(top) the ChannelMask is truncated to 4159 (FL FR FC LF BL BR TFL ERROR: don't match with NumChan)

ffmpeg show errors like:
[pcm_f32le @ 000001f8a19d2010] Invalid PCM packet, data has size 20 but at least a size of 28 was expected

VirtualDub2 output also a invalid wav

[pinterf]

Oh, I didn't expect other softwares to use speaker bits so quickly. Finally a good feedback. Anyway, channel count and bit setting must match, this is the user's responsibility, maybe it must be checked more strictly by avisynth (aside from that there can be bugs on my side as well)

[qyot27]

Oh, I didn't expect other softwares to use speaker bits so quickly. Finally a good feedback. Anyway, channel count and bit setting must match, this is the user's responsibility, maybe it must be checked more strictly by avisynth (aside from that there can be bugs on my side as well)
I thought it was going to be more complicated than it was as well. I was fiddling with stuff for the better part of a day before I realized that what avs_get_channel_mask was outputting could just be ingested as-is by a function that already existed in FFmpeg and turned it into literally a one-line addition (aside from the necessary boilerplate to load the function and check version presence):
https://github.com/qyot27/FFmpeg/commit/1443d2b6ab4ab224f6ec27dedb47857f033c64fe

Functionally, I was concerned about the note in readme_history (https://github.com/AviSynth/AviSynthPlus/blob/master/distrib/Readme/readme_history.txt#L162):
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.
and whether that would cause problems with larger or more exotic layouts (even though at that point you'd be dealing with numbers of speakers akin to theaters or Atmos configurations), but because it says 'all information is kept' I wasn't actually sure about that, or if the mappings between AviSynth and FFmpeg could end up not matching and causing issues when doing it with av_channel_layout_from_mask instead of doing something like needing to tether the AVS_[IT|MASK]_SPEAKER defines to their equivalents in FFmpeg and use a for loop iterating over the channels and using AV_CHANNEL_ORDER_CUSTOM or something.


The only real issue is that - because we have to have to protect it behind the get_version check, the version of the headers FFmpeg checks for needs to be raised when this goes upstream. And because the interface version bump was in the middle of the current dev cycle, getting the patch upstreamed will have to wait until after the official release of 3.7.3.

[tebasuna51]

Just to test this is a channel test (https://www.sendspace.com/file/g9bq5z) encoded with Audition 2017 like 3/4(L R C LFE Ls Rs Vhl Vhr)

With SetChannelMask("22031") FL FR FC LFE SL SR TFL TFR
7.1(top-side) the oficial ffmpeg decode it correctly but like1599 (FL FR FC LF BL BR SL SR) 7.1

Virtualdub2 show that info:

EDIT: 18 bits is enough for WAVE_FORMAT_EXTENSIBLE dwChannelMask definitions, but seems cut at 14 bits 16384

[pinterf]

Just to test this is a channel test (https://www.sendspace.com/file/g9bq5z) encoded with Audition 2017 like 3/4(L R C LFE Ls Rs Vhl Vhr)

With SetChannelMask("22031") FL FR FC LFE SL SR TFL TFR
7.1(top-side) the oficial ffmpeg decode it correctly but like1599 (FL FR FC LF BL BR SL SR) 7.1

Virtualdub2 show that info:

EDIT: 18 bits is enough for WAVE_FORMAT_EXTENSIBLE dwChannelMask definitions, but seems cut at 14 bits 16384
Thanks, fixed on github.
(No test build from me yet, other things are under construction.)

[tebasuna51]

Thanks, fixed on github.
(No test build from me yet, other things are under construction.)
Thanks, no problem we can wait.

[pinterf]

Functionally, I was concerned about the note in readme_history (https://github.com/AviSynth/AviSynthPlus/blob/master/distrib/Readme/readme_history.txt#L162):

and whether that would cause problems with larger or more exotic layouts (even though at that point you'd be dealing with numbers of speakers akin to theaters or Atmos configurations), but because it says 'all information is kept' I wasn't actually sure about that, or if the mappings between AviSynth and FFmpeg could end up not matching and causing issues when doing it with av_channel_layout_from_mask instead of doing something like needing to tether the AVS_[IT|MASK]_SPEAKER defines to their equivalents in FFmpeg and use a for loop iterating over the channels and using AV_CHANNEL_ORDER_CUSTOM or something.

Thank you for the update.
I don't know since when, but ffmpeg features a more sophisticated channel layout, which may superseed the 18 (+ "all channels") bits supported by WAVE_FORMAT_EXTENSIBLE. I was not able to stuff these extra exotic layout options into the available Avisynth VideoInfo bits.

[kedautinh12]

Avs+ asd-g's build r3996
https://gitlab.com/uvz/AviSynthPlus-Builds

[kedautinh12]

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

[kedautinh12]

Thanks, no problem we can wait.

Try new build

[tebasuna51]

AviSynthPlus r4001
https://gitlab.com/uvz/AviSynthPlus-Builds
Try new build

503 Server Unavailable

[guest]

503 Server Unavailable

Works for me !

[FranceBB]

Works for me !

Yes, it's back now, but it's been down for a while.

[tebasuna51]

AviSynthPlus r4001 work fine now with my channel test:

[tebasuna51]

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

[real.finder]

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)

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

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

[StvG]

this make dither tools not working

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

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

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 (https://forum.doom9.org/showthread.php?p=1986000#post1986000)

[real.finder]

Updated dither - 1.28.1.1 x64 from Asd-g: updated to 2.6 plugin, added support for passthrough frame properties (https://forum.doom9.org/showthread.php?p=1986000#post1986000)

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

[StvG]

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 (https://github.com/AviSynth/AviSynthPlus/issues/272#issuecomment-1054123695).

[tebasuna51]

A new version of LSMASHSource.dll to test in https://github.com/HomeOfAviSynthPlusEvolution/L-SMASH-Works/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 (https://github.com/AviSynth/AviSynthPlus/releases/tag/v3.7.3)

- 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.php?p=1988318#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! :D

https://i.imgur.com/3yCW94r.png

[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]

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:

https://i.imgur.com/tskunwc.png
https://i.imgur.com/WzqDMPv.png

a simple check with AVSMeter also shows no issues:

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

pause

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


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)

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

[tebasuna51]

@pinterf, we need a new AviSynthWrapper.dll (https://forum.doom9.org/showthread.php?p=1913117#post1913117) for MeGUI to support Avs+ 3.7.3 (avs_core_10)?

[real.finder]

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=download&id=1dKBH5DM6RwNSBBwdEoB-weg50I_whTEm

[zambelli]

@Z, U wanna post your mysterious script ?
a simple check with AVSMeter also shows no issues:
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. :rolleyes: I should've known better than to try to debug a problem at 1 am! :)

[FranceBB]

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. (https://github.com/pinterf/mvtools/issues/46)
(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?

:thanks:

[real.finder]

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