AviSynth+ thread Vol.2

[pinterf]

Originally Posted by wonkey_monkey

I think the SSE/AVX2 instructions do this automatically, though it may use banker's rounding (round x.5 to the nearest even number, up or down) instead of rounding up (I'm not sure if you can change the default but you can explicitly do the rounding yourself first before converting).

SSE routines are using cvttps (double t: truncate, same as the int typecast in C). Former code was using integer_value = (int)(floating_pt + 0.5f) (after saturation check), now the plus 0.5 is gone.

[wonkey_monkey]

Well it certainly won't make an audible difference. Personally I'd go for cvtps - the tiny bias towards even numbers is statistically fair, and is not going to be audible (how often are two neighbouring .5 float samples likely to crop up? And even if they do, it's parts-in-billions), particularly if you're using it (as is currently done but with doubles) as the first step for converting to the lower bit-depths.

Edit: that missing 0.5 is causing a slight "visible" bias to waveforms when converting to 8-bit compared to 3.6.1. Not sure about 16-, 24-, and 32-bit yet as I'm having other problems of my own with those.

PS Does anyone know the logic behind this behaviour of Amplify():

8bit and 24bit audio is converted to float; the other audio formats are kept as they are.

?

[pinterf]

Originally Posted by wonkey_monkey

PS Does anyone know the logic behind this behaviour of Amplify():
"8bit and 24bit audio is converted to float; the other audio formats are kept as they are."
?

The Amplify routines were written only for int16, int32 and float. The rest two formats (8 and 24 bits) are converted to float (better than nothing)

[tebasuna51]

Originally Posted by pinterf

The Amplify routines were written only for int16, int32 and float. The rest two formats (8 and 24 bits) are converted to float (better than nothing)

One more time: All Avisynth audio internal or external filters than involve volume changes must operate only in float format.

It is not "better than nothing" is the correct way.

Amplify, ConvertToMono, MixAudio, MonoToStereo, Normalize, ResampleAudio, SuperEQ, SSRC and TimeStretch must work always in float format.
The user is free to use the ConvertAudioTo any int format if desired, most the times unnecesary because players or encoders accept float samples without problems.

Preserve int format is usefull for lossless manipulation, but when a volume change is done the audio is lossy now, and does not make sense preserve int format.

[pinterf]

Then it's the user's (bad) choice when he is using integer audio formats?

[tebasuna51]

Maybe the user don't know than is a bad choice (lose precission, risk of clip) manipulate the volume with int formats.

Is always better operate with float samples and recover the int format at end if is necesary ( I can't imagine for what).

[wonkey_monkey]

Well either they should all preserve the input format, or they should all convert to float - although the latter would, in my opinion, violate the Principle of Least Astonishment. I spent a little while last night tracking down what I thought was a bug in my filter that only seemed to affect 8-bit and 24-bit audio, but it was actually a problem with float audio because I had used an Amplify().

After all, the levels video filter doesn't convert to high bit depth, and nor would anyone expect it to. If users want higher resolution they should convert explicitly first. Most of my recent video filters convert to float internally but always convert back to the input format (with dithering) - except for YUY2, aka the Freak Colourspace.

[tebasuna51]

Originally Posted by wonkey_monkey

Well either they should all preserve the input format...

In audio there are some input classes:

- lossy formats (MP3, AC3, DTS, AAC,... ). The decoders always output float samples, if aren't requested to downsample the output.
There are users than don't know that, and ask about AC3 16 bits or DTS 24 bits when lossy formats don't have bitdepth, and doesn't make sense convert that float samples to int.

- 8 bits int (PCM or equivalent, rare cases): can be converted to float, manipulate it and reconvert to 8 bits int without lose that poor quality.

- 32 bits int: I never see a real sample, only useless experiments (the human ear can distinguise only until a 20 bit precission).

- 16/24 bits int PCM or lossless encoded (FLAC,TrueHD,DTS-MA,...) only functions than remain the volume unchanged (AudioTrim,DelayAudio, Get/MergeChannels) must preserve the input format, other functions deceive the user, than can think have still a lossless audio when is already lossy or even distorted by clip.

Only that last case is relevant for the discussion, we can lie the user with the Principle of least astonishment, or follow the correct way already used in AviSynth: "Audio samples will be automatically converted if any filters requires a special type of sample."

And include Amplify, ConvertToMono, MixAudio, MonoToStereo, Normalize, ResampleAudio to only manage Float samples.

My 5 cent. for Avs+ audio development.
If you want other 5 cent. include ChannelMask like audio property instead NumChannels.

[Boulder]

Any ideas why Asd-g's GMSD and MDSI functions don't get any benefit from multithreading? I just tested one clip with AVSMeter and without Prefetch, got avg 6.81 fps and with Prefetch(24,1), 6.66 fps. Average CPU usage 23,3% / 26,1% respectively.

https://github.com/Asd-g/AviSynthPlu...ster/GMSD.avsi
https://github.com/Asd-g/AviSynthPlu...ster/MDSI.avsi

EDIT: with Prefetch(threads=24, frames=10), 2.37 fps / 34,1%

[StvG]

Originally Posted by Boulder

Any ideas why Asd-g's GMSD and MDSI functions don't get any benefit from multithreading? I just tested one clip with AVSMeter and without Prefetch, got avg 6.81 fps and with Prefetch(24,1), 6.66 fps. Average CPU usage 23,3% / 26,1% respectively.

https://github.com/Asd-g/AviSynthPlu...ster/GMSD.avsi
https://github.com/Asd-g/AviSynthPlu...ster/MDSI.avsi

EDIT: with Prefetch(threads=24, frames=10), 2.37 fps / 34,1%

Without prefetch:

Frames processed:                   442 (0 - 441)
FPS (min | max | average):          10.76 | 50.43 | 43.85
Process memory usage (max):         321 MiB
Thread count:                       66
CPU usage (average):                7.4%

Time (elapsed):                     00:00:10.081

With prefetch(8):

Frames processed:                   1750 (0 - 1749)
FPS (min | max | average):          47.45 | 987.9 | 172.3
Process memory usage (max):         580 MiB
Thread count:                       74
CPU usage (average):                65.9%

Time (elapsed):                     00:00:10.156

[Boulder]

Script based on my Zopti script:

SetCacheMode(0)
orig = FFVideoSource("c:\zopti\lotr_fotr.avi").AssumeFPS(24000./1001)

b = -75/100.0					# optimize b = _n_/100.0 | -150..50 | b
c = 15/100.0					# optimize c = _n_/100.0 | -100..100 | c

downscaled_width = 1920
downscaled_height = 808

alternate = BicubicResize(orig, downscaled_width, downscaled_height, b=b, c=c).Lanczos4Resize(orig.width(),orig.height())

GMSD(alternate, orig, show=true)

#prefetch(24)

AVSMeter 3.0.6.0 (x64), (c) Groucho2004, 2012-2020
AviSynth+ 3.7.0 (r3382, 3.7, x86_64) (3.7.0.0)

Number of frames:                      400
Length (hh:mm:ss.ms):         00:00:16.683
Frame width:                          3840
Frame height:                         1608
Framerate:                          23.976 (24000/1001)
Colorspace:                      YUV420P16

Frames processed:                   400 (0 - 399)
FPS (min | max | average):          0.980 | 8.501 | 7.318
Process memory usage (max):         865 MiB
Thread count:                       41
CPU usage (average):                25.0%

Time (elapsed):                     00:00:54.661

With Prefetch(threads=24, frames=1):

AviSynth+ 3.7.0 (r3382, 3.7, x86_64) (3.7.0.0)

Number of frames:                      400
Length (hh:mm:ss.ms):         00:00:16.683
Frame width:                          3840
Frame height:                         1608
Framerate:                          23.976 (24000/1001)
Colorspace:                      YUV420P16

Frames processed:                   400 (0 - 399)
FPS (min | max | average):          0.116 | 30.55 | 6.887
Process memory usage (max):         1044 MiB
Thread count:                       65
CPU usage (average):                27.0%

Time (elapsed):                     00:00:58.078

The testclip is FFV1 encoded.

[StvG]

To use prefetch efficiently you should start with prefetch(x) where x is 2 and increase by 2 until find the most efficient value.
Here quick example with similar to your script:

Without prefetch:

orig=ffvideosource("001.mkv").ConvertBits(16) #source is 10-bit HEVC
downscaled_width = 1920
downscaled_height = 1080
b=1/3.0
c=1/3.0
b=BicubicResize(orig, downscaled_width, downscaled_height, b=b, c=c).Lanczos4Resize(orig.width(),orig.height())
gmsd(b, orig)

Number of frames:                     1350
Length (hh:mm:ss.ms):         00:00:56.306
Frame width:                          3840
Frame height:                         2160
Framerate:                          23.976 (24000/1001)
Colorspace:                      YUV420P16

Frames processed:                   28 (0 - 27)
FPS (min | max | average):          2.269 | 3.377 | 2.797
Process memory usage (max):         1639 MiB
Thread count:                       46
CPU usage (average):                5.9%

Time (elapsed):                     00:00:10.009

With prefetch:

orig=ffvideosource("001.mkv").ConvertBits(16) #source is 10-bit HEVC
downscaled_width = 1920
downscaled_height = 1080
b=1/3.0
c=1/3.0
b=BicubicResize(orig, downscaled_width, downscaled_height, b=b, c=c).Lanczos4Resize(orig.width(),orig.height())
gmsd(b, orig)
prefetch(4)

Number of frames:                     1350
Length (hh:mm:ss.ms):         00:00:56.306
Frame width:                          3840
Frame height:                         2160
Framerate:                          23.976 (24000/1001)
Colorspace:                      YUV420P16

Frames processed:                   73 (0 - 72)
FPS (min | max | average):          1.091 | 256416 | 7.141
Process memory usage (max):         1961 MiB
Thread count:                       50
CPU usage (average):                38.9%

Time (elapsed):                     00:00:10.223

[pinterf]

I think with the frames=1 you have just serialized the process. Default value for frames is threads*2, see Avisynth wiki on Prefetch

[Boulder]

Originally Posted by StvG

To use prefetch efficiently you should start with prefetch(x) where x is 2 and increase by 2 until find the most efficient value.

Yes, I know how it works, having tested it quite a lot when I switched back to Avisynth from VapourSynth. It works just fine in my normal encoding cases but this Zopti issue has got me baffled.

Originally Posted by pinterf

I think with the frames=1 you have just serialized the process. Default value for frames is threads*2, see Avisynth wiki on Prefetch

With my go-to settings of Prefetch(threads=24, frames=10) (fastest when encoding with x265), it gets just ridiculously slow. 2.35 fps / 32,1% this time.

[Boulder]

I think I may have found the problem. My test clip is produced by using these:

SelectEvery(920, 1)
Trim(3, 202)

When encoded with ffmpeg, it gives the clip a very strange framerate instead of the original one.

If the clip is decoded with orig = FFVideoSource("c:\zopti\silverado.avi"), it's slow as molasses but opens normally in VDub.
If it's decoded with orig = FFVideoSource("c:\zopti\silverado.avi",fpsnum=24000,fpsden=1001), it's very fast but it keeps on processing beyond the clip length, which is 200 frames. I checked the output in VDub, and it's actually repeating the same frame for the amount of frames that was in the original SelectEvery call

So where is the actual problem? I tested LWLibavVideoSource as well, same problem there.

You can find a testclip here:
https://drive.google.com/file/d/1fuV...ew?usp=sharing

[StvG]

Originally Posted by Boulder

Yes, I know how it works, having tested it quite a lot when I switched back to Avisynth from VapourSynth. It works just fine in my normal encoding cases but this Zopti issue has got me baffled.

You wrote in the first post:

Originally Posted by Boulder

Any ideas why Asd-g's GMSD and MDSI functions don't get any benefit from multithreading? I just tested one clip with AVSMeter and without Prefetch, got avg 6.81 fps and with Prefetch(24,1), 6.66 fps. Average CPU usage 23,3% / 26,1% respectively.

https://github.com/Asd-g/AviSynthPlu...ster/GMSD.avsi
https://github.com/Asd-g/AviSynthPlu...ster/MDSI.avsi

EDIT: with Prefetch(threads=24, frames=10), 2.37 fps / 34,1%

I was curious and tested.
Those scripts benefit of mt.
It seems you have additional filters/processing in the script?
Did you try with prefetch(4):

SetCacheMode(0)
orig = FFVideoSource("c:\zopti\lotr_fotr.avi").AssumeFPS(24000./1001)

b = -75/100.0					# optimize b = _n_/100.0 | -150..50 | b
c = 15/100.0					# optimize c = _n_/100.0 | -100..100 | c

downscaled_width = 1920
downscaled_height = 808

alternate = BicubicResize(orig, downscaled_width, downscaled_height, b=b, c=c).Lanczos4Resize(orig.width(),orig.height())

GMSD(alternate, orig, show=true)

prefetch(4)

[Boulder]

Originally Posted by StvG

I was curious and tested.
Those scripts benefit of mt.
It seems you have additional filters/processing in the script?

Please see the previous post, it's definitely an issue caused by the source clip confusing the decoder. I don't know how it gets worse with multithreading because source decoding should be serialized anyway.

Originally Posted by tebasuna51

If you want other 5 cent. include ChannelMask like audio property instead NumChannels.

That would be very useful.

[StvG]

Originally Posted by Boulder

Please see the previous post, it's definitely an issue caused by the source clip confusing the decoder. I don't know how it gets worse with multithreading because source decoding should be serialized anyway.

Yes, I can reproduce the issue with your sample.

[kedautinh12]

New hqdn3d support HBD
https://github.com/Asd-g/hqdn3d