AviSynth+ thread Vol.2

[pinterf]

Nope, line 380:

int new_size = (int)(_pimpl->vi.BytesFromAudioSamples(std::max(count, _pimpl->AudioCacheStart + (int64_t)_pimpl->CacheCount - start)) + 8192) & -8192; // Yes +1 to +8192 bytes


GetAudio is being called with start = 240000 and count = 24000.

Edit: _pimpl->MaxSampleCount = 96084352
Good catch, I searched only for explicite CACHE_AUDIO_AUTO_START_ON text.
Fix? Something like this:
int64_t new_size = (_pimpl->vi.BytesFromAudioSamples(std::max(count, _pimpl->AudioCacheStart + _pimpl->CacheCount - start)) + 8192) & -8192; // Yes +1 to +8192 bytes
new_size = std::min((int64_t)8192 * 1024, new_size);
_RPT2(0, "CA:%x: Autoupsizing buffer to %d bytes!\n", this, (int)new_size);
SetCacheHints(_pimpl->AudioPolicy, (int)new_size); // updates maxsamplecount!!

[wonkey_monkey]

Yay, bug squished! Thanks pinterf.

Is it of any concern that the logic should come close to allocating such a large cache (if not for the std::min)? Is it just because I jumped 40 minutes ahead in the same clip?

[pinterf]

Yay, bug squished! Thanks pinterf.

Is it of any concern that the logic should come close to allocating such a large cache (if not for the std::min)? Is it just because I jumped 40 minutes ahead in the same clip?
I think the 8 MB size I see in the code is just a logical limit. And yes, simply jumping 40 minutes triggered the overflow.

[pinterf]

Even if I don't kill the env, avisynth hangs !

#self.env = None # it is commented out !!

print('release finished')
# at this point all has been released and AvsPmod should do nothing, but the procedure doesn't return, so avisynth doesn't return.

Please note that:
Next test using AviSource for the same script:
AviSource("C:\Users\GPo\Desktop\preview_test.avs")

If I open the same script just once, not directly but with AviSource, there are no more problems with other tabs (scripts) that are loaded directly.
Nothing has changed in AvsPmod, it works just as before and releasing the env works also, theoretically it can only be the Avisynth C interface that has changed something after using it once with AviSource.

Video in Archive 7z: https://drive.google.com/file/d/1KgZ2h2uN6X5mFxtY2B38R_Qtk7efvbGQ/view?usp=sharing

And here Test 2: https://forum.doom9.org/showthread.php?p=2014491#post2014491
Thanks for the video. I see. I couldn't find those points in the source, are they private? Another question: which line's "env = None" did you comment out?
Edit1: I found the place, I think, putting there printfs I got similar debug window like you had.

Edit2:

New finding.

The reference count of the main clip (script containing RIFE) never reaches zero. As a result, the clip is not destroyed, and the RIFE plugin's "free_filter" is not called.

Clip objects are reference-counted, and their destructor is invoked only when the counter reaches zero. The function avs_take_clip (as_clip) increases the count by one. Copying with avs_copy_value also increases it by one. Conversely, avs_release_clip decreases the count by one, and avs_release_value on a 'clip' type AVS_Value also decreases it.

Each copy_value must have a corresponding release_value pair. Similarly, each take_clip must have a corresponding release_clip pair.

I see that this is handled correctly throughout the code, invoke is ok, copy and release_on_del flags usages, but still, somehow somewhere it misses a clip release.

Since the free_filter callback event is not triggered, RIFE does not clean up and destroy its GPU instance objects. This is likely why simply unloading the DLL causes internal issues.

[VoodooFX]

@pinterf Will the new version require the wrapper to be updated for MeGUI?

[Kurt.noise]

@pinterf Will the new version require the wrapper to be updated for MeGUI?
I tested rev 4178, and the last bundle provided in my releases was ok.

[Emulgator]

Congrats, pinterf and gispos, and many thanks for the effort !
Now further regression testing... Win10P64, i9-11900K+128GB, dGPU RTX3080+16GB, iGPU Intel UHD750
Yes, AvsPmod64 2.7.9.2 can handle AviSynth64+ r4066 and r4178 nicely, releasing works, no stalls on my few attempts.

