AviSynth+ thread Vol.2

[pinterf]

Originally Posted by Dogway

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]

Originally Posted by pinterf

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.

Originally Posted by pinterf

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]

Originally Posted by Dogway

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.

Originally Posted by pinterf

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 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]

Originally Posted by Reel.Deel

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]

Originally Posted by Dogway

Full range gives me 136 .0 with:

ConvertBits(8,fulls=false,fulld=true)

Thanks. I also noticed that the Levels wiki page has some questionable numbers listed for full range:



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().
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]

Originally Posted by qyot27

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

Ah... Let the nightmare begin...

Originally Posted by qyot27

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]

Originally Posted by FranceBB

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 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]

Originally Posted by qyot27

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.



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

[pinterf]

Originally Posted by gispos

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.



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]

Originally Posted by qyot27

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.

Originally Posted by 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 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...perties_AVS.2B
• and here: http://avisynth.nl/index.php/Interna...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

[wonkey_monkey]

Isn't PropDelete the thing to use?

[Boulder]

Originally Posted by wonkey_monkey

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]

Originally Posted by pinterf

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?