AviSynth+ thread Vol.2 [Archive] - Page 5

Boulder

23rd May 2020, 19:51

How much memory is required for all those 24 threads? Mvtools working area can be quite memory hungry for example, multiply it by 24 (filters are mostly MT_MULTI_INSTANCE mode) + UHD source. What is avsmeter telling? If it is near 4GB then use SetMemoryMax with e.g. 8000 or use a value which is probably above the memory need by a safe margin.
Pinterf, I thank you :) It was the default cache, which was not enough.. I raised it to 10000 and CPU usage jumped substantially to 90-100% with much less GPU usage than earlier.

I owe you one good pörkölt :)

pinterf

23rd May 2020, 19:54

Could you pls do a test: keep the original default 4GB memory and set the other cache mode, I wrote about above. What are your numbers now?

pinterf

23rd May 2020, 20:28

This is a follow-up to this post:
https://forum.doom9.org/showthread.php?p=1912913#post1912913

and I do agree with FranceBB on his conclusion.

My issues occur under Win7-64 on a Core i5 CPU with 8GB of RAM.

In any case I feel that AVS+ 3.6 is not ready for prime time yet. Please implement a more thorough quality control before publishing "stable" builds which turn out to be not that stable at all.

Cheers
manolito
Out of couriosity what happens when you remove _all_ CPP2.5 plugins then put them back one by one, which is the culprit?

Secondly
You can agree with FranceBB but you don't know what happened with his environment, nor do we know, but we'll solve it, maybe it was a mis-compiled version as I have written my example.

We can solve his problem with a much larger possibility that issues like why does not work properly and old tool which was tested and used when probably not even Avisynth 2.6 was final-released with plugins which I have to chase all around then finally download from Internet-wayback machine.

Boulder

23rd May 2020, 21:55

BTW your script is using isb=false for both forward and backward vectors, which seems to be wrong.
Gah, a silly copy-paste mistake by me there in the example :)

Could you pls do a test: keep the original default 4GB memory and set the other cache mode, I wrote about above. What are your numbers now?

The default took about 5100 MB, SetCacheMode(1) went to ~4700 when the first frames of actual content (first 50 frames or so were just black) were being processed.

With max at 10000, the usage is almost 9300 MB with SetCacheMode(1).

I haven't done any real-life tests with encoding yet so I don't know what the optimal prefetch value is.

tormento

24th May 2020, 08:13

A minor note: vector scaling is no longer necessary with newer mvtools, MDegraining a 16 bit clip will accept vectors made from arbitrary bit depth source. This is why you can MDegrain even a 32 bit float clip.
Out of curiosity, I am bit confused about how the HBD plugins treat the images.

AFAIK the most used bit depths nowadays are 8 and 10 (12 on some specialized streams only).

How does it work when you set HBD or a plugin receives a HBD?

Doest it switch to 16 bits (or more) regardless of true bit depth or does it work with the same bit depth of the source?

Because if it goes straight to 16 bit to work on a 10 bit stream, it seems to me really a waste of power and it would need a dedicated algorithm to process 10 bit only, as they are the second most common after 8, and get faster.

tormento

24th May 2020, 08:20

1.) You can have now multiple Prefetchers (new in 3.6)
What is a good ratio to determine the number of frames to be prefetched? Now I am using Prefetch(6) because I am GPU memory bound. What effect has the frame parameter? Is it a sort of caching or what? Would set Prefetch (1,6) has the same effects on speed? :confused:

pinterf

24th May 2020, 08:32

For internal calculations the bits used are usually more than that, 16-32 bits (15-16 bit is used even for most 8 bit filters) Only very simple filters, where no precise calculation happens, keep the bit depth internally (e.g. mt_binarize). Imagine, when you multiply two 8 bit data you'll have 16 bit result.
Processing 10 bits can be faster that 16 bits however, in mvtools I had differently optimized - quicker - SAD routines for 10 bits because summing up sixteen 10 bit numbers still fit in a 16bit register, while summing up 16bit numbers require 32 bit processing already.
But such optimization specialization is tricky, increases internal complexity and in general it is the very last step when developer have inifinite free time and cannot do other meaningful stuff :)
Plus: as it requires extra programming resources it has to be done when it has real benefits and the task to optimize is the bottleneck in a process.

tormento

24th May 2020, 08:36