Still AviSynth64+ r4178 crashes if I call RIFE instances within Scriptclip while r4066 performs nicely.
To exclude any sidesuckers I rewrote my interpolation .avsis to get rid of RIFEwrap.
I am calling RIFE directly now: Much better, huge speed gain !

With which Avs+ version the regression came in ? It seems to be the r41xy versions.

AviSynth64+ r4066: 1 RIFE instance within Scriptclip: Playable in AvsPmod64/Encoders64. Topaz 2.6.4 loads script, sees and processes all frames. Ok.
AviSynth64+ r4073: 1 RIFE instance within Scriptclip: Playable in AvsPmod64. Topaz 2.6.4 immediately sees no frame, range 0..-1. Unusable for Topaz.
AviSynth64+ r4096 Clang: 1 RIFE instance within Scriptclip: Playable in AvsPmod64. Topaz 2.6.4 immediately sees no frame, range 0..-1. Unusable for Topaz.
AviSynth64+ r4096 LLVM: 1 RIFE instance within Scriptclip: Playable in AvsPmod64. Topaz 2.6.4 immediately sees no frame, range 0..-1. Unusable for Topaz.

AviSynth64+ r4173: 1 RIFE instance within Scriptclip: F5-loading in AvsPmod64 2.7.9.2: 1st frame 0 gets loaded.
When I press Play: I hear the first audio blip for that frame 0, then frame 0 is shown stuck for 5..6 seconds, no audio.
After these 5 seconds I hear the same audio blip of frame 0 a second time, then AvsPmod64 aborts.
Topaz 2.6.4 crashes immediately on script loading.

AviSynth64+ r4177: 1 RIFE instance within Scriptclip: F5-loading in AvsPmod64 2.7.9.2: 1st frame 0 gets loaded.
When I press Play: I hear the first audio blip for that frame 0, then frame 0 is shown stuck for 5..6 seconds, no audio.
After these 5 seconds I hear the same audio blip of frame 0 a second time, then AvsPmod64 aborts.
Topaz 2.6.4 crashes immediately on script loading.

AviSynth64+ r4178: 1 RIFE instance within Scriptclip: F5-loading in AvsPmod64 2.7.9.2: 1st frame 0 gets loaded.
When I press Play: I hear the first audio blip for that frame 0, then frame 0 is shown stuck for 5..6 seconds, no audio.
After these 5 seconds I hear the same audio blip of frame 0 a second time, then AvsPmod64 aborts.
Topaz 2.6.4 crashes immediately on script loading.

P.S. I have to repeat those tests.
I found a repeatable race condition which leads to stalled processing, under same hovering CPU/GPU load, even with r4066.
After around ~83% progress rendering slows down sharply until the very same frame seems to be served forever,
sometimes advancing, then stalling, downstream forcing a reloading, but AviSynth+ delivers no more frames
and downstream is waiting forever.

AviSynth64+ r4066 serving a restoration script for frameskipped 29.97->25fps footage.
The sequence is: Skippy 25p -> periodically/manually insert dup-before-skip, obtaining duppy-skippy 29,97p ->
Interpolate over each dup -> obtain smooth moving 29.97p -> Interpolate 2x fps -> 59.94p
The script concatenates various trimmed segments of SelectEvery(5,0,0,1,2,3,4).Assumefps("ntsc_video"),
then calling an Interpolation .avsi which contains ScriptClip loops containing RIFE procedures which are auto-triggered by consecutive dups.
If the SelectEvery() section is commented out (because the source contains no frameskips), all is well, no stalling.
Happens the same on 2 identical machines, System SSDs not exact mirrors, but similar environment.

P.P.S. It just hits me that the rendering getting stuck around 83% progress (5/6) matches the frame ratio (5in/6out) !
Non-matching framecount/current_frame calculation/reporting along SelectEvery/ScriptClip/RIFE?

