Avisynth+

[pinterf]

No idea, personally I was even feeling better that there was no push on a release each second day. There is not much left on my side (overlay), but definitely I still need many evenings for finishing that. The already existing parts should be pretty usable now. True, releasing the version is the easier thing, but writing proper documentation is another necessary task. Not to mention then the filters, ouch..., but you know it better, how these things work :)

My fork is a working fork, the official one is ultim's.

[LigH]

@ ajp_anton:

Well, I am not such a "Professional Code Monkey" as Myrsloik ... ;) But I would not consider motion estimation as "basic functionality". Instead, SeparateFields() and Weave() are basic features of video processing (it's like comparing integral calculus with integer addition). Hard to point at a specific criterion; and it would not be my decision anyway.

But I could imagine at least two points: a) plugin functions can be a magnitude more complex than basic functions, therefore it is certainly wise to include only functions in the kernel which can easily be overlooked and guaranteed to work correctly for a long time and a wide range of uses, and it is fortunate that plugins can be updated separately from the kernel when they are fixed or expanded; b) plugin authors are possibly not members of the core development team, so they may work in their own environment, with their own rules, may or may not share source code as they prefer.

[real.finder]

I am with LigH, external plugins better for advanced filters

this also make them easy to update without reinstall all Avisynth and so...

and Avisynth already has many lines...

I hope Avisynth+ developers make that Avisynth internal filters in external dll like what they did in TimeStretch and ImageSeq and so

[Groucho2004]

But I could imagine at least two points: a) plugin functions can be a magnitude more complex than basic functions, therefore it is certainly wise to include only functions in the kernel which can easily be overlooked and guaranteed to work correctly for a long time and a wide range of uses, and it is fortunate that plugins can be updated separately from the kernel when they are fixed or expanded; b) plugin authors are possibly not members of the core development team, so they may work in their own environment, with their own rules, may or may not share source code as they prefer.
Exactly, particularly (b). The whole point of the plugin sub-system is that anyone skilled enough can write and, more importantly, maintain their stuff. The core should be kept as lean as possible.

[ajp_anton]

Ah, yes, while I'm no developer so don't fully grasp the difficulties of work environments, I at least see the point in being able to update complex plugins more often than the whole core. So it's better to only include things that are simple enough to be considered "finished" and not break unexpectedly.

[jpsdr]

I hope Avisynth+ developers make that Avisynth internal filters in external dll like what they did in TimeStretch and ImageSeq and so
There is a "side" issue with it, i've encounter when i've made my mutli-threading resampler.
You don't have acces anymore easely to other internal filters, you have to use the "invoque" interface instead of accessing directly the internal functions, this has a performance issue.

[ryrynz]

Are there any plans for a DirectShow filter that can serve as a replacement for ffdshow's AviSynth processing?


Not at this time. It'd be pretty easy to implement for someone who is familiar with dshow though (and that's usually the bottleneck for dshow-related stuff anyway).

Any dev here interested in creating something sometime to replace ffdshow raw? The only down sides right now of using ffdshow raw is that I have to disable it for every 10 bit
video and the crashing on the odd occasion with start up of even simple scripts. Something new would be a good companion program for Avisynth+. I can't be the only one clamoring for this surely :D

[TheFluff]

Re: the masktools in core stuff: no. No no no no. NO! Literally everything anyone other than ajp_anton said is completely backwards. I doubt you could get it more backwards if you tried.

First, it is remarkable that people seem to think SeparateFields is basic functionality while the masktools junk like LUTs, convolutions, simple convolution-based filters (i.e. Sobel/Prewitt) and the other stuff in masktools isn't, because it indicates you have absolutely no foundation at all to stand on in neither discrete mathematics nor in digital raster graphics. These are completely trivial filters that are absolutely essential building blocks. I'll grant though that MVTools is a lot more esoteric - it's a technology fundamental to digital video but there's a ton of ways to do it, it's just that in Avisynth there's MVTools and nothing else.

Second, the "let people maintain their own plugins" thing has empirically been conclusively proven to be a complete red herring. Go directly to "fragmentation", do not pass Go and do not collect $200. How many vaguely incompatible MVTools forks do we have now, again? Is it five or more? Literally nobody wants to maintain this junk because Avisynth plugin code quality tends to be absolute garbage and is written to be unmaintainable. There's a reason the VS ports have tended to just throw out most of the old code and rewritten large parts from scratch.