as it requires extra programming resources it has to be done when it has real benefits and the task to optimize is the bottleneck in a process.
I asked because I was planning to always use SMDegrain in HBD precision and then go back to 8 or 10 bit but sometimes the overhead is just too much to be of any use. Is there any optimization I could apply?

pinterf

24th May 2020, 08:38

What is a good ratio to determine the number of frames to be prefetched? Now I am using Prefetch(6) because I am GPU memory bound. What effect has the frame parameter? Is it a sort of caching or what? Would set Prefetch (1,6) has the same effects on speed? :confused:
This parameter exists for your individual fine tuning and experiments. Probably when you find a number for a specific script or filter, you have to re-test it for another one. When you don't know if you need it, do not specify it.

But since we do not have knowledge base on the real value of this parameter, always share your findings.

tormento

24th May 2020, 08:40

But since we do not have knowledge base on the real value of this parameter, always share your findings.
Can I have a wider explanation of what happens when I prefetch frames instead of threads? I have read 3.6.0 release notes but it did not clarify things a lot to me.

pinterf

24th May 2020, 08:40

I asked because I was planning to always use SMDegrain in HBD precision and then go back to 8 or 10 bit but sometimes the overhead is just too much to be of any use. Is there any optimization I could apply?
Reduce your input to 320x200 :)

tormento

24th May 2020, 08:42

Reduce your input to 320x200 :)
I deeply hate you with all my heart. :D

pinterf

24th May 2020, 09:52

Can I have a wider explanation of what happens when I prefetch frames instead of threads? I have read 3.6.0 release notes but it did not clarify things a lot to me.
You are always specifying threads, then you can further specify the frame numbers to look ahead. Default value of frames is threads*2.

gispos

24th May 2020, 12:48

...Default value of frames is threads*2.
Thank you, I had already asked myself that.
Then my prefetch (4, 8) doesn't do anything for frame caching. :D

Boulder

24th May 2020, 14:54

The new cache mode has quite an impact at least in my case where I have that MVTools stuff + downscaling in linear light and debanding with neo_f3kdb. I tested with AVSMeter with an insanely high SetMemoryMax(16384) to make sure cache size will not restrict anything. The default cache mode ran at 9.495 fps and SetCacheMode(1) at 12.36 fps. Memory usage was almost the same, both around 11000 MB.

I'll continue testing to see if lowering the prefetch value from 24 makes any difference.

Boulder

24th May 2020, 16:41

Some tests of x265 encodes with different prefetch values and the abovementioned script structure:

threads=24, frames default 2.53 fps
threads=24, frames 12 2.57 fps
threads=24, frames 24 2.51 fps
threads=24, frames 8 2.56 fps
threads=24, frames 10 2.57 fps
threads=24, frames 16 2.55 fps
threads=22, frames 16 2.55 fps
threads=20, frames 12 2.58 fps
threads=16, frames 12 2.57 fps
threads=12, frames 12 2.55 fps

It's quite easy to see that most of the time is spent inside x265 instead of frameserving. At least in my case, lowering the amount of frames was slightly beneficial.

stax76

24th May 2020, 16:52

In the staxrip tracker the most active power user posted when avisynth 3.5 is installed staxrip produces errors, it's fine if avisynth is not installed because then staxrip uses the included portable version 3.6 and it's also fine if 3.6 is installed. I had to explain this, maybe some devs can give some advice, my answer:

I changed it to don't allow old versions like currently done for Visual C++ 2019, it shows:

The currently used version of is not compatible (too old).

And it doesn't allow to edit the version except editing Versions.txt directly instead of using the GUI to do it.

Ideally it should not allow defining a custom path in this case but I'm not sure it's worth the trouble writing this code.

Here is the situation:

Most tools like StaxRip.exe or avs2pipemod.exe just load AviSynth with code like this:

LoadLibrary("AviSynth.dll")

This is however not a full path and what now is happening is the OS will search this DLL, for that it uses a strict order, first it will search it in the startup folder so next to staxrip.exe or next to avs2pipemod.exe or whatever tool is loading the avs file. Next it searches in the system folder, which is where avisynth is installed. I have tried to create soft links for avisynth.dll next to staxrip.exe but this did not work for unknown reason and then I gave up.

One issue was if avisynth is not installed then ffmpeg does not work because it does not use default DLL loading which searches in the path env var which staxrip sets. To fix that a soft link is working, qyot27 and stainless did help me to make this work.

In staxrip I could use a full path to load avisynth.dll and avs2pipemod has an option for that too, for the other tools an option could be requested, I can image some authors like rigaya would help, for some tools a mod could be created but for some tools it would be very difficult like ffmpeg.