PPPS. Took SelectEvery() out of the chain.
Played that reduced script in AvsPmod: No problem, plays until the end 100%.
Fed that reduced script to Topaz: 83% stuck.
SelectEvery back in, played the full script in AvsPmod: No problem, plays until the end 100%.
Fed the full script to Topaz: 83% stuck.
It might have to do with how frames are reported to Topaz, I guess; the no frames (0,-1) could point into such direction as well.

Ok, back to intermediates then for such corner cases.

PPPPS: The 83% stuck was Topaz fault choking on audio stream shorter than video.
As I exported a test clip from AvsPmod and threw it into Vegas it beame obvious:
My 25->29 procedures within AviSynth+ led to audio being only 83% of video length.
Workaround: KillAudio() at the start, AudioDub() at the end after all trickery is done.

[pinterf]

AviSynth64+ r4066: 1 RIFE instance within Scriptclip: Playable in AvsPmod64/Encoders64. Topaz 2.6.4 loads script, sees and processes all frames. Ok.
AviSynth64+ r4073: 1 RIFE instance within Scriptclip: Playable in AvsPmod64. Topaz 2.6.4 immediately sees no frame, range 0..-1. Unusable for Topaz.
[...]
If the SelectEvery() section is commented out (because the source contains no frameskips), all is well, no stalling.
Happens the same on 2 identical machines, System SSDs not exact mirrors, but similar environment.

PPPS. Took SelectEvery() out of the chain.
Played that reduced script in AvsPmod: No problem, plays until the end 100%.

Fantastic job on the bug report!
These helped a lot.
There indeed was a commit related to Interleave (which is called by SelectEvery). I'm gonna look at it.

EDIT: Please try with this test build.
EDIT 2: Found the cause of the crash. Test build removed and currently under construction.
EDIT3: The access violation occurred when AviSynth was inside a ScriptClip with a C plugin and getPropInt (or any other runtime getter).
Please try this build (find the 4182-uncommitted version):
https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.3.4178

One less bug. Let's see how it is working for you. I had successful reloads and parallel scripts open in the new AvsPMod. Thanks.

[Jamaika]

YUV420P8 doesn't work for me.
if (!vi.IsPlanar() || !vi.IsPlanarRGB() || !vi.IsPlanarRGBA())
throw_error("clip must be planar");

[StainlessS]

Jamaika, is that YOUR code, or Avs+ code ?

If yours (where post is Off Topic in this thread), then how about


if (!(vi.IsPlanar() || vi.IsPlanarRGB() || vi.IsPlanarRGBA()))
throw_error("clip must be planar");

[Jamaika]

Jamaika, is that YOUR code, or Avs+ code ?

If yours (where post is Off Topic in this thread), then how about


if (!(vi.IsPlanar() || vi.IsPlanarRGB() || vi.IsPlanarRGBA()))
throw_error("clip must be planar");

This is of e.g. avsresize but IsPlanar() is present in many add-ons to AVS+.

[StainlessS]

... but IsPlanar() is present in many add-ons to AVS+.
Yep, but you have to use it correctly.

if (!vi.IsPlanar() || !vi.IsPlanarRGB() || !vi.IsPlanarRGBA())
throw_error("clip must be planar");

Your code says, if any one of (IsPlanar, IsPlanarRGB, IsPlanarRGBA) is false then throw error,
so, as at least one of them (actually at least 2 of them) is always false, so will always throw an error.

Mine

if (!(vi.IsPlanar() || vi.IsPlanarRGB() || vi.IsPlanarRGBA()))
throw_error("clip must be planar");

says, if all of (IsPlanar, IsPlanarRGB, IsPlanarRGBA) are false then throw error.

EDIT: This would also work (if all isPlanarXXX false)

if (!vi.IsPlanar() && !vi.IsPlanarRGB() && !vi.IsPlanarRGBA())
throw_error("clip must be planar");

[Jamaika]

So I open the planar documentation. I assume that YUV420P8 is planar so the codec should work but it doesn't for gcc 14.2.0. I'm testing 11.5.0 now. I'll know soon.
http://avisynth.nl/index.php/Planar

[StainlessS]

Just use either of the code snippets I gave in post #3062, it will work, It is your logic that is wrong.

either,


if (!(vi.IsPlanar() || vi.IsPlanarRGB() || vi.IsPlanarRGBA()))
throw_error("clip must be planar");


