Avisynth+

[asteri]

Please learn how to read previous pages of forum.

http://forum.doom9.org/showthread.php?p=1772657#post1772657
http://forum.doom9.org/showthread.php?p=1772944#post1772944

Thank you!
I would recommend ultim to publish these builds as "test builds" also on official page: http://avs-plus.net/

[ryrynz]

Thank you!
I would recommend ultim to publish these builds as "test builds" also on official page: http://avs-plus.net/

I don't think that will happen. The most recent changes break some previously compatible plugins plus there has been a lot of code committed recently. A proper build will be posted when ready.

[feisty2]

The midpoint is 127.5 for full-range 8-bit video, and multiplying by 257 just gives you 32767.5, which is the midpoint for full-range 16-bit video.



127.5 agreed, theoretically (0+255)/2=127.5, and 127.5 is not an integer.


It is a known problem that this convention for full-range YCbCr fails to accurately represent any pure grey colour, which is why there's another convention where the nominal minimum is 0 and the nominal maximum is 2^n, which in turn runs into the problem of failing to accurately represent pure red (#FF0000) and pure blue (#0000FF).


agreed, and instead of assuming representing any pure gray color is impossible, I think it makes sense to round 127.5 to 128 and gray colors will be representable, and I will hold on to my point before you link me a doc that explains how full range YCbCr works in detail, got noda last time I googled about full range YUV


Also, please type English.


I'm 19 not 91 and I'm good with the language I'm typing, and I will roll with it, you don't like it? suck it, bite me! bi-o-tch

[feisty2]

oh, and btw, just say if 127.5 is exactly how standards defined it, and gray colors are not representable, pure black will be rounded to its closest color [0, 128, 128] at uint8_t and [0, 32768, 32768] at uint16_t, your way, * 257, it's gonna be [0, 32896, 32896], my way, [0, 32768, 32768], and obviously the error between 32768 and 32767.5 << the error between 32896 and 32767.5

[pinterf]

New internal filters ported to 16 bit/float

AddBorders
LetterBox
HorizontalReduceBy2
VerticalReduceBy2
ReduceBy2 (= Horiz + Vert)
BlankClip/Blackness (->FadeXXX )
Tweak (todo: sat=0 + Float source = little greenish),
new param: bool realcalc, always true for 16/float: no integer lookup table arithmetic, pure double


