AviSynth+ thread Vol.2

[TDS]

Originally Posted by kedautinh12

Avs+ r3682
https://gitlab.com/uvz/AviSynthPlus-Builds

Hi ked,

Not sure what's going on with this build, but I have had major decoding problems on 1 PC, but every other PC it has worked fine.

Had to revert back to r3661, on that 1 PC...strange behaviour

[kedautinh12]

Originally Posted by TDS

Hi ked,

Not sure what's going on with this build, but I have had major decoding problems on 1 PC, but every other PC it has worked fine.

Had to revert back to r3661, on that 1 PC...strange behaviour

You need report here
https://gitlab.com/uvz/AviSynthPlus-Builds/-/issues

[TDS]

Originally Posted by kedautinh12

You need report here
https://gitlab.com/uvz/AviSynthPlus-Builds/-/issues

Yeah, I can't be bothered signing up, just to do that...I found a fix, so I'm happy.

[LigH]

But others may be left sad.

[TDS]

Originally Posted by LigH

But others may be left sad.

LigH, it's interesting how you quite often find some of my posts (anywhere in the Forum), and leave a very "thought provoking" comment

In my post about r3682, I mentioned that it only had a problem on 1 PC (so far), and going back to r3661 solved the problem, however, on further thought, it maybe an AVX thing, as the Xeon 5680's don't support AVX, and therefore, I will have several PC's that r3682 will probably have the same issue.

So even though I wont be reporting this "officially", I'm sure someone will pickup on this problem, and either give an explanation, or better still, fix it (for all the older PC's out there)

[FranceBB]

Scenario: I index a file flagged as TFF but that is actually BFF.

Question: Why when I use "AssumeBFF()" the frame property value _FieldBased isn't updated and stays to 2, Top Field First?

Here the indexing says _FieldBased(2) so Top Field First


Here I use AssumeBFF() but the value of _FieldBased stays to 1, so Top Field First:



That is until I set it myself with: PropSet("_FieldBased", 1)





I generally nuke all frame properties with propclearall() but in our staff the collective decision was to make frame properties work, so I'm trying to make them work...

So... is this expected / the right behavior? And in case: why?

[LigH]

Interlaced clips are not generally field based. This property means something different: The result after "SeparateFields()" is field based because previously woven fields are now separate frames.

[FranceBB]

Originally Posted by LigH

Interlaced clips are not generally field based. This property means something different: The result after "SeparateFields()" is field based because previously woven fields are now separate frames.

I know, that was in "Avisynth terms" before frame properties were introduced.
The "FieldBased" and "FrameBased" meant something else entirely and were about what you're describing, in fact you had AssumeFrameBased() and AssumeFieldBased(), but this "_FieldBased" has nothing to do with AssumeFieldBased(), it's a frame property provided by the indexer in an FFMpeg-like style, hence the nightmare and why I generally start every script with: propclearall() to go back to the good old Avisynth.

[StvG]

Keep in mind that AssumeBFF/AssumeTFF/AssumeFieldBased... are clip properties while _FieldBased is frame property.

[FranceBB]

Gotcha.
So the old Avisynth clip properties won't update the new ffmpeg frame properties and that's the expected behaviour 'cause it's the user himself that has to populate them with propset (), I see...
I guess I'll shy away from frame properties once again

[qyot27]

Okay, so after so many months of putting this off, I have some performance comparisons between different CPU architectures.

Performance benchmarks for AviSynth+ on PowerPC and ARM (Apple Silicon)

The test benches are:

• Power Mac G5 Quad, 8GB of DDR2 SDRAM, 7200rpm hard drive, Mac OS X 10.5 "Leopard"
• Power Mac G5 Quad, 8GB of DDR2 SDRAM, SSD in USB/FW enclosure, booted over USB 2.0, Debian (Ports) sid ppc64
• M1 Mac Mini, 8GB LPDDR4X Unified memory, Internal SSD, macOS 12 "Monterey"
• (Control system) Intel Core i5-9400, 64GB DDR4 SDRAM, NVMe M.2 SSD, Ubuntu 22.04