OR

if (!vi.IsPlanar() && !vi.IsPlanarRGB() && !vi.IsPlanarRGBA())
throw_error("clip must be planar");

[Jamaika]

if (!vi.IsPlanar() && !vi.IsPlanarRGB() && !vi.IsPlanarRGBA())
throw_error("clip must be planar");

I simply deleted it and it worked, but I wonder what IsPlanar() does.

For me, this entry is incorrect.
What is the meaning of writing for the value if (1 and 0 and 0) it will be zero.

[pinterf]

I simply deleted it and it worked, but I wonder what IsPlanar() does.

For me, this entry is incorrect.
What is the meaning of writing for the value if (1 and 0 and 0) it will be zero.
If you read your problematic expression aloud in your native language, you'll likely start to sense what's wrong with it.

[Jamaika]

If you read your problematic expression aloud in your native language, you'll likely start to sense what's wrong with it.
I'm not going to think about it.

It doesn't work. when I delete the record it works.
z_ConvertFormat(pixel_type="YUV420P8", colorspace_op="709:709:709:full=>709:709:709:limited", dither_type="none")

Saved by fastblur
for (int pid = 0; pid < vi.NumComponents(); pid++) {
bool uv = _planes[pid] == PLANAR_U || _planes[pid] == PLANAR_V;
planes.push_back({
vi.IsPlanar() ? _planes[pid] : 0,
vi.IsPlanar() ? 0 : pid,
vi.IsPlanar() ? 0 : vi.NumComponents(),
!(uv || _planes[pid] == PLANAR_A), uv,
uv ? uv_pyramid : y_pyramid,
uv ? sub_w : 0,
uv ? sub_h : 0
});
}

Edit: For gcc 11.5.0 IsPlanar() doesn't work. So my previous arguments are worthless since the basic function doesn't work.
https://www.sendspace.com/file/16t0ja

[StainlessS]

Again, your logic is wrong.
One of the correct ones given

if (!vi.IsPlanar() && !vi.IsPlanarRGB() && !vi.IsPlanarRGBA())
throw_error("clip must be planar");


!IsPlanar !IsPlanarRGB !IsPlanarRGBA AND
0 0 0 0
0 0 1 0
0 1 0 0
0 1 1 0
1 0 0 0
1 0 1 0
1 1 0 0
1 1 1 1 NOT Planar && NOT PlanarRGB && NOT PlanarRGBA, then ThrowError


EDIT: OR,

if (!(vi.IsPlanar() || vi.IsPlanarRGB() || vi.IsPlanarRGBA()))
throw_error("clip must be planar");




IsPlanar IsPlanarRGB IsPlanarRGBA OR NOT
0 0 0 0 1 ! (Planar || PlanarRGB || PlanarRGBA), then ThrowError
0 0 1 1 0
0 1 0 1 0
0 1 1 1 0
1 0 0 1 0
1 0 1 1 0
1 1 0 1 0
1 1 1 1 0

[Jamaika]

!IsPlanar !IsPlanarRGB !IsPlanarRGBA AND
0 0 0 0
0 0 1 0
0 1 0 0
0 1 1 0
1 0 0 0
1 0 1 0
1 1 0 0
1 1 1 1 NOT Planar && NOT PlanarRGB && NOT PlanarRGBA, then ThrowError

Correct train of thought, but it would mean that videos for avsresize must always be interlaced. I don't know anything about that.
http://avisynth.nl/index.php/Avsresize

[StainlessS]

What has interlaced got to do with your assertion about IsPlanar being wrong ???
EDIT: Planar has nothing to do with being interlaced, it is the color format in memory [being in planes, rather than interleaved eg RGB24 or YUY2]
[ Planar can be interlaced or not (ie Progressive), Interleaved color formats can be interlaced or not (ie Progressive) ]

Planar means storage for each color channel is stored separately and contiguously, eg
RGB planar, stored as RRRRRRRRRR, GGGGGGGGGG, BBBBBBBBBB. Each channels pixel values stored together, in planes.
RGB24, RGB Interleaved stored as RGB,RGB,RGB,RGB,RGB,RGB,RGB,RGB,RGB,RGB. Each pixel channels stored together Interleaved (although usually as BGR, I think).

