Avisynth+

[qyot27]

Possibly connected to AVS Standard MergeChroma problem, here:- http://forum.doom9.org/showthread.php?p=1504231#post1504231
Was originally
MergeChroma (clip1, clip2, float Chromaweight=1.0)
IanB Added Alias
MergeChroma (clip1, clip2, float weight=1.0)

Perhaps it did not make it into AVS+

EDIT: And MergeLuma used LumaWeight, also added the Weight alias. [EDIT: About v2.6 Alpha 3, period].
The fork happened right around the run-up to 2.6a5 (the initial patchset was discussed in the Alpha 4 thread only 1 or 2 weeks before Alpha 5 was released), so anything added prior to that would be included automatically and wouldn't need specific porting. Commits from after Alpha 5 have been periodically reviewed and merged if there aren't any conflicts, or if there are few enough conflicts in a commit that the patch can still be updated easily and merged in.

[pinterf]

thanks
the weight part on yv12

Fixed in the development branch. Only 16 bit path worked correctly. MergeLuma and Merge was not affected. Thank you for the report.

[jpsdr]

Don't know where to put information, but Microsoft just released a new VS2015 Updt3 redistribuable : 14.0.24215 (the previous was 24212).
I thought i have to put this information here, as the redistribuable is sometimes critical...

[pinterf]

Huh, now I can see the end of the tunnel.

Almost all internal filters are ported to native 10-12-14-16 bit, and float formats, Planar RGB(A), RGB48 and 64.
Histogram and Overlay is still under development.

From Histogram only "Levels" is ported, it has a shiny new bits=xxx parameter, you can visualize YUV histogram with 9, 10, 11 or 12 bits precision. Use bits=12 if you have a 8K monitor :)
From Overlay modes so far only "add" is ported to 10-16 bits. Unfortunately, like Histogram sub-modes, each Overlay mode is a unique filter, so they have to be ported one-by-one.

And now, let's back to work...

[ajp_anton]

Will Overlay still convert everything to YUV444 internally? And what about Layer, will those two be merged at some point and simply be aliases for the same thing?

[pinterf]

Will Overlay still convert everything to YUV444 internally? And what about Layer, will those two be merged at some point and simply be aliases for the same thing?
Yes, at some point :)
Overlay still converts everything to 444 internally. Using 420 and 422 natively (when I was porting "add" method) was more than difficult (=time consuming), it would require rather a rewrite than a patch or conversion.

[real.finder]

Yes, at some point :)
Overlay still converts everything to 444 internally. Using 420 and 422 natively (when I was porting "add" method) was more than difficult (=time consuming), it would require rather a rewrite than a patch or conversion.

even in Y8?

[pinterf]

even in Y8?
Yes.

I have never used Overlay, but I had the feeling that it would be the ugliest part of the port. No wonder I left it to the last one :)

Overlay used internal converters for the basic color spaces (Y8, YV12, YUY2, RGB (PC.601/rec601) and YV24, that (at least for YV12 and YUY2) were much faster than simply doing "Invoke" for the similar avisynth core converters. I have the feeling that all this was programmed before YV24 color space have emerged.

Since in Avisynth plus we have much more possible input/output formats than before, first I simply replaced the internal converters with Invoke ConvertToYUV444. But it was slow, very slow (2-4 times slower than before) for YV12 and YUY2. I can live without YUY2, but you know, the goal is "not slower than before". At least not _that much_ slower.

Because core converters are generic, e.g. for YV12 the chroma gets properly resized with the appropriate method (using a generic avisynth resizer: bilinear AFAIK as default). YUY2 conversion in avisynth core first converts the frame to YV16 than converts it further to YV24, again: chroma resize takes place here, another Invoke, caching, etc. It has simply too much overhead.

Overlay's internal resizer is fast, because it is specific, simply spreads YV12 chroma to double size for YV24, and averages back when converting to YV24 again. In one simple pass. Y8 conversion to the internal 444 format is a simple luma copy plus fill chroma with neutral grey.

On the other side, the 444 format of Overlay filter has (had) special internal buffers holding the frame, so it even copied a standard YV24 frame to this internal 444 representation, and back when output was YV24.

This latter case is optimized now a bit, using avisynth's standard YV24 (now YUV444P8..16) frames, so at least the YV24 double conversion (from and to) is omitted now and the filter is a bit faster in general.

But because of that speed difference, I had to put back the YUY2 and YV12 conversions to use the existing converters of Overlay. All other conversions use avisynth's core converters.

Because of the speed difference experienced (why convert 4:2:0 to 4:4:4 then back?) I tried to implement a conversionless method, to have Overlay work with native 420 and 422 formats, but it would need more time.

[THEAST]

I am trying to manually build the latest version of Avisynth+ from the github repository using MSVC2015. I know that it is probably not officially supported but I thought I'd try anyway. I am using this build:

https://github.com/pinterf/AviSynthPlus/commit/547f536d28039c79bfb76d777701b83d9188cb8a

Everything seems to compile fine except the main stuff: the DirectShow plugin and Avisynth.dll.

For the former, the compilation stops here:

https://github.com/pinterf/AviSynthPlus/blob/MT/plugins/DirectShowSource/directshow_source.cpp#L112

And this is the error:

user-defined literal suffix does not match the earlier "__DATE__" PluginDirectShowSource d:\AviSynthPlus\plugins\DirectShowSource\directshow_source.cpp
cannot concatenate user-defined string literals with mismatched literal suffix identifiers PluginDirectShowSource D:\AviSynthPlus\plugins\DirectShowSource\directshow_source.cpp
invalid literal suffix '__DATE__'; literal operator or literal operator template 'operator ""__DATE__' not found PluginDirectShowSource D:\AviSynthPlus\plugins\DirectShowSource\directshow_source.cpp

For the latter the compilation stops here:
const char _AVS_VERSTR[] = AVS_VERSTR;
const char _AVS_COPYRIGHT[] = AVS_VERSTR AVS_COPYRIGHT;

This is from "AviSynthPlus\avs_core\core\main.cpp", line 113 and 114, but doesn't exist on the copy on github; I guess it is generated by cmake. It seems in my case, "AVS_VERSTR" seems to be undefined. I am probably doing something wrong here since I would expect cmake to define it. I tried defining it manually and the compilation went forward but still stopped here:

https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/filters/focus.cpp#L558

The error is:

'y': redefinition; different basic types AvsCore D:\AviSynthPlus\avs_core\filters\focus.cpp

Any idea how to fix these issues?

[pinterf]

For the former, the compilation stops here:

https://github.com/pinterf/AviSynthPlus/blob/MT/plugins/DirectShowSource/directshow_source.cpp#L112

And this is the error:

user-defined literal suffix does not match the earlier "__DATE__" PluginDirectShowSource d:\AviSynthPlus\plugins\DirectShowSource\directshow_source.cpp
cannot concatenate user-defined string literals with mismatched literal suffix identifiers PluginDirectShowSource D:\AviSynthPlus\plugins\DirectShowSource\directshow_source.cpp
invalid literal suffix '__DATE__'; literal operator or literal operator template 'operator ""__DATE__' not found PluginDirectShowSource D:\AviSynthPlus\plugins\DirectShowSource\directshow_source.cpp


Are you sure that you have switched to the MT branch?
This was an old problem, had to put spaces before (around?) __DATE__ and __TIME__


https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/filters/focus.cpp#L558

The error is:

'y': redefinition; different basic types AvsCore D:\AviSynthPlus\avs_core\filters\focus.cpp

Any idea how to fix these issues?

The same for this. This compilation error was fixed already. Check the function, the loop variable should be y0 for the current source and not y.

(VS2015 is the "official" compiler for the project)

[THEAST]

Ouch, you are right, I was on the master branch. I knew I was making an obvious mistake. I will switch to MT and try again, sorry for the inconvenience.

P.S. The compilation guide on the first page recommends MSVC 2013, that is why I thought 2013 is the maximum version that is officially supported.

[pinterf]

You will need Chikuzen's pull request for turn.cpp and .h. that I simply copied for my mt branch w/o properly using git.
See them in the current avs+ pull request list

[qyot27]

Or for ease of use:
git clone git://github.com/pinterf/AviSynthPlus.git
cd AviSynthPlus
git checkout MT
git remote add chikuzen git://github.com/chikuzen/AviSynthPlus.git
git fetch chikuzen
git checkout -b turn chikuzen/turn
git checkout MT
git merge turn
and then go about compiling.

[THEAST]

Right on time, I just got to the part where Avisynth still didn't compile because the turn functions were undefined. :p

Edit: Okay, it finally worked, thank you for the help. :)