Maybe it's not worth the trouble and just leave it as is, it's many avs tools like 10.

For vapoursynth it's working that a user can decide via setting if portable or installed version should be used, it can be defined in the settings dialog of staxrip and it worked for all tools I have tested, staxrip, ffmpeg, vspipe, mpv.net, only problem was mpc-be, not particular important since mpv.net is the primary player in staxrip and it supports portable mode for avisynth and vapoursynth. I have reported it and volt has a new avs vpy source filter in development which is awesome. Maybe somebody can try nvenc and qsvenc for which I don't have hardware or driver.

FranceBB

24th May 2020, 17:00

Test this one (32-bit only):
http://www.mediafire.com/file/we5m234xrxbxjd6/AviSynth%252B_3.6.0_i686-xp-nosimd.7z/file

Still access violation.

This is weird, - I'm using cmakegui, checked the XP support checkbox, generated the solution file and it listed that v141_xp toolset is forced, OK.
Went into VS2019 GUI, opened project properties and there was no sign of XP toolset settings, only the /Zc:threadSafeInit- option. It still listed the non-XP v142 toolset.
EDIT: When I pressed the "Generate" once again then it created the proper xp targeted solution

I see! Would you mind uploading the newly created build?
Or is it the AviSynth+_3.6.0_i686-xp-nosimd uploaded by qyot27?

You can agree with FranceBB but you don't know what happened with his environment, nor do we know, but we'll solve it, maybe it was a mis-compiled version as I have written my example.

We can solve his problem with a much larger possibility

Well I'm not sure what happened with my environment either, but thank you for being confident that you can solve the issue. I really appreciate that. :)

manolito

24th May 2020, 19:27

Out of couriosity what happens when you remove _all_ CPP2.5 plugins then put them back one by one, which is the culprit?

Thanks for this suggestion, it helped me to narrow it down to the latest Manao MaskTools2 version 2.0a48. I use mt_masktools-26.dll in my AVS plugins folder, but for some reason AVSMeter recognized it as an AVS 2.5 plugin. Removing this DLL and replacing it with a current PinterF version solved the LAV Filters problem, but this is something I can't and do not want to do. (Replacing the DLL with the TP7 version 2.0 b1 made no difference.)

The problem is that several older AVSI scripts in my plugins folder rely on MaskTools2, and just replacing Maskools with the latest High Bit Depth versions will not work. A while ago I asked Real.Finder explicitly if I could use his latest Srestore version with an older version of MaskTools2, and his answer was NO. I guess the same is true for QTGMC or LFSMod or FineSharp. I do not need and do not want Hi Bit Depth or Hi Color, so I will stay away from such plugins. I installed AVS+ solely in the hope for better speed from multitasking, everything else has no relevance for me.

And if AVS+ 3.6 now gives me issues using older AVS 2.5 plugins then I will stop using it.

Cheers
manolito

pinterf

25th May 2020, 05:31

Thanks for this suggestion, it helped me to narrow it down to the latest Manao MaskTools2 version 2.0a48. I use mt_masktools-26.dll in my AVS plugins folder, but for some reason AVSMeter recognized it as an AVS 2.5 plugin. Cheers
manolito
Hi,
I checked it, and AvsMeter recognizes mt_masktools-2.6.dll a CPP2.5 DLL, probably because it is using the non-final AVS 2.6 header file, which has AVISYNTH_INTERFACE_VERSION = 5
instead of 6. So this is a pre-2.6 DLL.

EDIT: even if it used a pre-avs 2.6 DLL, the plugin doesn't have AvisynthPluginInit3, only AvisynthPluginInit2
EDIT: test-test-test Retro masktools 2.0.48 as an Avisynth 2.6 dll. https://drive.google.com/open?id=1xPzwTtIHOwvnmNAlJvbT0JkffmEUQA67
Do _NOT_ mix it with masktools2!

pinterf

25th May 2020, 11:52

Still access violation.
I see! Would you mind uploading the newly created build?
Or is it the AviSynth+_3.6.0_i686-xp-nosimd uploaded by qyot27?

No, I just started to build one for XP then I made a sanitiy check before the actual build and was a bit surprised that this build would not be for XP contrary to the choice in cmake gui.

pinterf

25th May 2020, 14:07

Did you know?
New Format function in 3.6
http://avisynth.nl/index.php/Internal_functions#String_functions
and scroll down a bit