EDIT: Wiki Color Format:- https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/convert.html#color-formats
EDIT: The color formats: RGB, YUY2 and YV12:- https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/advancedtopics/sampling.html#the-color-formats-rgb-yuy2-and-yv12
EDIT: Colorspaces:- https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/FilterSDK/ColorSpaces.html
Planar:- http://avisynth.nl/index.php/Planar
Interleaved:- http://avisynth.nl/index.php/Interleaved

Interlaced versus field-based video :- http://avisynth.nl/index.php/Interlaced_fieldbased
Advanced topics:- http://avisynth.nl/index.php/Advanced_topics

[Jamaika]

What has interlaced got to do with your assertion about IsPlanar being wrong ???
EDIT: Planar has nothing to do with being interlaced, it is the color format in memory [being in planes, rather than interleaved eg RGB24 or YUY2]
[ Planar can be interlaced or not (ie Progressive), Interleaved color formats can be interlaced or not (ie Progressive) ]

Planar means storage for each color channel is stored separately and contiguously, eg
RGB planar, stored as RRRRRRRRRR, GGGGGGGGGG, BBBBBBBBBB. Each channels pixel values stored together, in planes.
RGB24, RGB Interleaved stored as RGB,RGB,RGB,RGB,RGB,RGB,RGB,RGB,RGB,RGB. Each pixel channels stored together Interleaved (although usually as BGR, I think).

EDIT: Wiki Color Format:- https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/corefilters/convert.html#color-formats
EDIT: The color formats: RGB, YUY2 and YV12:- https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/advancedtopics/sampling.html#the-color-formats-rgb-yuy2-and-yv12
EDIT: Colorspaces:- https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/FilterSDK/ColorSpaces.html
Planar:- http://avisynth.nl/index.php/Planar
Interleaved:- http://avisynth.nl/index.php/Interleaved

Interlaced versus field-based video :- http://avisynth.nl/index.php/Interlaced_fieldbased
Advanced topics:- http://avisynth.nl/index.php/Advanced_topics

Maybe, my input codec is:
Planar YUV Formats: I420 0x30323449 12 8 bit Y plane followed by 8 bit 2x2 subsampled U and V planes.

Avisynth function: LWLibavVideoSource [input_yuv420p.mp4, 30000, 1001]
Input #0, avisynth, from 'AudioBoost3.avs': 0KB sq= 0B
Duration: 00:42:05.52, start: 0.000000, bitrate: 0 kb/s
Stream #0:0: Video: rawvideo (I420 / 0x30323449), yuv420p(progressive), 704x480, 29.97 fps, 29.97 tbr, 29.97
tbn
The problem is with:
Avisynth function: LWLibavVideoSource [input_yuv420p.mp4, 30000, 1001]
Avisynth function: z_ConvertFormat [YUV420P8, 709:709:709:limited=>709:709:709:limited, none]
[avisynth @ 000002f02ad57f60] avsresize: clip must be planar.

test wiki:
LWLibavVideoSource("input_rgb24.avi",fpsnum=30000,fpsden=1001)
ConvertToPlanarRGB()
z_ConvertFormat(pixel_type="YUV420P8", colorspace_op="rgb:709:709:full=>709:709:709:limited")

[avisynth @ 000002f02ad57f60] avsresize: clip must be planar.

[pinterf]

This one is really tricky: I420 is a variant of YV12, but their colorspace constants differ. Some filters can only accept and check against the exact YV12 format.

This is why VideoInfo::IsSameColorspace
- first checks for exact code match,
then if no exact match then
- it compares the two VideoInfo's IsYV12() which reports true even if the clip is I420 _or_ YV12.

[wonkey_monkey]

Some questions spring to mind:

Can we see the whole script, just to make absolutely sure nothing else is happening?
Did you compile both AviSynth+ and AVSResize with GCC? Have you made any other changes to either of them?

[Jamaika]

