"worker" issues

[chainikdn]

Quickly change SVP settings several times, for example move the "quality/perf" slider ---> video player will hang.

It hangs at _avsScriptClip = invokeResult.AsClip();

    [External Code] 
    avisynth_filter_64.ax!PClip::operator=(const PClip & x) Line 1131   C++
>   avisynth_filter_64.ax!AvsFilter::CAviSynthFilter::ReloadAviSynthScript(const _AMMediaType & mediaType) Line 834 C++
    avisynth_filter_64.ax!AvsFilter::CAviSynthFilter::Receive(IMediaSample * pSample) Line 299  C++
    avisynth_filter_64.ax!CTransformInputPin::Receive(IMediaSample * pSample) Line 763  C++
    [External Code]

... which means it hangs at destruction of previous clip ... which means it's locked at _sourceFrameAvailCv

_avsScriptClip is still alive after FrameHandler::EndFlush() and GetSourceFrame() still can be called.

[Nuihc88]

The above build doesn't seem to affect the issue... This is the .dll version i'm seeing the above x32 problem with: AviSynth_v3.5_r3043.zip I just copied the .dlls from a recently updated SVP 4 (which i don't normally use except for testing purposes) to (semi-)portable PotPlayer installations for quick speed comparisons...

I'm not quite sure whether my configuration on the x64 side is even fully functional, since i'm basically just copy-pasting stuff all over the place, however there i encountered these oddities while loading the configuration interface: The script itself was running normally, both with the above version and v3.6.1... These only show up when i try to open AVSF configuration window. I don't think i'm gonna be much help with diagnosing the x64 builds as it's not my main configuration. However, i did try changing the 'Video Renderer' and turning off the 'Built-in Video Transform Filter' to no effect and will at least try to check which version the problem was introduced in before giving up on it..... EDIT: The x64 bug seems to be present in it's current form in chainikdn's v0.7.0 build, but absent in the official v0.7.0 ; v0.6.1 shows the 'Alert' without opening the glitched window.

[chainikdn]

You're calling CreateScriptEnvironment2 with the value 7 which is avs 3.5.1+ and doesn't work with 3.5.0 installed by SVP. My build made with 6.

[Nuihc88]

You're calling CreateScriptEnvironment2 with the value 7 which is avs 3.5.1+ and doesn't work with 3.5.0 installed by SVP. My build made with 6.

I'm vaguely aware of interface versions 6 & 7, but have no idea how calling CreateScriptEnvironment() & CreateScriptEnvironment2() works, let alone how it relates to the bugs above. EDIT: Nevermind i get it now, i guess i'm too tired to read things right, yet also too tired to sleep...

So that just leaves the x64 config bug that seems to be affecting all AVS+ versions (that i tried). EDIT2: After taking a nap i realized that my player versions were different, so i tried updating 64bit PotPlayer and that appears to have fixed it. Still no idea as to the actual cause behind it, but at least anyone reading this will know what to try if they encounter it.

PS. Ran some performance tests which would suggest that on average, under high load scenarios, 'OutputThreads' registry value of '2' gives slightly better performance than 1, 3 or 4 assuming the system is otherwise idle. In MadVR: value 1 gives more dropped frames; while 3 & 4 give more presentation glitches. I can't detect any meaningful difference between 'InputThreads' values <5.

[CrendKing]

OK. That's a lot of information. Can you summarize the situation? Do I need to lower interface version to 6 or OK with 7? Any remaining problem with x64?

'OutputThreads' registry value of '2' gives slightly better performance than 1, 3 or 4

The default "no value" (meaning 1 thread) should be sufficient for most modern (read "less than 5 years old") computer to handle most videos (read "less than 4K 60fps"). 2 is usually overkill. However, making it to 3 or 4 should not degrade the performance in any noticeable degrade. The cost of context switch and synchronization should be negligible.

value 1 gives more dropped frames

Dropping frame suggests misconfiguration. Do you experience the same in avsf 0.6.1, because that is also single threaded.

3 & 4 give more presentation glitches

Please take a look at CPU and GPU usage. Number of output threads should not affect presentation glitches, unless your computer is under heavy load.

difference between 'InputThreads' values

There is no such thing as "InputThreads". It is hard coded as 1 thread. chainikdn suggested this earlier in the thread and I agreed:

I'd say that input threads are not necessary at all, single threaded input in the main thread is ok.

In the use case of the filter, input thread doesn't do much heavy lifting, whereas output thread needs to scale.

[Nuihc88]

OK. That's a lot of information. Can you summarize the situation? Do I need to lower interface version to 6 or OK with 7? Any remaining problem with x64?

I don't think the interface version will be an issue as there is hardly any reason to use version 6 anymore. Haven't been able to reproduce the x64 issue after updating PotPlayer; i would just assume it was a player issue if it wasn't so inconsistent among AviSynth Filter versions.

The default "no value" (meaning 1 thread) should be sufficient for most modern (read "less than 5 years old") computer to handle most videos (read "less than 4K 60fps"). 2 is usually overkill. However, making it to 3 or 4 should not degrade the performance in any noticeable degrade. The cost of context switch and synchronization should be negligible.

I was purposefully over-stressing my configuration for testing purposes. My computer is almost 15 years old and it's memory bandwidth is seriously bottlenecking the GPU, partly due to a BIOS patch to enable a AM2+ socket Phenom II x4 940be CPU it wasn't designed for. The test scenario used was FullHD HDR HEVC framedoubling on a high motion scene. In other words, i think the LAV Video Decoder & SVPflow are having to compete for CPU access to fill their buffers. Adding an extra thread seems to smooth out the buffering, but i guess adding even more just increases delays on an already overwhelmed system.

Dropping frame suggests misconfiguration. Do you experience the same in avsf 0.6.1, because that is also single threaded.

Please take a look at CPU and GPU usage. Number of output threads should not affect presentation glitches, unless your computer is under heavy load.

It's really no problem in regular use, i'm just letting you know that my test results suggest that '2' could be a better default as it doesn't seem to degrade performance even on an ancient system.

There is no such thing as "InputThreads". It is hard coded as 1 thread. chainikdn suggested this earlier in the thread and I agreed:

I'd say that input threads are not necessary at all, single threaded input in the main thread is ok.

In the use case of the filter, input thread doesn't do much heavy lifting, whereas output thread needs to scale.

I saw it in the source code and decided to give it a try. Good to know it's disabled.

[CrendKing]

I'm closing this issue since I can't reproduce the freeze on the Apex video and no one is posting new information or issue, and this ticket has been too long to track. If you have new issue, please open separate ticket.