AvsPmod (Windows_x86) mod

[FranceBB]

Originally Posted by StainlessS

More ass kissing required. Use your tongue, he like that

Chelsea is blue and Gispos is a dude, we don't do that here. :P

Originally Posted by gispos

I am still waiting for a 'EDIT: Arg. Not so fast.'

Glad that it works.

eheheheh not this time. This time it works for real.

[Emulgator]

2.7.4.7_(Windows_x86-32)_audio_XP: So geil !
2.7.4.7_(Windows_x86-32)_2_audio_XP: the same.

Everything works, scrub, audio, prefetch, normal speed, max.speed.
We are getting closer to Vegas, I feel ;-))

The odd .mp4 clip max unprefetched 260fps.
The proper DV-PAL avi prefetched (2,2) max 110fps, Prefetch 4,10 works too now ! the same 110fps @ 85% CPU playing from 7200rpm SSD.
Now Nominal speed fps (25fps). Reported fps starting with 23,xyz, approaching and crossing 25fps after some 10 frames, nothing to worry about.
QTGMC with Prefetch (4,10): 6,4fps @ 88..98% CPU.

A dream, not a single stall.
Deep respect, gispos !

[FranceBB]

Thanks!
Not everyone shows love for XP, but it's nice when people do.

[gispos]

Sorry, the 2.7.4.7 contained a bug that affected the menu bar. see Bugfix 2.7.4.8

AvsPmod 2.7.4.8

* Audio playback is now WinXP 32bit compatible
* Fast VUV > RGB conversion (DecodeYUVtoRGB.dll, DTL Doom9) now also for 32 bit available.
* Added: Options > Font & Colors > Mis 2 > 'Video controls frame text field bold', use bold font style or not.
* Added: avisynth 'DelayAudio' as a slider to filterdb.dat
* Minor bugfix audio: In the playback, an attempt was always made to create the audio, even if the video did not contain any audio.
* Bugfix 2.7.4.8: When clicking in the "Video" menu bar, an error is displayed if the video (clip) is not initialized. Sorry.

Edit:
What I noticed about the audio playback with LWLibavAudioSource:
You should always set av_sync to true, otherwise asynchronous playback can occur with some videos.
AvsPmod and VirtualDub2 for example plays them sometimes synchronous and sometimes not synchronous if av_sync is not set.

[gispos]

AvsPmod 2.7.4.9 Pre-Release

Playback thread revised again:
Replacing old proven routines has increased speed and response, I hope this is not at the expense of robustness.
Instead of an entry into the main thread a lock is used to avoid a collision between main and playthread.

On my system for 1920 x 1080 video without filter:
without 'Prefetch display conversion' from 80 fps to 100 fps
with 'Prefetch display conversion' from 102 fps to 148 fps
with 'Fast YUV420 display conversion' from 100 to 130 fps

With light filtering only 1 to 3 fps increase is left. But this can make the difference to a clean or not clean audio playback.
I am curious if it works with WinXP 32bit.

https://drive.google.com/drive/folde...usp=drive_link

[FranceBB]

Originally Posted by gispos

I am curious if it works with WinXP 32bit.

Source clip is an MPEG-2 SD in yv12 50p, playback speed set to "Normal Speed".


Playback results on Windows XP x86:

- Legacy legacy settings (video, no audio) 50fps
- Legacy settings (video, audio) 50fps
- Prefetch RGB Display Conversion (video, audio) 50fps
- Prefetch RGB Display Conversion, fast YUV420 auto reset (video, audio) 50fps
- Prefetch RGB Display Conversion, fast YUV420 display conversion using DecodeYUVtoRGB() (video, audio) - error


This is probably because DecodeYUVtoRGB() is expecting AVX2, however on Windows XP there's nothing after SSE4.2

In other words, you can make use of MMX, SSE, SSE2, SSSE3, SSE4.1, SSE4.2 but nothing else. It doesn't matter if the CPU supports them, XP won't use them.
This is an example using a simple utility called "CPU Instruction.exe" which checks the available CPU instructions from the OS:

                Supported Features
                ==================

Vendor String: GenuineIntel
Brand  String: Intel(R)Core(TM)i7-6700 CPU@2.60GHz

                Instruction Sets
                ----------------

MMX  SSE  SSE2  SSE3  SSSE3  SSE4.1  SSE4.2

                Supported Special Instructions
                ------------------------------

Conditional Moves
FXSAVE and FXSTOR
XSAVE and XSTOR for processor extended state management.
POPCNT
RDRAND
AES (Advanced Encryption Standard) Instruction Set

Please, press enter to end the application ...

if you go to the Intel web page about my CPU, you'll see that it does actually support AVX and AVX2 as well, however that's useless in XP as it will just ignore them.



In fact, manually calling

DecodeYUVtoRGB(matrix=0, threads=1, gain=74, offset=0)

leads to:



If and only if DTL wants to make it XP friendly, he should check the available instructions at runtime and use the right codepath accordingly, 'cause otherwise it would fail.
This isn't just an XP thing, there might be people with other Windows (like Win7, Win10 etc) with CPUs without AVX2 and it would fail there too.

