AviSynth+ thread Vol.2

[pinterf]

Unrelated, but as I understand it scale_inputs has no effect with LUT mode right? It's always dependent on input bitdepth (and input variables).
To tell the truth I don't know, there are so many conversion options in Expr that I always have to look into the topic deeper, again and again.

[Dogway]

A 14 bit lutxy needs a 0.5 GBytes LUT table. Probably this is too much to keep all of it in a fast cache memory.
When you decrease the bit depth to 12 and 10 bits, it would act quicker.
But LUT it is still going pixel-by-pixel, while Expr can translate 32 pixels at a time. We wish that the optimum - which to use, lut or Expr - would be guessed before use.

That's right, 12-bit is faster at least for my CPU (8Mb L3 cache). I didn't know it depended on cache rather than RAM. Newer CPUs have bigger caches but in any case I think it's safer to limit lutxy to 12-bit for LUT.

To tell the truth I don't know, there are so many conversion options in Expr that I always have to look into the topic deeper, again and again.

I did some benchmarks and reached to that conclusion, but I will rerun them to be sure. These kind of things show up with big filters like QTGMC.

[Reel.Deel]

I think green bar luma value is wrong in the wiki of ColorBarsHD. It should read 133 (currently 134), I had to double check with the original paper. Its full range value also has to be fixed.


What should full range be? I'll go ahead and update the wiki.

I guess because it is divisible by 7 and allows of drawing perfectly spaced bar sections.

I think you're correct, from the original script (http://avisynth.nl/index.php/HDColorBars) that ColorBarsHD is based on there is this comment:

#Bugs/Limitations:
#Width of bars may not be totally accurate, especially e.g. section1 where width divisor of 7 doesn't add up.

[Dogway]

What should full range be? I'll go ahead and update the wiki.

Full range gives me 136 .0 with:
ConvertBits(8,fulls=false,fulld=true)

[Reel.Deel]

Full range gives me 136 .0 with:
ConvertBits(8,fulls=false,fulld=true)

