Avisynth+

[Groucho2004]

This isn't working with Avisynth 2.6

if (!vi.IsY() && !vi.Is420() && !vi.Is422() && !vi.Is444() && !vi.IsRGB())
env->ThrowError("ConvertToShader: Source format is not supported.");


Is420 returns false, but IsYV12 works. I made sure to update headers to the latest version.
From avisynth.h:
// YV12 must be 0xA000008 2.5 Baked API will see all new planar as YV12
// I420 must be 0xA000010

Run the debugger and check the actual value that is returned.

[MysteryX]

hum... now it works. Perhaps it didn't recompile properly after updating the headers.

[burfadel]

I made a post regarding an issue with Avisynth and pixel types in combination with different bit depths here:
https://forum.doom9.org/showpost.php?p=1817968&postcount=160

Updated the first post with version 1.6.

If you extract the luminance channel such it is just the Y channel, obviously it is a different format to the YUV clip such as output from the chroma filtering. You first have to convert back to the same format before combining. This is fine, however when you are in more than 8 bits, the commands such as isYV12() etc do not work since it is expecting a YUV420Y8 clip for it to be true. Since it is a YUV420P10 clip (for example) the command isYV12() seems to give back false. If you run convertToYV12(), it keeps the higher bitdepth of 10 etc, so isYV12() still doesn't work. This, and possibly other little issues, are problematic when you want to have the output clip the same format as the input clip and it isn't 8-bit etc. This is why I put back the 'do not process' flags to the luma commands, it was either that or dropping support for YV16 and YV24, which obviously isn't desirable.

It works fine as is because the bit depths can be matched easily and the pixel type hasn't changed. I could do a convertbits() just so isYV12() etc works, but then it's an extra unnecessary bit of processing that will probably affect speed more than what was gained by converting it to Y8 and going back to the desired pixel type.

Imagine a source of YV16 and 10 bit. If you extract the Y channel, process it, to merge it back to the original clip you need to first convert it (can't do a direct merge chroma). To do this, you need to know the format of the original clip, which is problematic because isYUV() works, but isYV16() doesn't because in this case, it is really asking , effectively isYUV422P8(). The result therefore is false. Am I missing something, or do you really have to go isYV16(Convertbits(8)) first so it answers true if a bit depth other than 8 for YUV4224Px? If this is true, then it is NOT :) consistent with convertYV16(), since that keeps the bit depth. You can literally go ConvertToYV16() followed by isYV16(), and it will return false if it isn't 8 bit.

[MysteryX]

Imagine a source of YV16 and 10 bit. If you extract the Y channel, process it, to merge it back to the original clip you need to first convert it (can't do a direct merge chroma). To do this, you need to know the format of the original clip, which is problematic because isYUV() works, but isYV16() doesn't because in this case, it is really asking , effectively isYUV422P8(). The result therefore is false. Am I missing something, or do you really have to go isYV16(Convertbits(8)) first so it answers true if a bit depth other than 8 for YUV4224Px? If this is true, then it is NOT :) consistent with convertYV16(), since that keeps the bit depth. You can literally go ConvertToYV16() followed by isYV16(), and it will return false if it isn't 8 bit.
Use IsYUV420(), IsYUV422() and IsYUV444()

Was looking for a link but can't find those commands in the docs!

EDIT: Is420 :) in clip properties

[raffriff42]

I made a post regarding an issue with Avisynth and pixel types in combination with different bit depths here:
https://forum.doom9.org/showpost.php?p=1817968&postcount=160