Took a list from here (http://avisynth.nl/index.php/Internal_filters) and made a summary of YUV related functions that have NO 16/32 bit version.

Color conversion and adjustment filters

ColorYUV
Invert
Levels
Limiter
MergeARGB / MergeRGB


Overlay and Mask filters

MaskHS
Overlay
Subtract


Geometric deformation filters

SkewRows


Pixel restoration filters

Blur / Sharpen


Debug filters (most of it)

ColorBars / ColorBarsHD
Compare
Histogram
Info
ShowFrameNumber / ShowSMPTE / ShowTime
Subtitle

[colours]

oh, and btw, just say if 127.5 is exactly how standards defined it

The only standard I know of defining what to do with full-range YCbCr is JFIF, and it has a nominal luma range of 0 to 255 and a nominal chroma range of 0.5 to 255.5. (libjpeg-turbo implements this. (https://github.com/libjpeg-turbo/libjpeg-turbo/blob/123f7258a86e9e701e9c4cf9ce1a1ace00eca98f/jccolor.c#L38) Z also assumes this convention (https://github.com/sekrit-twc/zimg/blob/bbec5ad6d4482f01633a6d0c9a739063bcfce0a5/src/zimg/depth/quantize.h#L34), as does Dither_convert_rgb_to_yuv/yuv_to_rgb. I think swscale also does this, but the source code is a nightmare to read so I'm not 100% sure.)

AVS (and by extension, AVS+) uses a different convention for the Convert* filters (https://github.com/AviSynth/AviSynthPlus/blob/13d1967fb8583d994be9460d73261beeb6461bc8/avs_core/convert/convert_planar.cpp#L619), where the nominal luma range is 0 to 255 and the nominal chroma range is 1 to 255.

The "correct" convention is obviously 0 to 255 for both luma and chroma, but for whatever reason that's not what we ended up with. Apart from JFIF (which, you know, defines only what to do for JFIF files), no standard in common use defines what the nominal levels for full-range YCbCr should be; BT.601, BT.709, etc. only define the nominal levels for TV-range YCbCr.

Edit: Since vivan mentioned H.264, I went and checked that, and it defines a nominal chroma range of 0.5 to 2^n−0.5 in Annex E. (I assume HEVC says the same thing.) But really, my original point was that these all map RGB values to YCbCr values linearly; the exact endpoints to use for the range is something we can decide after we get rid of the strange idea of mapping 0 to 0, 128 to 32768, and 255 to 65535.

pure black will be rounded to its closest color [0, 128, 128] at uint8_t

In case you're bad at arithmetic, 127.5 is equally close to both 127 and 128.

and obviously the error between 32768 and 32767.5 << the error between 32896 and 32767.5

Also, dithering exists and anyone who cares about colour accuracy is already using it when converting between colourspaces with limited precision.

[real.finder]

New internal filters ported to 16 bit/float

AddBorders
LetterBox
HorizontalReduceBy2
VerticalReduceBy2
ReduceBy2 (= Horiz + Vert)
BlankClip/Blackness (->FadeXXX )


Took a list from here (http://avisynth.nl/index.php/Internal_filters) and made a summary of YUV related functions that have NO 16/32 bit version.

Color conversion and adjustment filters

ColorYUV
Invert
Levels
Limiter
MergeARGB / MergeRGB
Tweak


Overlay and Mask filters

MaskHS
Overlay
Subtract


Geometric deformation filters

SkewRows


Pixel restoration filters

Blur / Sharpen


Debug filters (most of it)

ColorBars / ColorBarsHD
Compare
Histogram
Info
ShowFrameNumber / ShowSMPTE / ShowTime
Subtitle


Compare has a bug in Y8 http://forum.doom9.org/showthread.php?p=1773137#post1773137

what about UToY8(clip clip) and VToY8(clip clip) (http://avisynth.nl/index.php/Swap)?

UToY and VToY was already there

so for 16 bit/float will have a new UToYx and VToYx or UToYUV400 and VToYUV400 to output in HBD?

[tormento]

Any modernization to SMDegrain with newer 16 bit filters would be glad ;)

[pinterf]

Edited the summary above with:
Tweak (todo: sat=0 + Float source = little greenish),
new param: bool realcalc, always true for 16/float: no integer lookup table arithmetic, pure double

And now one week holiday mode ON.
Probably I will read the forum but my internet will be limited.

[pinterf]

Compare has a bug in Y8 http://forum.doom9.org/showthread.php?p=1773137#post1773137

what about UToY8(clip clip) and VToY8(clip clip) (http://avisynth.nl/index.php/Swap)?

UToY and VToY was already there

so for 16 bit/float will have a new UToYx and VToYx or UToYUV400 and VToYUV400 to output in HBD?

Unfortunately UtoY and VToY is reserved already, and works with 16/32 bit. They do not truncate to a Y8/Y16/Y32 clip.

So UtoY8 and VToY8 is silently working like UtoY16/32 and VtoY16/32. The result clip is greyscale one.
I did not like the names like UtoLumaOnly, etc... so it remained with the Y8 ending, until someone finds a proper name for it and everybody agrees with it :)

[pinterf]

Any modernization to SMDegrain with newer 16 bit filters would be glad ;)

A big bottleneck is mvtools2. It is easier to backport it from VS than make it work with other colorspaces than 8 bit YV12/YUY.

[vivan]

The only standard I know of defining what to do with full-range YCbCr is JFIFH.264 defines full range, in Annex E. HEVC probably does it too.

[tormento]

A big bottleneck is mvtools2. It is easier to backport it from VS than make it work with other colorspaces than 8 bit YV12/YUY.
So, how does SMDegrain in LSB works?

[pinterf]

Mdegrain has lsb output option AFAIK

[ultim]

And now one week holiday mode ON.
Probably I will read the forum but my internet will be limited.

Well deserved, thank you pinterf! By the time you come back, I should have the fixes for the MT mode ready. Though this weekend is for family, and the next week there will be a lot of traveling for work... The code changes aren't that earth-shaking as far as line counts go, but there are a lot of edge cases and I have probably rewritten everything about 2-3 times already. These are causing me a lot of headache.

[MysteryX]

I'm porting AvsFilterNet to work with AviSynth+ and Visual Studio 2015. The project was never finished; the hard work was done but a few things were missing or done wrong.

Ultim, I was wondering what are the MT issues you're talking about. Now I'm seeing weird things (testing with the latest AVS build).

When running in MT mode 3, the calls are coming from many different threads. When running in MT mode 2, I would expect the GetFrame calls to come from the same threads as the calls to the constructors, but that's not the case. C++ will either "work" or give undefined behaviors, but C# is a lot more thread-aware and won't let it slip by when working with non-thread-safe objects. I'm surprised that C++ code works anyway. I tested MT mode 3 in pure C++ code too and the calls were indeed coming from many different threads.

Also, if the CreateFilter function returns a "FlipVertical" which is MT mode 1, then the plugin also runs in MT mode 1.

Now that I'm testing with AviSynthShader, I'm also seeing something else weird. If I run even without MT mode, my class gets instantiated 6 times? Not sure who is responsible for this.

Better wait until you bring out your next version for testing.

[TurboPascal7]

When running in MT mode 3, the calls are coming from many different threads. When running in MT mode 2, I would expect the GetFrame calls to come from the same threads as the calls to the constructors, but that's not the case.
At the same time?
It's perfectly fine to get calls from different threads at different points of time.

[feisty2]

In case you're bad at arithmetic, 127.5 is equally close to both 127 and 128.

I said "rounded to ...", floor(127.5)=127 and round(127.5)=128, and fine, "rounded to one of its closest colors [0, 128, 128] at uint8_t", I like your suggestions and they are healthy but, you always overreact about bits and pieces of rigorousness problems in the description, it's not a scientific dissertation so it's okay long as you get what I was saying.


Edit: Since vivan mentioned H.264, I went and checked that, and it defines a nominal chroma range of 0.5 to 2^n+0.5 in Annex E. (I assume HEVC says the same thing.)
think that should be 2^n-0.5 not +0.5 (255 = 2^8 - 1 not 2^8), who's bad at arithmetic now? ;), anyways, the midpoint goes 128 and that's good, I'll take that.


But really, my original point was that these all map RGB values to YCbCr values linearly; the exact endpoints to use for the range is something we can decide after we get rid of the strange idea of mapping 0 to 0, 128 to 32768, and 255 to 65535.

0-0 128-32768 255-65535, that's almost linear, my point was little disturbance to the linearity to set the midpoint straight was the kind of tradeoff I would take.

[feisty2]

AVS (and by extension, AVS+) uses a different convention for the Convert* filters, where the nominal luma range is 0 to 255 and the nominal chroma range is 1 to 255.

I think that's just fairly wrong, midpoint goes (255-1)/2=127 by that definition and 32767 at uint16_t, and 127*257=32639 and that's pretty far from 32767..

[ultim]

I'm porting AvsFilterNet to work with AviSynth+ and Visual Studio 2015. The project was never finished; the hard work was done but a few things were missing or done wrong.

Ultim, I was wondering what are the MT issues you're talking about. Now I'm seeing weird things (testing with the latest AVS build).

When running in MT mode 3, the calls are coming from many different threads. When running in MT mode 2, I would expect the GetFrame calls to come from the same threads as the calls to the constructors, but that's not the case. C++ will either "work" or give undefined behaviors, but C# is a lot more thread-aware and won't let it slip by when working with non-thread-safe objects. I'm surprised that C++ code works anyway. I tested MT mode 3 in pure C++ code too and the calls were indeed coming from many different threads.

Also, if the CreateFilter function returns a "FlipVertical" which is MT mode 1, then the plugin also runs in MT mode 1.

Now that I'm testing with AviSynthShader, I'm also seeing something else weird. If I run even without MT mode, my class gets instantiated 6 times? Not sure who is responsible for this.

Better wait until you bring out your next version for testing.

That you get the calls from different threads in MT mode 3 is normal. 3 only guarantees that the calls are never made at the same time, but none of the MT modes limits the calls to the same thread.

The main MT issue that I'm talking about is exactly the problem you described with FlipVertical. Of course it does not only affect FlipVertical, but any filter whose constructor returns another filter than itself which is of lesser protection. This is the infamous issue #37 in the bugtracker. When this gets solved, it will also allow plugin developers to specify MT modes again without relying on the non-final IScriptEnv2. I am also trying to improve the efficiency of MT mode 3, planning improvements to the threadpool(s), and add automated diagnostics. More details when each of these gets done.

[colours]

think that should be 2^n-0.5 not +0.5 (255 = 2^8 - 1 not 2^8), who's bad at arithmetic now? ;)

You and me alike, I guess. (Fixed.)

I think that's just fairly wrong, midpoint goes (255-1)/2=127 by that definition and 32767 at uint16_t, and 127*257=32639 and that's pretty far from 32767..

The midpoint is still 128 for the AVS Convert* convention, and the scaling factor would be 32767/127 ≈ 258.01 if we were to assume a nominal chroma range of 1 to 65535 for 16-bpc YCbCr.

The nonlinear mapping you're suggesting is bad for the reason that it does not mesh with any of the full-range conventions in use, and, being non-linear, necessarily requires a bit more computation than a linear mapping. Changing bit depth should be an essentially free operation, not one that requires branching on every other pixel.

The mappings involved for the different chroma full-range conventions are thus:

# naive full-range ([0,255] to [0,65535])
x *= 257

# Dither_convert_* ([0.5,255.5] to [0.5⋅256,255.5⋅256])
x *= 256

# H.264-like ([0.5,255.5] to [0.5,65535.5])
# note: needs to be clamped to [0,65535]
x = 257 * x - 128

# AVS Convert*-like ([1,255] to [1,65535])
# note: needs to be clamped to [0,65535]
x = (32767 * x - 32640) / 127

[feisty2]

dammit, just got myself another reason to stick with floating point by.. yeah, the H264 method seems pretty cool to me tho..

[MysteryX]

The main MT issue that I'm talking about is exactly the problem you described with FlipVertical. Of course it does not only affect FlipVertical, but any filter whose constructor returns another filter than itself which is of lesser protection.
I've heard several people being very skeptical of MT and who are staying away from it. But really this issue is not that bad. For the most part, MT is working perfectly fine. As for this issue, it is not a context-dependent issue resulting in "undefined" behaviors. It will give a defined behavior for a plugin returning another plugin with a different MT mode.

One way to "patch" the issue is to return a dummy plugin at the end with the desired MT mode. It should work; however it only patches the issue without resolving it.

[shekh]

The mappings involved for the different chroma full-range conventions are thus:


...

# AVS Convert*-like ([1,255] to [1,65535])
# note: needs to be clamped to [0,65535]
x = (32767 * x - 32640) / 127

Looks like this is the same convention as used by graphics hardware to unpack signed normalized integers
Probably the right one? :)

[ajp_anton]

Unfortunately UtoY and VToY is reserved already, and works with 16/32 bit. They do not truncate to a Y8/Y16/Y32 clip.

So UtoY8 and VToY8 is silently working like UtoY16/32 and VtoY16/32. The result clip is greyscale one.
I did not like the names like UtoLumaOnly, etc... so it remained with the Y8 ending, until someone finds a proper name for it and everybody agrees with it :)

What about "ShowU" and "ShowV"? Similar to "ShowRed" etc for RGB. They could then all agree on what pixel_type to accept. Though IMO they should all just return a luma plane only.

[real.finder]

What about "ShowU" and "ShowV"? Similar to "ShowRed" etc for RGB. They could then all agree on what pixel_type to accept. Though IMO they should all just return a luma plane only.

I agree with you, but still see no problem with UtoYx and VToYx

If pinterf make UtoY8 and VToY8 silently working like UtoY16/32 and VtoY16/32 then he should make the same thing for ConvertToY8 so the old scripts work in 16/32 bit if the plugins support that

[pinterf]

He did :) ConvertToY8 works for 16/32. But this is illogical.

[ajp_anton]

What about...

Include only "sane" function names in Avisynth+, and include an .avsi file with all legacy aliases needed for compatibility. That way the actual function name should already explain what it does ("does converttoy8 support 16-bit, and will it silently convert to 8-bit?"), and the aliases can be examined manually to see what they do, and can be modified if the user likes.

[ultim]

EDIT: There is newer build available here (http://forum.doom9.org/showthread.php?p=1774770#post1774770).

In case you guys want to make sure pinterf has some work when he gets back, be sure to give a spin to the high bit-depth filters in r2043 (http://avs-plus.net/builds) and report any issues :)

Compared to the previous test build, we have:
- A lot (http://forum.doom9.org/showthread.php?p=1773294#post1773294) more internal filters now that support 16/32-bit processing.
- A correctness fix to the float resampler.
- ConvertTo/FromStacked() moved to their own DLL, and added the ConvertTo/FromDoubleWidth() functions to support some yet-another-hbd-format-that-shouldn't-exist-but-is-apparently-in-use-by-LSMASHWorks-or-avs2yuv. Please rely on this plugin only when and only as long as necessary because it is provided only to support the transition to the proper high bit-depth formats. They will be killed off in due time.
- Resamplers and some other filters should now properly throw an out-of-memory error instead of sometimes crashing when low on memory.
- 8->16bit scaling is in this build done as described by ITU standards and Microsoft. This is what you want most of the time, unless you are saving to some rare exotic codec or a series of RGB images. This is not to say Avs+ will not support other methods, but this is what is done atm.

[MysteryX]

Quick questions.
- How do I know a clip has UINT16 or FLOAT formats?
- What about Dithering?

[Chikuzen]

- How do I know a clip has UINT16 or FLOAT formats?
bool is_uint16 = (vi.pixel_type & VideoInfo::CS_Sample_Bits_16) != 0;
bool is_float = (vi.pixel_type & VideoInfo::CS_Sample_Bits_32) != 0;

- What about Dithering?
Currently, nothing.

[ultim]

bool is_uint16 = (vi.pixel_type & VideoInfo::CS_Sample_Bits_16) != 0;
bool is_float = (vi.pixel_type & VideoInfo::CS_Sample_Bits_32) != 0;


Or easier, but AvsPlus-specific:
bool is_uint16 = vi.ComponentSize() == 2;
bool is_float = vi.ComponentSize() == 4;

Btw, there is a another new function vi.NumComponents(), which is 1 for greyscale, 3 for yuv/rgb, 4 for rgba etc.

Unlike IScriptEnv2, these can be considered stable.

[Groucho2004]

@ultim, pinterf
Did you guys get a chance to look at this one (http://forum.doom9.org/showthread.php?p=1773061#post1773061)? Not high priority I guess but still...

[MysteryX]

Or easier, but AvsPlus-specific:
bool is_uint16 = vi.ComponentSize() == 2;
bool is_float = vi.ComponentSize() == 4;

Btw, there is a another new function vi.NumComponents(), which is 1 for greyscale, 3 for yuv/rgb, 4 for rgba etc.

Unlike IScriptEnv2, these can be considered stable.
Is there a way to define macros that allow using the simpler new syntax while remaining compatible with AviSynth 2.6?

[Chikuzen]

@ultim, pinterf
Did you guys get a chance to look at this one (http://forum.doom9.org/showthread.php?p=1773061#post1773061)? Not high priority I guess but still...

from avisynth.cpp line 1686

int size = pitchY * height + 2 * pitchUV * heightUV;
size = size + align -1;

VideoFrame *res = GetNewFrame(size);

1920*30*1080*30 + 2*960*30*540*30 = 2799360000
max of int32_t is 2^31 - 1= 2147483647
i don't know whether this is bug or spec.

[MysteryX]

1920*30*1080*30 + 2*960*30*540*30 = 2799360000
max of int32_t is 2^31 - 1= 2147483647
i don't know whether this is bug or spec.
Why the *30?

There was discussion recently regarding x64 and whether the frame size should be INT(32-bit) like Ultim implemented or 64-bit. Changing that would require recompiling every x64 plugin.

[Chikuzen]

Why the *30?
see groucho's post.

There was discussion recently regarding x64 and whether the frame size should be INT(32-bit) like Ultim implemented or 64-bit. Changing that would require recompiling every x64 plugin.

from avisynth.cpp line 1228

VideoFrame* ScriptEnvironment::AllocateFrame(size_t vfb_size)
{
if (vfb_size > (size_t)std::numeric_limits<int>::max())
{
throw AvisynthError(this->Sprintf("Requested buffer size of %zu is too large", vfb_size));
}


so, it's a bug.
vfb_size should be calculated on size_t.
error messages should be correct.

[jpsdr]

It would be nice if the avisynth header can be kept compatible with VS2010.

[ultim]

It would be nice if the avisynth header can be kept compatible with VS2010.

ok. it might happen that we accidentially break vs2010 because none of the active developers use it so we don't test it. but if you let us know of problems with vs2010 we'll correct it, as long as it is only the public headers.

[MysteryX]

ok. it might happen that we accidentially break vs2010 because none of the active developers use it so we don't test it. but if you let us know of problems with vs2010 we'll correct it, as long as it is only the public headers.
http://forum.doom9.org/showthread.php?p=1773786#post1773786

[jpsdr]

ok. it might happen that we accidentially break vs2010 because none of the active developers use it so we don't test it. but if you let us know of problems with vs2010 we'll correct it, as long as it is only the public headers.

Basicaly, functions of C++11 are not supported (only VS2015 begin to allmost fully support it from what i've understood), so delete is not supported.

[qyot27]

Lines 443 and 444 in turn.cpp (https://github.com/AviSynth/AviSynthPlus/blob/MT/avs_core/filters/turn.cpp#L443) cause compilation errors in VS2013. Is 'constexpr' an intended change, or was it a typo that slipped in there?

EDIT: Okay, apparently it is (http://en.cppreference.com/w/cpp/language/constexpr) (why didn't I try looking that up before?). But since it fails, I'm thinking either VS2013 is missing the header to support it, or turn.cpp needs the right header added to its includes.

[jpsdr]

VS2013 just begin to support a few features of C++11, and so it's probably VS2013 missing the header.

[ultim]

http://forum.doom9.org/showthread.php?p=1773786#post1773786

Ah, ok. I will get rid of "delete" there. Will be in the next push.

Lines 443 and 444 in turn.cpp (https://github.com/AviSynth/AviSynthPlus/blob/MT/avs_core/filters/turn.cpp#L443) cause compilation errors in VS2013. Is 'constexpr' an intended change, or was it a typo that slipped in there?

EDIT: Okay, apparently it is (http://en.cppreference.com/w/cpp/language/constexpr) (why didn't I try looking that up before?). But since it fails, I'm thinking either VS2013 is missing the header to support it, or turn.cpp needs the right header added to its includes.

constexpr is a core language feature and cannot be added via a header. As is currently, it will not compile on VC2013. Please ask chikuzen if he can do something about it, as he's the author of those lines, and I'm not really an intrinsics expert.

[TheFluff]

templated intrinsics is the new cool thing to do if you want to write optimized code that supports multiple bitdepths without copypasting shit all over the place, get with the times and upgrade yer compilers

[TurboPascal7]

Does it even have to do anything with the intrinsics there? Looks completely unnecessary (like most of the C++ duhuhu).

[Chikuzen]

Please ask chikuzen if he can do something about it.
hmm, ok.
I'll send a PR.

btw, when does AVS+ keep supporting VS2013? 22nd century?

[feisty2]

Guess it's probably not a good idea to stay vs2010 or 2013, the latest c++ standard is c++14 so..
And vs2015 community is free anyways, what's the point of getting stuck at square one

[MysteryX]

I have a question. Let's say I run a script at 8fps, then in the middle of it, I'm running something else. Obviously performance goes down to, say, 4fps. Once the other task is done and the script has all the resources again, however, it stays stuck at 4fps and doesn't go back to 8fps. Has anyone else noticed this? What's causing that?

[jackoneill]

Guess it's probably not a good idea to stay vs2010 or 2013, the latest c++ standard is c++14 so..
And vs2015 community is free anyways, what's the point of getting stuck at square one

You don't have to use all the cool new features just because you can.