There is absolutely no reason to have such video fundamentals as convolutions and LUT's in an externally maintained plugin. Do it right, once (there is no really not much room for variation with these fundamentals, there's generally one correct implementation), and make it maintainable. Then ship it with the core application and hope nobody gets any funny ideas to try to rice out their own homegrown variants (haha, who am I kidding, this is the forum where someone tried to rice out bitblt).

[mcjordan]

I need some help to compile latest Avisynth (r2277) from git repository (with VS 2015 Update 3):
I've some things in compilation log that make me feel nervous ;-)
---
...\AviSynthPlus\avs_core\convert\convert.cpp(1968): warning C4244: 'argument': conversion from 'intptr_t' to 'int', possible loss of data
...
...\AviSynthPlus\avs_core\filters\focus.cpp(413): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data
...\AviSynthPlus\avs_core\filters\focus.cpp(1099): note: see reference to function template instantiation 'void af_horizontal_rgb32_64_c<uint8_t>(BYTE *,size_t,size_t,size_t,int)' being compiled
...\AviSynthPlus\avs_core\filters\focus.cpp(415): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data
...
...\AviSynthPlus\avs_core\filters\levels.cpp(194): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data
...
...\AviSynthPlus\avs_core\filters\text-overlay.cpp(1411): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data
etc.
---
After some reading I found (briefly) this:
"The risk here is that size_t might be larger than (unsigned) int, and thus you cannot safely convert if that is the case." aka full story:
---
"In short, size_t is never negative, and it maximizes performance because it's typedef'd to be the unsigned integer type that's big enough -- but not too big -- to represent the size of the largest possible object on the target platform.

Sizes should never be negative, and indeed size_t is an unsigned type. Also, because size_t is unsigned, you can store numbers that are roughly twice as big as in the corresponding signed type, because we can use the sign bit to represent magnitude, like all the other bits in the unsigned integer. When we gain one more bit, we are multiplying the range of numbers we can represents by a factor of about two.

So, you ask, why not just use an unsigned int? It may not be able to hold big enough numbers. In an implementation where unsigned int is 32 bits, the biggest number it can represent is 4294967295. Some processors, such as the IP16L32, can copy objects larger than 4294967295 bytes.

So, you ask, why not use an unsigned long int? It exacts a performance toll on some platforms. Standard C requires that a long occupy at least 32 bits. An IP16L32 platform implements each 32-bit long as a pair of 16-bit words. Almost all 32-bit operators on these platforms require two instructions, if not more, because they work with the 32 bits in two 16-bit chunks. For example, moving a 32-bit long usually requires two machine instructions -- one to move each 16-bit chunk.