[pinterf]

Right on time, I just got to the part where Avisynth still didn't compile because the turn functions were undefined. :p

Edit: Okay, it finally worked, thank you for the help. :)

When you find something strange, don't hesitate to report it.

If someone is curious about what has been done in the past month, read my comments here: https://github.com/AviSynth/AviSynthPlus/pull/101 since I comment the changes in the pull request of the mainstream project.

[kypec]

P.S. The compilation guide on the first page recommends MSVC 2013, that is why I thought 2013 is the maximum version that is officially supported.

Not that I would be compiling Avisynth+ myself but the recommended tools usually mean the minimum supported version. Compilers should be mostly backward compatible.:p

[THEAST]

@kypec, bad assumption on my part. ;p

Anyway, I built the latest revision with both MSVC 2015 Update 3 and ICC 2016 Update 4 and compared with r1689 that I was using before using AVSMeter. For a SD video with QTGMC (medium options) and prefetch(12), the latest revision built with MSVC is 0.5-1% faster than 1689. The iCC version is actually slower than both which is very surprising. For another script with a 1080p video resized to 720p using Spline36 and running with one thread, latest revision built with MSVC and r1689 have the same speed while the ICC version is again slower than both. Fortunately, unlike the revisions after 1689 that I tested before Avisynth+ development was resumed, the latest build does not run into a deadlock with QTGMC.