Thanks. I also noticed that the Levels wiki page (http://avisynth.nl/index.php/Levels) has some questionable numbers listed for full range:

https://i.ibb.co/HnqpxKN/avslevels.png

Unless this is specific to levels, only 8bit 255 is correct and I'm not sure about 255/256 or any of the other 32-bit numbers.

[Dogway]

I always use n/255 for 32-bit float. You can check my list in ex_dlut() (https://github.com/Dogway/Avisynth-Scripts/blob/78444f2e558781ee63866757a4c4a59d7704b4f1/ExTools.avsi#L7077).
As you see it depends on clip range. This chart assumes legal range for the values so I guess for Levels() this would have something to do with 'coring'.
In my opinion you should set coring to false and treat the clip as full range.
The last column seems correct, it's the maximum permitted video signal value for either limited or full range.

[qyot27]

Side announcement/notifications:
FFmpeg has merged the patches which allow it to read certain selected frame properties.
x264 has now switched to AviSynth+ when on non-Windows platforms.

x264 had been using AvxSynth on Linux and macOS for a little over nine years (2013-Feb-12). Unlike FFmpeg, x264 ships a local copy of the avisynth_c.h header, so it's much more likely for the average distro's x264 package to just start working with a user's self-built AviSynth+ install, once they catch up to where x264-git is (and assuming they aren't disabling it because users don't understand how the input module selector works and complained about it failing even though it was working as expected).

The FFmpeg patches mean that the relevant frame properties (_FieldBased, _Matrix, _ChromaLocation, _Primaries, _Transfer, and _ColorRange) can now be passed through to the output, if the output format supports setting those properties for itself from what FFmpeg reports (HEVC encoding through libx265 does), and libavformat-based decoding has the ability to see those properties and programs using that information can then take appropriate action. mpv, for instance, can now use its autotonemapping for HDR content served through an AviSynth script. Requires a new enough build of FFMS2 or LSMASHSource to populate those properties when opening the source video, as well as AviSynth+ 3.7.1 for libavformat to try reading the frameprops.

[qyot27]

What I mean by the ffmpeg stuff:
The avs script:
FFmpegSource2("LG New York HDR UHD 4K Demo.ts",atrack=-1)
Spline64Resize(1280,720)

Prior to the patches (and still true if you try using 3.7.0 or below with FFmpeg):
$ ffmpeg -i test_hdr.avs
ffmpeg version N-105655-ge4ad38d0f7-6ubuntu5 Copyright (c) 2000-2022 the FFmpeg developers
built with gcc 11 (Ubuntu 11.2.0-7ubuntu2)
configuration: --prefix=/usr --extra-version=6ubuntu5 --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --arch=amd64 --enable-gpl --enable-debug --disable-stripping --enable-version3 --enable-mbedtls --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libcodec2 --enable-libdav1d --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libjack --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libplacebo --enable-libpulse --enable-librabbitmq --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzimg --enable-libzvbi --enable-lv2 --enable-omx --enable-openal --enable-opencl --enable-opengl --enable-sdl2 --enable-librsvg --enable-libmfx --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-nvenc --enable-chromaprint --enable-frei0r --enable-libx264 --enable-avisynth --enable-vapoursynth --cpu=skylake --extra-cflags='-march=skylake' --extra-ldflags=-pthread --pkg-config-flags=--static
libavutil 57. 21.100 / 57. 21.100
libavcodec 59. 21.100 / 59. 21.100
libavformat 59. 17.102 / 59. 17.102
libavdevice 59. 5.100 / 59. 5.100
libavfilter 8. 27.100 / 8. 27.100
libswscale 6. 5.100 / 6. 5.100
libswresample 4. 4.100 / 4. 4.100
libpostproc 56. 4.100 / 56. 4.100
Guessed Channel Layout for Input Stream #0.1 : stereo
Input #0, avisynth, from 'test_hdr.avs':
Duration: 00:01:12.24, start: 0.000000, bitrate: 0 kb/s
Stream #0:0: Video: rawvideo (Y3[11][10] / 0xA0B3359), yuv420p10le(bottom first), 1280x720, 25 fps, 25 tbr, 25 tbn
Stream #0:1: Audio: pcm_f32le, 48000 Hz, stereo, flt, 3072 kb/s
At least one output file must be specified


$ ffmpeg -i test_hdr.avs
ffmpeg version N-105655-ge4ad38d0f7-6ubuntu5 Copyright (c) 2000-2022 the FFmpeg developers
built with gcc 11 (Ubuntu 11.2.0-7ubuntu2)
configuration: --prefix=/usr --extra-version=6ubuntu5 --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --arch=amd64 --enable-gpl --enable-debug --disable-stripping --enable-version3 --enable-mbedtls --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libcodec2 --enable-libdav1d --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libjack --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libplacebo --enable-libpulse --enable-librabbitmq --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzimg --enable-libzvbi --enable-lv2 --enable-omx --enable-openal --enable-opencl --enable-opengl --enable-sdl2 --enable-librsvg --enable-libmfx --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-nvenc --enable-chromaprint --enable-frei0r --enable-libx264 --enable-avisynth --enable-vapoursynth --cpu=skylake --extra-cflags='-march=skylake' --extra-ldflags=-pthread --pkg-config-flags=--static
libavutil 57. 21.100 / 57. 21.100
libavcodec 59. 21.100 / 59. 21.100
libavformat 59. 17.102 / 59. 17.102
libavdevice 59. 5.100 / 59. 5.100
libavfilter 8. 27.100 / 8. 27.100
libswscale 6. 5.100 / 6. 5.100
libswresample 4. 4.100 / 4. 4.100
libpostproc 56. 4.100 / 56. 4.100
Guessed Channel Layout for Input Stream #0.1 : stereo
Input #0, avisynth, from 'test_hdr.avs':
Duration: 00:01:12.24, start: 0.000000, bitrate: 0 kb/s
Stream #0:0: Video: rawvideo (Y3[11][10] / 0xA0B3359), yuv420p10le(tv, bt2020nc/bt2020/smpte2084, progressive), 1280x720, 25 fps, 25 tbr, 25 tbn
Stream #0:1: Audio: pcm_f32le, 48000 Hz, stereo, flt, 3072 kb/s
At least one output file must be specified


The key lines there are,
before:
Stream #0:0: Video: rawvideo (Y3[11][10] / 0xA0B3359), yuv420p10le(bottom first), 1280x720, 25 fps, 25 tbr, 25 tbn
and after:
Stream #0:0: Video: rawvideo (Y3[11][10] / 0xA0B3359), yuv420p10le(tv, bt2020nc/bt2020/smpte2084, progressive), 1280x720, 25 fps, 25 tbr, 25 tbn.

[FranceBB]

Side announcement/notifications:
[list] FFmpeg has merged the patches which allow it to read certain selected frame properties.


Ah... Let the nightmare begin... :(


The FFmpeg patches mean that the relevant frame properties can now be passed through to the output

Is there a way to DISABLE it on the FFMpeg side or is it on by default and will always stay on?

'cause I noticed that when I use: propclearall() in Avisynth, FFMpeg gets bogus properties, but it's not like before, like it used to be.
I expected propclearall() to clear all frame properties and therefore make FFMpeg behave like it used be, but it doesn't, that only works from the Avisynth point of view, but now instead of not passing any properties it's passing the WRONG properties, which is even worse.
On the other hand, I can't make use of frame properties in any way in Avisynth and make sure that everything is always correct 'cause many filters just don't modify them, so I end up with the wrong properties anyway, hence the propclearall().

As I stated in the other topic, I very much believe that there should be a way, like a command, in FFMpeg to disable frame properties and go back to the way it was before.
This way, users can decide whether to use them or not.
On the Avisynth side we have propclearall() which has been my most used function and I've spread it everywhere in every script I made, but now we need something on the FFMpeg side to instruct it not to read any of what Avisynth is passing.

The reason why I've been so keen on insisting on this is that I've got lots of issues with some workflows that have been working for years and then stopped due to frame properties (like the top left chroma location thingy for XDCAM-50, remember?).
In this very moment in time it's much much better not to have frame properties than to have them for me.

[qyot27]

Ah... Let the nightmare begin... :(



Is there a way to DISABLE it on the FFMpeg side or is it on by default and will always stay on?

'cause I noticed that when I use: propclearall() in Avisynth, FFMpeg gets bogus properties, but it's not like before, like it used to be.
I expected propclearall() to clear all frame properties and therefore make FFMpeg behave like it used be, but it doesn't, that only works from the Avisynth point of view, but now instead of not passing any properties it's passing the WRONG properties, which is even worse.
On the other hand, I can't make use of frame properties in any way in Avisynth and make sure that everything is always correct 'cause many filters just don't modify them, so I end up with the wrong properties anyway, hence the propclearall().

As I stated in the other topic, I very much believe that there should be a way, like a command, in FFMpeg to disable frame properties and go back to the way it was before.
This way, users can decide whether to use them or not.
On the Avisynth side we have propclearall() which has been my most used function and I've spread it everywhere in every script I made, but now we need something on the FFMpeg side to instruct it not to read any of what Avisynth is passing.

The reason why I've been so keen on insisting on this is that I've got lots of issues with some workflows that have been working for years and then stopped due to frame properties (like the top left chroma location thingy for XDCAM-50, remember?).
In this very moment in time it's much much better not to have frame properties than to have them for me.

These are the default cases for those six properties in FFmpeg:
st->codecpar->field_order = AV_FIELD_UNKNOWN
st->codecpar->color_range = AVCOL_RANGE_UNSPECIFIED
st->codecpar->color_primaries = AVCOL_PRI_UNSPECIFIED
st->codecpar->color_trc = AVCOL_TRC_UNSPECIFIED
st->codecpar->color_space = AVCOL_SPC_UNSPECIFIED
st->codecpar->chroma_location = AVCHROMA_LOC_UNSPECIFIED
Which is correct, because there's no one true default for all rawvideo formats. If they aren't set, UNSPECIFIED or UNKNOWN is the correct value.

What it seems is happening, is that propDelete and propClearAll either remove the value, or set the value to 0 and treat that as implicitly having removed it. The problem is that the enums that set those properties consider 0 a valid number or somehow interpret the missing value to be equivalent to the value being 0. Which means it selects `case 0` instead of the default UNSPECIFIED case. These are the values for `case 0`:
st->codecpar->field_order = AV_FIELD_PROGRESSIVE
st->codecpar->color_range = AVCOL_RANGE_JPEG
st->codecpar->color_space = AVCOL_SPC_RGB
st->codecpar->chroma_location = AVCHROMA_LOC_LEFT
Primaries and Transfer have no case 0, so they actually work 'correctly' in the sense it reports back 'unknown'.

All the charts have a specific number of options corresponding to the cases in the switcher:
_FieldBased has three (0-2)
_ColorRange has two (0, 1)
_Primaries has twelve (1, 2, 4-12, 22)
_Transfer has seventeen (1, 2, 4-18)
_Matrix has fourteen (0-2, 4-14)
_ChromaLocation has six (0-5)

What am I getting at here? Well, if you happen to set a value for one of those properties to a number which does not coincide with one of the cases, it falls back to UNSPECIFIED, which would be the same as pre-frameprop treatment behavior.

So a safe value for all of them could be, say, -1. Or one way outside the boundaries, like 100. Or for _Primaries, _Transfer, and _Matrix, 3.

Does propClearAll actually remove the value entirely (propShow would imply that it does), or just set it to 0? Does FFmpeg (or more precisely, the compiler or C language itself) interpret the absense of a value to be equivalent to 0 when dealing with the switch-case? I have no clue. Those are areas that need to be explored when trying to figure it out, but what this does uncover is simple: if you want it to go back to how it was before, just use a function like this:
function propUnsetAll(clip c)
{
c.propClearAll()
last.propSet("_FieldBased",-1)
last.propSet("_ColorRange",-1)
last.propSet("_Primaries",-1)
last.propSet("_Transfer",-1)
last.propSet("_Matrix",-1)
last.propSet("_ChromaLocation",-1)
return last
}
and the result of
Import("../propunset.avsi")
FFmpegSource2("LG New York HDR UHD 4K Demo.ts",atrack=-1)
Spline64Resize(1280,720)
propUnsetAll()
is this:
ffmpeg version N-105655-ge4ad38d0f7-6ubuntu5 Copyright (c) 2000-2022 the FFmpeg developers
built with gcc 11 (Ubuntu 11.2.0-7ubuntu2)
configuration: --prefix=/usr --extra-version=6ubuntu5 --toolchain=hardened
--libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu
--arch=amd64 --enable-gpl --enable-debug --disable-stripping --enable-version3
--enable-mbedtls --enable-ladspa --enable-libaom --enable-libass
--enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio
--enable-libcodec2 --enable-libdav1d --enable-libflite --enable-libfontconfig
--enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm
--enable-libjack --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg
--enable-libopenmpt --enable-libopus --enable-libplacebo --enable-libpulse
--enable-librabbitmq --enable-librubberband --enable-libshine --enable-libsnappy
--enable-libsoxr --enable-libspeex --enable-libsrt --enable-libssh --enable-libtheora
--enable-libtwolame --enable-libvidstab --enable-libvorbis --enable-libvpx
--enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzimg
--enable-libzvbi --enable-lv2 --enable-omx --enable-openal --enable-opencl
--enable-opengl --enable-sdl2 --enable-librsvg --enable-libmfx --enable-libdc1394
--enable-libdrm --enable-libiec61883 --enable-nvenc --enable-chromaprint
--enable-frei0r --enable-libx264 --enable-avisynth --enable-vapoursynth
--cpu=skylake --extra-cflags='-march=skylake' --extra-ldflags=-pthread --pkg-config-flags=--static
libavutil 57. 21.100 / 57. 21.100
libavcodec 59. 21.100 / 59. 21.100
libavformat 59. 17.102 / 59. 17.102
libavdevice 59. 5.100 / 59. 5.100
libavfilter 8. 27.100 / 8. 27.100
libswscale 6. 5.100 / 6. 5.100
libswresample 4. 4.100 / 4. 4.100
libpostproc 56. 4.100 / 56. 4.100
Guessed Channel Layout for Input Stream #0.1 : stereo
Input #0, avisynth, from '/home/qyot27/Videos/test_hdr.avs':
Duration: 00:01:12.24, start: 0.000000, bitrate: 0 kb/s
Stream #0:0: Video: rawvideo (Y3[11][10] / 0xA0B3359), yuv420p10le, 1280x720, 25 fps, 25 tbr, 25 tbn
Stream #0:1: Audio: pcm_f32le, 48000 Hz, stereo, flt, 3072 kb/s
At least one output file must be specified

Stream #0:0: Video: rawvideo (Y3[11][10] / 0xA0B3359), yuv420p10le, 1280x720, 25 fps, 25 tbr, 25 tbn

[FranceBB]

Ahhhh, I get it now!
So that's why it didn't go back to unspecified when I was trying! Setting them all to -1 is indeed a nice trick. I'm gonna try to play with it on Monday as I get back to work, but I'm sure it's gonna work 'cause you already tried eheheheh.

It's incredible that I've never thought about setting them to impossible values! Thanks for the tip, Stephen!! ;)

[qyot27]

It certainly needs to be documented in a table, considering that it required taking a dive into FFmpeg's source code to even figure out what the entries in, to quote, "[X] as specified in ITU-T H.265 Table E.[Y]" were, and then compare it to the VapourSynth documentation on Resize (www.vapoursynth.com/doc/functions/video/resize.html) to make sure they were using the same values.

Just so it actually is somewhere, here you go, in table form:
+---------------------------------------+
| _FieldBased |
+------------------+--------------------+
| Value | Meaning |
+------------------+--------------------+
| 0 | Progressive |
+------------------+--------------------+
| 1 | Bottom field first |
+------------------+--------------------+
| 2 | Top field first |
+------------------+--------------------+
| All other values | Unknown / unset |
+------------------+--------------------+

+-----------------------------------------------+
| _ColorRange |
+------------------+----------------------------+
| Value | Meaning |
+------------------+----------------------------+
| 0 | Full range, a.k.a. JPEG |
+------------------+----------------------------+
| 1 | Limited range, a.k.a. MPEG |
+------------------+----------------------------+
| All other values | Unknown / unset |
+------------------+----------------------------+

+------------------------------------+
| _Primaries |
+------------------+-----------------+
| Value | Meaning |
+------------------+-----------------+
| 1 | BT709 |
+------------------+-----------------+
| 2 | Unspecified |
+------------------+-----------------+
| 4 | BT470M |
+------------------+-----------------+
| 5 | BT470BG |
+------------------+-----------------+
| 6 | SMPTE170M |
+------------------+-----------------+
| 7 | SMPTE240M |
+------------------+-----------------+
| 8 | FILM |
+------------------+-----------------+
| 9 | BT2020 |
+------------------+-----------------+
| 10 | SMPTE428 |
+------------------+-----------------+
| 11 | SMPTE431 |
+------------------+-----------------+
| 12 | SMPTE432 |
+------------------+-----------------+
| 22 | EBU3213 |
+------------------+-----------------+
| All other values | Unknown / unset |
+------------------+-----------------+

+------------------------------------+
| _Transfer |
+------------------+-----------------+
| Value | Meaning |
+------------------+-----------------+
| 1 | BT709 |
+------------------+-----------------+
| 2 | Unspecified |
+------------------+-----------------+
| 4 | GAMMA22 |
+------------------+-----------------+
| 5 | GAMMA28 |
+------------------+-----------------+
| 6 | SMPTE170M |
+------------------+-----------------+
| 7 | SMPTE240M |
+------------------+-----------------+
| 8 | LINEAR |
+------------------+-----------------+
| 9 | LOG |
+------------------+-----------------+
| 10 | LOG_SQRT |
+------------------+-----------------+
| 11 | IEC61966_2_4 |
+------------------+-----------------+
| 12 | BT1361_ECG |
+------------------+-----------------+
| 13 | IEC61966_2_1 |
+------------------+-----------------+
| 14 | BT2020_10 |
+------------------+-----------------+
| 15 | BT2020_12 |
+------------------+-----------------+
| 16 | SMPTE2084 |
+------------------+-----------------+
| 17 | SMPTE428 |
+------------------+-----------------+
| 18 | ARIB_STD_B67 |
+------------------+-----------------+
| All other values | Unknown / unset |
+------------------+-----------------+

+---------------------------------------+
| _Matrix |
+------------------+--------------------+
| Value | Meaning |
+------------------+--------------------+
| 0 | RGB |
+------------------+--------------------+
| 1 | BT709 |
+------------------+--------------------+
| 2 | Unspecified |
+------------------+--------------------+
| 4 | FCC |
+------------------+--------------------+
| 5 | BT470BG |
+------------------+--------------------+
| 6 | SMPTE170M |
+------------------+--------------------+
| 7 | SMPTE240M |
+------------------+--------------------+
| 8 | YCGCO |
+------------------+--------------------+
| 9 | BT2020_NCL |
+------------------+--------------------+
| 10 | BT2020_CL |
+------------------+--------------------+
| 11 | SMPTE2085 |
+------------------+--------------------+
| 12 | CHROMA_DERIVED_NCL |
+------------------+--------------------+
| 13 | CHROMA_DERIVED_CL |
+------------------+--------------------+
| 14 | ICTCP |
+------------------+--------------------+
| All other values | Unknown / unset |
+------------------+--------------------+

+------------------------------------+
| _ChromaLocation |
+------------------+-----------------+
| Value | Meaning |
+------------------+-----------------+
| 0 | LEFT |
+------------------+-----------------+
| 1 | CENTER |
+------------------+-----------------+
| 2 | TOPLEFT |
+------------------+-----------------+
| 3 | TOP |
+------------------+-----------------+
| 4 | BOTTOMLEFT |
+------------------+-----------------+
| 5 | BOTTOM |
+------------------+-----------------+
| All other values | Unknown / unset |
+------------------+-----------------+

[gispos]

Does propClearAll actually remove the value entirely (propShow would imply that it does), or just set it to 0? Does FFmpeg (or more precisely, the compiler or C language itself) interpret the absense of a value to be equivalent to 0 when dealing with the switch-case? I have no clue. Those are areas that need to be explored when trying to figure it out, but what this does uncover is simple: if you want it to go back to how it was before, just use a function like this:
function propUnsetAll(clip c)
{
c.propClearAll()
last.propSet("_FieldBased",-1)
last.propSet("_ColorRange",-1)
last.propSet("_Primaries",-1)
last.propSet("_Transfer",-1)
last.propSet("_Matrix",-1)
last.propSet("_ChromaLocation",-1)
return last
}

Then we are back to the ConvertToRGB32 error.
Avisynth and other plugin developers who use frame properties should agree on a consistent standard. Without the user having to assign a value to the properties themselves if they don't want to use them or delete them.

https://i.postimg.cc/qvGWh8K1/Error.jpg (https://postimages.org/)

If everyone agrees that -1 is unspecified, then it would probably work.

[pinterf]

Then we are back to the ConvertToRGB32 error.
Avisynth and other plugin developers who use frame properties should agree on a consistent standard. Without the user having to assign a value to the properties themselves if they don't want to use them or delete them.

https://i.postimg.cc/qvGWh8K1/Error.jpg (https://postimages.org/)

If everyone agrees that -1 is unspecified, then it would probably work.
Unspecified values are not equal to -1.
Some properties have no "Unspecified" value, such as _ColorRange: 0, 1, or does not exist at all.

[pinterf]

It can be a decision though how "invalid" values are treated by plugins or Avisynth's internal filters. ITU tables specify "unspecified" where applicable.

[Reel.Deel]

function propUnsetAll(clip c)
{
c.propClearAll()
last.propSet("_FieldBased",-1)
last.propSet("_ColorRange",-1)
last.propSet("_Primaries",-1)
last.propSet("_Transfer",-1)
last.propSet("_Matrix",-1)
last.propSet("_ChromaLocation",-1)
return last
}


For a property nuke function like this one, would it not be better to set all of the properties that have an actual unspecified value to that? For example, _Primaries, _Transfer and _Matrix can all be set to 2. Unless I missed something from the previous posts. Maybe even setting _ChromaLocation to 0 since left is the most common chroma placement.

edit: left the post in edit for about an hour and did not notice pinterf's reply.

It certainly needs to be documented in a table, considering that it required taking a dive into FFmpeg's source code to even figure out what the entries in, to quote, "[X] as specified in ITU-T H.265 Table E.[Y]" were, and then compare it to the VapourSynth documentation on Resize (www.vapoursynth.com/doc/functions/video/resize.html) to make sure they were using the same values.


Most of them are documented in the wiki but in various places:


Matrix: http://avisynth.nl/index.php/Convert#Parameter_Details
Chroma loc: http://avisynth.nl/index.php/Convert#Frame_properties_AVS.2B
and here: http://avisynth.nl/index.php/Internal_functions#Reserved_frame_property_names

But yes, I agree they need to be documented and formatted nicely. Once I get done with the internal filters rst docs I'll move onto the syntax portion and will include this info there. Hopefully by summer time :D

[wonkey_monkey]

Isn't PropDelete the thing to use?

[Boulder]

Isn't PropDelete the thing to use?

I agree with that idea, just a little cumbersome as of now. I always thought propClearAll deletes properties, but apparently a propDeleteAll would be very useful for backward compatibility cases.

[gispos]

Unspecified values are not equal to -1.
Some properties have no "Unspecified" value, such as _ColorRange: 0, 1, or does not exist at all.
I did not claim that either. I only wrote
"All (developers) should agree on a standard" and there the value -1 would be useful.

If now -1 would be considered as not existing, there would be no problems here.

[wonkey_monkey]

I tried PropClearAll and sure enough, no properties. All deleted. PropShow shows nothing and my own program, assuming I've written it correctly which I think I have, shows nothing.

If ffmpeg is getting spurious values from somewhere, is that not an ffmpeg problem?

[qyot27]

This is what the switch-cases for the frame properties look like in FFmpeg's AviSynth demuxer:
/* Field order */
switch (avs_library.avs_prop_get_int(avs->env, avsmap, "_FieldBased", 0, &error)) {
case 0:
st->codecpar->field_order = AV_FIELD_PROGRESSIVE;
break;
case 1:
st->codecpar->field_order = AV_FIELD_BB;
break;
case 2:
st->codecpar->field_order = AV_FIELD_TT;
break;
default:
st->codecpar->field_order = AV_FIELD_UNKNOWN;
}

All six of the frame properties in question are of type int (http://avisynth.nl/index.php/Internal_functions#Reserved_frame_property_names), so presumably, the appropriate API call to fetch that value is avs_prop_get_int.

If avs_prop_get_int is reporting the absence of a frame property as NULL, then it's equal to zero as guaranteed by C99. Zero is a valid value for four of those frame properties, which does not match it being absent (for _Primaries and _Transfer, no case 0 exists, so those do fall back to the default UNSPECIFIED value like they're supposed to).

[FranceBB]

I tried PropClearAll and sure enough, no properties. All deleted. PropShow shows nothing and my own program, assuming I've written it correctly which I think I have, shows nothing.

Of course, PropClearAll() does indeed remove all frame properties, so as long as you're gonna use filters inside Avisynth you're gonna be fine. The "problem" is when FFMpeg tries to access them.


If ffmpeg is getting spurious values from somewhere, is that not an ffmpeg problem?

It is... sort of.
I've looked at Stephen's code in FFMpeg and indeed each value has a default, namely:

/* Field order */
switch (avs_library.avs_prop_get_int(avs->env, avsmap, "_FieldBased", 0, &error)) {
case 0:
st->codecpar->field_order = AV_FIELD_PROGRESSIVE;
break;
case 1:
st->codecpar->field_order = AV_FIELD_BB;
break;
case 2:
st->codecpar->field_order = AV_FIELD_TT;
break;
default:
st->codecpar->field_order = AV_FIELD_UNKNOWN;
}

/* Color Range */
switch (avs_library.avs_prop_get_int(avs->env, avsmap, "_ColorRange", 0, &error)) {
case 0:
st->codecpar->color_range = AVCOL_RANGE_JPEG;
break;
case 1:
st->codecpar->color_range = AVCOL_RANGE_MPEG;
break;
default:
st->codecpar->color_range = AVCOL_RANGE_UNSPECIFIED;
}

/* Color Primaries */
switch (avs_library.avs_prop_get_int(avs->env, avsmap, "_Primaries", 0, &error)) {
case 1:
st->codecpar->color_primaries = AVCOL_PRI_BT709;
break;
case 2:
st->codecpar->color_primaries = AVCOL_PRI_UNSPECIFIED;
break;
case 4:
st->codecpar->color_primaries = AVCOL_PRI_BT470M;
break;
case 5:
st->codecpar->color_primaries = AVCOL_PRI_BT470BG;
break;
case 6:
st->codecpar->color_primaries = AVCOL_PRI_SMPTE170M;
break;
case 7:
st->codecpar->color_primaries = AVCOL_PRI_SMPTE240M;
break;
case 8:
st->codecpar->color_primaries = AVCOL_PRI_FILM;
break;
case 9:
st->codecpar->color_primaries = AVCOL_PRI_BT2020;
break;
case 10:
st->codecpar->color_primaries = AVCOL_PRI_SMPTE428;
break;
case 11:
st->codecpar->color_primaries = AVCOL_PRI_SMPTE431;
break;
case 12:
st->codecpar->color_primaries = AVCOL_PRI_SMPTE432;
break;
case 22:
st->codecpar->color_primaries = AVCOL_PRI_EBU3213;
break;
default:
st->codecpar->color_primaries = AVCOL_PRI_UNSPECIFIED;
}

/* Color Transfer Characteristics */
switch (avs_library.avs_prop_get_int(avs->env, avsmap, "_Transfer", 0, &error)) {
case 1:
st->codecpar->color_trc = AVCOL_TRC_BT709;
break;
case 2:
st->codecpar->color_trc = AVCOL_TRC_UNSPECIFIED;
break;
case 4:
st->codecpar->color_trc = AVCOL_TRC_GAMMA22;
break;
case 5:
st->codecpar->color_trc = AVCOL_TRC_GAMMA28;
break;
case 6:
st->codecpar->color_trc = AVCOL_TRC_SMPTE170M;
break;
case 7:
st->codecpar->color_trc = AVCOL_TRC_SMPTE240M;
break;
case 8:
st->codecpar->color_trc = AVCOL_TRC_LINEAR;
break;
case 9:
st->codecpar->color_trc = AVCOL_TRC_LOG;
break;
case 10:
st->codecpar->color_trc = AVCOL_TRC_LOG_SQRT;
break;
case 11:
st->codecpar->color_trc = AVCOL_TRC_IEC61966_2_4;
break;
case 12:
st->codecpar->color_trc = AVCOL_TRC_BT1361_ECG;
break;
case 13:
st->codecpar->color_trc = AVCOL_TRC_IEC61966_2_1;
break;
case 14:
st->codecpar->color_trc = AVCOL_TRC_BT2020_10;
break;
case 15:
st->codecpar->color_trc = AVCOL_TRC_BT2020_12;
break;
case 16:
st->codecpar->color_trc = AVCOL_TRC_SMPTE2084;
break;
case 17:
st->codecpar->color_trc = AVCOL_TRC_SMPTE428;
break;
case 18:
st->codecpar->color_trc = AVCOL_TRC_ARIB_STD_B67;
break;
default:
st->codecpar->color_trc = AVCOL_TRC_UNSPECIFIED;
}

/* Matrix coefficients */
switch (avs_library.avs_prop_get_int(avs->env, avsmap, "_Matrix", 0, &error)) {
case 0:
st->codecpar->color_space = AVCOL_SPC_RGB;
break;
case 1:
st->codecpar->color_space = AVCOL_SPC_BT709;
break;
case 2:
st->codecpar->color_space = AVCOL_SPC_UNSPECIFIED;
break;
case 4:
st->codecpar->color_space = AVCOL_SPC_FCC;
break;
case 5:
st->codecpar->color_space = AVCOL_SPC_BT470BG;
break;
case 6:
st->codecpar->color_space = AVCOL_SPC_SMPTE170M;
break;
case 7:
st->codecpar->color_space = AVCOL_SPC_SMPTE240M;
break;
case 8:
st->codecpar->color_space = AVCOL_SPC_YCGCO;
break;
case 9:
st->codecpar->color_space = AVCOL_SPC_BT2020_NCL;
break;
case 10:
st->codecpar->color_space = AVCOL_SPC_BT2020_CL;
break;
case 11:
st->codecpar->color_space = AVCOL_SPC_SMPTE2085;
break;
case 12:
st->codecpar->color_space = AVCOL_SPC_CHROMA_DERIVED_NCL;
break;
case 13:
st->codecpar->color_space = AVCOL_SPC_CHROMA_DERIVED_CL;
break;
case 14:
st->codecpar->color_space = AVCOL_SPC_ICTCP;
break;
default:
st->codecpar->color_space = AVCOL_SPC_UNSPECIFIED;
}

/* Chroma Location */
switch (avs_library.avs_prop_get_int(avs->env, avsmap, "_ChromaLocation", 0, &error)) {
case 0:
st->codecpar->chroma_location = AVCHROMA_LOC_LEFT;
break;
case 1:
st->codecpar->chroma_location = AVCHROMA_LOC_CENTER;
break;
case 2:
st->codecpar->chroma_location = AVCHROMA_LOC_TOPLEFT;
break;
case 3:
st->codecpar->chroma_location = AVCHROMA_LOC_TOP;
break;
case 4:
st->codecpar->chroma_location = AVCHROMA_LOC_BOTTOMLEFT;
break;
case 5:
st->codecpar->chroma_location = AVCHROMA_LOC_BOTTOM;
break;
default:
st->codecpar->chroma_location = AVCHROMA_LOC_UNSPECIFIED;
}
}


So we do indeed have a default which is "UNSPECIFIED" which makes FFMpeg act the same as before.
The problem is that when FFMpeg calls the Avisynth APIs asking for frame properties, Avisynth will return "null" after it has been asked for 'cause PropClearAll() removed each and every property.
Here's the tricky bit: "null" gets interpreted by FFMpeg as... well... 0, which is a valid value for the frame properties, so it never goes to default which is "UNSPECIFIED".

It does go there if the Avisynth APIs version are lower than 9 (it used to be 8.1 but it caused a segmentation fault in 8.0 and it was a pain to solve so Stephen bumped them to 9), so effectively unless someone is using Avisynth 3.7.1 or 3.7.2 (so if they're using older version like 3.7.0 etc) the values will be set to default and it will be as it was before thanks to this bit of code:

if (avs_library.avs_get_version(avs->clip) >= 9) {

frame = avs_library.avs_get_frame(avs->clip, framedata);
avsmap = avs_library.avs_get_frame_props_ro(avs->env, frame);

I think Stephen would agree with this.


EDIT: Oh, he already replied and yeah it's like I thought


If avs_prop_get_int is reporting the absence of a frame property as NULL, then it's equal to zero as guaranteed by C99. Zero is a valid value for four of those frame properties, which does not match it being absent.

[MasterNobody]

Shouldn't ffmpeg check error value of avs_prop_get_int calls? As far as I looked it should be GETPROPERROR_UNSET in case of absent property.

[qyot27]

After looking more at the Readme and headers, avs_prop_get_type can be used to check the status of a frame property and whether it's been set or not. This fixes the issue on my end:
https://github.com/qyot27/FFmpeg/commit/a3d542ab0fe4c7d4b10a4769f88658c6f52918b9

I don't know if this approach is better or worse than checking the error value, though it does provide a way of knowing whether the property is set before an error would occur.

[FranceBB]

I don't know if this approach is better or worse

it's better.
Thank you for this. I look forward to try it on Monday.

[StvG]

After looking more at the Readme and headers, avs_prop_get_type can be used to check the status of a frame property and whether it's been set or not. This fixes the issue on my end:
https://github.com/qyot27/FFmpeg/commit/a3d542ab0fe4c7d4b10a4769f88658c6f52918b9

I don't know if this approach is better or worse than checking the error value, though it does provide a way of knowing whether the property is set before an error would occur.

Another variant: int error = 0;
/* Field order */
int64_t field = avs_library.avs_prop_get_int(avs->env, avsmap, "_FieldBased", 0, &error);
if (error != 0) { // no property
st->codecpar->field_order = AV_FIELD_UNKNOWN;
}
else {
switch (field) {
case 0:
st->codecpar->field_order = AV_FIELD_PROGRESSIVE;
break;
case 1:
st->codecpar->field_order = AV_FIELD_BB;
break;
case 2:
st->codecpar->field_order = AV_FIELD_TT;
break;
default:
st->codecpar->field_order = AV_FIELD_UNKNOWN;
}
}

[Dogway]

Are the weights of this function ops correct? I plan to add a score to expressions, I searched on instructions tables (https://www.agner.org/optimize/instruction_tables.pdf) but I'm not sure I got it right or whether it depends on CPU arch. I based it on Haswell.

function ex_lutperf(string str) {

str= " "+str+" "
a = FindStrInstance(str,"+") * 1
s = FindStrInstance(str,"-") * 2
m = FindStrInstance(str,"*") * 2
d = FindStrInstance(str,"/") * 4
t = FindStrInstance(str,"?") * 3
e = FindStrInstance(str,"^") * 6
mn = FindStrInstance(str," min " ) * 2
mx = FindStrInstance(str," max " ) * 2
ab = FindStrInstance(str," abs " ) * 2
r = FindStrInstance(str," sqrt " ) * 2
l = FindStrInstance(str," log " ) * 2
c = FindStrInstance(str," clip " ) * 3
x = FindStrInstance(str," exp " ) * 6
si = FindStrInstance(str," sin " ) * 6
co = FindStrInstance(str," cos " ) * 6
at = FindStrInstance(str," atan " ) * 6
a2 = FindStrInstance(str," atan2 ") * 6

return a+s+m+d+t+e+mn+mx+ab+r+l+c+x+si+co+at+a2 }

[pinterf]

Are the weights of this function ops correct? I plan to add a score to expressions, I searched on instructions tables (https://www.agner.org/optimize/instruction_tables.pdf) but I'm not sure I got it right or whether it depends on CPU arch. I based it on Haswell.

function ex_lutperf(string str) {

str= " "+str+" "
a = FindStrInstance(str,"+") * 1
s = FindStrInstance(str,"-") * 2
m = FindStrInstance(str,"*") * 2
d = FindStrInstance(str,"/") * 4
t = FindStrInstance(str,"?") * 3
e = FindStrInstance(str,"^") * 6
mn = FindStrInstance(str," min " ) * 2
mx = FindStrInstance(str," max " ) * 2
ab = FindStrInstance(str," abs " ) * 2
r = FindStrInstance(str," sqrt " ) * 2
l = FindStrInstance(str," log " ) * 2
c = FindStrInstance(str," clip " ) * 3
x = FindStrInstance(str," exp " ) * 6
si = FindStrInstance(str," sin " ) * 6
co = FindStrInstance(str," cos " ) * 6
at = FindStrInstance(str," atan " ) * 6
a2 = FindStrInstance(str," atan2 ") * 6

return a+s+m+d+t+e+mn+mx+ab+r+l+c+x+si+co+at+a2 }
sqrt, log, exp, sin, cos, atan, atan2 are not single instruction functions, their core can be 20-100 more complex than a simple abs. What is common: operand load and conversion to float (and scale if needed) before the operation, and the final (scale back and ) check range, convert back to integer and store to memory.

[pinterf]

Avisynth+ 3.7.2 test8
https://drive.google.com/uc?export=download&id=1G79jALjVbOS-2ZbWL1YZGmfe32dJhdli

all 3.7.2 changes so far:
20220227 3.7.2-WIP
------------------
- PropDelete: accept a non-empty array string as list of property names to remove
Parameter is not optional, and has no name. It can be either a string (as before) or an array of strings
propDelete("_Matrix") # old syntax, still accepted
propDelete(["_Matrix", "_ColorRange"])
- PropCopy: new string parameter "props" as list of property names to remove
"props": a non-empty array of strings

old syntax, still accepted:
propCopy(org,true) # merge from all org's properties
propCopy(org,false) # erase all then copy all org's properties (exact copy)
new syntax
propCopy(org,true,props=["_Matrix", "_ColorRange"]) # merge
propCopy(org,props=["_Matrix", "_ColorRange"]) # erase all then copy only selected
- Histogram Levels: stop using shades of grey on top of bars.
- Histogram Levels: use bar color 255 for RGB instead of Y's 235. (and scaled eqivivalents)
- Fix: Histogram "Levels": prevent crash when factor=0.0
- Fix: Histogram "Levels": fix regression incorrect "factor" applied for U/V part drawing when format was subsampled (non-444)
Regression since 20160916 r2666 (commit 986e2756)
- Histogram "Audiolevels" and StereoOverlay to deny planar RGB
- Histogram "Luma": support 10-16 and 32 bits
- Histogram: give parameter name "factor" and type 'float' for Histogram's unnamed optional parameter used in "Level" mode.
Other modes just ignore this parameter if given.
- Fix: Histogram "color" may crash on certain dimensions for subsampled formats.
Regression since 20180301 r2632.
- Fix: Histogram "color" and "color2" mode check and give error on Planar RGB
- Fix: missing Histogram "color2" CCIR rectangle top and bottom line (black on black)
Regression since 3.6.2-test1 (commit 1fc82f03)
- Fix: Compare to support 10-14 bits
was: factor was always using 65535 (2^16-1) instead of (2^bit depth - 1)
was: 16 bit luma/rgb color values were used for drawing graph
- Fix: Compare
'channels' parameter default to "Y" when input is greyscale;
instead of "YUV" which was giving error because of U and V does not exist for this format.
- ShowRed/Green/Blue/Alpha/Y/U/V
- support YUY2 input
- support YV411 output
- (not changed: ShowU/ShowV may give error for 420, 422 or 411 format outputs when clip dimensions are
not eligible for a given output subsampling (check for appropriate mod2 or mod4 width or height)
- Copy alpha from source when target is alpha-capable
- Fill alpha with maximum pixel value when target is alpha-capable but source ha no alpha component
- Delete _Matrix and _ChromaLocation frame properties when needed.
- More consistent behaviour for YUV and planar RGB sources.

Default pixel_type is adaptive. If none or empty ("") is given for pixel_type then target format is
- YUV444 when source is Y, YUV or YUVA
- RGB32/64 (packed RGB) when source is RGB24/32/48/64
- RGBP (planar RGB) when source is RGBP or RGBAP

When 'rgb' is given for pixel_type then then target format is

- RGB32/64 (packed) when source is RGB24/32/48/64 - old, compatible way
- RGB planar when source is planar RGB(A) or YUV(A) or Y - changed from rgb32/64 because all bit depth must be supported

When 'yuv' is given (new option!) for pixel_type then then target format is

- YUV444 for all sources

Also there is a new option when pixel_type is still not exact, and is given w/o bit depth.
pixel_type which describes the format without bit depth is automatically extended to a valid video string constant:

y, yuv420, yuv422, yuv444, yuva420, yuva422, yuva444, rgbp, rgbap

Examples:

32 bit video and pixel_type 'y' will result in "Y32"
16 bit video and pixel_type 'yuv444' will result in "YUV444P16"
8 bit video and pixel_type 'rgbap' will result in "RGBAP8"

- Fix #263. Escaping double-quotes results in error
- Allow top_left (2) and bottom_left (4) chroma placements for 422 in colorspace conversions, they act as "left" (0, "mpeg2")
in order not to give error with video sources which have _ChromaLocation set to other than "mpeg2"
See https://trac.ffmpeg.org/ticket/9598#comment:5
- Fix: Expr LUT operation Access Violation on x86 + AVX2 due to an unaligned internal buffer (<32 bytes)
- Fix: Chroma full scale as ITU Rec H.273 (e.g +/-127.5 and not +/-127) in internal converters, ColorYUV and Histogram
- Fix #257: regression in 3.7.1: GreyScale to not convert to limited range when input is RGB. Regression in 3.7.1
Accepts only matrix names of limited range as it is put in the documentation.
- Fix #256: ColorYUV(analyse=true) to not set _ColorRange property to "full" if input has no such
property and range cannot be 100% sure established. In general: when no _ColorRange for input and
no parameter which would rely on a supposed default (such as full range for gamma), then an
output frame property is not added.
When no _ColorRange for input and no other parameters to hint color range then
- gamma<>0 sets full range
- opt="coring" sets limited range
- otherwise no _ColorRange for output would be set
- Overlay (#255): "blend": using accurate formula using float calculation. 8 bit basic case is slower now when opacity=1.0.
Higher bit depths and opacity<1.0 cases are quicker.
Mask processing suffered from inaccuracy. For speed reasons mask value 0 to 255 were handled
as mask/256 instead of mask/255. Since with such calculation maximum value was not the expected 1.0 but rather 255/256 (0.996)
this case was specially treated as 1.0 to give Overlay proper results at least the the two extremes.
But for example applying mask=129 to pixel=255 resulted in result_pixel=128 instead of 129. This was valid on higher bit depths as well.
Note 3.7.2 Test2 has a regression of broken maskless mode for 0<opacity<1 which was fixed in 3.7.2 test 3
- Fix: Attempt to resolve deadlock when an Eval'd (Prefetch inside) Clip result is
used in Invoke which calls a filter with GetFrame in its constructor.
(AvsPMod use case which Invokes frame prop read / ConvertToRGB32 after having the AVS script evaluated)
Remark: problem emerged in 3.7.1test22 which is trying to read frame properties of the 0th frame in its constructor.
A similar deadlock situation was already fixed earlier in Neo branch and had been backported but it did not cover this use case.
Note: Prefetch(1) case was fixed in 3.7.2 Test3

[Dogway]

Thank you! Do you think we should treat filters as to not overflow video signal max value (for HBD)? Or keeping "range_max" as "range_size-1" albeit illegal video signal?

EDIT: I think copypasta typo in propCopy "as list of property names to copy"
Do you think a negative selection propCopy is possible? Like I want to copy all frameprops from clip to mask, including custom ones (future scene changes, stats), but not "_ColorRange", "_Transfer", etc.
Also I noticed that "props" is val type? "propCopy(org,true,props="_ChromaLocation")", not sure if intended.
And got a crash with ArrayDel(arr,-1), I was trying (with -1) to not delete an index if a condition was met

[kedautinh12]

Why test 8 don't have Cuda ver??

[guest]

Why test 8 don't have Cuda ver??

Curious how it jumped from test 3 to test 8.....

And no "normal" x86, only XP option.

[kedautinh12]

Curious how it jumped from test 3 to test 8.....

And no "normal" x86, only XP option.

x86_xp can use in win 11, i checked it. You can compare between test 3 and test 8 with changelogs

[guest]

x86_xp can use in win 11, i checked it. You can compare between test 3 and test 8 with changelogs

OK, thanks for that...

But who would use x86 much these days, anyway..

[Reel.Deel]

Curious how it jumped from test 3 to test 8.....


The intermediate test versions were released in the issues section but only for x64. I'm working on the online/offline documentation (https://github.com/AviSynth/AviSynthPlus/pull/264) and found a few bugs, pinterf fixed those issues and provided test versions along the way :)

But who would use x86 much these days, anyway..

I don't use x86 but still have it installed, does no harm.

[pinterf]

Why test 8 don't have Cuda ver??
I stopped including "CUDA" in the name, it's basically a non-XP 64 bit version of Avisynth+ which _can_ accept specially written CUDA Avisynth plugins. Knowing the fact that almost no one is using these Avisynth-Neo CUDA-aware interface I removed it from the name. Such an Avisynth+ build does not use CUDA at all, it is just able to host such filters; the only known plugin set which is compatible with this interface is https://github.com/pinterf/AviSynthCUDAFilters which is there for people/developers who'd like to play with this interface.

[pinterf]

Thank you! Do you think we should treat filters as to not overflow video signal max value (for HBD)? Or keeping "range_max" as "range_size-1" albeit illegal video signal?
I hope all internal Avisynth filters keep this rule, along with the external plugins I maintain. When it is not fulfilled, e.g. you encounter >1023 pixel values for a 10 bit clip, it is a bug, please report it.


EDIT: I think copypasta typo in propCopy "as list of property names to copy"
Do you think a negative selection propCopy is possible? Like I want to copy all frameprops from clip to mask, including custom ones (future scene changes, stats), but not "_ColorRange", "_Transfer", etc.
So this idea was not only in my mind, good, I was thinking about it, even a regex or wildcard-support version.


Also I noticed that "props" is val type? "propCopy(org,true,props="_ChromaLocation")", not sure if intended.
No. It is array of string. But in Avisynth - when the function signature expects array - a single parameter is reported as a single-element array. PropCopy syntax does not need array delimiter brackets for a single property name.


And got a crash with ArrayDel(arr,-1), I was trying (with -1) to not delete an index if a condition was met
Thanks to the report.

[FranceBB]

And no "normal" x86, only XP option.

XP version is compiled with Zc:threadSafeInit and using v141_xp instead of v142 and it targets SSE2 (but so do non XP builds so who cares), that's it, nothing special about it, it's compatible with every OS from XP onward without any issues, so you can use it in XP, Vista, 7, 8, 8.1, 10, 11 ;)

[Dogway]

I hope all internal Avisynth filters keep this rule, along with the external plugins I maintain. When it is not fulfilled, e.g. you encounter >1023 pixel values for a 10 bit clip, it is a bug, please report it.

I got deceived by the levels chart in the previous Reel.Deel's post (https://forum.doom9.org/showthread.php?p=1964603#post1964603).
The valid signal/data range only applies to legal range signals. Full range still occupies the full size minus 1.

I checked on ITU-R BT.2100-2 Table 9 (https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.2100-2-201807-I!!PDF-E.pdf#page=12), and fixed my values.

# data_max = Select (bitd, [255.,255.], [1019.,1023.], [4079.,4095.], [16319.,16383.], [65279.,65535.], [16711679.,16776960.], [ 1., 1.]) # Legal upper bound for video signal in legal range
# data_min = Select (bitd, [ 0., 0.], [ 4., 0.], [ 16., 0.], [ 64., 0.], [ 256., 0.], [ 65536., 0.], [ 0., 0.]) # Legal lower bound for video signal in legal range


With that said the chart in the Levels wiki ("http://avisynth.nl/index.php/Levels") should be fixed.

[Reel.Deel]

With that said the chart in the Levels wiki ("http://avisynth.nl/index.php/Levels") should be fixed.

I fixed it the rst docs (locally):

https://i.ibb.co/LZ1RHG7/avisynthplus-levels.png"]https://i.ibb.co/LZ1RHG7/avisynthplus-levels.png

I figured you misunderstood my question. I'll fix the wiki later, the levels page and also the autoscale (http://avisynth.nl/index.php/Autoscale_parameter) page.

[magnetite]

I stopped including "CUDA" in the name, it's basically a non-XP 64 bit version of Avisynth+ which _can_ accept specially written CUDA Avisynth plugins. Knowing the fact that almost no one is using these Avisynth-Neo CUDA-aware interface I removed it from the name. Such an Avisynth+ build does not use CUDA at all, it is just able to host such filters; the only known plugin set which is compatible with this interface is https://github.com/pinterf/AviSynthCUDAFilters which is there for people/developers who'd like to play with this interface.

Is DTL's MVTools2 mod an exception, since it uses DX12 compute shaders? Or is that outside of CUDA and doesn't require a special Avisynth+ build to run?

[DTL]

" outside of CUDA and doesn't require a special Avisynth+ build to run?"

Yes. All DX12 interfacing is inside MAnalyse only. Planned to extended to MDegrainN to reuse uploaded to accelerator frames.
But it require Windows10 (or newer) to have 'native' DX12 interface (and drivers from hardware accelerator manufacturer to support DX12-ME + compute shaders 5). I read about attempts to integrate DX12 to Win7 but it looks need significant re-write of user-application too to support these hacks. Also it was reported to run at AMD hardware that is not CUDA compatible at all - as was expected from Microsoft+DX hardware abstraction layers. May be new enough intel hardware will also support it someday (or already - not tested).

It is really some selection for developers: which API to hardware accelerators to implement/support - CUDA may be compatible between Windows/UNIX builds but limited to NVIDIA HW manufacturer only. The DirectX compatible between many HW accelerators manufacturers but limited to Windows host OS only (may be some hacks for UNIX exist or may be developed in the future). Microsoft invest into DirectX hardware abstraction infrastructure (user-side API and requirements for drivers developers / hardware developers) and naturally want to get profit - so UNIX 'official' DirectX support may be limited if any at all.

As I understand the Avisynth developers do not like idea to be limited by Windows only so the development of core support for offloading some computing to accelerator via Microsoft->DirectCompute (DX+compute shaders) API is unlikely. So it is currently possible only inside some single or sequenced filters from the single plugins pack with some additional interfacing about upoladed to accelerator resources for reusing.

[wonkey_monkey]

What would be the recommended way in C++ to check if the current AviSynth environment supports properties?

[pinterf]

What would be the recommend way in C++ to check if the current AviSynth environment supports properties?
Something like this commit:
https://github.com/pinterf/AjkMedian/commit/f99fdaada9af8360235e05baf1eb78af160354f6
With this technique your plugin will pass existing properties further, even if property read-write is not implemented. Same V8 check is enough for reading properties.

When you actively want to set properties I recommend a second check against V9 interface version, with which you can use an additional interface function env->MakePropertyWritable when the original frame content must be untouched. Otherwise after a MakeWritable or NewVideoFrameP you can use the getFramePropsRW

https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/FilterSDK/FilterSDK.html#what-s-new-in-the-api-v8
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/FilterSDK/FilterSDK.html#what-s-new-in-the-api-v9
and the env->CheckVersion part under
https://avisynthplus.readthedocs.io/en/latest/avisynthdoc/FilterSDK/Cplusplus_api.html#getenvproperty-v8

[wonkey_monkey]

Thanks. I must get around to updating my plugins one day soon...

[kedautinh12]

Wow, new avatar monkey :D

[ryrynz]

Pinterf needs one. Dogway needs a Dog. Reeldeel can have a movie reel.

[wonkey_monkey]

Would consideration be given to changing ImageSource so that it selects the most appropriate colourspace for the depth of the input image? By default 16-bit PNGs produce an 8-bit clip, which seems at odds with other source filters. And whether or not there is any transparency could decide whether it should be RGB[24/48] or RGB[32/64] (or maybe it should default to planar RGB nowadays).

As I understand it JPEG is also usually YCbCr, which could also be returned as a valid colourspace, instead of converting to RGB...?

[DTL]

JPEG is 'full-range' typically I think. Also it can have 4:4:4 non chroma subsampled form (and looks 4:2:2 too). So in the old Avisynth to be more compatible without additional range properties it looks was converted to RGB type. Keeping YCrCb (also with chroma subsampled) may confuse users with unnatural to video 'full-range' YCrCb.
Also JPEG is typically for static pictures encoding same as for old non-moving pictures pixel-based from computers. So to load JPEG same as BMPs and other pixel-based formats it may be converted to the same non-video RGB. To indicate it is static picture. Not picture from moving picture sequence.

[qyot27]

Would consideration be given to changing ImageSource so that it selects the most appropriate colourspace for the depth of the input image? By default 16-bit PNGs produce an 8-bit clip, which seems at odds with other source filters. And whether or not there is any transparency could decide whether it should be RGB[24/48] or RGB[32/64] (or maybe it should default to planar RGB nowadays).

As I understand it JPEG is also usually YCbCr, which could also be returned as a valid colourspace, instead of converting to RGB...?
The problem is that DevIL doesn't support outputting YUV or planar RGB. It *might* be able to do RGB48/RGBA64, but the way the plugin currently works doesn't let that go through. Apart from that, technically FFMS2 does have an FFImageSource function (https://github.com/FFMS/ffms2/blob/master/src/avisynth/avisynth.cpp#L320) that'll do whatever FFmpeg does.

The real solution would be to move to a different image library that does support YUV and high bit depth images easily. From a basic search, the only one I feel probably comes close to both the goal ImageSource had in using DevIL and that supports YUV/HBD stuff is SAIL (https://github.com/HappySeaFox/sail). If that happens, it'd be down the road a ways.