Using size_t avoids this performance toll. According to this fantastic article, "Type size_t is a typedef that's an alias for some unsigned integer type, typically unsigned int or unsigned long, but possibly even unsigned long long. Each Standard C implementation is supposed to choose the unsigned integer that's big enough--but no bigger than needed--to represent the size of the largest possible object on the target platform."
---
...and this:
"Converting an int to intptr_t and back is unlikely to lose information but there's no actual guarantee that intptr_t is wider than int.
If you want to store pointer values, store them in pointer objects. That's what pointer objects are for.
Any pointer to an object or incomplete type can be converted to void* and back again without loss of information. There is no such guarantee for pointers to functions -- but any pointer-to-function type can be converted to any other pointer-to-function-type and back without loss of information. (I'm referring to the C standard; I think POSIX provides some additional guarantees.)"
---
Help? (for "right" compilation)?

[pinterf]

I need some help to compile latest Avisynth (r2277) from git repository (with VS 2015 Update 3):
I've some things in compilation log that make me feel nervous ;-)
---
...\AviSynthPlus\avs_core\convert\convert.cpp(1968): warning C4244: 'argument': conversion from 'intptr_t' to 'int', possible loss of data
---
Help? (for "right" compilation)?

In those cases you can ignore these warnings.
Rarely size_t is used for numbers where traditionally int is more than enough: e.g. frame width, height, pitch of the frame. At some places I replaced them back to int to use them uniformly throughout the code.
One or two of the cases you mentioned I am to blame, so probably I will look through them and will fix these warnings.

[mcjordan]

Thank you, pinterf! I highly appreciate your hard work and help for all community.

[pinterf]

Good news.

Just after four months from the beginning I think I have finished all that I wanted (and did't want :) ) to do regarding the high-bit-depth transition.

All that is left is some exotic histogram types that are not ported to 10+ bits and some filters are not available in float.

But most of this giga-hack is done, maybe I should prepare a test build for you along with giving information what has been changed lately, including new function and new or extended filters.

Thank you for your patience.

[raffriff42]

Sounds great! I'll note any changes in the wiki (http://avisynth.nl/index.php/Internal_filters) for you.

[burfadel]

Good news.

Just after four months from the beginning I think I have finished all that I wanted (and did't want :) ) to do regarding the high-bit-depth transition.

All that is left is some exotic histogram types that are not ported to 10+ bits and some filters are not available in float.

But most of this giga-hack is done, maybe I should prepare a test build for you along with giving information what has been changed lately, including new function and new or extended filters.

Thank you for your patience.

Sounds good! Thanks.

[real.finder]

Good news.

Just after four months from the beginning I think I have finished all that I wanted (and did't want :) ) to do regarding the high-bit-depth transition.

All that is left is some exotic histogram types that are not ported to 10+ bits and some filters are not available in float.

But most of this giga-hack is done, maybe I should prepare a test build for you along with giving information what has been changed lately, including new function and new or extended filters.

Thank you for your patience.

waiting for new build :thanks:

I remember I read that a lot of avs filters already did 8 to 16 and did the edit then back to 8, can someone list them? or list that don't do that

edit: I think I read it from http://forum.doom9.org/showthread.php?p=1773670#post1773670 and maybe another place too

[MysteryX]

Is native dithering supported yet?

[pinterf]

Is native dithering supported yet?
Ordered dither for 10-16 to 8 bits. In next release of course.

[MysteryX]

ok I'm still very confused with the new functions. Is there a page with updated documentation of the new 16-bit functions?

I'd have to make AviSynthShader compatible with this too; and convert my whole script at the same time -- if it's possible yet.

[pinterf]

ok I'm still very confused with the new functions. Is there a page with updated documentation of the new 16-bit functions?

I'd have to make AviSynthShader compatible with this too; and convert my whole script at the same time -- if it's possible yet.

When I have time, but soon. I wanted to finish some mvtools parts for 16 bit, hence the delay.

[Reel.Deel]

Good news.

Just after four months from the beginning I think I have finished all that I wanted (and did't want :) ) to do regarding the high-bit-depth transition.

All that is left is some exotic histogram types that are not ported to 10+ bits and some filters are not available in float.

But most of this giga-hack is done, maybe I should prepare a test build for you along with giving information what has been changed lately, including new function and new or extended filters.

Thank you for your patience.

Pinterf, you shouldn't be thanking us, we should be thanking you!! Thanks for all you hard work! :)
Work and other things have kept me busy the last few months but hopefully things will start to die down shortly and I'll get back to the docs. Right now a good percentage of the internal filters are done but I have to go back and document the HBD RGB support as well as the additional parameters for some of the filters.

Sneak peak:

Crop:
https://s9.postimg.org/o4nfk2wzv/Avi_Synth_Plus_Documentation_Crop.png (https://s9.postimg.org/p6xm2mft9/Avi_Synth_Plus_Documentation_Crop.png)

Turn:
https://s14.postimg.org/lvuqavad9/Avi_Synth_Plus_Documentation_Turn.png (https://s14.postimg.org/fux1dsnr3/Avi_Synth_Plus_Documentation_Turn.png)


Sounds great! I'll note any changes in the wiki (http://avisynth.nl/index.php/Internal_filters) for you.

I don't know if listings all AVS+ changes alongside the 'official' documentation is a good idea. Might be a tad confusing. Ultim said that he will host the updated docs on http://avs-plus.net/. This will include information on all the changes and new features. Most of this info is already on the AVS+ wiki page.

[TheFluff]

Crop:
https://s9.postimg.org/o4nfk2wzv/Avi_Synth_Plus_Documentation_Crop.png (https://s9.postimg.org/p6xm2mft9/Avi_Synth_Plus_Documentation_Crop.png)

why is cropbottom still a thing

I mean, of all the dumb things you could have syntactic sugar for...

[pinterf]

Looking good.

The layout of the supported colorspaces will definitely need reorganizing, as the 10, 12 and 14 bits are now equally usable both in YUV/YUVA, and Planar RGB/RGBA as 16 bits.
So it won't be needed to mention them separately, simply: YUV(A) 10-16 bits | 32 bits: (checkbox checked), PlanarRGB(A) 8 | 10-16 bits | 32 bits: (ok, ok, not ok), etc...

There will be hints on usage, e.g. Tweak can benefit from 10 bits, because it can use faster lookup tables, while at 16 bits the filter should calculate every pixel realtime. And so on...

Thank you all for the documentation work in advance.

[pinterf]

O.K., I think that first phase of the high bit depth development is over for Avisynth+, it's time to start public tests.
Download Avisynth+ r2290-MT (https://github.com/pinterf/AviSynthPlus/releases/tag/r2290-MT)

Let's see who finds the first significant bug that I have to hotfix, possibly even tomorrow :)
I have no illusions that you may find one soon, as almost every internal filters was adapted to 8+ bits. Although I tested them parallel with 8 bit vs. high bit depth until they were giving identical results, the sheer amount of the changed code should make us cautious.

Many 8+ bit code paths got sse2 support, a few even AVX and AVX2, but there are still many which is still in C. Gradually they will be replaced with SIMD intrinsics, if needed.

In brief:

new basic color spaces: YUVA (YUV + alpha support) and Planar RGB and RGBA
10, 12, 14, 16 bits and float for greyscale, YUV, YUVA, Planar RGB, Planar RGBA
RGB48 and RGB64 packed RGB formats
Filters that worked for RGB24 and RGB32 now work with planar RGB and RGB48 and RGB64
Similarly: YUV filters will work with YUVA on all mentioned bit-depths (though some of them have no 32 bit float support)


For filter writers there is an updated avisynth.h header

defines new color spaces
automatic fallback of new avs+ specific VideoInfo function calls to work with classic avs dll (e.g. vi.BitsPerComponent returns 8 instead of giving exception, though it does not exists in classic avisynth 2.6)
and of course 64bit ready

At the moment you can grab it from here (https://github.com/pinterf/AviSynthPlus/tree/r2290-MT/avs_core/include) and don't forget the subfolders as cpuid.h defines AVX2, which is basically the new SSE2 for this decade.

Thanks to Myrsloik, you can feed your clips directly into avisynth+
https://github.com/FFMS/ffms2/releases
http://forum.doom9.org/showthread.php?t=127037

And pipe for 10 bit encoding with avs2pipemod:
http://forum.doom9.org/showthread.php?p=1775368#post1775368

FFMS2("prores_yuv422p10le_hq_apch_yuv422p10.mov").Info().Histogram("levels",bits=10)
RemoveAlphaPlane()
ConvertBits(8, dither=0)


or read/write 10 bits

FFMS2("prores_yuv422p10le_hq_apch_yuv422p10.mov")
Info()
RemoveAlphaPlane() #YUVA original
ConvertBits(10)


avs2pipemod -y4mp test10.avs | ".\x264_10.exe" --stdin y4m - --crf 0 --preset fast --output ".\iam10bit.MKV

Thanks for everybody who was involved in this project.
Test it and give feedback.
Detailed description of the changed function will follow later.
I wish you a good experimenting.

[tormento]

O.K., I think that first phase of the high bit depth development is over for Avisynth+, it's time to start public tests
:thanks::thanks::thanks:

[Sparktank]

YUVA, fancy.

I feel like I just walked into the same building that just got revonations.

[Thunderbolt8]

apparently Sony Vegas is able to work/dither in 32-bit float when it comes to video levels pixel format. would this be useful to have here as well?

[vcmohan]

It is good that avsynth+ now support larger bit depths as well as float formats. A few doubts:
1. Does the avs+ present 16 bit (zeroes filled in higher bits) for the 10 to 14 bit inputs? Also expects similar outputs from the plugins?
2. In packed formats of RGB or RGBA with smaller than 8 or larger than 8 bit depth is it the plugin's responsibility to unpack, fill zeroes in bits as required for processing and undo all this for output?
3. In float formats (assuming only 32 bit formats are supported) what are the value ranges of Y ( 0.0 to 1.0 ?)and U,V (-0.5 - 0.5?) planes?
4. Is there an easier way of downloading the header and the sub folder files than copying each file in raw and saving with that name?

[qyot27]

It is good that avsynth+ now support larger bit depths as well as float formats. A few doubts:
1. Does the avs+ present 16 bit (zeroes filled in higher bits) for the 10 to 14 bit inputs? Also expects similar outputs from the plugins?
There was a long discussion about this and whether the real bits were stored in the MSB or LSB, look back a few pages.

4. Is there an easier way of downloading the header and the sub folder files than copying each file in raw and saving with that name?
git clone git://github.com/AviSynth/AviSynthPlus
cd AviSynthPlus
git checkout MT
git checkout -b fixheader b4f292b4dbfad149697fb65c6a037bb3810813f9
make install PREFIX=/path/to/whereever
The specific commit checkout is necessary for anything that uses the C interface (like Libav, prominently), since there's a regression in the HEAD version of capi.h right now as regards stuff built with MSVC vs. GCC.

[burfadel]

Let's see who finds the first significant bug that I have to hotfix, possibly even tomorrow :)

No hotfix yet? You must have done a better job than you realised :).

[pinterf]

It is good that avsynth+ now support larger bit depths as well as float formats. A few doubts:
1. Does the avs+ present 16 bit (zeroes filled in higher bits) for the 10 to 14 bit inputs? Also expects similar outputs from the plugins?
2. In packed formats of RGB or RGBA with smaller than 8 or larger than 8 bit depth is it the plugin's responsibility to unpack, fill zeroes in bits as required for processing and undo all this for output?
3. In float formats (assuming only 32 bit formats are supported) what are the value ranges of Y ( 0.0 to 1.0 ?)and U,V (-0.5 - 0.5?) planes?
4. Is there an easier way of downloading the header and the sub folder files than copying each file in raw and saving with that name?
Still no time for proper intro to avs+, see short answers

1.) 10-14 bit formats are not scaled to full 16 bit, their maximum pixel value is (1<<bit_per_component)-1, that is 10 bit range is 0-1023, 12 bits 0-4095, 14 bits 0-16383, 16 bit 0-65535.

YUV bit depth conversions are simple bit-shifts as it was mentioned earlier in this topic. RGB bit-depth conversions are always full scale e.g. 0..255 -> 0..1023 (stretch)

Alpha plane conversion is always full scale, also for YUVA, so that a fully transparent 255 is always mapped to the largest available pixel value within the format.

2.) Packed RGB formats support either 8 (RGB24/32) or 16 bit (RGB48/64) internal bit-depths. However we should note that in the future planar RGB is the way to go with 8-10-12-14-16 bits and float. For plugin writers: planar RGB plane constants are PLANAR_G, PLANAR_B and PLANAR_R. This is also the internal order of the planes. For YUV the constants are unchanged: PLANAR_Y, PLANAR_U and PLANAR_V. The Alpha channel is PLANAR_A for both YUVA and Planar RGBA.

3.) Float. U and V channels for the 32 bit float format are not shifted to the +/-0.5 range. Any float channels are represented 0..1 internally. When special handling needed, e.g in tweak, etc, they are normalized to the +/-0.5 range, do the calculations the go back to 0..1.

4.) Not yet.

[pinterf]

YUVA, fancy.

I feel like I just walked into the same building that just got revonations.
Let's call it face-lift.

[vcmohan]

Many thanks for this. I still need few clarifications. Sorry to bother you. For the 10 t0 14 bit depth formats is it correct to assume that avs+ provides to the plugin 16 bit values with the MSB s filled in with appropriate number of zeroes.
I also infer that packed RGB formats support only 8bit or 16 bit per color .
In case of float U and V values, vapoursynth uses -0.5 to + 0.5.range. Any reason for this departure by AVS+? Which of these are standard?

[pinterf]

Many thanks for this. I still need few clarifications. Sorry to bother you. For the 10 t0 14 bit depth formats is it correct to assume that avs+ provides to the plugin 16 bit values with the MSB s filled in with appropriate number of zeroes.

Yes, the internal filters (and the external ones in the future) are responsible to properly clamp the values to the 0..max_pixel_value range.
There are places in the core filters however where I had to make extra checkings for the valid values, mostly in functions that use lookup, to avoid overindexing a 10 bit lut table with a falsely presented higher pixel value.
Or in Histogram. But for most of other filters there is no pre-check, that would slow down the processing.


I also infer that packed RGB formats support only 8bit or 16 bit per color .
In case of float U and V values, vapoursynth uses -0.5 to + 0.5.range. Any reason for this departure by AVS+? Which of these are standard?
No reason, for most of the internal filters it was much easier not to deal with the range shift, UToY, VToY works transparently, did not have to make special cases for differently handling U and V just for float, etc. And this three months timeframe was clearly not enough to look at all these problems and questions from an independent, external overview.

[pinterf]

Avisynth Plus Quick reference guide

Color spaces

Greyscale (Y only)

8 bit: Y8
10, 12, 14, 16 bits: Y10, Y12, Y14, Y16
32 bits (float): Y32 (yes, Y32 instead of YS)
Check: IsY (instead of IsY8 which is 8 bit only)
ComponentCount() for greyscale formats returns 1

YUV: planar format with a luma (Y) and two chroma (U, V) channels

8 bits: YV12, YV16, YV24, YV411
for filters requiring colorspace name YUV420/YUV422/YUV444 or YUV420P8/YUV422P8/YUV444P8 is also accepted
10 bit: YUV420P10, YUV422P10, YUV444P10
12 bit: YUV420P12, YUV422P12, YUV444P12
14 bit: YUV420P14, YUV422P14, YUV444P14
16 bit: YUV420P16, YUV422P16, YUV444P16
32 bit (float/Single precision): YUV420PS, YUV422PS, YUV444PS

YV411 has no high bit depth variant

Check#1: Is420, Is422, Is444 (instead of IsYV12/IsYV16/IsYV24 which are for 8 bits only)
Check#2: IsYUV
for compatibility reasons, IsYUV returns true for YUY2 and Y also
For strict checking one can check IsPlanar (for distinct from YUY2) and ComponentCount==3 (for distinct from greyscale)

YUVA: planar format with a luma (Y), two chroma (U, V), and one Alpha (A) channels

8 bit: YUVA420/YUVA422/YUVA444 or YUVA420P8/YUVA422P8/YUVA444P8
10, 12, 14, 16, 32 bits: see corresponding YUV name and use YUVA

Check#1: Is420, Is422, Is444
Check#2: IsYUVA
ComponentCount for YUVA returns 4
Note: YUVA is a separate color space family, in order to handle YUV and YUVA clips, you have to check for YUVA separately.

Packed RGB
8 bits: RGB24, RGB32 (BGR and BGRA internally)
16 bits: RGB48, RGB64

Check: IsRGB ; note: IsRGB now true for planar RGB(A) color spaces.
Check2: IsRGB24, IsRGB32, IsRGB48, IsRGB64

Planar RGB, RGBA: RGB family with 3 or 4 planes of colors
Plane order is GBR and GBRA internally

8 bits: RGBP, RGBAP or RGBP8, RGBAP8
10, 12, 14, 16 bits: RGBP10..RGBP16, RGBAP10..RGBAP16
32 bits (float/Single precision): RGBPS, RGBAPS

Check: IsPlanarRGB or IsPlanarRGBA respectively
Check#2: generally IsRGB is also true

Colorspace conversions

ConvertToY for all bit depths (8 bit only: ConvertToY8)
ConvertToYUV420 for all bit depths (8 bit only: ConvertToYV12)
ConvertToYUV422 for all bit depths (8 bit only: ConvertToYV16)
ConvertToYUV444 for all bit depths (8 bit only: ConvertToYV24)
ConvertToYUV411 (this is 8 bit only: same as ConvertToYV411)

All parameters are the same as in their old 8 bit-only counterparts

YUV420: c[interlaced]b[matrix]s[ChromaInPlacement]s[chromaresample]s[ChromaOutPlacement]s
Greyscale: c[matrix]s
others: c[interlaced]b[matrix]s[ChromaInPlacement]s[chromaresample]s


ConvertToPlanarRGB
ConvertToPlanarRGBA
ConvertToPlanarRGBA will copy the Alpha channel of a packed RGB32 or RGB64 format



ConvertToRGB24
ConvertToRGB32
ConvertToRGB48
ConvertToRGB64

Conversions to either packed or planar RGB targets have the same parameters as in their old 8 bit-only counterparts
(c[matrix]s[interlaced]b[ChromaInPlacement]s[chromaresample]s)

matrix parameter can have a new value

rec601
rec709
PC.601/PC709
PC.709/PC709
AVERAGE
rec2020 (new)


Colorspace conversions are working within the same bit depth:
e.g. you cannot convert a 10 bit YUV420P10 to RGB64.


AddAlphaPlane([mask=default_alpha_value])
YUV->YUVA, RGBP -> RGBAP, RGB24->RGB32, RGB48->RGB64
If optional mask parameter is supplied, the alpha plane is set to this value.
Default: maximum pixel value of current bit depth (255/1023/4095/16383/65535/1.0)

If the current video format already has alpha channel and mask is provided, then the alpha plane will be overwritten with the new mask value.

RemoveAlphaPlane
YUVA->YUV, RGBAP->RGBP, RGB32->RGB24, RGB64->RGB48


Bit depth conversion
ConvertBits(bits[,truerange,dither)

Old versions: ConvertTo8bit, ConvertTo16bit(bits), ConvertToFloat
I recommend that you use the ConvertBits format.

For Y, U and V channels the conversion is a simple bit-shift.
For R, G, B and A channels the pixel values are "streched" in order to have 0..255 to be mapped to 0..65535
At the moment you cannot choose this behaviour as a parameter.

parameters:

bits
target bit depth: 8, 10, 12, 14, 16, 32
truerange
default: true
Choose this if you want to convert 10-16 bit formats without re-scaling underlying pixel data. E.g.
clip10bit.ConvertBits(16, truerange=false) will leave pixel data in the 0..1023 range, but will change the video format from YUVxxxP10 to YUVxxxP16
dither
optional, at the moment works for 10-16 bits->8 bit conversions
Valid values:
-1: no dither (default)
0: ordered dither

of course, more methods will come later



Compatibility conversions
Conversions for hacked 16 bit formats.
For filters that use 16 bit video data in a fake 8 bit colorspace. Avisynth plus provides built-in conversions for your convenience until more plugins supporting high bit depth appear.


ConvertToStacked
ConvertFromStacked([bits=b])
ConvertToDoubleWidth
ConvertFromDoubleWidth([bits=b])


Misc. video info properties

ComponentSize
8 bit: 1 (bytes)
10-16 bit: 2 (bytes)
32 bit float: 4 (bytes)
BitsPerComponent
8, 10, 12, 14, 16, 32
ComponentCount
1 for greyscale
3 for YUV, Planar RGB, RGB24 and RGB48
4 for YUVA, Planar RGBA, RGB32 and RGB64

[Myrsloik]

What's the AVERAGE matrix good for? Is this an odd attempt at naming YCgCo or something else?

[Yanak]

Hello,

I always used to add a logo on my videos using this command :
https://s14.postimg.org/5ht6urnc1/75448720161026153618cr0cr.png

Now in avisynth r2290 x64 it returns me this :
https://s14.postimg.org/unu51lwc1/22317820161026153618crcr.png


I read the previous post about references and tried with ConvertToYUV420() instead of ConvertToYV12() but the result is the same as last picture.
If i leave the ConvertToYV12() where it is the result is always messed up, if i move it at the end of the script it works.

Don't know if i understand everything correctly or missing something, i'm a bit lost in this now.

If anyone have a clue about this please, thanks a lot for the help.

[pinterf]

Hello,

I always used to add a logo on my videos using this command :

Now in avisynth r2290 x64 it returns me this :

I read the previous post about references and tried with ConvertToYUV420() instead of ConvertToYV12() but the result is the same as last picture.
If i leave the ConvertToYV12() where it is the result is always messed up, if i move it at the end of the script it works.

Don't know if i understand everything correctly or missing something, i'm a bit lost in this now.

If anyone have a clue about this please, thanks a lot for the help.
Thanks for the report. Looking into the fix right now.

[Yanak]

So it's a bug then, was not really sure about it,

Take your time and thanks for the hard work on this :)

[pinterf]

Expected sooner, but the first bug was reported. Big thanks for it, really.

The fix is available:

Avisynth Plus r2294MT (https://github.com/pinterf/AviSynthPlus/releases/tag/r2294)

Avisynth Plus r2294-MT
Date: 20161026
- Fix: Overlay 8 bit YV12 and possibly YUY2
- New: DirectShowSource and AviSource
16-bit RGB input support (BGR[48], BRA[64])

The addition came from our new contributor, ignus2.

Changed files compared to the r2290 release:
avisynth.dll and directshowsource.dll

[Yanak]

Thanks a lot for the dedicated work and quick fix,

Have a nice day.

Ps : tested and yes it works as before, thanks again :)

[ajp_anton]

Should converting between linear/gamma be handled by internal filters somehow?

[jpsdr]

Is something like this still working with all these new format/size, or should i do otherwise ?

const int src_width = vi.IsPlanar() ? vi.width : vi.BytesFromPixels(vi.width);

If otherwise, what should i do ?

:thanks:

[StainlessS]

Whats wrong with this ?

const int src_width = src->GetRowSize(PLANAR_Y)


vi.width is width in pixels, GetRowSize(PLANAR_Y) gets row size in bytes of Y if Planar and also works ok with YUY2 / RGB.

I should not imagine that anything has changed in AVS+

[pinterf]

Is something like this still working with all these new format/size, or should i do otherwise ?

const int src_width = vi.IsPlanar() ? vi.width : vi.BytesFromPixels(vi.width);

If otherwise, what should i do ?

:thanks:
It depends, what do you want to do with it?

For non-planar sources BytesFromPixels(1) will return
RGB24: 3
RGB32: 4
RGB48: 6
RGB64: 8
YUY2: 2

If you want to get the byte size of a row (within one plane for planar or the whole packed line for old RGB formats), by using BytesFromPixels(width) you will get the occupied bytes of one row.

I suppose you use it in resampler, this is how it is used there:
int work_width = vi.IsPlanar() ? vi.width : vi.BytesFromPixels(vi.width) / pixelsize
where pixelsize is vi.ComponentSize() (1 for 8 bits, 2 for 10-16 bits, 4 for float)

[jpsdr]

Ok, thanks.

[Ignus2]

About 16-bit RGB support:
I'd like to have some opinions here.

The fourccs I added to AviSource/DirectShowSource was based on what ffmpeg defined for them (bgr48le: BGR0 ie. BGR[48], bgra64le: BRA@ ie. BRA[64]):
https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/raw.c

Bottom-first vs Top-first
Currently, afaik, packed RGB (both 8/16-bit) is always stored inside avs+ upside down (bottom-first). This is OK (doesn't matter), the question is how to handle 16-bit RGB data when it enters/exits avs+. We all know for DIB formats inside avi/vfw/dshow the sign of the height matters: negative height means top-first, positive height means bottom-first.
BGR0 and BRA@ are basically the 16-bit equivalents of BI_RGB 24/32 bit, however it is unclear whether they should be treated as DIB or not (meaning: should the sign of the height matter or not).
We had a long discussion with shekh about this on how to interpret it, and we think these formats don't qualify for the DIB rule, so the sign of the height shouldn't matter (as they are separate fccs), or should it?
^Opinions needed here.

The reason fcc:BI_RGB with bits:64 doesn't work (when coming from a codec for example) is that it makes dshow croak. I believe it is because dshow tries to match to a mediasubtype, and there is none for BI_RGB 64bit, so it fails. So the only option is to use some fourcc, for which the only one existing is defined in ffmpeg (the fact that ffmpeg however cannot read back AVIs written by itself containing BGR0/BRA@ fourcc is another story).

Y8 as DIB
Avs+ AviSource/DirectShowSource treats Y8 as DIB meaning the sign of the height matters and also expects 4-byte boundary padding. Why is that (source)?

Greets,
I.

[Myrsloik]

About 16-bit RGB support:
...

Y8 as DIB
Avs+ AviSource/DirectShowSource treats Y8 as DIB meaning the sign of the height matters and also expects 4-byte boundary padding. Why is that (source)?

Greets,
I.

This is simple. Planar formats aren't aligned to 4 bytes. What's a packed format? Formats with only one plane. Y8 has only one plane and thus follows this rule. Note that partially packed formats like NV12 with its two planes aren't packed. This is common wisdom and you'll notice corrupted output everywhere once you stop following it. See AVFS bugs, and probably some ancient vdub blog posts and the avisynth vfw code. That part has nothing to do with DIB btw.

[Ignus2]

This is simple. Planar formats aren't aligned to 4 bytes. What's a packed format? Formats with only one plane. Y8 has only one plane and thus follows this rule. Note that partially packed formats like NV12 with its two planes aren't packed. This is common wisdom and you'll notice corrupted output everywhere once you stop following it. See AVFS bugs, and probably some ancient vdub blog posts and the avisynth vfw code. That part has nothing to do with DIB btw.

Thanks, now I'm wiser :)
EDIT: And why does Y8 take the sign of the height into account (in AviSource)? Is it also something common I'm not yet aware of?

Any thoughts on 16-bit packed RGBA (the other question)?

[real.finder]

This may be strange, but why we don't has hex colors (aka Web colors (https://en.wikipedia.org/wiki/Web_colors))?

I think it will be useful in Motion Analyze (http://forum.doom9.org/showpost.php?p=1783788&postcount=80)

[StainlessS]

I've no idea how you would want the hex colors arranged (if more than 8 bits per channel),
but maybe some of the scripting here could be persuaded to provide whatever you require.

http://forum.doom9.org/showthread.php?p=1711065&highlight=colors_rgb.avsi#post1711065

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

EDIT: Colors are from Avisynth provided colors_rgb.avsi in plugins folder.


The diligent amongst you might notice two copies of "color_palegoldenrod" in the mp4,
this is a duplicate in colors_rgb.avsi as installed by v2.6RC1, you might like to delete duplicate from your copy,
reported in RC1 devs thread.
The duplicate color in colors_rgb_avsi should have been fixed in v2.6, but not in above GIF.

EDIT: And see here:- http://avisynth.nl/index.php/Color_presets