AviSynth+ thread Vol.2

[MeteorRain]

Also I'm hoping we'll get CI very soon. Ideally a Windows and a Linux build.

[Sharc]

Is there some capture device that uses only 8-bit audio? Personally I see no reason to use anything below 16 bits.
I don't know the history of those transfers (captures). They date 12 to 16 years back. Maybe it was a system limitation, or just a (default) setting.

[tebasuna51]

That makes sense. Any idea why 8 to 16 code added the extra noise?
0x80 (unsigned byte center) => 0x0080

I make some test and you are right, the conversion 8 -> 16 is wrong

A silence (0 value) in 8 bit unsigned is 0x80 but is converted to signed 16 bits like 0x0080 (128 value).

All values have this problem, the conversion must be:

Value_16_signed = Value_8_unsigned - 128

Nobody have detected this problem before.

[MeteorRain]

tebasuna: The code has a comment of
// 8 Bit data is stored += 128

// signed 16 bit data is composed of signed 8 bit data times 256 + (signed 8 bit data + 128)

// This make 0x7f(255-128) -> 0x7fff & 0x80(0-128) -> 0x8000


So it must have been intentional.

If we all agree it's wrong, then I'm gonna fix that.

[Boulder]

I don't know the history of those transfers (captures). They date 12 to 16 years back. Maybe it was a system limitation, or just a (default) setting.

Probably due to some (incorrect) advice to use a lower bitdepth.. soundcards have supported 16-bit audio for quite a long time now. Something like since the mid 90s at least.

[qyot27]

Yea that's exactly why I want to improve it a bit.

By the way, what's the development process now? Shall I raise a PR directly to main repo, or should I raise it to your copy first? Anyone available for a code review? I notice that you are also in the process of porting to ARM, maybe that parts should be tested by someone before the merge?
Yep, PRs can go to the main repo.

[tebasuna51]

tebasuna: The code has a comment of
// 8 Bit data is stored += 128

// signed 16 bit data is composed of signed 8 bit data times 256 + (signed 8 bit data + 128)

// This make 0x7f(255-128) -> 0x7fff & 0x80(0-128) -> 0x8000


So it must have been intentional.

If we all agree it's wrong, then I'm gonna fix that.

The comment is wrong, yes.

The conversion must be:
Uns. Audio Signed
8bit dec Volume 16 bit
---- --- --- ------ ------
0xFF 255 127 32512 0x7F00
0xFE 254 126 32256 0x7E00
...
0X82 130 2 512 0x0200
0x81 129 1 256 0x0100
0x80 128 0 0 0x0000
0x7F 127 -1 -256 0xFF00
0x7E 126 -2 -512 0xFE00
...
0x01 1 -127 -32512 0x8100
0x00 0 -128 -32768 0x8000

A fast way in ASM can be invert first bit (a binary XOR with 0x80) and add 8 0' (or delete last for 16 -> 8)

[MeteorRain]

Sent my PR and waiting for your reviews.

[real.finder]