There currently are no SIMD optimizations for AltiVec (PowerPC), or NEON (ARM), so those architectures are essentially at SetMaxCPU("none") anyway. There's also some difference in the compilers used: the M1 Mac Mini uses the default AppleClang, the G5 in OS X uses GCC 7, while the G5 in Debian and the Core i5 both used GCC 12. And because of the difference in architectures, the Version() output does differ slightly in horizontal resolution.

Single-thread Script:
Version(5000).ConvertToYUV420()

Multi-thread script:
SetFilterMTMode("DEFAULT_MT_MODE", MT_NICE_FILTER)
Version(5000).ConvertToYUV420()
Prefetch(x)

Testing:
avs2yuv test.avs -o /dev/null

Build types:

• Default build, equivalent to no outstanding optimzations (GCC -O0, in effect)
• -O3, which is the highest(?) level of optimization GCC provides in a single preset and includes tree vectorization

+---------------------+---------------+-----------------+-------------+---------------------------------+--------------+
|                     | G5 Quad, OS X | G5 Quad, Debian | M1 Mac Mini | Core i5-9400 (SetMaxCPU = none) | Core i5-9400 |
+---------------------+---------------+-----------------+-------------+---------------------------------+--------------+
| Single thread       | 66.98 fps     | 40.02 fps       | 477.51 fps  | 353.41 fps                      | 840.73 fps   |
+---------------------+---------------+-----------------+-------------+---------------------------------+--------------+
| Single thread, -O3  | 260.32 fps    | 319.96 fps      | 2285.78 fps | 1373.73 fps                     | 7110.95 fps  |
+---------------------+---------------+-----------------+-------------+---------------------------------+--------------+
| Multi-thread=4      | 172.41 fps    | 150.31 fps      | 1744.24 fps | 1387.84 fps                     | 3343.81 fps  |
+---------------------+---------------+-----------------+-------------+---------------------------------+--------------+
| Multi-thread=4, -O3 | 639.01 fps    | 1143.41 fps     | 7897.31 fps | 5505.51 fps                     | 30668.71 fps |
+---------------------+---------------+-----------------+-------------+---------------------------------+--------------+
| Multi-thread=6      | -             | -               | -           | 1990.05 fps                     | 4603.13 fps  |
+---------------------+---------------+-----------------+-------------+---------------------------------+--------------+
| Multi-thread=6, -O3 | -             | -               | -           | 6838.58 fps                     | 26036.46 fps |
+---------------------+---------------+-----------------+-------------+---------------------------------+--------------+
| Multi-thread=8      | -             | -               | 2233.69 fps | -                               | -            |
+---------------------+---------------+-----------------+-------------+---------------------------------+--------------+
| Multi-thread=8, -O3 | -             | -               | 9821.22 fps | -                               | -            |
+---------------------+---------------+-----------------+-------------+---------------------------------+--------------+

Yeah, the obvious problem above is the whole 'running Debian in an enclosure through a USB 2.0 port', rather than directly through the SATA interface inside of the Mac. I do wonder if the rather poor -O0 numbers on Debian reflect that issue somewhat, even if the -O3 runs don't.

To be fair, the Power Mac G5 Quad was released in 2005, the M1 Mac Mini in 2020, and the Core i5 machine was built in 2019 (initially with only 16GB of RAM, upgraded to 64GB at the end of 2021). The G5 also can take a maximum of 16GB, which I may eventually do, so I'm not exactly sure how that might affect later results for the same test.

The M1 is a heterogenous chip, with 4 performance cores and 4 efficiency cores. Running Prefetch(4) was both to make it comparable to the G5 being a quad core, but it also demonstrates the core topology in the M1, as I'm guessing it prefers the performance cores first and the efficiency cores second, as evidenced by the much smaller jump in performance going from 4 threads to 8 threads (not nothing, but not anywhere near like having 8 performance cores).

Version().ConvertToYUV420() is also a really, really synthetic and unscientific benchmark, and not really representative of importing actual footage and filtering it. But since Version() is often one of the first scripts someone runs, why not?

[real.finder]

I did test with 12400F in win11 with Avs+ r3682 by asd-g (G S in gitlab) https://gitlab.com/uvz/AviSynthPlus-...4/AviSynth.dll