Anyway, as far as I'm concerned, I'm totally fine with the Avisynth YUV to RGB conversion used by AVSPmod mod by default.


Ok, SD was easy, let's try something harder.

Source clip is an H.264 FULL HD in yv12 23,976p, playback speed set to "normal speed":


- Legacy legacy settings (video, no audio) 23,97fps
- Legacy settings (video, audio) 23,97fps
- Prefetch RGB Display Conversion (video, audio) 23,97fps
- Prefetch RGB Display Conversion, fast YUV420 auto reset (video, audio) 23,97fps
- Prefetch RGB Display Conversion, fast YUV420 display conversion using DecodeYUVtoRGB() (video, audio) - error


Outstanding, but let's see if we can go one step further and dare to dream with UHD.

Source clip is an H.265 UHD in 4:2:0 10bit, 23,976p, playback speed set to "normal speed":


- Legacy legacy settings (video, no audio) 13,01fps
- Legacy settings (video, audio) 12,44fps
- Prefetch RGB Display Conversion (video, audio) - error
- Prefetch RGB Display Conversion, fast YUV420 auto reset (video, audio) - error
- Prefetch RGB Display Conversion, fast YUV420 display conversion using DecodeYUVtoRGB() (video, audio) - error


Although the system has 64 GB of RAM available through PAE, being a 32bit system, each process cannot exceed 2 GB of RAM, therefore with the Prefetch RGB Display Conversion, you end up saturating 2GB and getting a malloc error.
PAE is a clever way of extending the 32bit system to 36bit so that by having an HAL in front, the system is able to handle 64 GB of RAM, but with the same catches of a 32bit one, namely that you can't really exceed the maximum allocable memory per process of a 32bit system. Using things like MPPipeline() to split functions into different processes, allows you to have as many processes as you want, thus being able to allocate 2GB per filter (i.e per process) up to 64GB of RAM (the maximum possible RAM available in a 36bit system).

[gispos]

Originally Posted by FranceBB

If and only if DTL wants to make it XP friendly, he should check the available instructions at runtime and use the right codepath accordingly, 'cause otherwise it would fail.

This isn't just an XP thing, there might be people with other Windows (like Win7, Win10 etc) with CPUs without AVX2 and it would fail there too.

I'm surprised about AVX2, because I have installed a check for the presence of AVX2. Then the menus should be turned off.
But as you write, the check on WinXP apparently does nothing because the CPU confirms AVX2 but XP can not use it and returns an error.
Then my AVX2 test is probably useless, it tests the CPU.

Originally Posted by FranceBB

Outstanding, but let's see if we can go one step further and dare to dream with UHD.

Source clip is an H.265 UHD in 4:2:0 10bit, 23,976p, playback speed set to "normal speed":

- Legacy legacy settings (video, no audio) 13,01fps
- Legacy settings (video, audio) 12,44fps
- Prefetch RGB Display Conversion (video, audio) - error
- Prefetch RGB Display Conversion, fast YUV420 auto reset (video, audio) - error
- Prefetch RGB Display Conversion, fast YUV420 display conversion using DecodeYUVtoRGB() (video, audio) - error

OK, then with a 32bit system no UHD playback possible (or just with half speed).

Originally Posted by FranceBB

PAE is a clever way of extending the 32bit system to 36bit so that by having an HAL in front, the system is able to handle 64 GB of RAM, but with the same catches of a 32bit one, namely that you can't really exceed the maximum allocable memory per process of a 32bit system. Using things like MPPipeline() to split functions into different processes, allows you to have as many processes as you want, thus being able to allocate 2GB per filter (i.e per process) up to 64GB of RAM (the maximum possible RAM available in a 36bit system).

Interesting thing

Edit:
Ever tested UHD with 'Resample Filter'? Should then at least run a little faster... I think.
Help > Resample Filter readme

Under Menu Options > 'Resample filter...' a prefetch can be added after the Spline36Resize, separated by a semicolon.
Spline36Resize;Prefetch(1)

If there are no problems with Prefetch(1) and it becomes faster, I can change the other prefetch too.

[DTL]

I currently do not know why at AVX2 CPU the targeted to AVX2 environment build of executable crash with 'illegal instruction' . As I understand operating system only route thread data to CPU core and not detect any instructions used. The only idea is to make SSE2-targeted build with AVX2 intrinsics-based SIMD program inside. May be with AVX2-targeting the VS2019 adds some not-supported by WinXP instructions at executable loading into process space ?

As a simple check - any other AVS plugin with x86-32 compilation and forcing of AVX2 with user-param also resulted in crash at 32bit WinXP with 'illegal instruction' reason ?

This is SSE2-targeted x86_32 build - https://drive.google.com/file/d/1OjH...ew?usp=sharing . Do it also crashes with 'illegal instruction' reason at 32bit WinXP ? It must have only up to SSE2 instructions at all executable and run AVX2 part (main processing) only at CPUs with AVX2 detected.