Did you compile both AviSynth+ and AVSResize with GCC? Have you made any other changes to either of them?
Everything is possible, but this is a curiosity. Is this a gcc, mingw64 bug? Others on this forum add codecs x264,x265,vvenc,...

[wonkey_monkey]

Everything is possible, but this is a curiosity. Is this a gcc, mingw64 bug? Others on this forum add codecs x264,x265,vvenc,...

That doesn't answer my question. I think we may struggle here...

[StainlessS]

By Pinterf
This one is really tricky: I420 is a variant of YV1
I don't really think it is relevant. [But maybe]
It's the c code he's using somewhere [???, wherever he was using it, it WAS WRONG],
Don't know where he's using it.
On occasion some users change avs functions so they don't havta
provide fn args [ EDIT: bad idea ], me is guessing it's something like that.
{ Changes function, then wants help to make it work without telling what weird changes have been made/hard_coded }

Also, maybe should answer Wonkey Donkey questions.

[Emulgator]

Pinterf, hats off to you ! You did it. Beautiful.
Your AviSynth64+ version r4178-4182-uncommitted loads & unloads my reduced script in AvsPmod 2.7.9.2.
Processing finally with even CPU load, no more pulsing, and a beautiful speed gain !
And Topaz 2.6.4 eats the script happily and sees all frames. A dream came true.
Going deeper soon.

[pinterf]

Pinterf, hats off to you ! You did it. Beautiful.
Your AviSynth64+ version r4178-4182-uncommitted loads & unloads my reduced script in AvsPmod 2.7.9.2.
Processing finally with even CPU load, no more pulsing, and a beautiful speed gain !
And Topaz 2.6.4 eats the script happily and sees all frames. A dream came true.
Going deeper soon.
... Somewhere I knew it :) I received a fabulous Sleep Score of 82 from my Garmin. Thanks for your time. I'll make these commits live now.

[tormento]

If only Dogway would take advantage of the new features in his scripts…

[pinterf]

Freshly built v4193.

- 32 and 64-bit XP compatible versions
- 64 bit Intel ICX compiled version (only Avisynth.dll, plugins were just copied)
May require Intel C++ 2025 redistributable: https://www.intel.com/content/www/us/en/developer/articles/tool/compilers-redistributable-libraries-by-version.html

Download Avisynth+ 3.7.3 r4193 test:
https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.3.4193

Changes since official 3.7.3
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/changelist374.html
and
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/FilterSDK/FilterSDK.html#api-v11-whats-new
and millions of updated documentation pages.

[StainlessS]

Lovely, tanx P :)

[TR-9970X]

Surely it must be nearly time for 3.7.4....

[Emulgator]

Woohoo ! Donation on the way.
https://forum.doom9.org/showthread.php?p=2014728#post2014728
Still via this ?
https://buymeacoffee.com/pinterf
Or if paypal, PM me.

[pinterf]

Woohoo ! Donation on the way.
https://forum.doom9.org/showthread.php?p=2014728#post2014728
Still via this ?
https://buymeacoffee.com/pinterf
Or if paypal, PM me.
Thanks :), I tried to hide it well.

[real.finder]

Freshly built v4193.

- 32 and 64-bit XP compatible versions
- 64 bit Intel ICX compiled version (only Avisynth.dll, plugins were just copied)
May require Intel C++ 2025 redistributable: https://www.intel.com/content/www/us/en/developer/articles/tool/compilers-redistributable-libraries-by-version.html

Download Avisynth+ 3.7.3 r4193 test:
https://github.com/pinterf/AviSynthPlus/releases/tag/v3.7.3.4193

Changes since official 3.7.3
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/changelist374.html
and
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/FilterSDK/FilterSDK.html#api-v11-whats-new
and millions of updated documentation pages.

I did try it with last avspmod update and it work fine so far (its first time I did try the 64bit test update)
:thanks:

[tormento]

64 bit Intel ICX compiled version
Be my Valentine. :D

[FranceBB]

Who needs chocolate when we have a new Avisynth build to test! :)

https://i.imgur.com/6FnS5NV.png

[gispos]

Freshly built v4193.