pinterf

25th May 2020, 14:25

Did you know (#2)?
New "SetMaxCPU" function in 3.6
http://avisynth.nl/index.php/Internal_functions#Global_Options

pinterf

25th May 2020, 14:46

Did you know (#3)?
Escaped string literals (from Nekopanda's fork)
http://avisynth.nl/index.php/The_full_AviSynth_grammar#Literals

manolito

25th May 2020, 15:53

EDIT: test-test-test Retro masktools 2.0.48 as an Avisynth 2.6 dll. https://drive.google.com/open?id=1xPzwTtIHOwvnmNAlJvbT0JkffmEUQA67
Do _NOT_ mix it with masktools2!

Thanks for this test build...

It does work on my Win7 computer with a CORE i5, but on my old XP machine (no SSE2) I get an access violation.

Anyways, it does not make much of a difference. The vast majority of my plugins are CPP 2.5 plugins, and I do want to keep using them.

The StaxRip version I use interfaces with AviSynth through the VFW interface, and this seems to cause my issues with AVS+ 3.6. Other host applications for AviSynth (like AVStoDVD) do not have these problems with LAV Filters not being released from memory, it is only StaxRip. And after more tests I found out that a lot of the CPP 2.5 plugins trigger this issue.

So some of the changes between AVS+ 3.5.1 and 3.6 must have broken the VFW interface with the effect that old 2.5 plugins no longer work correctly.

Now you might want to get rid of the VFW interface altogether in the near future, or you might want to drop support for 2.5 plugins, I don't know. Since I am unwilling to give up my StaxRip version or replace my 2.5 plugins with newer 2.6 versions, I only can decide to stick with AVS+ 3.5.1. All the new features are nothing I am interested in, so I do not miss out on anything.

Cheers
manolito

pinterf

25th May 2020, 15:57

On the output side, VfW interface is used e.g. for VirtualDub2, I had no problems on that side however.

pinterf

25th May 2020, 16:08

Thanks for this test build...

It does work on my Win7 computer with a CORE i5, but on my old XP machine (no SSE2) I get an access violation.

It's important because it was created with XP settings on the DLL side.

This masktools project consists of two parts, the other - non DLL part - was not flagged with this XP special option.
Test 2: (ThreadSafeInit- flag set to all modules)
https://drive.google.com/open?id=12dmNGCuxy-QD2bKh2XqZhI3CquBDXKGD

manolito

25th May 2020, 17:22

Alright, the new test build now runs on my XP machine without any problems...

For the VfW interface I had not even thougt about VDub, thanks for mentioning it.

And yes, I can easily reproduce the issue under VDub. I use an older version by FCCHandler with integrated MPEG2 support (VDub2 does nothing for me), but this should not make a difference.

This is the source script:
movie = "d:\test.mp4"
a = DirectShowSource(movie, video = false)
v = DSS2(movie)
AudioDub(v, a)
Crop(0,0,-Width % 4,-Height % 4)
FineSharp()

DSS2Mod plus the latest stable LAV Filters installed.

The FineSharp script relies on MT_MaskTools-26 and RemoveGrain and Repair. All of them are CPP 2.5 plugins.

If you comment out the FineSharp call in the above script and open it with VDub, everything works fine. But if you activate FineSharp, things change. Opening the script just once is no problem, but if you reopen the script you will see that the previous LAV Filter instances stay in memory. Reopen the script a couple of times, and you will see your taskbar populated with many LAV instances (if you have enabled the tray icons in the LAV settings).

So I believe that it really is the VfW interface which is broken in AVS+ 3.6. Are we getting somewhere?

jpsdr

25th May 2020, 18:12

pinterf

25th May 2020, 18:19

I assume SetMaxCPU will have effect on this kind of code:

SSE2_Enable=((env->GetCPUFlags()&CPUF_SSE2)!=0);
AVX_Enable=((env->GetCPUFlags()&CPUF_AVX)!=0);
AVX2_Enable=((env->GetCPUFlags()&CPUF_AVX2)!=0);

It's working for the code on the constructor ?
Interesting for debuging.

BTW, there is still no possibility to know the prefecth value used in the script within the Create function or the constructor ?
For experiments check env->GetEnvProperty(prop_id), which function is now is part of IScriptEnvironment, their constant are also in avisynth.h. Don't know when and what it returns, but you can even ask it in every GetFrame. And do your thread count adjustment on-the-fly?

jpsdr

26th May 2020, 11:58

And do your thread count adjustment on-the-fly?
For my needs... Not...
It's like... wanting to change the tires of a car while driving...

I need the information when i create the threapools
if (!poolInterface->CreatePool(prefetch)) env->ThrowError("...") in the Create function.
Then i create for one (or more) pool the number of threads (in each pool) in the constructor (with each step a check to be sure everything went fine), and in the GetFrame the creation part is allready done, everything is ready to use, and used.

Anyway, it's not critical, as the parameter can be set.

real.finder

26th May 2020, 14:02

the output of GeneralConvolution seems different from AviSynth 2.6, is it bug?

using

ConvertTorgb32
GeneralConvolution(Matrix="-1 2 -1 2 0 2 -1 2 -1")

vcmohan

26th May 2020, 14:13

And a list about changes that affect future plugins.
Both serious and not so serious plugin writers have to keep in mind............................................

Inheritance is broken if a filter does not behave in a frame-property friendly way. There is not problem when a plugin is using MakeWriteable. But when using NewVideoFrame which accepts only a format input (VideoInfo) the chain is broken. There is no frame property source for this empty frame. Avisynth core cannot guess it. But now we have a new IScriptEnvironment function "NewVideoFrameP" with the option of specifying the property source which will be copied to the newly created frame as well..
After a long time I am going through this thread and got alarmed. In the initial years of Avisynth 2.5 plugin creators were advised not to use MakeWritable function but use NewVideoFrame(vi) and copy the input frame. I have been using that advice meticulously since then and modified my old sources.
Now it appears MakeWritable may be the way to go. Also it appears NewVideoFrame(vi) will break.
Do I need to alter all my avisynth+ plugins with this new environment? True when using IscriptEnvironment2 we were warned that it may change. But for keeping thread safety getting buffers from avisynth became possible and convenient.
I request to please advise me on these aspects.

real.finder

26th May 2020, 14:31

hi vcmohan
since you about update your plugins, can you make your plugins look for libfftw3f-3.dll first, then fftw3.dll like https://github.com/pinterf/fft3dfilter/blob/8c47e8d371afc7d6f9dce08ecb3443761a1cea00/fft3dfilter/FFT3DFilter.cpp#L711 ?

FranceBB

26th May 2020, 19:56

No, I just started to build one for XP then I made a sanitiy check before the actual build and was a bit surprised that this build would not be for XP contrary to the choice in cmake gui.

Ok so the build that you generated, although it was supposed to be for XP when you selected it with CMake, but it wasn't.
By the way, I connected my GitHub account and selected the project on my computer and when I have time I'll take a look at it and I'll try to make a /Zc:threadSafeInit debug x86 build to see whether it works or not, however I'm not really familiar with CMake... Image (https://i.imgur.com/7za3JSk.png)
If you or someone else has time to make a /Zc:threadSafeInit x86 debug test build in the meantime, I'll test it.

pinterf

26th May 2020, 20:42

Ok so the build that you generated, although it was supposed to be for XP when you selected it with CMake, but it wasn't.
By the way, I connected my GitHub account and selected the project on my computer and when I have time I'll take a look at it and I'll try to make a /Zc:threadSafeInit debug x86 build to see whether it works or not, however I'm not really familiar with CMake... Image (https://i.imgur.com/7za3JSk.png)
If you or someone else has time to make a /Zc:threadSafeInit x86 debug test build in the meantime, I'll test it.
With minus at the end.
/Zc:threadSafeInit-
Sorry, I had zero time, need a few days even for this simple task.

mastrboy

27th May 2020, 12:08

Is there a similar function to Histogram("luma") that works with > 8 bit content in Avisynth+ 3.6?

pinterf

27th May 2020, 16:05

Dear volunteers, please test this version with as much CPP-2.5 plugins as you can (including those which were crashing with 3.6)
Avisynth+ 3.6.1-20200527 test (https://drive.google.com/file/d/1xDjqN54__PJRKc05l-ntmX8h95qqaJFb/view?usp=sharing)

Files only, *XP-compatible version, 32 bit version runs on SSE
*cannot guarantee until you are reporting that is really works.

Features: a bit (much) more friendly to Avisynth 2.5 style plugins

- AvisynthPluginInit2 passes a separate ScriptEnvironment for CPP2.5 plugins, so Avisynth+ can catch their AddFunction and Invoke methods
- since Avs2.5-ness is registered during plugin loading and AddFunction, calling such plugins from Avisynth+ core can happen in a compatible way without memory leaks.

This results in stopping memory leak (on e.g. "last" clip would not freed up on destroying ScriptEnvironment) resulted in increasing memory consumption when doing consecutive script reloads in VirtualDub or probably in other editors.

pinterf

27th May 2020, 16:24

After a long time I am going through this thread and got alarmed. In the initial years of Avisynth 2.5 plugin creators were advised not to use MakeWritable function but use NewVideoFrame(vi) and copy the input frame. I have been using that advice meticulously since then and modified my old sources.
Now it appears MakeWritable may be the way to go. Also it appears NewVideoFrame(vi) will break.
Do I need to alter all my avisynth+ plugins with this new environment? True when using IscriptEnvironment2 we were warned that it may change. But for keeping thread safety getting buffers from avisynth became possible and convenient.
I request to please advise me on these aspects.

In Interface V8 the buffer pool has been moved to the standard IScriptEnvironment.

As for MakeWritable, I don't know why it was on the blacklist.

You can use NewVideoFrame in the future, it will take a long time until plugins are starting to use frame properties and the rules and conventions are defined and handled properly. All we have now that you can define, read and write frame properties.
You can tell on creating a new empty frame which previous frame you want to be the parent of the frame properties.
MakeWritable will do this copy instead of you automatically.

This was my transition in mvtools to apply proper passing of those theoretical frame properties:
https://github.com/pinterf/mvtools/commit/6537322da866392d82cce226160a3bfbb318a8f8
You can see there different techniques:
- no source given at all (mask),
- using NewVideoFrameP passing the source of fp immediately
- using NewVideoFrame, then set fp's later by copyFrameProps.

Plus it is done adaptively, only when filter detects a V8 interface.

manolito

27th May 2020, 16:53

pinterf

27th May 2020, 16:56

Thanks for the test build, but Google won't let me download it without logging in. You can call me a bit paranoid, but I refuse to open accounts with Google, Microsoft and other collectors of personal data.

So can you or someone else please upload the file somewhere else?

Thanks
manolito
I didn't know that. Sad, because the other sites which are frequently used here are much worse with their ads and malicious redirects.
Edit: changed the link above, please try this one https://drive.google.com/file/d/1xDjqN54__PJRKc05l-ntmX8h95qqaJFb/view?usp=sharing
They have changed the default behaviour.

ChaosKing

27th May 2020, 17:00

pinterf

27th May 2020, 17:01

Works here without login. I had a similar issue once with one drive links. Try in private tab.
Yep, I modified, I have edited my post

tormento

27th May 2020, 17:14

Files only, *XP-compatible version, 32 bit version runs on SSE
Does it change something for non xp?

Inside I can see xp-ish directories only.

real.finder

27th May 2020, 17:20

the output of GeneralConvolution seems different from AviSynth 2.6, is it bug?

using

ConvertTorgb32
GeneralConvolution(Matrix="-1 2 -1 2 0 2 -1 2 -1")

with avs+ it look more blur

manolito

27th May 2020, 17:22

Edit: changed the link above, please try this one https://drive.google.com/file/d/1xDjqN54__PJRKc05l-ntmX8h95qqaJFb/view?usp=sharing

Yes, this link works without logging in, thanks...

manolito

27th May 2020, 17:45

Yes, whatever you changed in this version, it did solve all the previous problems... :D:D

Tested with the old StaxRip 32-bit version (which uses the VfW interface) and with VDub. No more memory leaks, the LAV Filter instances are always correctly released from memory when the AVS script is closed.

As tormento already asked, will you apply these changes also to the Non-XP versions? I found these issues under Win7-64. Or do the XP versions which you uploaded check the CPU capabilities and use them if present?

Whatever, I am really glad that I now can keep using my old CPP 2.5 plugins without issues under AVS+.

Thanks again
manolito

manolito

27th May 2020, 18:28

Or do the XP versions which you uploaded check the CPU capabilities and use them if present?

I did a short speed benchmark comparing the x86-XP files from the test version to the x86 standard files from the previous AVS+ version 3.5.1.

I used a HD AVC clip and converted it to an SD clip with X264. Prefetch set to 4.

Result: (taken at 10% into the encode)
3.5.1 : 43.98 fps
3.6 test : 44.05 fps

Looks like the XP compatible XP x86 version does use CPU extensions higher than SSE if the CPU supports it. I see no reason to not use the XP compatible files under Win7 or higher.