Imagine a source of YV16 and 10 bit. If you extract the Y channel, process it, to merge it back to the original clip you need to first convert it (can't do a direct merge chroma). To do this, you need to know the format of the original clip, which is problematic because isYUV() works, but isYV16() doesn't because in this case, it is really asking , effectively isYUV422P8(). The result therefore is false. Am I missing something, or do you really have to go isYV16(Convertbits(8)) first so it answers true if a bit depth other than 8 for YUV4224Px? If this is true, then it is NOT :) consistent with convertYV16(), since that keeps the bit depth. You can literally go ConvertToYV16() followed by isYV16(), and it will return false if it isn't 8 bit.
See my response to your first issue here (https://forum.doom9.org/showthread.php?p=1817994#post1817994). (oh hi MysteryX)
Yes, you can do a direct merge chroma, with CombinePlanes (http://avisynth.nl/index.php/CombinePlanes) (MergeChroma (http://avisynth.nl/index.php/Merge#MergeChroma)should also work)
To get the format of the original clip, use Is420, Is444 etc, with BitsPerComponent (http://avisynth.nl/index.php/Clip_properties#Color_Format).

[burfadel]

Mergechroma didn't work, since one clip is Y8 and the other YV12 , formats have to match. Combineplanes should work though. I should have realised about the is422() etc! I'll fix this later today my time and hopefully works. Thanks for the info!

[george84]

The Readme says

- 64 bit OS:
copy Avisynth.dll from x86 folder to the windows SysWOW64 folder
copy Avisynth.dll from x64 folder to the windows System32 folder

I think x86 goes to System32 and x64 goes to SysWOW64

[LigH]

No, that's the common mis-assumption. For every Windows flavour, "system32" is the place where the DLL for the native architecture goes. For compatibility reasons.

If you have a 32-bit Windows, the 32-bit DLL goes to system32. Logical.
If you have a 64-bit Windows, the 64-bit DLL goes to system32. Because of compatibility reasons.

And because a 32-bit DLL is not native to a 64-bit Windows, it goes to a special directory "SysWOW64", which is mapped to "system32" for 32-bit applications running on a 64-bit Windows in a compatibility layer.

Germans would comment: "Klingt komisch, ist aber so." (Sounds strange but is true.)

[george84]

Germans would comment: "Klingt komisch, ist aber so." (Sounds strange but is true.)

Also swiss would comment this.

Is it right to deduce (When looking at referenced installer for r2294) that this installer will handle things correctly, so no manual copying of dll is needed, and it even includes newest version of avisynth?

[Groucho2004]

Is it right to deduce (When looking at referenced installer for r2294) that this installer will handle things correctly, so no manual copying of dll is needed, and it even includes newest version of avisynth?No, it does not have the latest version so you would have to copy the DLLs and plugins.
I suggest you use my universal installer (http://forum.doom9.org/showthread.php?t=172124), it has the latest version of AVS+.

[george84]

Thank you. But on the download page http://avisynth.nl/index.php/Avisynthplus/Downloads, yours is referenced. So I had the correct one.

[Groucho2004]

Thank you. But on the download page http://avisynth.nl/index.php/Avisynthplus/Downloads, yours is referenced. So I had the correct one.As I mentioned, if you use the r2294 installer you'll have to copy the DLLs (r2408) manually.

[george84]

Yes, but of course one would use AvisynthUniversalInstaller_2017-09-02.7z · 4.79 MB
which is in same directory.

[george84]

Plugins for high bit depth support.
Here in Forum I find docs on support of high bit depth. How can I know which plugins support this feature. In http://avisynth.nl/index.php/AviSynth%2B I find the newest version but no mention of bitdepth support.

[sneaker_ger]

Test if they support such input. Look into their changelogs/documentation. If they are old you know they don't.

[george84]

If they are old you know they don't.

What is old? Older than first Avisynth+ version which had high bit depth support?

[sneaker_ger]

Yes, that's what I meant. (I didn't mention an actual date because I don't know it from the top of my head. Maybe someone else knows.)

[Groucho2004]

Yes, but of course one would use AvisynthUniversalInstaller_2017-09-02.7z which is in same directory.That's a different kind of installer. I suggest you read the first post in the thread to which I linked in post #3611.

[george84]

I need
TransAll.dll
vsfilter.dll
zoom.dll
freeframe.dll
ffms2.dll
NicAudio.dll
FFMS2.avs

vsfilter and NicAudio are probably independent of bit depth.
ffms2 seems to be the only one working, but for transall there seems to exist an alternative on vcmohans page.
freeframe is not mandatory
zoom is available as source and it should be easy to adapt it.

So I might give it a try.

[george84]

@Groucho2004
Your link via post 3611 goes to https://www.dropbox.com/sh/oxx5cm9hkbpj5oz/AAD0QBnTlczv7xW3jEdSjenHa?dl=0

The link on page http://avisynth.nl/index.php/Avisynthplus/Downloads goes to https://www.dropbox.com/sh/oxx5cm9hkbpj5oz/AAD0QBnTlczv7xW3jEdSjenHa?dl=0

So where is the difference? Anyway, thank you for the installer. It works well.

[LigH]

Did you accidently paste the same URL twice, or are they exactly the same?

[george84]

Did you accidently paste the same URL twice, or are they exactly the same?

They are the same.

[Groucho2004]

So where is the difference?The "Universal Installer" hosts 7 different Avisynth versions from which you can choose via batch file. Switching from one version to another is very simple. Even if you don't want to play around with various versions, the installer has the latest AVS+ version and you don't have to mess around with copying files to the system directories.

The r2294 installer is a "classic" installer which only installs AVS+.

[george84]

The r2294 installer is a "classic" installer which only installs AVS+.

I see now our misunderstanding. I assume you talk about file AviSynth+ r2294.7z · 2.85 MB. I didn't even realize this was an installer because in same directory there was this file AvisynthUniversalInstaller_2017-09-02.7z · 4.79 MB and I talked about the later.

[george84]

x = ImageSource("C:/Users/Walter/Documents/SMIL/BSG23/testsuite/OLED/ColorCheck/colorcheckerchart4kElleV4Big2.tif", use_DevIL = true, pixel_type = "RGB48")
z = ConvertToYUV444(x, matrix="Rec2020")
z = Info(z,size=100)
x

I use avisynth+ 32bit newest version and tested above script in AvsPmod newest version. It correctly displays picture. In info it says for x: colorspace= RGB48, Bitdepth = 16.

When doing output of z instead of x:

1. there is an error message in AvsPmod "Error trying to display the clip..."

2. When encoding with RipBot264 I get strange colors and the video shows only the left half (stretched) of original tif picture. In info it says for z: colorspace=YUV444P16

So I assume there is one problem in AvsPmod and another one in Avisynth+.

Edit1

Insert z = ConvertToStacked(z) after ConvertToYUV444 it displays in AvsPmod. Whatever that means?

[Groucho2004]

When doing output of z instead of x:

1. there is an error message in AvsPmod "Error trying to display the clip..."

2. When encoding with RipBot264 I get strange colors and the video shows only the left half (stretched) of original tif picture. In info it says for z: colorspace=YUV444P16

So I assume there is one problem in AvsPmod and another one in Avisynth+.

Edit1

Insert after ConvertToYUV444 it displays in AvsPmod. Whatever that means?
Nothing wrong with AVS+. AVSPmod simply cannot identify this colorspace (it does know about the stacked variants, that's why ConvertToStacked() worked).

As for ripbot, no idea. Can it even encode 444P16?

[george84]

Thank you for fast response. It is really AvsPmod which confused me.
Actually I need 10 bits. So I inserted
z = ConvertBits(z,10)

and checked result with AVSMeter. Resulting color space is YUV444P10.

I now did the encoding without RipBot, reimported the result with vapoursynth to check the precision of colors. Everything is perfect.

For further work and test, I plan to use AvsPmod and on the very last output statement I will create a stack. I have huge avs scripts and want to adapt them for Rec2020 and high bit depth. I was evaluating vapoursynth but currently prefer Avisynth+.

[Atak_Snajpera]

In case if you need simple installer here is my installation script.
http://www.mediafire.com/file/489x44ql11m3u6e/AviSynthPlus_MT_Installer.7z

[george84]

AVSMeter 2.5.5 (x86) - Copyright (c) 2012-2017, Groucho2004
AviSynth+ 0.1 (r2508, MT, i386) (0.1.0.0)

Exception 0xC0000005 [STATUS_ACCESS_VIOLATION]
Module: C:\Users\Walter\Downloads\AvisynthUniversalInstaller_2017-09-02\AvisynthRepository\AVSPLUS_x86\plugins\Shibatch.dll
Address: 0x61AAA393

C:\Users\Walter\Downloads\AVSMeter255>SHIFT

Not sure if this is right place to post. Above violation occurs on a script of 1400 lines. The script displays well in AvsPmod which gives Video Information correctly (CS = RGB24)

Problem is not important for me.

[LigH]

Might be placed better in the thread for AVSMeter if it is specific (well, leave it here, no need to double) ... but the author (Groucho2004) would surely be interested in the script, possibly as well in the output of "AVSMeter -avsinfo" (which checks DLL dependencies first).

[george84]

I didn't find AVSmeter thread. Here is output of -avsinfo. Script > 1400 lines. So would be difficult to isolate error.

C:\Users\Walter\Downloads\AVSMeter255>"AVSMeter.exe" -avsinfo

AVSMeter 2.5.5 (x86) - Copyright (c) 2012-2017, Groucho2004

VersionString: AviSynth+ 0.1 (r2508, MT, i386)
VersionNumber: 2.60000
File / Product version: 0.1.0.0 / 0.1.0.0
Interface Version: 6
Multi-threading support: Yes
Avisynth.dll location: C:\WINDOWS\SysWOW64\avisynth.dll
Avisynth.dll time stamp: 2017-06-29, 09:00:22 (UTC)
PluginDir+ (HKLM, x86): C:\Users\Walter\Downloads\AvisynthUniversalInstaller_2017-09-02\AvisynthRepository\AVSPLUS_x86\plugins
PluginDir2_5 (HKLM, x86): C:\Users\Walter\Downloads\AvisynthUniversalInstaller_2017-09-02\AvisynthRepository\AVSPLUS_x86\plugins


[CPP 2.6 / 32 Bit plugins]
C:\Users\Walter\Downloads\AvisynthUniversalInstaller_2017-09-02\AvisynthRepository\AVSPLUS_x86\plugins\ConvertStacked.dll
C:\Users\Walter\Downloads\AvisynthUniversalInstaller_2017-09-02\AvisynthRepository\AVSPLUS_x86\plugins\ConvertStacked.dll
C:\Users\Walter\Downloads\AvisynthUniversalInstaller_2017-09-02\AvisynthRepository\AVSPLUS_x86\plugins\DirectShowSource.dll
C:\Users\Walter\Downloads\AvisynthUniversalInstaller_2017-09-02\AvisynthRepository\AVSPLUS_x86\plugins\DirectShowSource.dll
C:\Users\Walter\Downloads\AvisynthUniversalInstaller_2017-09-02\AvisynthRepository\AVSPLUS_x86\plugins\ImageSeq.dll
C:\Users\Walter\Downloads\AvisynthUniversalInstaller_2017-09-02\AvisynthRepository\AVSPLUS_x86\plugins\ImageSeq.dll
C:\Users\Walter\Downloads\AvisynthUniversalInstaller_2017-09-02\AvisynthRepository\AVSPLUS_x86\plugins\Shibatch.dll
C:\Users\Walter\Downloads\AvisynthUniversalInstaller_2017-09-02\AvisynthRepository\AVSPLUS_x86\plugins\Shibatch.dll
C:\Users\Walter\Downloads\AvisynthUniversalInstaller_2017-09-02\AvisynthRepository\AVSPLUS_x86\plugins\TimeStretch.dll
C:\Users\Walter\Downloads\AvisynthUniversalInstaller_2017-09-02\AvisynthRepository\AVSPLUS_x86\plugins\TimeStretch.dll
C:\Users\Walter\Downloads\AvisynthUniversalInstaller_2017-09-02\AvisynthRepository\AVSPLUS_x86\plugins\VDubFilter.dll
C:\Users\Walter\Downloads\AvisynthUniversalInstaller_2017-09-02\AvisynthRepository\AVSPLUS_x86\plugins\VDubFilter.dll

C:\Users\Walter\Downloads\AVSMeter255>SHIFT

[jpsdr]

Maybe the first thing to do is to update avsmeter to the last version (actualy 2.6.5) and test your script with it to see if tge access violation still occurs.

[LigH]

I didn't find AVSmeter thread.

» AVSMeter 2.6.5 (https://forum.doom9.org/showthread.php?t=174797) «

It's also included in Groucho's Avisynth Stuff (https://forum.doom9.org/showthread.php?t=173259)... :o

[george84]

Continued in thread » AVSMeter 2.6.5 « (https://forum.doom9.org/showthread.php?t=174797)

[qyot27]

So in the interest of trying to resolve this issue that's been (at least partially) holding up the Linux work, here's a few builds:

FFmpeg r87486 (http://www.mediafire.com/file/r7tz60eunq8wv7m/ffmpeg_r87486.7z)
FFMS2 C-plugin r1145+104 (http://www.mediafire.com/file/ndpzuqq3m64m0rc/ffms2_r1145%2B104-avs%2Bvsp.7z)
AviSynth+ r2510 (VS2017) (http://www.mediafire.com/file/bmh4t99pc7apk95/avisynth__r2510-g6831004b-20170930.7z)
AviSynth+ r2509 (GCC 7.2.0/MinGW-w64 5.0.2) (http://www.mediafire.com/file/ku2an85e7gjf7cp/avisynth__r2509-gcctest.7z)

Includes both 32-bit and 64-bit in all packages. Windows XP supported by all builds. The 32-bit MSVC build of AviSynth+ and the FFMS2 C-plugin can be used on non-SSE2. The GCC builds of AviSynth+ require SSE2.

THE GCC BUILD IS FOR TESTING. The issue I was referring to above is that the 32-bit GCC build cannot be used by FFmpeg, because of the weirdness that comes with 32-bit builds, calling convention differences on Windows, and function decorations between GCC and MSVC. It's even a tiny lie that the 32-bit build can't be used by FFmpeg; there is a way that it can be made to work, but doing so would make that build of FFmpeg incompatible with the MSVC builds of AviSynth+ (with the possible exception of MSVC builds of FFmpeg being able to use MSVC builds of AviSynth+, but I don't know that for sure). The build of FFmpeg above is a standard build, and will work with the standard MSVC builds of AviSynth+ as well as the 64-bit GCC build of AviSynth+. This only ever affects Windows, since the underlying problems causing this are Windows-specific.

Additionally, the GCC builds of AviSynth+ shouldn't be able to use MSVC-built C++ plugins just due to the incompatibility between C++ implementations, but it is possible for the 64-bit build to use the 64-bit FFMS2 C-plugin (and likely, any other C plugins with 64-bit versions). AVISource also works, so there are at least two source filters that can be used with it. My ability to test under 64-bit Windows is almost non-existent, because I have to run it under a VM on a Silvermont under Ubuntu, running off an external USB 2.0 port. My tests with it under 64-bit Wine are what this information was gleaned from.

I'd like to be able to fix this properly so 32-bit GCC builds can be used with FFmpeg without breaking compatibility with MSVC. My attempts at forcing this have failed thus far. Trying to build as 32-bit with __stdcall ends up breaking compilation, and nothing I tried to force the function decorations into line worked. I'd assume it's actually that if we can fix the code so GCC doesn't choke when using __stdcall on 32-bit builds, it'd probably be okay (so long as I could get the decorations correct, and it wouldn't screw up building under MSVC or the 64-bit GCC build). I'm also really tired of trying to do so, so there's also a part of me that would probably be totally okay with it if we don't support building 32-bit AviSynth+ with GCC on Windows (as I said before, it's a Windows-specific issue; any future Linux support could use 32-bit with no problem, even if the market share for 32-bit Linux is dwindling pretty fast too).

[real.finder]

Japanese friend (he is not the Developer) give me this mod of avs+ that use CUDA

QTGMC Core i7-6700 https://i.imgur.com/gs5WsEM.png
CUDA版(KTGMC) GeForce GTX 1060 6GB https://i.imgur.com/kRc7bhg.png

KTGMC: QTGMC for CUDA https://github.com/nekopanda/AviSynthCUDAFilters/releases
AviSynth+CUDA https://github.com/nekopanda/AviSynthPlus/releases

well, I don't has nvidia gpu so I can't test that

[tuanden0]

Japanese friend (he is not the Developer) give me this mod of avs+ that use CUDA

QTGMC Core i7-6700 https://i.imgur.com/gs5WsEM.png
CUDA版(KTGMC) GeForce GTX 1060 6GB https://i.imgur.com/kRc7bhg.png

KTGMC: QTGMC for CUDA https://github.com/nekopanda/AviSynthCUDAFilters/releases
AviSynth+CUDA https://github.com/nekopanda/AviSynthPlus/releases

well, I don't has nvidia gpu so I can't test that

Here's my test with GTX 1060 3GB:
Without CUDA: https://i.imgur.com/W2WFT9R.png
With CUDA: https://i.imgur.com/aE1SbfM.png

I tried to remove DumpfilterGraph and it still work but no FPS change.
If I remove Prefetch then FPS go down to 48 and time go up to 2 min.
I put "OnCUDA" on all filteres but it's not work, except "OnCPU" work with source filter and FPS not change.

[poisondeathray]

Japanese friend (he is not the Developer) give me this mod of avs+ that use CUDA

QTGMC Core i7-6700 https://i.imgur.com/gs5WsEM.png
CUDA版(KTGMC) GeForce GTX 1060 6GB https://i.imgur.com/kRc7bhg.png

KTGMC: QTGMC for CUDA https://github.com/nekopanda/AviSynthCUDAFilters/releases
AviSynth+CUDA https://github.com/nekopanda/AviSynthPlus/releases

well, I don't has nvidia gpu so I can't test that




Thanks, looks interesting!


Just a suggestion, but should this fork and it's testing be moved to a separate thread ?

The readme's are in Japanese ,but google translate does an ok job I think

[poisondeathray]

I got the kqtgmc , knnedi3 , working with avisynth+cuda .

Some quick tests on a gtx860 were consistently slower than avisynth+mt for KQTGMC, and KNNEDI3 (ie. avisynth+mt on CPU was about 1.2-1.4x faster using the normal CPU versions QTGMC and NNEDI3), maybe a faster card would put it over the top . I didn't test validity/quality results yet.

The same .dll was able to run the "normal" avisynth+mt script as is too (ie. with prefetch(x) ), with the same speed



Here's my test with GTX 1060 3GB:
Without CUDA: https://i.imgur.com/W2WFT9R.png
With CUDA: https://i.imgur.com/aE1SbfM.png

I tried to remove DumpfilterGraph and it still work but no FPS change.
If I remove Prefetch then FPS go down to 48 and time go up to 2 min.
I put "OnCUDA" on all filteres but it's not work, except "OnCPU" work with source filter and FPS not change.

Look at the readme (use google translate) . You need to wrap in OnCPU, OnCUDA

Did you notice no speed change ? What about GPU-z ? monitor GPU card usage, or try device_index=x to swap GPU# (take out KNLMeansCL for testing now, because that will use GPU too)

Im guessing not all filters are accelerated, or maybe your card is as fast as CPU processing ?

[poisondeathray]

@tuanden0 - you have the same card as the developer, but a 3GB model instead of 6GB. He got 83.43fps vs. 27.33fps for QTGMC on "fast" preset

Just try the exact same script for now, to see if there is a speed difference for you

[vivan]

i5-4670k + gtx 1080
88 fps CPU, 430 fps CUDA

But script results do differ.
I need to upgrade my QTGMC...

[tuanden0]

@tuanden0 - you have the same card as the developer, but a 3GB model instead of 6GB. He got 83.43fps vs. 27.33fps for QTGMC on "fast" preset

Just try the exact same script for now, to see if there is a speed difference for you

Here you are :cool:
Without CUDA: https://i.imgur.com/TuO78nY.png
With CUDA: https://i.imgur.com/TUSWvuO.png
With CUDA 2: https://i.imgur.com/c06mL6c.png

:devil:

[real.finder]

I hope someone port that to use opencl (maybe Khanattila since he has experience in it)

so many people can use it

[poisondeathray]

i5-4670k + gtx 1080
88 fps CPU, 430 fps CUDA

But script results do differ.
I need to upgrade my QTGMC...


differ - did you mean qualitatively different results ?

[vivan]

differ - did you mean qualitatively different results ?They are just different, it's hard to say which one is better.
https://i.imgur.com/JRM9vJb.png
https://i.imgur.com/8AsGgNL.png

134 fps on 1920x1080 video ("Fast" Preset) :eek:

[jpsdr]

The following line works in standard avisynth but not in avs+ x64.

black = BlankClip(last, width=64, height=32, Color_yuv=color_black)

and probably the next (forgot to test, and i'm under standard avisynth without avs+ access while writing these lines).

white = BlankClip(last, width=64, height=32, Color_yuv=color_white)

[LigH]

In which way does it "not work"? Do you have any error messages?

I suppose it doesn't know color constants?

---------------------------
VirtualDub Error
---------------------------
Avisynth open failure:
I don't know what 'color_black' means.
(H:\Video\black-white.avs, line 1)
---------------------------
OK
---------------------------


That should be fixable by providing a color names import scriptlet (colors_rgb.avsi (https://github.com/dcherian/tools/blob/master/misc/avisynth-reader/avisynth/distrib/color_presets/colors_rgb.avsi) in plugins+ / plugins64+).

My former AviSynth 2.56 installation seems to have provided this file in AviSynth 2.5\plugins already.

But the color constants known in legacy AviSynth 2.55+ (http://avisynth.nl/index.php/Color_presets) are RGB colors, not YUV.
__

Actually, nope ... sorry. The file "colors_rgb.avsi" does exist in all my plugin directories for all AviSynth flavours, but is not auto-loaded. I have to Import() it explicitly to make it work.

[Yanak]

Already had similar issues with avs+ x64

blankclip(color=color_black) # doesn't work, " I don't know what color_black means "
blankclip(color=$000000) #works

Switched for Hex values when i needed it but did not suspected this could be a bug

[LigH]

Well, if you explicitly
Import("colors_rgb.avsi")
it works as well; it's just strange that auto-importing from the plugins auto-load directory doesn't work ... anymore? I thought it did, once.

[Groucho2004]

Well, if you explicitly
Import("colors_rgb.avsi")
it works as well; it's just strange that auto-importing from the plugins auto-load directory doesn't work ... anymore? I thought it did, once.See here (https://forum.doom9.org/showthread.php?p=1714618#post1714618).