- 32 and 64-bit XP compatible versions
- 64 bit Intel ICX compiled version (only Avisynth.dll, plugins were just copied)
May require Intel C++ 2025 redistributable: https://www.intel.com/content/www/us/en/developer/articles/tool/compilers-redistributable-libraries-by-version.html
.
AvsPmod runs with the Intel ICX build without problems, but I can't open a script with any other program.

Do I have to install the runtimes ?
Is the Intel build better (faster) on an Intel CPU ?

[tormento]

AvsPmod runs with the Intel ICX build without problems, but I can't open a script with any other program.
Yes you have to. Read pinterf release post again. :)

I am using ICX build with AvsPmod with no problems here.

[tormento]

Who needs chocolate when we have a new Avisynth build to test! :)
:eek:

[pinterf]

AvsPmod runs with the Intel ICX build without problems, but I can't open a script with any other program.

Do I have to install the runtimes ?
Is the Intel build better (faster) on an Intel CPU ?
Runtimes are probably needed, but I cannot check since I already have them on my machine because of the tests. The Intel build should be quicker. In this case, the XP builds are using the Visual Studio 2017 compiler, so they probably lack all the 2019 and 2022 Microsoft compiler optimizations. Even if the Intel build were equal to an MSVC 2022 build, the XP builds using 2017 technology are probably slower. However, this may be an urban legend. I guess, the actual speed gain is negligible unless you do synthetic tests using only internal Avisynth functions without using external scripts.

[TR-9970X]

Runtimes are probably needed, but I cannot check since I already have them on my machine because of the tests. The Intel build should be quicker. In this case, the XP builds are using the Visual Studio 2017 compiler, so they probably lack all the 2019 and 2022 Microsoft compiler optimizations. Even if the Intel build were equal to an MSVC 2022 build, the XP builds using 2017 technology are probably slower. However, this may be an urban legend. I guess, the actual speed gain is negligible unless you do synthetic tests using only internal Avisynth functions without using external scripts.

Possibly stupid question....

Why XP builds ?

What build should I use for Ryzen CPU's, using W11 Pro ?

[FranceBB]

Why XP builds ?

What build should I use for Ryzen CPU's, using W11 Pro ?

it's just a term to say that they were compiled using v141_xp which is the Microsoft compiler, MSVC. They run on all versions of Windows from Windows XP all the way up to Windows 11. You're gonna be fine. ;)

As a bit of history, Avisynth has been supporting Windows 98SE and Windows 2000 since its inception on May 19th, 2000. The last Avisynth version, 2.6.1, from 2016, still supported them. When Avisynth+ arrived it brought plenty new things like high bit depth planar support (before we only had stacked and interleaved) and it was a major upgrade from the classic codebase. Support for Windows 98SE and Windows 2000 was dropped and the minimum requirement was bumped up to Windows XP which is still the case right now. :)

[TR-9970X]

it's just a term to say that they were compiled using v141_xp which is the Microsoft compiler, MSVC. They run on all versions of Windows from Windows XP all the way up to Windows 11. You're gonna be fine. ;)

As a bit of history, Avisynth kept supporting Windows 98SE and Windows 2000 since its Inception in April 2000 without dropping it. The last Avisynth version, 2.6.1, from 2016, still supported them. When Avisynth+ arrived it brought plenty new things like high bit depth planar support (before we only had stacked and interleaved) and it was a major upgrade from the classic codebase. Support for Windows 98SE and Windows 2000 was dropped and the minimum requirement was bumped up to Windows XP which is still the case right now. :)

Thanks for that, but to be pedantic, would the Intel build be suitable for Ryzen's, as it seems they might be optimised for Intel CPU's ?

[FranceBB]

Thanks for that, but to be pedantic, would the Intel build be suitable for Ryzen's, as it seems they might be optimised for Intel CPU's ?

The intel builds are created with ICC, the Intel compiler that used to be shipped with Intel Parallel Studio. They're gonna work on the Ryzen as well, but they were originally optimized with Intel Xeon in mind. As for the speed compared to MSVC, they're probably faster even if they're being used on an AMD CPU, but I don't know for sure. You should really try and test yourself with AVSMeter. I only really have an Intel i7 at home and several Intel Xeon at work, so I can't test it for you. :(