SetMaxCPU("none")
Version(5000).ConvertToYUV420()

PS Z:\> .\avs2yuv test.avs - > NULL
Avs2YUV 0.30
Script file:    test.avs
Resolution:     384x104
Frames per sec: 24
Total frames:   5000
Progress       Frames       FPS   Elapsed    Remain
[100.0%]   4999/5000     521.71   0:00:09   0:00:00
Started:        Sat Sep 10 07:13:17 2022
Finished:       Sat Sep 10 07:13:26 2022
Elapsed:        0:00:09

faster than M1

edit: with avs2yuv test.avs -o NUL is even faster

PS Z:\> .\avs2yuv test.avs -o NUL
Avs2YUV 0.30
Script file:    test.avs
Resolution:     384x104
Frames per sec: 24
Total frames:   5000
Progress       Frames       FPS   Elapsed    Remain
[100.0%]   4999/5000     651.68   0:00:07   0:00:00
Started:        Sat Sep 10 09:04:01 2022
Finished:       Sat Sep 10 09:04:08 2022
Elapsed:        0:00:07

To be fair, the Power Mac G5 Quad was released in 2005

I wonder what will PS3 CELL in Linux will do

edit2: btw, is there are a way to get GCC -O3 in windows without losing msvc plugins support?

[qyot27]

Originally Posted by real.finder

I did test with 12400F in win11 with Avs+ r3682 by asd-g (G S in gitlab) https://gitlab.com/uvz/AviSynthPlus-...4/AviSynth.dll

SetMaxCPU("none")
Version(5000).ConvertToYUV420()

PS Z:\> .\avs2yuv test.avs - > NULL

edit: with avs2yuv test.avs -o NUL is even faster

The first run was redirecting to a file named NULL, the second was actually going to the null device.

I wonder what will PS3 CELL in Linux will do

You'd probably be limited by what version of what distro you could run on it, as the only ones I was aware of are long dead or would have dropped support for the PS3 by now. Gentoo or one of the *BSDs (yes, I know, not Linux) might be the only really viable contemporary options left at this point.

GCC also dropped support for the SPE side of the Cell architecture in GCC 10, so you'd either have to make do with only the PPE (essentially a regular dual-core PowerPC, derived from the POWER4 like the G5 was), or you would have to go back to GCC 9 and hope it could optimize across the entire unit.

edit2: btw, is there are a way to get GCC -O3 in windows without losing msvc plugins support?

Nope. The C++ ABIs are incompatible with each other. Unless there's some way of wrapping C++ dlls in a C interface bridge, but I'm not holding my breath.

[qyot27]

Originally Posted by real.finder

edit2: btw, is there are a way to get GCC -O3 in windows without losing msvc plugins support?

What is possible, though, is having AviSynth+GCC live alongside the regular MSVC builds, with only one of them active at a time. 64-bit* builds of FFmpeg, x264, or avs2yuv will accept either one. GCC plugins can be stored in their own plugins_gcc and plugins64_gcc directories, which keeps them from conflicting with the MSVC ones.

*32-bit requires a completely separate build; when I've put up FFmpeg or mpv builds, that's what the -avsgcc suffixed ones are.

On Windows, I have symlinks to AviSynth.dll in system32 and syswow64 instead of the real .dlls, which I have in the typical AviSynth+ installation path. Then I can have many different versions there, with suffixes on them, and if I need to test one, I just change out which one is the active AviSynth.dll that the symlinks are pointed at:

$ ls -l
total 122980
-rwxrwxrwx 2 qyot27 qyot27  5811200 Mar 17 22:27  AviSynth32.dll
-rwxrwxrwx 2 qyot27 qyot27   351744 Dec 21  2008  avisynth32.dll.258
-rwxrwxrwx 2 qyot27 qyot27  5355520 Jan 11  2021  AviSynth32.dll.370
-rwxrwxrwx 2 qyot27 qyot27  6279168 Dec 29  2021  AviSynth32.dll.371
-rwxrwxrwx 2 qyot27 qyot27 15084112 Mar 20 22:43  AviSynth32.dll.372gcc
-rwxrwxrwx 2 qyot27 qyot27   378368 May 17  2016  avisynth32.dll.bak
-rwxrwxrwx 1 qyot27 qyot27 13509136 Feb 21  2021  AviSynth32.dll.staticgcc
-rwxrwxrwx 2 qyot27 qyot27  6542336 Mar 17 22:24  AviSynth64.dll
-rwxrwxrwx 2 qyot27 qyot27  5968384 Jan 11  2021  AviSynth64.dll.370
-rwxrwxrwx 2 qyot27 qyot27  6443520 Dec 28  2021  AviSynth64.dll.371
-rwxrwxrwx 2 qyot27 qyot27 19356916 Mar 20 22:43  AviSynth64.dll.372gcc
-rwxrwxrwx 2 qyot27 qyot27 19267536 Dec 24  2021  AviSynth64.dll.gcc
-rwxrwxrwx 2 qyot27 qyot27 14604864 Mar 21  2019  AviSynth64.dll.gcc2831
-rwxrwxrwx 1 qyot27 qyot27  2047488 Jan 11  2021  DevIL32.dll
-rwxrwxrwx 1 qyot27 qyot27  2300928 Jan 11  2021  DevIL64.dll
drwxrwxrwx 1 qyot27 qyot27        0 Jan  1  2022  docs
drwxrwxrwx 1 qyot27 qyot27     4096 Jan  1  2022  Examples
drwxrwxrwx 1 qyot27 qyot27    12288 Jan  1  2022  FilterSDK
drwxrwxrwx 1 qyot27 qyot27     4096 Jan  1  2022  License
drwxrwxrwx 1 qyot27 qyot27    40960 May 29 14:16  plugins
drwxrwxrwx 1 qyot27 qyot27     4096 Mar 20 14:54  plugins+
drwxrwxrwx 1 qyot27 qyot27     4096 May 20 23:11  plugins64
drwxrwxrwx 1 qyot27 qyot27     4096 Mar 20 14:53  plugins64+
drwxrwxrwx 1 qyot27 qyot27     4096 Mar 20 23:40  plugins64_gcc
drwxrwxrwx 1 qyot27 qyot27     4096 Mar 20 23:40  plugins_gcc
-rwxrwxrwx 2 qyot27 qyot27   170739 Dec 31  2021  readme_history.txt
-rwxrwxrwx 1 qyot27 qyot27   100640 Jun 19  2020  readme.txt
-rwxrwxrwx 2 qyot27 qyot27    23234 Jul  5  2018 'Setup Log 2018-07-05 #001.txt'
-rwxrwxrwx 2 qyot27 qyot27   259173 Nov 29  2020 'Setup Log 2020-11-29 #001.txt'
-rwxrwxrwx 2 qyot27 qyot27   336204 Jan  1  2022 'Setup Log 2022-01-01 #001.txt'
-rwxrwxrwx 1 qyot27 qyot27   356473 Jan  1  2022  unins000.dat
-rwxrwxrwx 1 qyot27 qyot27  1256527 Jan  1  2022  unins000.exe

[real.finder]

Unless there's some way of wrapping C++ dlls in a C interface bridge

something like LoadPluginEx.dll that used to load AviSynth v1.0x and v2.0x plugins in avs 2.5? anyway if we can get the speed of GCC -O3 then it worth the workaround

[Reel.Deel]

New test build (r3689): https://gitlab.com/uvz/AviSynthPlus-Builds

[wonkey_monkey]

Is there a way to override an internal function but still call the original version when required? E.g.:

function FlipVertical(clip c) {
  return c.FlipVertical
}

As you'd imagine, this causes AviSynth to crash due to the recursive nature of the function, but is there, or could there be, some prefixed version of FlipVertical than can be called from within the function instead?

It would be useful to implement an environment-wide override for a built-in function, for example to workaround this oversight from way back when: http://forum.doom9.net/showthread.php?p=1849921

[EternalStudent]

Very cool you're testing on one of the newer Mac's with ARM! I used to mess around with a NVIDIA Jetson way back when (pre-public release), and wished there was more general support for arm64 hardware.

But on to my question... Are there any Avisynth+ logs I can look in, or a debug mode I can enable? I see a bit of text in a log, but it's very terse. And I'm not seeing an event connected with my problems.