I don't know if this is the right place to made a "request", but the original Tom Barry's DCTfilter had "offx" and "offy" parameters for offsets which apparently have been removed in later versions. These were useful to run this script (https://forum.doom9.org/showpost.php?p=1191009&postcount=6) that mimic a lowpass filter. Is it possible to add these offset parameters back into current DCTFilter or maybe there're other ways to get the exact same "lowpass" results?
Thanks

I think it's better to request this here https://github.com/Asd-g/DCTFilter/issues

[MeteorRain]

Right now we still have the following inline asm left in the code.

MergeChannels::GetAudio [scalar]
Amplify::GetAudio [scalar]
Normalize::GetAudio [scalar]
MixAudio::GetAudio [scalar]

ResampleAudio::GetAudio & FilterUD_mmx [SIMD]

memcpy_amd
asm_BitBlt_ISSE

I think the scalar code can be safely deleted since modern compiler should produce comparable code.

SIMD code can be rewritten into intrinsics.

How about bitblt / memcpy code? They should only work faster on old CPU and only on 32-bit. std::copy should give very optimal performance.

[vcmohan]

I have been updating my plugins for the 3.6 version and correcting for earlier using IScriptEnvironment2.
A particular function SegAmp in my modPlus plugin I modified and tested fully in 3.5 version v6 and even had a bench mark run. I then tested in 3.6 v8. While all other functions were running OK, this particular function gave an error "error Reading Source Frame 0, Avisynth Read Error: SetLogParams. could not open file "po"for writing. I was using colorbars as input. I then converted to YV24. It ran OK. I then commented out converttoYV24(), reverting back to earlier color space. Curiously it now ran and I could even bench mark.
What could be the problem?

[pinterf]

memcpy_amd
asm_BitBlt_ISSE

How about bitblt / memcpy code? They should only work faster on old CPU and only on 32-bit. std::copy should give very optimal performance.
I've left them active only for pre-avx processors.

[MeteorRain]

Did some quick benchmark on L5506 (took me a long time to find a non-avx user).

memcpy_amd is slightly slower than system memcpy and std::copy, by about 3%. On sandy bridge it's running 15% slower. On a modern Ryzen it's running half the speed.

asm_BitBlt_ISSE is not quick either. The core code is movntq / _mm_stream_pi which uses 64 bit registers, not a modern SSE 128bit registers.

My personal opinion is there's no need to keep this ancient code. (Considering this is still called ISSE, which is probably optimized against Pentium 4 or earilier.)

[tormento]

Is there a reason of the AviSynth installer including colors_rgb.avsi + colors_rgb.txt and the "files only" not?

[qyot27]

asm_BitBlt_ISSE is not quick either. The core code is movntq / _mm_stream_pi which uses 64 bit registers, not a modern SSE 128bit registers.

My personal opinion is there's no need to keep this ancient code. (Considering this is still called ISSE, which is probably optimized against Pentium 4 or earilier.)
SSE2 introduced the 128-bit registers for integer operations. First-generation SSE (Pentium III) re-used the MMX registers.

[MeteorRain]

I have to say, translating those MMX code to SSE is pain nass. ResampleAudio took me hours and I'm only half done.

[pinterf]

Service announcement, I'll be *offline for two weeks.
*not doing any serious work other than running :) and will have limited PC access; my reactions on questions will be lagging a bit.

[StainlessS]

Missing you already :)

[FranceBB]

Service announcement, I'll be *offline for two weeks.
*not doing any serious work other than running :) and will have limited PC access; my reactions on questions will be lagging a bit.

You deserve this two weeks holiday after all you've done, Ferenc.
I'm already looking forward for you to come back. :D

[ChaosKing]

Was this ported from neo avs+ ? https://forum.doom9.org/showthread.php?p=1859306#post1859306
I saw Filtergraph.cpp in https://github.com/pinterf/AviSynthPlus/blob/master/avs_core/core/FilterGraph.cpp
but with avs+ 3.4 it says DumpFilterGraph() is unknown.


EDIT
whoops why am I still on 3.4. Installed avs 3.6 and it works now

If someone wants to test it, you need to call SetGraphAnalysis(true) at the beginning of your script and DumpFilterGraph the end.

[Nuihc88]

Here's a few problems i've been encountering with v3.6.1 and later builds:

1. Some test builds are giving me occasional Access Violations and silent crashes while seeking during realtime playback; i get far more of the former with test8 than test6, test4 & test5 seem to be working most reliably for me. Seeking or pausing for extended periods of time during realtime playback seems to be the surest way to trigger it, even so it only happens about 1 out of every 50 tries. Each build handles the issue differently and gives a slightly different error, always starting with 0xC0000005, when one is given at all.
2. Sometimes realtime playback never recovers on it's own after presentation queue drops to zero, despite there being enough computational power for it. Seems to have about 50% chance of occurring.
3. After test6, playback recovery behavior has changed for the worse, if a script is too heavy, instead of just dropping interpolated frame(s), video sometimes starts lagging behind the audio.
4. Final 3.6.1 build (r3300) and later are causing hard lockups with PotPlayer.

I'm guessing that all of above is due to memory leak(s) somewhere. Perhaps someone can verify if they're getting the same ones...


There's also this older problem with Prefetch, which may warrant investigation at some point:

When using multiple instances of Prefetch (with SVPflow filters) there are times when the same frame is returned two times in a row.
In realtime playback usage this can also cause both sync-drifting and occasional jerky movements (without frame drops or glitches showing up in MadVR's OSD).
Frame repeats become more frequent with each additional Prefetch buffer, regardless of whether it's from an additional Prefetch instance or thread and rate of occurrence doesn't seem to scale with buffer size or latency.
Latencies reported by MadVR also more than double every time a new Prefetch thread is added. Thread count of other filters doesn't have nearly as much impact on latency.

I have been trying to gather more detailed information on the nature of the issue for the past month, but haven't managed to figure out a whole lot. I'm guessing that there's probably an off-by-one bug somewhere within cache management.


My test environment is 64bit Win7, running 32bit AviSynth+ through PotPlayer, ffdshow and MadVR.

[manolito]

Can you reproduce all of these issues when using AVS+ 3.5.1 32-bit? I have this feeling that merging the features from the AVS+ Neo fork are responsible for most of these issues.

With the plugins I use AVS+ 3.6.1 is now just as stable as version 3.5.1, but I really see no advantage whatsoever over 3.5.1. It's all in the name of progress... :p

[Nuihc88]

Can you reproduce all of these issues when using AVS+ 3.5.1 32-bit? I have this feeling that merging the features from the AVS+ Neo fork are responsible for most of these issues.

I really only started checking and testing pinterf's builds on regular basis after he started merging stuff from the Neo fork and AVS+ inherited it's realtime speed and latency benefits.

v3.5.2 builds were fairly stable for me, but i did get an occasional Access Violation at least with some of those too. Realtime usage has a tendency to highlight stability problems that are far less often encountered in 'normal' use; repeatedly seeking back on a scene to optimize script performance, even more so.
In my much earlier notes i had marked r2772 & r2923 as exceptionally stable, but even between those, some builds were far less so, which is one of the reasons i'm suspecting that there's a memory leak somewhere.

I don't think the Prefetch issues could have even been detected before the merge, as Neo was too unstable and AVS+ too slow and inflexible to test with. In any case, the new version of the Prefetch function performs far faster with one thread than the old version ever did with any value.

[real.finder]

this work fine for me

mp_pipeline("""
### dll: Avisynth-3.6.2_20200624_test1-filesonly\x64\AviSynth.dll
ColorBars(width=640, height=480, pixel_type="yv12")
admfilter(custom_filter="dfttest(Sigma=(adSigma+1.0)/f)")
Prefetch(4)
### ###
""")

it was not before https://forum.doom9.org/showthread.php?p=1904931#post1904931

admfilter is in AdvancedDenoising.avsi (https://github.com/realfinder/AVS-Stuff/blob/master/avs%202.5%20and%20up/AdvancedDenoising.avsi) and it also need this (https://github.com/realfinder/AVS-Stuff/blob/master/avs%202.5%20and%20up/Zs_RF_Shared.avsi)

[real.finder]

pinterf, if you have time, can you please check this? https://forum.doom9.org/showthread.php?p=1917585#post1917585

[gispos]

this work fine for me

mp_pipeline("""
### dll: Avisynth-3.6.2_20200624_test1-filesonly\x64\AviSynth.dll
ColorBars(width=640, height=480, pixel_type="yv12")
admfilter(custom_filter="dfttest(Sigma=(adSigma+1.0)/f)")
Prefetch(4)
### ###
""")

it was not before https://forum.doom9.org/showthread.php?p=1904931#post1904931

admfilter is in AdvancedDenoising.avsi (https://github.com/realfinder/AVS-Stuff/blob/master/avs%202.5%20and%20up/AdvancedDenoising.avsi) and it also need this (https://github.com/realfinder/AVS-Stuff/blob/master/avs%202.5%20and%20up/Zs_RF_Shared.avsi)
admfilter(custom_filter="dfttest(Sigma=(adSigma+1.0)/f)")

Please help me.
I don't know what 'color_white' means. (AdvancedDenoising.avsi, line 107)

Zs_RF_Shared.avsi is loaded.

[StainlessS]

I don't know what 'color_white' means.

colors_rgb.avsi, installed along with Avisynth/+

# ...
global color_violet = $EE82EE
global color_wheat = $F5DEB3
global color_white = $FFFFFF
global color_whitesmoke = $F5F5F5
global color_yellow = $FFFF00
global color_yellowgreen = $9ACD32
# ...


EDIT: Maybe that color_white should be replaced with $FFFFFF, should not really need to install an avsi just to use an obvious definition.

[gispos]

colors_rgb.avsi, installed along with Avisynth/+

Thanks StainlessSS, It must have been lost. I have to google it.

[tormento]

colors_rgb.avsi, installed along with Avisynth/+
As I reported earlier, it's not included in the "file only" version.

[LigH]

:sly: May require a "supplement" files archive in addition to the "file only" archive... :o

[Groucho2004]

My take on this using common sense: :sly:

Anyone downloading the files-only package has Avisynth+ already installed either via regular installer or Universal Installer. Either option installs/contains the colors_rgb.avsi file. So, no need to put it in the package unless there were changes to it which I believe happens only once a decade.

[StainlessS]

Last change to colors_rgb.avsi was (2015) removal of a double entry for color_palegoldenrod,
https://forum.doom9.org/showthread.php?p=1711065#post1711065


EDIT: The diligent amongst you might notice two copies of "color_palegoldenrod" in the mp4,
this is a duplicate in colors_rgb.avsi as installed by v2.6RC1, you might like to delete duplicate from your copy,
reported in RC1 devs thread.


https://dl.dropboxusercontent.com/s/akrph1tq1tszmsi/hexyuv.gif

The double entry is in the image when topmost color is OrangeRed.
EDIT: Only the RGB colors are in colors_rgb.avsi, the other YUV color values are calculated from those, see linked thread.

[gispos]

Avisynth 3.6.2
Have not tried whether it is the same with the 3.6.x versions

If MP_Pipeline is in a script, this script can no longer be loaded with AviSource.
This is a huge problem for me, with Delphi 'AviSource' is the only way to open a script when MCTD is called in that script.

I would like to know why that is with Delphi and 'MCTD', it has been plaguing me for a few months and I just can't figure it out.

Edit:
That with Avisynt 3.6.2 and AviSource was my mistake.
There was a 3.6.1 version in one system directory, after replacement AviSource works again.

[wonkey_monkey]

Are we able to apply and read per-frame/per-clip property values these days (in C++)? If so is there documentation?

[DJATOM]

Probably that can be used as example how to use them in plugins: https://github.com/AviSynth/AviSynthPlus/blob/3b96a4feddbf67ae19c9e56320f950debdadf20f/avs_core/filters/conditional/conditional_reader.cpp#L1189

[wonkey_monkey]

Thanks, I'll peruse that.

I still think a true inter-filter communication system would be awesome... at least for the kind of filters I keep finding myself writing...

[wonkey_monkey]

This isn't really sinking very well, so... if a frame or clip is given a property, but is then passed through another filter, are all the properties lost?

[StainlessS]

This isn't really sinking very well, so... if a frame or clip is given a property, but is then passed through another filter, are all the properties lost?

Something here:- https://forum.doom9.org/showthread.php?p=1913860#post1913860

Suggest Search on:- keyword "Properties", Show result as Posts, user name Pinterf, search in forum(s) Capturing & Editing Video/Avisynth Developement.

[LigH]

There is a report in the German Gleitz forum (https://gleitz.info/forum/index.php?thread/48236-megui-stürzt-nach-audio-encode-immer-ab/) about audio issues with MeGUI (it locks up, no progress) when SuperEQ is used to upmix stereo to 6Ch. MeGUI prepares an AviSynth script and a subdirectory with SuperEQ parameter files per channel. But the conversion apparently gets stuck. This happens also when the script is fed directly into ffmpeg. I did not yet test this myself. But I guess it could be worth an investigation whether any regression was introduced in the audio part (depending on the exact AviSynth+ DLL version)...

MeGUI: 2924 x86
AviSynth+ 3.5 (r3106, 3.5, i386)

[manolito]

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

I have no idea what to make of it, but after a few days of testing with different HD sources (only testing 32-bit AVS+) I can clearly reproduce that version 3.6.1 Test 8 is by far more stable in MT mode than the later versions 3.6.1 stable (tested only the "standard" non-XP version) and also the latest 3.6.2 Test 1 version.

Test platform:
ThinkPad T530 with a Core i5-3230M (Ivy Bridge, 3rd generation)
8 GB of RAM
Win7 Pro 64-bit
AVS+ Prefetch value was set to 4 threads

I converted HD sources (AVC or HEVC video at 50 fps, AAC, AAC-LATM or E-AC3 audio) to SD with AVC video and AAC audio. I used older 2.6 and 2.5 plugins. MT settings from the mtmodes.avsi taken from the AVS+ Wiki page, additions taken from this post by almosely:
https://forum.doom9.org/showthread.php?p=1865279#post1865279
The changes are in the 3rd paragraph of the post.

These tweaks made AVS+ 3.5.x quite stable already, but with some exceptions. After establishing a job in StaxRip (latest stable 32-version) it turned out that it was mostly necessary to save the job first, reboot and then start the job. Also Web browsing during the X264 encode was not really safe. If I did not take these precautions, X264 would crash randomly, mostly near the end of the conversion.

After experimenting with the AVS+ 3.6.1 test builds I found that the MT behavior had improved. Especially with Test 8 it was possible to browse the Web, even streaming a YouTube clip during the encode. Also a reboot before starting the actual encode was no longer required.

But the joy stopped after installing the stable version 3.6.1. The old occasional crashes were back again. I used the "standard" non-XP build.

And last I tested 3.6.2 Test 1, this build is XP-compatible again. So I hoped that the stability of 3.6.1 Test 8 would reappear, but it did not. Same random crashes as with 3.5.x and 3.6.1 stable.

The conclusion is that these differences in MT stability have nothing to do with the fact if the build is XP compatible or not. It looks more like something in the code itself has changed after 3.6.1 Test 8, and this change affects memory handling in multitasking mode. No way for a user to debug this, only pinterf or qyot27 could possibly find out what is going on here.

I am back to version 3.6.1 Test 8 for the time being...


Cheers
manolito

[tebasuna51]

...audio issues with MeGUI (it locks up, no progress) when SuperEQ is used to upmix stereo to 6Ch. MeGUI prepares an AviSynth script and a subdirectory with SuperEQ parameter files per channel. But the conversion apparently gets stuck.
...any regression was introduced in the audio part (depending on the exact AviSynth+ DLL version)...
AviSynth+ 3.5 (r3106, 3.5, i386)

Of course the regression is here:
SuperEQ(clip, string filename)

Audio is always converted to Float.
AVS+ no conversion is performed. Accepts Float audio only.

The script created by MeGUI must include a ConvertAudioToFloat() before call SuperEQ in Avs+

[LigH]

Thanks, I will report that there.

[qyot27]

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

I have no idea what to make of it, but after a few days of testing with different HD sources (only testing 32-bit AVS+) I can clearly reproduce that version 3.6.1 Test 8 is by far more stable in MT mode than the later versions 3.6.1 stable (tested only the "standard" non-XP version) and also the latest 3.6.2 Test 1 version.

Test platform:
ThinkPad T530 with a Core i5-3230M (Ivy Bridge, 3rd generation)
8 GB of RAM
Win7 Pro 64-bit
AVS+ Prefetch value was set to 4 threads

I converted HD sources (AVC or HEVC video at 50 fps, AAC, AAC-LATM or E-AC3 audio) to SD with AVC video and AAC audio. I used older 2.6 and 2.5 plugins. MT settings from the mtmodes.avsi taken from the AVS+ Wiki page, additions taken from this post by almosely:
https://forum.doom9.org/showthread.php?p=1865279#post1865279
The changes are in the 3rd paragraph of the post.

These tweaks made AVS+ 3.5.x quite stable already, but with some exceptions. After establishing a job in StaxRip (latest stable 32-version) it turned out that it was mostly necessary to save the job first, reboot and then start the job. Also Web browsing during the X264 encode was not really safe. If I did not take these precautions, X264 would crash randomly, mostly near the end of the conversion.

After experimenting with the AVS+ 3.6.1 test builds I found that the MT behavior had improved. Especially with Test 8 it was possible to browse the Web, even streaming a YouTube clip during the encode. Also a reboot before starting the actual encode was no longer required.

But the joy stopped after installing the stable version 3.6.1. The old occasional crashes were back again. I used the "standard" non-XP build.

And last I tested 3.6.2 Test 1, this build is XP-compatible again. So I hoped that the stability of 3.6.1 Test 8 would reappear, but it did not. Same random crashes as with 3.5.x and 3.6.1 stable.

The conclusion is that these differences in MT stability have nothing to do with the fact if the build is XP compatible or not. It looks more like something in the code itself has changed after 3.6.1 Test 8, and this change affects memory handling in multitasking mode. No way for a user to debug this, only pinterf or qyot27 could possibly find out what is going on here.

I am back to version 3.6.1 Test 8 for the time being...
All of the changes between test8 and the final version of 3.6.1 were on June 15th. There are seven of them to investigate.

http://www.mediafire.com/file/xzjmybvbjjeugqf/avs_stax32_bisect.7z/file

That's a pack of five of those commits (two of them don't compile on their own, but require the following commit). You can test those and see if one of them is where the issue was introduced.

[manolito]

Thanks very much for this upload, should be very helpful...
Will start testing tonight.

[magnetite]

So I was experimenting with the CUDA version of Avisynth+ which was merged into the main Avisynth+ branch. It seems that it results in a memory leak. While using MeGUI, it gets stuck on the pre-processing phase, then the memory usage goes through the roof (99% RAM usage with 16 GB installed) before the app locks up.


LoadPlugin("C:\MeGUI 64-bit\tools\lsmash\LSMASHSource.dll")
LWLibavVideoSource("Z:\Outer Limits\Season 3\Disc 4\Dead Man's Switch.mkv", cachefile="D:\Temp\eksmcibs.nc1\Dead Man's Switch.mkv.lwi")
#crop
#resize
OnCPU(2)
KTGMC(Preset="Slow")
OnCUDA(6)


The same script run under the Nekopanda version of Avisynth (r2827) is able to run just fine. The memory usage was around 1 GB or so on average.

[Nuihc88]

All of the changes between test8 and the final version of 3.6.1 were on June 15th. There are seven of them to investigate.

http://www.mediafire.com/file/xzjmybvbjjeugqf/avs_stax32_bisect.7z/file

That's a pack of five of those commits (two of them don't compile on their own, but require the following commit). You can test those and see if one of them is where the issue was introduced.
Nevermind posted too quickly... These three of the problems i reported earlier appear to be gone in the build from the 'r3298f-git_82a06eee'-folder:
2. Sometimes realtime playback never recovers on it's own after presentation queue drops to zero, despite there being enough computational power for it. Seems to have about 50% chance of occurring.
3. After test6, playback recovery behavior has changed for the worse, if a script is too heavy, instead of just dropping interpolated frame(s), video sometimes starts lagging behind the audio.
4. Final 3.6.1 build (r3300) and later are causing hard lockups with PotPlayer.
I'll keep testing these builds and reporting my findings (by editing this post) as well...
...looks like the problem #3 is still there, but much harder to trigger with these new test builds compared to test8...
...nevermind, i forgot to test them without Prefetch, it was masking both problems #2 & #3, both of which are still present...
...Still haven't encountered problem #4 with any of these builds yet, however i noticed that without Prefetch both builds 'r3297f-git_0c09510f' & 'r3298f-git_82a06eee' are much slower than the rest and 'r3294f-git_7a0aa2f3' is a little bit slower than the ones before it.

[qyot27]

r3298f is the same as the final release of 3.6.1. There are absolutely zero code differences between them. The two commits that separate 3298 from 3300 are docs and comments only. The only practical difference is that I did update to the latest version of VS2019 before running off all these test builds.

[manolito]

I am still in the middle of my tests, it turned out to be a little more difficult than I anticipated... :scared:

It turned out that the random crashes only occur with long source files (duration of more than 2 hours). Makes testing very time consuming.

My results so far are that r3290 (Test 8) up to r3292 have no problems with MT, but r3294 caused crashes again. I will test r3297 later tonight and report back.

[qyot27]

Does avs+ work on big endian cpus now?
I would be surprised if it would work seamlessly. I'm totally uneducated on big endian CPUs other that once I was programming POS terminals with Motorola 68000.
If you didn't test it then the answer is definitely no with all that old code lying around...
"Which BE CPUs?" would be the more important question, I think. I mean, I did run a test on a qemu-system-ppc VM emulating a G4¹ and it could compile and run:

http://i.imgur.com/w8WT7HEl.png (https://i.imgur.com/w8WT7HE.png)
(Void Linux ppc glibc; musl chokes on something in AviSynth+, or something in the loader in avs2yuv or FFmpeg, probably the atexit handler)

Although I think that's a bit over-the-top; all it required was adding the predefined macros for PPC into avs/config.h. A Talos II or Blackbird setup would make more sense, but unless it's significantly trickier to do, POWER9-based CPUs supposedly can operate in ppc64le mode.

Some of the filters may produce unexpected results - Version().ConvertTo444() was okay, the resulting output from x264 played with correct colors using the media player in the live session, but ConvertToYV12().BilinearResize(640,352) caused incorrect colors (not sure if it was the conversion to YV12 or the resizer). To actually test efficiently, I'd have to do a real install so I can test FFmpeg/FFplay directly instead of piping in.

¹only because the G3 iBook I have access to didn't want to boot from either CD or USB so that I could test with a modern Linux that still supports that platform. And there's no way I was going to try to figure out how to get a suitably-modern version of GCC or Clang running on OS X 10.2.

[real.finder]

ppc

maybe someone will make a cell (ps3 cpu) port for avs+ some day :P