Full disclosure: I've been an AMD fanboy since birth, I owned plenty of CPUs the likes of AMD Athlon 1600, AMD Athlon 3200, AMD Athlon 3800, those were great monocore CPUs. Unfortunately, when multi core were introduced, I had one heartbreak after another, starting with the AMD Athlon 64 X2 but the one that made me draw the line was when my AMD Phoenom II X6 1100T, a 6c/6th at 3.3GHz (with boost to 3.7GHz) was being beaten by 4c/8th Intel i7 and was struggling even against 4c/4th Intel i5 of the time. Three years later, in 2013, I moved to Intel and I've never looked back.

[pinterf]

Thanks for that, but to be pedantic, would the Intel build be suitable for Ryzen's, as it seems they might be optimised for Intel CPU's ?
Suitable.

The optimizations applied in our builds are generic "optimize for speed" settings, making them suitable for any processor architecture. It's a one-size-fits-all approach. Even Intel processor generations vary, so if someone wants a finely tuned version for their specific processor type, they would need to do it themselves.

Most of the internal optimizations in Avisynth are handcrafted for SSE2, SSSE3, SSE4.1, AVX2, etc. While not all are implemented, SSE2 and AVX2 are generally covered. Only a few areas have versions written solely in C. Compilers can further optimize our already SIMD-optimized versions, which is where different compilers like Intel C++ Compiler, LLVM, GCC, and MSVC can excel or fall short.

In general, they all do excellent jobs.

[TR-9970X]

The intel builds are created with ICC, the Intel compiler that used to be shipped with Intel Parallel Studio. They're gonna work on the Ryzen as well, but they were originally optimized with Intel Xeon in mind. As for the speed compared to MSVC, they're probably faster even if they're being used on an AMD CPU, but I don't know for sure. You should really try and test yourself with AVSMeter. I only really have an Intel i7 at home and several Intel Xeon at work, so I can't test it for you. :(

Full disclosure: I've been an AMD fanboy since birth, I owned plenty of CPUs the likes of AMD Athlon 1600, AMD Athlon 3200, AMD Athlon 3800, those were great monocore CPUs. Unfortunately, when multi core were introduced, I had one heartbreak after another, starting with the AMD Athlon 64 X2 but the one that made me draw the line was when my AMD Phoenom II X6 1100T, a 6c/6th at 3.3GHz (with boost to 3.7GHz) was being beaten by 4c/8th Intel i7 and was struggling even against 4c/4th Intel i5 of the time. Three years later, in 2013, I moved to Intel and I've never looked back.

Nice, thanks again.

I have a majority of Ryzen's, but I do have a 13900KF, which is only a little "slower" than my 7950X.

I recently built a 32C Thread Ripper system, but haven't really done anything with it yet.

[TR-9970X]

Suitable.

The optimizations applied in our builds are generic "optimize for speed" settings, making them suitable for any processor architecture. It's a one-size-fits-all approach. Even Intel processor generations vary, so if someone wants a finely tuned version for their specific processor type, they would need to do it themselves.

Most of the internal optimizations in Avisynth are handcrafted for SSE2, SSSE3, SSE4.1, AVX2, etc. While not all are implemented, SSE2 and AVX2 are generally covered. Only a few areas have versions written solely in C. Compilers can further optimize our already SIMD-optimized versions, which is where different compilers like Intel C++ Compiler, LLVM, GCC, and MSVC can excel or fall short.

In general, they all do excellent jobs.

:thanks:

[LeXXuz]

I just updated AVS+ from an older build, 4066 IIRC, to the latest version.

Now I get an error in of my scripts saying "There is no function named 'ConvertToDoubleWidth' ".

Would appreciate some help on how to fix this.

[pinterf]

I just updated AVS+ from an older build, 4066 IIRC, to the latest version.

Now I get an error in of my scripts saying "There is no function named 'ConvertToDoubleWidth' ".

Would appreciate some help on how to fix this.
There must be a ConvertStacked.DLL in your Program Files (x86)/Avisynth+/plugins64+ (or plugins+ on 32-bit) folder