I'm using SVP 4 and manually installed a newer Avisynth+ (the latest release 3.7.2). I'm having periodic visual hangs, but haven't found a log that mentions an issue. Nothing interesting/new in SVP's event log, nor Windows 10's event viewer, etc.

I'd estimate weekly or more, I see a video just stop changing on screen for 5-10 seconds, but the audio is still playing back fine. If I'm using other programs they continue working, but clicking on the player seems to cause the system to try to fix the issue. Which makes the whole UI hang for 2-3 seconds (mouse cursor stops moving), then suddenly it'll work again... and playback video frames at higher speed trying to get the video to match the audio position. No other crashes or instability is noticed so I think it's SVP related, and Avisynth+ seems a logical place to get more information.

I realize this is an atypical use case for the program. And that they package a specific older version, though I can't seem to figure out how to use that copy after my manually installed version. So if I revert it'll be to some random thing I've downloaded, not whatever their tested version is.

Last I looked they were using a pretty old version, like the first after starting development again. And I couldn't find a labeled version that printed the same text in the log (website said 3.5.1, but log said 3.5...it's been a bit since I last tried to downgrade so I might be remembering wrong).

System details... Intel i7-4790k, 32GB RAM, NVIDIA 1080 ti, Windows 10 64-bit, all with latest "release" updates and drivers. Virtualization features are enabled (HyperX) to allow WSL2 to function, but I haven't been using it lately. GeForce Experience is installed, and it's doing the video driver updates to the gaming driver (not studio version). Using MPC-HC + AviSynth Filter + (internal) LAV Filters for playback. Worst resource usage (CPU) is often 30-50% from the video playback, and GPU often 10%. Also have Firefox and low resource games running, but I've seen the video hangs with a variety of videos playing, games, and websites. And I'm not playing DRM videos on Firefox (mostly text documentation today).

[StainlessS]

Sounds to me like you could do with a re-install of W10, or revert to a previous good image (Macrium Reflect or whatever).
Nobody else seems to have your problems, I have pretty similar setup except for i7-8700, GTX 1070 and latest Standard studio driver.

There is a free version of Macrium Reflect (search for "Macrium Reflect free offline install") otherwise you get a downloader exe.
Can make USB bootable drive from Macrium Tools menu, thats the only part of Macrium that i use.

Can also try FoxClone if you like, is USB bootable cloner based on Linux, (Macrium can have problems with certain linux setups if you multi-boot),
can clone FAT/FAT32/NTFS, and Ext2/Ext3/Ext4 filesystems. [EDIT: I'de down the Std version, Edge version is Beta I think]

Good idea to make a known good image that is easily go-backable to.


EDIT: Here the Nvidia ADVANCED driver search page:- https://www.nvidia.com/Download/Find.aspx?lang=en-uk#
Latest Standard GeForce 10 x64 WHQL Studio = v472.84 / 13 Dec 2021
(I don't use the Game Drivers, I've had probs with them in the past - EDIT: Try install of Standard driver before re-install W10)

EDIT: Macrium Reflect (Free) x64 on FileHorse:- https://www.filehorse.com/download-macrium-reflect-64/

FoxClone:- https://www.foxclone.com/

EDIT: Also note from D9 thread "AMD, Intel and Nvidia driver issues and last recommended version"

Originally Posted by StainlessS

Is there perhaps an error in OP PDF version number for 472.47 (there are two of them).


And from here [Official Advanced Driver Search | NVidia]:- https://www.nvidia.com/Download/Find.aspx?lang=en-uk#


472.84 from 2nd image seems to be latest standard WHQL Studio Driver, and given same date as the latest 472.47 in pdf, ie 13 Dec 2021.

EDIT: To Below, thanks

Originally Posted by Klaus1189

You are right, I correct it soon, some problems now.

[Reel.Deel]

Originally Posted by EternalStudent

Are there any Avisynth+ logs I can look in, or a debug mode I can enable? I see a bit of text in a log, but it's very terse. And I'm not seeing an event connected with my problems.

Try using the logging facility: http://avisynth.nl/index.php/SetLogParams