Other than these, I am also experiencing the "Only a single prefetcher is allowed per script." error when using DGDecode_mpeg2source, which was reported by bilditup1 a few pages ago (http://forum.doom9.org/showthread.php?p=1779369#post1779369). Is there any fix or workaround for this?

I also remember that somewhere after r1689, "SetFilterMTMode("", 2)" stopped working and had to be replaced by "SetFilterMTMode("DEFAULT_MT_MODE", 2)" for MT to work correctly, but it seems both work as expected in the latest revision. Can somebody comment which one is considered the official syntax now?

[LigH]

Why posting an URL as CODE insted of a link (http://forum.doom9.org/showthread.php?p=1779369#post1779369)?

[THEAST]

@LigH, sorry, bad habit. I have Linkification installed which makes all links clickable, didn't realize others have to copy/paste the link into address bar.

[Groucho2004]

The iCC version is actually slower than both which is very surprising.
Not at all. AVS+ has lots of the performance critical code already in SIMD intrinsics which means that the Intel compiler can't improve anything - probably make it worse by being overzealous in its optimization efforts.

[Sm3n]

Hi, here is my issue,

I can't reach the same speed I get with the old MTmode with the MT-pfmod. Why is that?

I have to give lot of memory but it's useless based on what I read.

my scripts:

Old MT:
SetMTMode(3,4)
SetMemoryMax(1600)
DGSource("Movie1.dgi",fieldop=0,deinterlace=0)+DGSource("Movie2.dgi",fieldop=0,deinterlace=0)+DGSource("Movie3.dgi",fieldop=0,deinterlace=0)+DGSource("Movie4.dgi",fieldop=0,deinterlace=0)
SetMTMode(2)
QTGMC(preset="Medium", FPSDivisor=2, EdiThreads=3)
#crop(2, 2, -2, -2)
Spline36Resize(1280,720)

New MT:
SetMemoryMax(10000)
SetFilterMTMode("DEFAULT_MT_MODE",2)#DEFAULT_MT_MODE MT_NICE_FILTER MT_MULTI_INSTANCE
SetFilterMTMode("DGSource",3)
DGSource("Movie1.dgi",fieldop=0,deinterlace=0)+DGSource("Movie2.dgi",fieldop=0,deinterlace=0)+DGSource("Movie3.dgi",fieldop=0,deinterlace=0)+DGSource("Movie4.dgi",fieldop=0,deinterlace=0)
QTGMC(preset="Medium", FPSDivisor=2, EdiThreads=3)
#crop(2, 2, -2, -2)
Spline36Resize(1280,720)
prefetch(7)


During avsmeter and x264 process the old MTmode is more stable and faster.
Doesn't make sense, is it?

[Groucho2004]

I can't reach the same speed I get with the old MTmode with the MT-pfmod. Why is that?

I have to give lot of memory but it's useless based on what I read.

...

New MT:
SetMemoryMax(10000)
SetFilterMTMode("DEFAULT_MT_MODE",2)#DEFAULT_MT_MODE MT_NICE_FILTER MT_MULTI_INSTANCE
SetFilterMTMode("DGSource",3)
DGSource("Movie1.dgi",fieldop=0,deinterlace=0)+DGSource("Movie2.dgi",fieldop=0,deinterlace=0)+DGSource("Movie3.dgi",fieldop=0,deinterlace=0)+DGSource("Movie4.dgi",fieldop=0,deinterlace=0)
QTGMC(preset="Medium", FPSDivisor=2, EdiThreads=3)
#crop(2, 2, -2, -2)
Spline36Resize(1280,720)
prefetch(7)

- Use the latest build of AVS+ (r2172)
- Download and use the .avsi with pre-defined MT Modes (http://publishwith.me/ep/pad/view/ro.rDkwcdWn4k9/latest) for various plugins.
- Disable the internal multithreading of filters (DftThreads = 1, EdiThreads = 1)
- Reduce/experiment with the value for Prefetch()

[Sm3n]

- Use the latest build of AVS+ (r2172)
- Download and use the .avsi with pre-defined MT Modes (http://publishwith.me/ep/pad/view/ro.rDkwcdWn4k9/latest) for various plugins.
- Disable the internal multithreading of filters (DftThreads = 1, EdiThreads = 1)
- Reduce/experiment with the value for Prefetch()

Cheers! I thought I was using the last AVS+

Can you specify the exact name of the .avsi? I put it in plugins directory, right?

[StainlessS]

Sm3n,
Go to the link provided by Groucho2004, Click DownLoad as Plain Txt (to the right of page).
Rename the result from "ro.rDkwcdWn4k9-rev.493.txt" to [EDIT: eg] "AnythingYouLike.avsi", and put in Plugins.

[Sm3n]

Sm3n,
Go to the link provided by Groucho2004, Click DownLoad as Plain Txt (to the right of page).
Rename the result from "ro.rDkwcdWn4k9-rev.493.txt" to "AnythingYouLike.avsi", and put in Plugins.

Thank you. That's what I did.

I finally came close to the speed I wanted to achieve. Still some adjustments to make but should be good enought to keep a version up-to-date rather than this old thing.

thank you all :)

[qyot27]

Has anyone else noticed that Debug builds don't work with FFmpeg but Release builds do? Because I ran into that problem just now while hammering out some issues with Ninja and I wasn't sure if that's expected.

[pinterf]

What does it mean that they don't work? Random crashes?

[qyot27]

Crash on startup. It tries to load AviSynth.dll and immediately crashes, but only if AviSynth+ was built as Debug. Release builds (-DCMAKE_BUILD_TYPE:STRING=Release) work as expected.

The reason this actually matters is that the non-MSVC generators seem to default to Debug. Or maybe it's just Ninja that defaults to Debug if you don't specify build type, and NMake wouldn't. But NMake is a generator of last resort.

[pinterf]

Could not reproduce.

Avs+ debug build from the last dev sources, and an ffmpeg.exe found somewhere on my disk

My avs script:
Avisource("Hi8.avi").assumefps(25,1).trim(0, 499)
ConvertToYUV444()

and a simple batch
ffmpeg -i smdff.avs -c:v libx264 -preset veryslow -crf 24 "Output.264"

ffmpeg version:
ffmpeg version 3.0 Copyright (c) 2000-2016 the FFmpeg developers
built with gcc 5.3.0 (GCC)
configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-avisynth
--enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv --enable-libass
--enable-libbluray --enable-libbs2b --enable-libcaca --enable-libdcadec --enable-libfreetype
--enable-libgme --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb
--enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libschroedinger
--enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-amrwbenc
--enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265
--enable-libxavs --enable-libxvid --enable-libzimg --enable-lzma --enable-decklink --enable-zlib
libavutil 55. 17.103 / 55. 17.103
libavcodec 57. 24.102 / 57. 24.102
libavformat 57. 25.100 / 57. 25.100
libavdevice 57. 0.101 / 57. 0.101
libavfilter 6. 31.100 / 6. 31.100
libswscale 4. 0.100 / 4. 0.100
libswresample 2. 0.101 / 2. 0.101
libpostproc 54. 0.100 / 54. 0.100

[qyot27]

AviSynth+ built from qyot27/mingwfix branch, Debug:
cmake ../AviSynthPlus -G "Visual Studio 12 2013" -DENABLE_PLUGINS:bool=off
cmake --build . --config Debug
C:\Users\Stephen\Documents\ffbuild>ffplay -i Test.avs
ffplay version r81781 git-248a336 Copyright (c) 2003-2016 the FFmpeg developers
built on Sep 26 2016 14:28:14 with gcc 6.2.0 (GCC)
libavutil 55. 30.100 / 55. 30.100
libavcodec 57. 58.100 / 57. 58.100
libavformat 57. 50.100 / 57. 50.100
libavdevice 57. 0.102 / 57. 0.102
libavfilter 6. 63.100 / 6. 63.100
libavresample 3. 0. 0 / 3. 0. 0
libswscale 4. 1.100 / 4. 1.100
libswresample 2. 1.100 / 2. 1.100
libpostproc 54. 0.100 / 54. 0.100
nan : 0.000 fd= 0 aq= 0KB vq= 0KB sq= 0B f=0/0
C:\Users\Stephen\Documents\ffbuild>gdb ffplay
GNU gdb (GDB) 7.9
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-msys".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Traceback (most recent call last):
File "<string>", line 3, in <module>
ImportError: No module named libstdcxx.v6.printers
/etc/gdbinit:6: Error in sourced command file:
Error while executing Python code.
Reading symbols from ffplay...(no debugging symbols found)...done.
(gdb) r -i test.avs
Starting program: /c/Users/Stephen/Documents/ffbuild/ffplay -i test.avs
[New Thread 4812.0x152c]
[New Thread 4812.0x187c]
[New Thread 4812.0x113c]
[New Thread 4812.0xe24]
ffplay version r81781 git-248a336 Copyright (c) 2003-2016 the FFmpeg developers
built on Sep 26 2016 14:28:14 with gcc 6.2.0 (GCC)
libavutil 55. 30.100 / 55. 30.100
libavcodec 57. 58.100 / 57. 58.100
libavformat 57. 50.100 / 57. 50.100
libavdevice 57. 0.102 / 57. 0.102
libavfilter 6. 63.100 / 6. 63.100
libavresample 3. 0. 0 / 3. 0. 0
libswscale 4. 1.100 / 4. 1.100
libswresample 2. 1.100 / 2. 1.100
libpostproc 54. 0.100 / 54. 0.100
[New Thread 4812.0xed0]
[New Thread 4812.0x19f4]
warning: DllMain: hModule=0x51a80000, ulReason=1, lpReserved=0x00000000, gRefCnt = 0
[New Thread 4812.0x19fc] 0 aq= 0KB vq= 0KB sq= 0B f=0/0
warning: DllMain: hModule=0x51a80000, ulReason=2, lpReserved=0x00000000, gRefCnt = 0
[New Thread 4812.0x12c8]
warning: DllMain: hModule=0x51a80000, ulReason=2, lpReserved=0x00000000, gRefCnt = 0
[New Thread 4812.0x15a0]
warning: DllMain: hModule=0x51a80000, ulReason=2, lpReserved=0x00000000, gRefCnt = 0
[New Thread 4812.0x18f0]
warning: DllMain: hModule=0x51a80000, ulReason=2, lpReserved=0x00000000, gRefCnt = 0
warning: StringDump: Allocating new stringblock.
warning: ScriptEnvironment::Invoke Import= 0KB sq= 0B f=0/0
warning: ScriptEnvironment::Invoke Eval
warning: ScriptEnvironment::Invoke Version
warning: ScriptEnvironment::GetNewFrame, no free entry in FrameRegistry. Requested vfb size=147487 memused=0 memmax=5132
27776
warning: Debug Assertion Failed!

Program: C:\Users\Stephen\Documents\ffbuild\ffplay.exe
File: f:\dd\vctools\crt\crtw32\stdio\output.c
Line: 1125

Expression: ("Incorrect format specifier", 0)

For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts.

(Press Retry to debug the application)
gdb: unknown target exception 0xc0000409 at 0x5211a893 0B f=0/0

Program received signal ?, Unknown signal.
[Switching to Thread 4812.0x19f4]
0x5211a893 in invoke_watson () from /c/WINDOWS/SYSTEM32/MSVCR120D.dll
(gdb) bt
#0 0x5211a893 in invoke_watson () from /c/WINDOWS/SYSTEM32/MSVCR120D.dll
#1 0x5211a874 in invalid_parameter () from /c/WINDOWS/SYSTEM32/MSVCR120D.dll
#2 0x520d4f73 in mbctombb_l () from /c/WINDOWS/SYSTEM32/MSVCR120D.dll
#3 0x5206256e in vsnprintf_c_l () from /c/WINDOWS/SYSTEM32/MSVCR120D.dll
#4 0x52062798 in vsnprintf_s_l () from /c/WINDOWS/SYSTEM32/MSVCR120D.dll
#5 0x5206261e in vsnprintf_s () from /c/WINDOWS/SYSTEM32/MSVCR120D.dll
#6 0x52120df0 in VCrtDbgReportA () from /c/WINDOWS/SYSTEM32/MSVCR120D.dll
#7 0x521273d4 in MSVCR120D!_CrtDbgReport () from /c/WINDOWS/SYSTEM32/MSVCR120D.dll
#8 0x5212738d in MSVCR120D!_CrtDbgReport () from /c/WINDOWS/SYSTEM32/MSVCR120D.dll
#9 0x51ae5053 in avs_clip_get_error () from /c/Users/Stephen/Documents/ffbuild/avisynth.DLL
#10 0x00000000 in ?? ()

Attempting to build pinterf/MT as Debug fails:
cmake ../AviSynthPlus -G "Visual Studio 12 2013"
cmake --build . --config Debug
Build FAILED.

"C:\Users\Stephen\Documents\avisynth_build\ALL_BUILD.vcxproj" (default target) (1) ->
"C:\Users\Stephen\Documents\avisynth_build\avs_core\AvsCore.vcxproj" (default target) (3) ->
(ClCompile target) ->
C:\Program Files\Microsoft Visual Studio 12.0\VC\include\xutility(2715): warning C4996: 'std::_Fill_n': Function call
with parameters that may be unsafe - this call relies on the caller to check that the passed values are correct. To di
sable this warning, use -D_SCL_SECURE_NO_WARNINGS. See documentation on how to use Visual C++ 'Checked Iterators' [C:\U
sers\Stephen\Documents\avisynth_build\avs_core\AvsCore.vcxproj]
C:\Program Files\Microsoft Visual Studio 12.0\VC\include\xutility(2715): warning C4996: 'std::_Fill_n': Function call
with parameters that may be unsafe - this call relies on the caller to check that the passed values are correct. To di
sable this warning, use -D_SCL_SECURE_NO_WARNINGS. See documentation on how to use Visual C++ 'Checked Iterators' [C:\U
sers\Stephen\Documents\avisynth_build\avs_core\AvsCore.vcxproj]
C:\Program Files\Microsoft Visual Studio 12.0\VC\include\xutility(2715): warning C4996: 'std::_Fill_n': Function call
with parameters that may be unsafe - this call relies on the caller to check that the passed values are correct. To di
sable this warning, use -D_SCL_SECURE_NO_WARNINGS. See documentation on how to use Visual C++ 'Checked Iterators' [C:\U
sers\Stephen\Documents\avisynth_build\avs_core\AvsCore.vcxproj]
C:\Program Files\Microsoft Visual Studio 12.0\VC\include\xutility(2715): warning C4996: 'std::_Fill_n': Function call
with parameters that may be unsafe - this call relies on the caller to check that the passed values are correct. To di
sable this warning, use -D_SCL_SECURE_NO_WARNINGS. See documentation on how to use Visual C++ 'Checked Iterators' [C:\U
sers\Stephen\Documents\avisynth_build\avs_core\AvsCore.vcxproj]
C:\Program Files\Microsoft Visual Studio 12.0\VC\include\xutility(2715): warning C4996: 'std::_Fill_n': Function call
with parameters that may be unsafe - this call relies on the caller to check that the passed values are correct. To di
sable this warning, use -D_SCL_SECURE_NO_WARNINGS. See documentation on how to use Visual C++ 'Checked Iterators' [C:\U
sers\Stephen\Documents\avisynth_build\avs_core\AvsCore.vcxproj]
C:\Program Files\Microsoft Visual Studio 12.0\VC\include\xutility(2715): warning C4996: 'std::_Fill_n': Function call
with parameters that may be unsafe - this call relies on the caller to check that the passed values are correct. To di
sable this warning, use -D_SCL_SECURE_NO_WARNINGS. See documentation on how to use Visual C++ 'Checked Iterators' [C:\U
sers\Stephen\Documents\avisynth_build\avs_core\AvsCore.vcxproj]
C:\Program Files\Microsoft Visual Studio 12.0\VC\include\xutility(2715): warning C4996: 'std::_Fill_n': Function call
with parameters that may be unsafe - this call relies on the caller to check that the passed values are correct. To di
sable this warning, use -D_SCL_SECURE_NO_WARNINGS. See documentation on how to use Visual C++ 'Checked Iterators' [C:\U
sers\Stephen\Documents\avisynth_build\avs_core\AvsCore.vcxproj]
C:\Program Files\Microsoft Visual Studio 12.0\VC\include\xutility(2715): warning C4996: 'std::_Fill_n': Function call
with parameters that may be unsafe - this call relies on the caller to check that the passed values are correct. To di
sable this warning, use -D_SCL_SECURE_NO_WARNINGS. See documentation on how to use Visual C++ 'Checked Iterators' [C:\U
sers\Stephen\Documents\avisynth_build\avs_core\AvsCore.vcxproj]


"C:\Users\Stephen\Documents\avisynth_build\ALL_BUILD.vcxproj" (default target) (1) ->
"C:\Users\Stephen\Documents\avisynth_build\avs_core\AvsCore.vcxproj" (default target) (3) ->
(ClCompile target) ->
C:\Users\Stephen\Documents\AviSynthPlus\avs_core\filters\focus.cpp(838): error C2899: typename cannot be used outside
a template declaration [C:\Users\Stephen\Documents\avisynth_build\avs_core\AvsCore.vcxproj]

8 Warning(s)
1 Error(s)

Time Elapsed 00:01:32.37

C:\Users\Stephen\Documents\avisynth_build>
Trying to build Release also fails on the error in focus.cpp. Just to get it to compile I changed line 838 from typedef typename to just typedef. The result is exactly the same as the mingwfix branch:
C:\Users\Stephen\Documents\ffbuild>gdb ffplay
GNU gdb (GDB) 7.9
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-msys".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Traceback (most recent call last):
File "<string>", line 3, in <module>
ImportError: No module named libstdcxx.v6.printers
/etc/gdbinit:6: Error in sourced command file:
Error while executing Python code.
Reading symbols from ffplay...(no debugging symbols found)...done.
(gdb) r -i test.avs
Starting program: /c/Users/Stephen/Documents/ffbuild/ffplay -i test.avs
[New Thread 1816.0x17cc]
[New Thread 1816.0x1fe8]
[New Thread 1816.0x1a74]
[New Thread 1816.0x1c1c]
ffplay version r81781 git-248a336 Copyright (c) 2003-2016 the FFmpeg developers
built on Sep 26 2016 14:28:14 with gcc 6.2.0 (GCC)
libavutil 55. 30.100 / 55. 30.100
libavcodec 57. 58.100 / 57. 58.100
libavformat 57. 50.100 / 57. 50.100
libavdevice 57. 0.102 / 57. 0.102
libavfilter 6. 63.100 / 6. 63.100
libavresample 3. 0. 0 / 3. 0. 0
libswscale 4. 1.100 / 4. 1.100
libswresample 2. 1.100 / 2. 1.100
libpostproc 54. 0.100 / 54. 0.100
[New Thread 1816.0x1cb4]
[New Thread 1816.0x1c60]
warning: DllMain: hModule=0x51250000, ulReason=1, lpReserved=0x00000000, gRefCnt = 0
[New Thread 1816.0x1fac] 0 aq= 0KB vq= 0KB sq= 0B f=0/0
warning: DllMain: hModule=0x51250000, ulReason=2, lpReserved=0x00000000, gRefCnt = 0
[New Thread 1816.0x1778]
warning: DllMain: hModule=0x51250000, ulReason=2, lpReserved=0x00000000, gRefCnt = 0
[New Thread 1816.0xe2c]
warning: DllMain: hModule=0x51250000, ulReason=2, lpReserved=0x00000000, gRefCnt = 0
[New Thread 1816.0x1ce8]
warning: DllMain: hModule=0x51250000, ulReason=2, lpReserved=0x00000000, gRefCnt = 0
warning: StringDump: Allocating new stringblock.
warning: ScriptEnvironment::Invoke Import= 0KB sq= 0B f=0/0
warning: ScriptEnvironment::Invoke Eval
warning: ScriptEnvironment::Invoke Version
warning: ScriptEnvironment::GetNewFrame, no free entry in FrameRegistry. Requested vfb size=147487 memused=0 memmax=5132
27776
warning: Debug Assertion Failed!

Program: C:\Users\Stephen\Documents\ffbuild\ffplay.exe
File: f:\dd\vctools\crt\crtw32\stdio\output.c
Line: 1125

Expression: ("Incorrect format specifier", 0)

For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts.

(Press Retry to debug the application)
gdb: unknown target exception 0xc0000409 at 0x511ca893 0B f=0/0

Program received signal ?, Unknown signal.
[Switching to Thread 1816.0x1c60]
0x511ca893 in invoke_watson () from /c/WINDOWS/SYSTEM32/MSVCR120D.dll
(gdb) bt
#0 0x511ca893 in invoke_watson () from /c/WINDOWS/SYSTEM32/MSVCR120D.dll
#1 0x511ca874 in invalid_parameter () from /c/WINDOWS/SYSTEM32/MSVCR120D.dll
#2 0x51184f73 in mbctombb_l () from /c/WINDOWS/SYSTEM32/MSVCR120D.dll
#3 0x5111256e in vsnprintf_c_l () from /c/WINDOWS/SYSTEM32/MSVCR120D.dll
#4 0x51112798 in vsnprintf_s_l () from /c/WINDOWS/SYSTEM32/MSVCR120D.dll
#5 0x5111261e in vsnprintf_s () from /c/WINDOWS/SYSTEM32/MSVCR120D.dll
#6 0x511d0df0 in VCrtDbgReportA () from /c/WINDOWS/SYSTEM32/MSVCR120D.dll
#7 0x511d73d4 in MSVCR120D!_CrtDbgReport () from /c/WINDOWS/SYSTEM32/MSVCR120D.dll
#8 0x511d738d in MSVCR120D!_CrtDbgReport () from /c/WINDOWS/SYSTEM32/MSVCR120D.dll
#9 0x512c6cc3 in avs_clip_get_error () from /c/Users/Stephen/Documents/ffbuild/avisynth.DLL
#10 0x00000000 in ?? ()
(gdb)

[pinterf]

Trying to build Release also fails on the error in focus.cpp. Just to get it to compile I changed line 838 from typedef typename to just typedef. The result is exactly the same as the mingwfix branch:

I found these articles:
http://stackoverflow.com/questions/19225458/error-c2899-typename-cannot-be-used-outside-a-template-declaration
http://stackoverflow.com/questions/6076015/typename-outside-of-template
"It doesn't matter anymore whether or not a use of typename QualifiedName happens in a template or not, in C++0x. That is, the following is perfectly legal for C++0x.
[...]
In C++03, typename could only be used inside of a template. And the explicit specialization in your code is not a template. There are no template<typename T ...> clauses (all parameters in your code are fixed). "

Did you enable c++11 option for the compiler?

[pinterf]

I have to look at something.

This debug print is ok:
"ScriptEnvironment::GetNewFrame, no free entry in FrameRegistry. Requested vfb size=147487 memused=0 memmax=513227776"

Then we get the error chain:
"warning: Debug Assertion Failed!

Program: C:\Users\Stephen\Documents\ffbuild\ffplay.exe
File: f:\dd\vctools\crt\crtw32\stdio\output.c
Line: 1125

Expression: ("Incorrect format specifier", 0)"

I think one of the debug output printf parameters is invalid for that build. I have to track down the culprit line. I suspect a size_t of int64 format specifier.

Edit:
Line 1678 of avisynth.cpp: could you replace the %7Iu and %6Iu to %7zu and %6zu?

"_snprintf(buf, 255, "ScriptEnvironment::GetNewFrame NEW METHOD EXACT hit! VideoFrameListSize=%7Iu GotSize=%7Iu FrReg.Size=%6Iu vfb=%p frame=%p SeekTime:%f\n", videoFrameListSize, vfb_size, FrameRegistry2.size(), vfb, frame, elapsed_seconds.count())";

Edit2:
Please, check it:
VS2015 surely knows about the cross-platform %zu specifier for size_t, but VS2013 may not recognize it, and expects %Iu there. VS2013 probably will not fail just prints "zu" instead.
(Remark: we should stay with %zu)

[qyot27]

I found these articles:
http://stackoverflow.com/questions/19225458/error-c2899-typename-cannot-be-used-outside-a-template-declaration
http://stackoverflow.com/questions/6076015/typename-outside-of-template
"It doesn't matter anymore whether or not a use of typename QualifiedName happens in a template or not, in C++0x. That is, the following is perfectly legal for C++0x.
[...]
In C++03, typename could only be used inside of a template. And the explicit specialization in your code is not a template. There are no template<typename T ...> clauses (all parameters in your code are fixed). "

Did you enable c++11 option for the compiler?
VS2013 always uses C++11. That quote has to do with VS2010.



I have to look at something.

This debug print is ok:
"ScriptEnvironment::GetNewFrame, no free entry in FrameRegistry. Requested vfb size=147487 memused=0 memmax=513227776"

Then we get the error chain:
"warning: Debug Assertion Failed!

Program: C:\Users\Stephen\Documents\ffbuild\ffplay.exe
File: f:\dd\vctools\crt\crtw32\stdio\output.c
Line: 1125

Expression: ("Incorrect format specifier", 0)"

I think one of the debug output printf parameters is invalid for that build. I have to track down the culprit line. I suspect a size_t of int64 format specifier.

Edit:
Line 1678 of avisynth.cpp: could you replace the %7Iu and %6Iu to %7zu and %6zu?

"_snprintf(buf, 255, "ScriptEnvironment::GetNewFrame NEW METHOD EXACT hit! VideoFrameListSize=%7Iu GotSize=%7Iu FrReg.Size=%6Iu vfb=%p frame=%p SeekTime:%f\n", videoFrameListSize, vfb_size, FrameRegistry2.size(), vfb, frame, elapsed_seconds.count())";

Edit2:
Please, check it:
VS2015 surely knows about the cross-platform %zu specifier for size_t, but VS2013 may not recognize it, and expects %Iu there. VS2013 probably will not fail just prints "zu" instead.
(Remark: we should stay with %zu)
Nope, same error with %zu.

[Sm3n]

- Use the latest build of AVS+ (r2172)
- Download and use the .avsi with pre-defined MT Modes (http://publishwith.me/ep/pad/view/ro.rDkwcdWn4k9/latest) for various plugins.
- Disable the internal multithreading of filters (DftThreads = 1, EdiThreads = 1)
- Reduce/experiment with the value for Prefetch()

I wanted to thank you again because thanks to this line "DftThreads = 1, EdiThreads = 1" my encoding process is way better (for now) than it was. I had a lot of x264 crashes since the update to Avs+ rxxxx, now it's over. I also could set the memorymax to a lower amount (2000) and prefetch (4) as well.

[THEAST]

@pinterf, would you kindly comment on the two points I mentioned here (http://forum.doom9.org/showthread.php?p=1781477#post1781477)?

[pinterf]

@pinterf, would you kindly comment on the two points I mentioned here (http://forum.doom9.org/showthread.php?p=1781477#post1781477)?

"Only a single prefetcher is allowed per script."
I cannot help you with this at the moment, ultim will investigate it after his busy weeks are over.

Regarding the optimizations:

In short: I don't know why you have experienced slower code with ICC.

Most of the time consuming tasks (filters, conversions, resizers) are directly programmed in sse2 intrinsics in the avs core. In a few cases ssse3 or sse4.1 is used.
We can regard them to be near optimal, as least for processors from the previous decade.
MMX code still exists for historical reasons in 32 bit avs versions.

32 bit Avisynth is compiled with /arch:SSE by default.
However, some newer high bit-depth parts that are in C, could easily gain from a /arch:SSE2 switch.

I don't know if avs+ should support pre-SSE2 processors in the future (we talk about 32 bit version), because it's not fair to give slower version to the existing 99.9% (assumption) of the users (nor environment friendly :-))

And back to the ICC vs VS2015:
When you are compiling avs+ with Intel C, you can set the primary target, e.g. SSE2 and I recommend to set a secondary target e.g. SSE4.2 or AVX2 for alternative code paths. I don't know if you have set this option or not.

I've seen that even VS2015 can generate alternative SSE4.2 version of the same C code and runs that version instead of SSE2 path.

Intel is very good at vectorization, I experienced a minimum of 5% gain for mvtools2 (ICC vs. VS2015 version). It would be even better with smart hints (tell that pointers are aligned, typical loop size, etc.), these are unavailable with current VS2015.

But for 8 bit video filters, the core is already optimized, and chooses hand-made SSE2 versions of the functions, automatically.

Even on VS2015 the difference between SSE2 optimized C vs. SSE2 intrinsics become near zero for some simple tasks.
And sometimes (just by seeing the generated code, see later) a compiler generated AVX2 path can be faster than a hand-made SSE2 version. But unfortunately AVS+ cannot decide (yet) whether using an AVX2 version from C code is faster than the pre-programmed SSE2 version.

Plus, when using intrinsics instead of direct asm, compiler can decide on generating faster asm code for the same intrinsic command. Using less registers, and using more efficient asm commands.

Nowadays AVX2 is already available on most i3-i7 processors from the recent years. AVX2 is really a good option as it has the same integer commands for 256 bit as SSE2 has in 128 bits.

I have only an AVX capable i7, and was playing to add AVX/AVX2 versions to some functions in mvtools2, while the main DLL is still compiles with SSE2. It works nicely, if I put the AVX/AVX2 specific things in distinct source files and set the forced AVX or AVX2 compilation flags only for these files.

These files that are intended to run on AVX, can hold not only C but existing SSE2 code, that is compiled to a more efficient one.
The only caveat of this, that when we choose the right function, have to know whether the AVX(2) C version is faster than the original SSE2 code and then choose that.

Finally an example, that shows us the possible drawback of running SSE2 version instead of a smartly compiled C. The avs core will always use SSE2 version of a function if it exists even if it would sub-optimal.

I was just experimenting with replacing the C code with SSE2 on a 10-16bit integer -> 32 bit float format conversion.

AVS (/arch:sse) C version vs. handmade SSE2: huge SSE2 win
AVS (/arch:sse2) C version vs. handmade SSE2: tie or minor difference.
(I can easily force C routines when developing)

C Code:

for (int x = 0; x < src_width; x++)
{
dstp_uint16[x] = srcp_uint16[x] * float_factor;
}


Avisynth 32 with SSE option:

$LN17@convert_ui:
movzx eax, WORD PTR [ebx-4]
lea ebx, DWORD PTR [ebx+8]
fld ST(0)
mov DWORD PTR tv813[esp+32], eax
fild DWORD PTR tv813[esp+32]
fstp QWORD PTR tv812[esp+32]
fld QWORD PTR tv812[esp+32]
fmul ST(0), ST(1)
fstp DWORD PTR [edx-8]
movzx eax, WORD PTR [ebx-10]
mov DWORD PTR tv808[esp+32], eax
fild DWORD PTR tv808[esp+32]
fstp QWORD PTR tv807[esp+32]
fld QWORD PTR tv807[esp+32]
fmul ST(0), ST(1)
fstp DWORD PTR [edx-4]
movzx eax, WORD PTR [ebx-8]
mov DWORD PTR tv803[esp+32], eax
fild DWORD PTR tv803[esp+32]
fstp QWORD PTR tv802[esp+32]
fld QWORD PTR tv802[esp+32]
fmul ST(0), ST(1)
fstp DWORD PTR [edx]
movzx eax, WORD PTR [ebx-6]
mov DWORD PTR tv797[esp+32], eax
fild DWORD PTR tv797[esp+32]
fstp QWORD PTR tv796[esp+32]
fmul QWORD PTR tv796[esp+32]
fstp DWORD PTR [edx+4]
add edx, 16 ; 00000010H
sub esi, 1
jne SHORT $LN17@convert_ui


Avisynth 32 with SSE2 option:
Smart recognition of vectorization of 4 pixels plus loop unrolling
SSE2 by VS2015 (4*uint16->4*float)xUnrollBy2
$LL7@convert_ui:
movq xmm1, QWORD PTR [ebp+ecx*2]
xorps xmm0, xmm0
punpcklwd xmm1, xmm0
cvtdq2ps xmm0, xmm1
mulps xmm0, xmm3
movups XMMWORD PTR [ebx+ecx*4], xmm0
movq xmm1, QWORD PTR [ebp+ecx*2+8]
xorps xmm0, xmm0
punpcklwd xmm1, xmm0
cvtdq2ps xmm0, xmm1
mulps xmm0, xmm3
movups XMMWORD PTR [ebx+ecx*4+16], xmm0
add ecx, 8
cmp ecx, esi
jl SHORT $LL7@convert_ui


Avisynth 32 with AVX2 option:
Smart recognition of vectorization of 8 pixels plus loop unrolling
AVX2 by VS2015: (8*uint16->8*float)xUnrollBy2
$LL7@convert_ui:
vpmovzxwd ymm0, XMMWORD PTR [esi+ecx*2]
vcvtdq2ps ymm0, ymm0
vmulps ymm0, ymm0, ymm2
vmovups YMMWORD PTR [edi+ecx*4], ymm0
vpmovzxwd ymm0, XMMWORD PTR [esi+ecx*2+16]
vcvtdq2ps ymm0, ymm0
vmulps ymm0, ymm0, ymm2
vmovups YMMWORD PTR [edi+ecx*4+32], ymm0
add ecx, 16 ; 00000010H
cmp ecx, ebx
jl SHORT $LL7@convert_ui

[Motenai Yoda]

and about /fp:fast which kind of gain it can get?

[Myrsloik]

I don't know if this is intentional but I found myself trying to use both the avs+ extended api while also having a proper fallback for the plain 2.6 api. That produced some wonderful gems like:


Like vi.IsY() but with the expected result on all avisynth versions:
(vi.IsY() || vi.IsY8())

A nice wrapper for vi.ComponentSize() that returns what you'd expect everywhere:
std::max(1, vi.ComponentSize());

My own number of planes function (packed formats count as a single plane obviously,
created since NumComponents() isn't available everywhere and would need to be "processed" anyway):
(vi.IsPlanar() && (vi.IsRGB() || vi.IsYUV())) ? 3 : 1;


And because base api is braindead and throws errors if you ask about the subsampling on non-yuv formats (why not just return 0? it's well defined yo!) I ended up wrapping that too.

I'm not sure this is ideal or the right way to go. Honestly fallback behavior is quite well defined for all your new functions as I realized after writing those lines so I propose that you go and add this remapping/fallback to avisynth.h if no exported version is aviailable:
int (VideoInfo::*NumComponents)() const; <- (vi.IsRGB() || vi.IsYUV()) ? 3 : 1 and return 4 if IsRGB32() I guess?
int (VideoInfo::*ComponentSize)() const; <- if exported function not available have stub return 1, it's obviously what's expected in every case
int (VideoInfo::*BitsPerComponent)() const; <- 8 here
bool (VideoInfo::*Is444)() const; <- remap to IsYV24()
bool (VideoInfo::*Is422)() const; <- remap to IsYV16()
bool (VideoInfo::*Is420)() const; <- remap to IsYV12()
bool (VideoInfo::*IsY)() const; <- remap to IsY8()
bool (VideoInfo::*IsRGB48)() const; <- return false (already does)
bool (VideoInfo::*IsRGB64)() const; <- return false (already does)
bool (VideoInfo::*IsYUVA)() const; <- return false (already does, there are no yuva formats in plain 2.6, right?)
bool (VideoInfo::*IsPlanarRGB)() const; <- return false (already does)
bool (VideoInfo::*IsPlanarRGBA)() const; <- return false (already does)

That's just my thought as a suffering programmer trying to make APIs meet. Also, I think I'm really right about this in an awesome way.

[pinterf]

Thanks for the feedback! I have some additional thoughts from the poor plugin writer's point of view. From within the core everything seems so easy and convenient (not quite true :)) But first I wanted to finish the internal filters, then return to the VideoInfo struct, but I'm leaving it for tomorrow)

[THEAST]

@pinterf, thank you for the detailed reply.
For ICC compilation, I just switched the compiler in Visual Studio to ICC and recompiled everything, didn't touch any switches. Do you recommend that I add a switch like "/arch:CORE-AVX2" to the command line?

[pinterf]

@pinterf, thank you for the detailed reply.
For ICC compilation, I just switched the compiler in Visual Studio to ICC and recompiled everything, didn't touch any switches. Do you recommend that I add a switch like "/arch:CORE-AVX2" to the command line?

You can try it, starting from SSE2 to AVX2. I really wonder what speed gain you will experience, if any. If you have time, please share the results.

Configuration Properties/ C/C++ / Code Generation: Enable Enhanced Instruction Set <-- minimal general requirement e.g. (/arch:SSE2)
Configuration Properties/ C/C++ / Code Generation (Intel C++): Add Processor Optimized Code Path <-- extra code paths for specific processor, e.g. (/QaxCORE-AVX2)

Under VS2015 and win32 target some source files containing MMX routines wont get compiled with AVX option (just a warning).
For x64 it is ok, MMX path is ifdef'd out on x64 targets.

[THEAST]

Okay, I will check and report back later. I am still using win32; after all, maybe it is time I switched to x64.

[ryrynz]

Okay, I will check and report back later. I am still using win32; after all, maybe it is time I switched to x64.

If you could link the ICC AVX build that would nice, cheers.

[ajp_anton]

As there are some plugins (masktools, mvtools... more?) that are almost necessary for everyone, why not make those "internal"? Who/what determines what filter should be internal and what is left to external plugins?

[pinterf]

I don't know if this is intentional but I found myself trying to use both the avs+ extended api while also having a proper fallback for the plain 2.6 api. That produced some wonderful gems like:


Like vi.IsY() but with the expected result on all avisynth versions:
(vi.IsY() || vi.IsY8())

A nice wrapper for vi.ComponentSize() that returns what you'd expect everywhere:
std::max(1, vi.ComponentSize());

My own number of planes function (packed formats count as a single plane obviously,
created since NumComponents() isn't available everywhere and would need to be "processed" anyway):
(vi.IsPlanar() && (vi.IsRGB() || vi.IsYUV())) ? 3 : 1;


And because base api is braindead and throws errors if you ask about the subsampling on non-yuv formats (why not just return 0? it's well defined yo!) I ended up wrapping that too.

I'm not sure this is ideal or the right way to go. Honestly fallback behavior is quite well defined for all your new functions as I realized after writing those lines so I propose that you go and add this remapping/fallback to avisynth.h if no exported version is aviailable:
int (VideoInfo::*NumComponents)() const; <- (vi.IsRGB() || vi.IsYUV()) ? 3 : 1 and return 4 if IsRGB32() I guess?
int (VideoInfo::*ComponentSize)() const; <- if exported function not available have stub return 1, it's obviously what's expected in every case
int (VideoInfo::*BitsPerComponent)() const; <- 8 here
bool (VideoInfo::*Is444)() const; <- remap to IsYV24()
bool (VideoInfo::*Is422)() const; <- remap to IsYV16()
bool (VideoInfo::*Is420)() const; <- remap to IsYV12()
bool (VideoInfo::*IsY)() const; <- remap to IsY8()
bool (VideoInfo::*IsRGB48)() const; <- return false (already does)
bool (VideoInfo::*IsRGB64)() const; <- return false (already does)
bool (VideoInfo::*IsYUVA)() const; <- return false (already does, there are no yuva formats in plain 2.6, right?)
bool (VideoInfo::*IsPlanarRGB)() const; <- return false (already does)
bool (VideoInfo::*IsPlanarRGBA)() const; <- return false (already does)

That's just my thought as a suffering programmer trying to make APIs meet. Also, I think I'm really right about this in an awesome way.

I hope I was able help with it. It really makes the plugin writer's life easier. Check changes on github.

I just copy/paste here the pull request comment

After Myrsloik's idea, there are changes in avisynth.h.

Avs+ specific VideoInfo:: functions (e.g. IsY, BitsPerComponent, Is444, etc) now work with an automatic fallback mechanism if they do not exists.

Using this avisynth.h ensures that one can use these new VideoInfo functions without any concern.
If no Is444 exists, IsYV24 will be called instead. IsY falls back to IsY8.
ComponentSize returns 1, BitsPerComponent returns 8, etc..

Thus the plugin writers can use the new VideoInfo:: functions without any hacks or ifdefs or workarounds and the code will work with classic avs 2.6, and with older avs+ versions.

[LigH]

Ehm ... advanced plugins line MaskTools and MVTools ... "necessary" for "everyone"? Do you even use their features manually? Or do you just need them to make even more complex scripts like QTGMC run with defaults, not even trying to understand what it does?

[Myrsloik]

I hope I was able help with it. It really makes the plugin writer's life easier. Check changes on github.

I just copy/paste here the pull request comment

After Myrsloik's idea, there are changes in avisynth.h.

Avs+ specific VideoInfo:: functions (e.g. IsY, BitsPerComponent, Is444, etc) now work with an automatic fallback mechanism if they do not exists.

Using this avisynth.h ensures that one can use these new VideoInfo functions without any concern.
If no Is444 exists, IsYV24 will be called instead. IsY falls back to IsY8.
ComponentSize returns 1, BitsPerComponent returns 8, etc..

Thus the plugin writers can use the new VideoInfo:: functions without any hacks or ifdefs or workarounds and the code will work with classic avs 2.6, and with older avs+ versions.

There's one more API question I've got that's kinda relevant for source and conversion plugins. How do I detect if high bitdepth formats are available at all?

In FFMS2 I kinda want to determine which output formats are actually available and then pick the best format to convert to based on what's available. Currently I have something kinda similar to this: (modified to fit with your latest header improvements)

VideoInfo vi= {};
vi.pixel_type = VideoInfo::CS_Y16;
HighBitDepth = (vi.ComponentSize() == 2);

And if that's true I assume the whole lump of planar rgb and 16bit stuff is available. But it doesn't feel clean to me. What's the preferred method?

[pinterf]

VideoInfo vi= {};
vi.pixel_type = VideoInfo::CS_Y16;
HighBitDepth = (vi.ComponentSize() == 2);

And if that's true I assume the whole lump of planar rgb and 16bit stuff is available. But it doesn't feel clean to me. What's the preferred method?
Unfortunately there is no clean method at the moment.
And there are earlier avs+ versions around that have already Y16 defined but missing 10-14 bit formats and planar rgb and yuv and rgb with alpha planes, so it's difficult.
Anyway, you can rely on this solution, and let's hope that those who want 10 bit workflow will follow avs+ updates.

[ajp_anton]

Ehm ... advanced plugins line MaskTools and MVTools ... "necessary" for "everyone"? Do you even use their features manually? Or do you just need them to make even more complex scripts like QTGMC run with defaults, not even trying to understand what it does?Well, Avisynth is full of internal functions that are far less useful. My question is, at what point should something be considered to be included by default?

Yes, I use masktools and mvtools "manually", especially masktools, but I might not be like the majority. I base my comment on their popularity on how many people talk about them, how to get them to work, how to find the correct and "best" working version for their version of Avisynth, etc. To me it looks like a lot of people, but maybe I'm wrong.

[Myrsloik]

Unfortunately there is no clean method at the moment.
And there are earlier avs+ versions around that have already Y16 defined but missing 10-14 bit formats and planar rgb and yuv and rgb with alpha planes, so it's difficult.
Anyway, you can rely on this solution, and let's hope that those who want 10 bit workflow will follow avs+ updates.

Any idea when this will be merged into the main MT branch so I can start using it. Or did your branch kinda become the main one? Forking is so confusing.