Avisynth+

[Groucho2004]

any installer for dummies?
Here (https://www.dropbox.com/s/xrh84z02sm2hpg8/AviSynth%2B%20r2022.7z?dl=0). This installer does not include the VC runtimes. If you need them, use the ones from ultim's dl location. I highly recommend to use ricktendo's All In One runtime installer (http://repacks.net/forum/viewtopic.php?f=6&t=125), very compact and all versions you'll ever need included.

[sl1pkn07]

thanks for the installer, but don't work with XP. no need the runtimes, because i want to install throught wine (vc2015 is installed by winetricks)

the workground is set wine to windows7, install avs+ and back to winxp

greetings

[Groucho2004]

thanks for the installer, but don't work with XP.The installer doesn't work on XP?

[Reel.Deel]

Maybe this?

Sidenote: similar to what happened a couple years ago with VS 2013 builds, Wine 1.9.x (i.e. the current dev branch) cannot use binaries built with VS 2015 yet. Even if you do have all the correct redist dlls available.

[sl1pkn07]

what the hell. in the first time i run the installer don't work. spawn a installer error window about the version of the windows. then switch to win7, install it and back to windows xp

now with winxp again, the installer works ok :?


shi......


sorry for the noise

[pinterf]

I'm aware of how much memory these frame sizes need (more or less).
I'm not sure if you realize that the point of that script is simply to force Avisynth to run out of memory and see how it behaves.

So, the only question is why the new version behaves differently.

Meanwhile the resizer memory question solved (why it seemed to use so big intermediate frame)

And I have learned that these are not the same
setmemorymax(16000)
setmemorymax(16000)
n = 5
colorbars(width = 1920 * n, height = 1080 * n, pixel_type = "rgb32").killaudio().assumefps(25, 1)
turnleft().pointresize(width() - 1920, height() - 1080)

result is 7680x4320

Flow: orig 9600x5400
-> turnleft 5400x9600
-> resize to 7680x4320 =
resize_horiz 5400x9600->7680x9600 (huge!)
resize_vert 7680x9600->7680x4320

or


turnleft()
pointresize(width() - 1920, height() - 1080)

result is 3480x8520

[pinterf]

I'm aware of how much memory these frame sizes need (more or less).
I'm not sure if you realize that the point of that script is simply to force Avisynth to run out of memory and see how it behaves.

So, the only question is why the new version behaves differently.
Accidental.
Now (maybe the running programs changed the memory consumption a bit) my test even did not return from a simple malloc.
While there is intensive memory swapping in the background.

So frame reservation error is caught, C++ object reservations and internals can cause C0000005 in the VC runtime, or other buffer reservations (Avisynth BufferPool for temporary buffers) can result in silent death in malloc when it cannot reserve e.g. a 2G memory area.

[ultim]

I'm aware of how much memory these frame sizes need (more or less).
I'm not sure if you realize that the point of that script is simply to force Avisynth to run out of memory and see how it behaves.

So, the only question is why the new version behaves differently.Accidental.
Now (maybe the running programs changed the memory consumption a bit) my test even did not return from a simple malloc.
While there is intensive memory swapping in the background.

So frame reservation error is caught, C++ object reservations and internals can cause C0000005 in the VC runtime, or other buffer reservations (Avisynth BufferPool for temporary buffers) can result in silent death in malloc when it cannot reserve e.g. a 2G memory area.

Here is a quick guess, but I will only be able to check it later in the evening.

The new resizers in the MT-branch use the IScriptEnv2->Allocate() to request temporary storage instead of requesting frame buffers (this is both faster and more memory-efficient). But if I remember correctly, Allocate() returns a NULL pointer when it runs out of memory instead of throwing an exception. My bet is that the resizers don't inspect the return value for error and so you get an access violation due to NULL-pointer dereference. If this guess is correct, the fix is to check the return value of allocate inside the resizer for NULL, and if NULL, call env->Throw().

[MysteryX]

AviSynthShader released with updated headers (https://github.com/mysteryx93/AviSynthShader/releases/tag/v1.5.2) + cleaned up the files mess

[real.finder]

@real.finder

Can you please explain me the following changes?


add Prefilter auto 16 (lsb) support
add TV_range bool
less lsb if not use lsb things and get ready for yv16 and yv24

Thanks ;)

"add Prefilter auto 16 (lsb) support" mean you can use 16bit (stack) not just the 8 bit normal one in external Prefilter

"add TV_range bool" see this http://avisynth.nl/index.php/Limiter and this http://avisynth.nl/index.php/Luminance_levels#What_are_luminance_levels.3F

anyway, TV_range is true by default, that will use Dither_Luma_Rebuild(S0=1.0,c=0.0625) see here http://avisynth.nl/index.php/SMDegrain#Introduction

if set TV_range to false then Dither_Luma_Rebuild will not be used

"less lsb if not use lsb things and get ready for yv16 and yv24"

SMDegrain was using KNLmeans with lsb (16bit) even without using lsb in setting, and "get ready for yv16 and yv24" this is for the future ;)

[tormento]

anyway, TV_range is true by default, that will use Dither_Luma_Rebuild(S0=1.0,c=0.0625) see here http://avisynth.nl/index.php/SMDegrain#Introduction

if set TV_range to false then Dither_Luma_Rebuild will not be used

Let TV_range true is good or evil?

[real.finder]

Let TV_range true is good or evil?

good for DVD and BD and tv things

[tormento]

good for DVD and BD and tv things

And, I imagine, evil for computer generated things and photos, correct?

[real.finder]

And, I imagine, evil for computer generated things and photos, correct?

didn't try, but yes, it's wrong in these cases

[Groucho2004]

AviSynthShader released with updated headers (https://github.com/mysteryx93/AviSynthShader/releases/tag/v1.5.2) + cleaned up the files mess
Why do you post this here? Trying to get your post count up? You already announced it in your own thread.
Is this now becoming a permanent thing that you fill almost every thread on this forum with your random ramblings?

[pinterf]

Resizers do not check allocation result. But in my test, they even dont reach the checking point. Provided if the OS is in low memory situation too. In this case I do not care the meaningful error report when even task manager response time is some minutes because of swapping

[Groucho2004]

Here's a funny one:

Script:
setmemorymax(16000)
n = 30
colorbars(width = 1920 * n, height = 1080 * n, pixel_type = "yv12").killaudio().assumefps(25, 1)
temporalsoften(4,4,8,15,2)

Error:
AVSMeter 2.3.0 (x64) - Copyright (c) 2012-2016 Groucho2004
AviSynth+ 0.1 (r2022, MT, x86_64) (0.1.0.0)

Requested buffer size of 18446744072213944351 is too large
(F:\Test\test.avs, line 3)

Avisynth want's to allocate 18 exabytes :D

Looks like 2^64 - 18446744072213944351 would be the correct value.

[ultim]

Resizers do not check allocation result. But in my test, they even dont reach the checking point. Provided if the OS is in low memory situation too. In this case I do not care the meaningful error report when even task manager response time is some minutes because of swapping

That doesn't always happen. Groucho reported he got an access violation at least once, and those with fast swap (SSD) or no swap at all because they turned it off would also crash. Anyway, I'm calling dibs on this fix.

On a different topic: I've got a private branch with some stuff not in MT, because it changes ScriptEnv2, so I don't want to mix it in unless it's ready. This way others can still merge from me or builds can be issued without breaking stuff too early. I think I've got a way to go about the MT-related issues, but I need to try it out to see if the theory works. Other unrelated fixes I will try to put in MT directly.

[Wilbert]

feature requests:

1) ConvertToYUV400 (same naming as ConvertYUV444, instead of ConvertToY16/32),
2a) PRGB colorformats (for the new bit-depths)
2b) ConvertToPRGB (planar RGB: PRGB <-> YUV420/YUV422 via in between format YUV444),
3) script functions which give the bit-depth.

Question: what happens when doing for example ConvertToYV12(available options) on a 16/32 bit YUV source? Is that implemented already?

[ultim]

feature requests:

1) ConvertToYUV400 (same naming as ConvertYUV444, instead of ConvertToY16/32),
2a) PRGB colorformats (for the new bit-depths)
2b) ConvertToPRGB (planar RGB: PRGB <-> YUV420/YUV422 via in between format YUV444),
3) script functions which give the bit-depth.


1) There is already ConvertToY() (without bit depth specification), but ConvertToYUV400() can be added as an alias for consistency with the other functions.
2) There are multiple RGB and multiple YUV color spaces, so at least >1 need to be supported to give correct results in most cases, if one wants to convert RGB<->YUV. When and if at all this will be done is better asked to pinterf, unless someone else steps up to implement it.
3) Sure.

EDIT:

Question: what happens when doing for example ConvertToYV12(available options) on a 16/32 bit YUV source? Is that implemented already?
IMHO those functions with exact bit depth specification should stay true to their name. For me it would be weird and unexpected if ConvertToYV24() produces float pixels at one point, since that is not YV24. So my stand on this is that ConvertToYV24() should be a shortcut for ConvertToYUV444().ConvertTo8Bits() (and similarly for other old functions).

[pinterf]

Question: what happens when doing for example ConvertToYV12(available options) on a 16/32 bit YUV source? Is that implemented already?
ConvertToYV12/16/24 operates only on 8 bit.

But within bitdepth ConvertTo420 inherited the same functionality as ConvertToYV12. Of course, no 16/32 bit RGB input (yet)

[pinterf]

Basic bitdepth converters are ready and pull requested.
ConvertTo8bit, ConvertTo16bit, ConvertToFloat

No dithering or whatever, plain c, float conversions accept a scale parameter, which is defaulting to 1.0 (0..1.0)


SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("lsmashvideosource", 3)
lsmashvideosource("13HoursCUT.mp4", format="YUV420P8")
x=last # 8 bit source test cases
x = x.ConvertToFloat() # 8-32
x = x.ConvertTo16bit() # 32-16
x = x.ConvertToFloat() # 16-32
x = x.ConvertTo16bit() # 32-16
x = x.ConvertTo8bit() # 16-8
x = x.ConvertTo16bit() # 8-16

x = x.Crop(0, 140, 0, -140)
x = x.Spline64Resize(900,500)
c8_420 = x.ConvertToYUV420(chromaresample="spline64", chromaOutPlacement = "mpeg2") #chromaInPlacement = "mpeg2",
c8_422 = x.ConvertToYUV422(chromaresample="bilinear") # chromaInPlacement = "mpeg2"
c8_444 = x.ConvertToYUV444()
c8_420_b = c8_444.ConvertToYUV420(chromaresample="point", chromaOutPlacement = "dv")

c8_420 = c8_420.ConvertToYUV444(chromaInPlacement = "mpeg1")
c8_422 = c8_422.ConvertToYUV444()
c8_444 = c8_444.ConvertToYUV444()
c8_420_b = c8_420_b.ConvertToYUV444()
StackHorizontal(StackVertical(c8_420,c8_420_b),StackVertical(c8_422,c8_444))
ConvertTo8bit()
Prefetch(8)


btw, it turned out that Float resizers don't look healty :)

[jackoneill]

feature requests:

1) ConvertToYUV400 (same naming as ConvertYUV444, instead of ConvertToY16/32),

One would expect a format called "YUV4XX" to have three planes. Will this have three planes or will it surprise users by having just one plane?

[Wilbert]

@Ultim, Pinterf,

Sounds great. Once high bit-depth planar RGB is also supported, it's possible to load and save high bit-depth images using DevIL (sadly DevIL supports only interleaved and not planar RGB formats).
I implemented such a thing a long time ago: https://sourceforge.net/p/avisynth2/patches/6/ At least i got it working ;)

@jackoneill, i see what you mean. I thought it would be a good idea to have a consistent naming of those conversions. I guess better would be ConvertToY400.

[ultim]

Dah... my two cents: let's just stick to ConvertToY().

[Chikuzen]

https://github.com/AviSynth/AviSynthPlus/blob/MT/avs_core/convert/convert.cpp#L742

I wouldn't like these conversions

on 8bit to 16bit
dstp0[x] = srcp0[x] << 8;

on 16bit to 8bit
dstp[x] = min((srcp0[x] >> 8) + ((srcp0[x] & 0x00FF) >> 7), 255);

on float to integer
dstp0[x] = static_cast<pixel_t>(srcp0[x] * factor + 0.5f);

I think these are general way.
- on high precision to low precision, rounding is better than truncation because less error.
- bit shift and saturate is easier to optimize than ｍultiplication and division.

[MysteryX]

Why do you post this here? Trying to get your post count up? You already announced it in your own thread.
Is this now becoming a permanent thing that you fill almost every thread on this forum with your random ramblings?
I will try my best to not take these attacks personal and to reduce the opportunities for verbal violence

[ultim]

https://github.com/AviSynth/AviSynthPlus/blob/MT/avs_core/convert/convert.cpp#L742

I wouldn't like these conversions

on 8bit to 16bit
dstp0[x] = srcp0[x] << 8;

on 16bit to 8bit
dstp[x] = min((srcp0[x] >> 8) + ((srcp0[x] & 0x00FF) >> 7), 255);

on float to integer
dstp0[x] = static_cast<pixel_t>(srcp0[x] * factor + 0.5f);

I think these are general way.
- on high precision to low precision, rounding is better than truncation because less error.
- bit shift and saturate is easier to optimize than ｍultiplication and division.

Both of your 16bit <-> 8bit conversions are very wrong.

When going from 8 to 16, you need to map the whole range of 0..225 to 0..65535. In your suggestion, you are simply multiplying by 256. 255x256 is 65280 instead of 65535. You actually need to scale by 257 instead of 256 for correct results, and pinterf is doing it correctly (257=65535/255).

When going down from 16 to 8, you need the reverse: x*255/65535. Unlike when going up, here it is sufficient to just shift by 8 bits for exact reults, because if your input is not a power of 2, your result will be like an integer-truncated division by 256.

Both these conversions from pinterf are correct. There is however an optimization potential he did not make use of when converting up to 16bit. The same upscaling can be done using only simple bit-arithmetic which often takes less machine cycles. If x is an 8-bit number, you can do (x << 8) | x to arrive at the 16-bit range, and this will also give exact results.

You are right about the float->int conversion though, adding 0.5f before the cast would minimize truncation errors.

[vivan]

Both of your 16bit <-> 8bit conversions are very wrong.

When going from 8 to 16, you need to map the whole range of 0..255 to 0..65535.It's not the only correct conversion. Actually standarts (BT.709/BT.2020) define another conversion, which uses 2^(n-8) as scaling factor. And so does msdn (https://msdn.microsoft.com/ru-ru/library/windows/desktop/bb970578(v=vs.85).aspx#overview).

Data is interpreted as having integer (higher 8 bits) and fractional (lower 8 bits) components. And this makes 16.0 and 235.0 (240.0) black and peak values regardless of the bitdepth.

I rememeber when ffmpeg first implemented high bit depth support is also used x >> 8 || x conversion, but it was then corrected.

[Chikuzen]

Actually standarts (BT.709/BT.2020) define another conversion, which uses 2^(n-8) as scaling factor. And so does msdn (https://msdn.microsoft.com/ru-ru/library/windows/desktop/bb970578(v=vs.85).aspx#overview).


I remembered that msdn page, too.
pinterf is correct about down scale to 8bit.

[pinterf]

btw, it turned out that Float resizers don't look healty :)
They are healthy now.

[pinterf]

Data is interpreted as having integer (higher 8 bits) and fractional (lower 8 bits) components. And this makes 16.0 and 235.0 (240.0) black and peak values regardless of the bitdepth.

This is important.

[shekh]

When going down from 16 to 8, you need the reverse: x*255/65535. Unlike when going up, here it is sufficient to just shift by 8 bits for exact reults, because if your input is not a power of 2, your result will be like an integer-truncated division by 256.


This is not exact

65404*255/65535 = 254.49 -> rounds to 254

65404>>8 = 255

[ultim]

This is not exact

65404*255/65535 = 254.49 -> rounds to 254

65404>>8 = 255

"because if your input is not a power of 2, your result will be like an integer-truncated division by 256" ... and not by 257, which is why it is nonsense what I wrote here. You are right, sorry, I don't know what I was thinking.

[ultim]

It's not the only correct conversion. Actually standarts (BT.709/BT.2020) define another conversion, which uses 2^(n-8) as scaling factor. And so does msdn (https://msdn.microsoft.com/ru-ru/library/windows/desktop/bb970578(v=vs.85).aspx#overview).

Data is interpreted as having integer (higher 8 bits) and fractional (lower 8 bits) components. And this makes 16.0 and 235.0 (240.0) black and peak values regardless of the bitdepth.

I rememeber when ffmpeg first implemented high bit depth support is also used x >> 8 || x conversion, but it was then corrected.

Ok, I didn't know that the scaling factor here is defined explicitly as 2^n. The boundaries 16-235/240 just come from TV-levels though.

[Chikuzen]

btw, I modified RawSource26 to support HDB formats.

Binary (https://github.com/chikuzen/RawSource_2.6x/releases/download/Plus-20160707/RawSourcePlus-20160707.zip)

note that this plugin will not work on avs2.6.

[LigH]

Then maybe it should be called RawSourcePlus instead... ;)

[pinterf]

1.) TemporalSoften 16bit/float ready.
Parameter ranges for thresholds and scenechange are unchanged 0-255. They are scaled internally to have the same effect on all bitdepth.
2.) 8->16 bit conversion reverted to p << 8. Let's not reinvent the wheel.

[ultim]

Ok so I got home, and since I know that at least for RGB 16-bit images pixels are scaled to 65535, I wanted to make sure that this 256-factor for YUV is not just some shit from MS. I fired up the bt709 spec, and it's true. While I haven't found a direct mention of how to scale to larger bitdepths (it doesn't define 16bit at all, only 10), it still implies simple power-of-two factors simply from the allowed data ranges in 8- and 10-bits. So I guess we should switch to this scale too. EDIT: Oh, I see pinterf already changed it. Good work :thumbs up:

[Wilbert]

AviSynthShader released with updated headers (https://github.com/mysteryx93/AviSynthShader/releases/tag/v1.5.2) + cleaned up the files mess
Why do you post this here? Trying to get your post count up? You already announced it in your own thread.
Is this now becoming a permanent thing that you fill almost every thread on this forum with your random ramblings?
I will try my best to not take these attacks personal and to reduce the opportunities for verbal violence

Groucho2004 is right. #2018 has nothing to do with AviSynth+ development. See #1875 for another example of a useless post. I suggest you remove those posts and respect the forum rules a little bit.

[ultim]

forget it i found it (https://github.com/sekrit-twc/zimg/)
EDIT: ok, looks promising. might be interesting for us too to just use this.

[pinterf]

Ok so I got home, and since I know that at least for RGB 16-bit images pixels are scaled to 65535, I wanted to make sure that this 256-factor for YUV is not just some shit from MS. I fired up the bt709 spec, and it's true. While I haven't found a direct mention of how to scale to larger bitdepths (it doesn't define 16bit at all, only 10), it still implies simple power-of-two factors simply from the allowed data ranges in 8- and 10-bits. So I guess we should switch to this scale too. EDIT: Oh, I see pinterf already changed it. Good work :thumbs up:

Changed after reading this one, which mentiones 12 bit rec 2020 (https://en.wikipedia.org/wiki/Rec._2020) with the exact black and white levels

[pinterf]

Wilbert, it was then you, who put those planar RGB constants in avisynth.h? The current development unfortunately phase lacks the high bit depth RGB.

When I uncommented and renamed the YUV planar constants in the header three weeks ago, I was thinking what to do with the RGB 48 bit, but wasn't familiar at all with that planar RGB, so the option remained in silence.

[Wilbert]

Wilbert, it was then you, who put those planar RGB constants in avisynth.h? The current development unfortunately phase lacks the high bit depth RGB.

When I uncommented and renamed the YUV planar constants in the header three weeks ago, I was thinking what to do with the RGB 48 bit, but wasn't familiar at all with that planar RGB, so the option remained in silence.
Ianb added them in avisynth.h. I just uncommented them and added the necessary stuff in order to be able to open and write 16-bit images with DevIL. It was fun to do that, but lost interest and didn't bother to clean it up.

Btw, regarding the functions ConvertTo8Bits(), etc ...
What about replacing them with a single one:
ConvertToBitDepth(bit-depth=8/16/float, dither=none/random/ordered/...)
Then you can add several dither methods later. I only implemented random dithering at that time (because that was a fast method).

[ajp_anton]

What about dithering to 10 bits, but still using 16 bits to preserve those two extra bits beyond 8? Like when encoding 10 bits with x264. I think dithering should be a separate function where you can set the target bitdepth to dither to (which can then be any integer below the current bitdepth), and the "convert to some bitdepth" should just round/truncate.

[feisty2]

actually I think it's a bit more complicated than that..
so, uint8_t->uint16_t

tv range should be
y = x * 256

full range should be
x -> y
0 -> 0
128 -> 32768
255 -> 65535
and obviously not a linear conversion

[feisty2]

and "128 -> 32768" is a must in full range case cuz pure black is [0, 128, 128] at uint8_t and [0, 32768, 32768] at uint16_t, and simple * 257 makes [0, 128, 128] go [0, 32896, 32896] and that's not pure black no more so incorrect conversion

[asteri]

Here (https://www.dropbox.com/s/xrh84z02sm2hpg8/AviSynth%2B%20r2022.7z?dl=0). This installer does not include the VC runtimes. If you need them, use the ones from ultim's dl location. I highly recommend to use ricktendo's All In One runtime installer (http://repacks.net/forum/viewtopic.php?f=6&t=125), very compact and all versions you'll ever need included.

r2022? I thought latest version is r1858 MT-pfmod. I became lost in number of releases and their versions. Can you explain what your r2022 has against 1858 MT-pfmod ?

[colours]

full range should be
x -> y
0 -> 0
128 -> 32768
255 -> 65535
and obviously not a linear conversion

and "128 -> 32768" is a must in full range case cuz pure black is [0, 128, 128] at uint8_t and [0, 32768, 32768] at uint16_t, and simple * 257 makes [0, 128, 128] go [0, 32896, 32896] and that's not pure black no more so incorrect conversion

… No? Where the hell do you even get these funny ideas?

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.

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

Neither of these conventions is nonlinear, but what you're proposing is.

that's not pure black no more

Also, please type English.

[ryrynz]

r2022? I thought latest version is r1858 MT-pfmod. I became lost in number of releases and their versions. Can you explain what your r2022 has against 1858 MT-pfmod ?

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

[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.

[ultim]

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

Those shuffles around line 458 need a compile-time constant expression, which is why lines 443-444 were made a constexpr, I suppose. Removing the constexpr needs different templating, different intrinsics, or a condition added in the depths of those loops...

[TurboPascal7]

Those shuffles around line 458 need a compile-time constant expression, which is why lines 443-444 were made a constexpr, I suppose. Removing the constexpr needs different templating, different intrinsics, or a condition added in the depths of those loops...
Welp. Imo just copypaste the whole function into three different functions for different sizeof(T) and the problem goes away on its own. The code will be better too.

[ultim]

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

Hopefully not for long.

VS2010-support is only for the public headers, not for compiling Avs+ core itself, so that you have a larger choice of compilers when writing your plugins.

VC2013 is the oldest supported compiler for compiling the core, and is only because of Wine, as apparently it still has some problems with the VC2015 runtimes. As soon as Wine gets with the times, I have no problem in dropping VC2013 support.

[RazorBurn]

Does someone here have links to Avisynth+MT r2005?

[fAy01]

Does someone here have links to Avisynth+MT r2005?

http://avs-plus.net/builds

2043 is the latest.

[tormento]

http://avs-plus.net/builds

2043 is the latest.

OMG... did not noticed it.

Changelog?

[ryrynz]

Changelog?

https://github.com/AviSynth/AviSynthPlus/commits/MT

Will 1858 be the last unofficial build with legacy plugin compatibility?

[MysteryX]

https://github.com/AviSynth/AviSynthPlus/commits/MT

Will 1858 be the last unofficial build with legacy plugin compatibility?
Just to be clear, the only plugins that are incompatible are those that used "env2" while ignoring the warning not to use it. Mostly to register their MT mode. Only a few plugins are doing that.

[RazorBurn]

http://avs-plus.net/builds

2043 is the latest.

Huge Thanks.. Bookmarked..!!

[ryrynz]

http://avs-plus.net/builds


If I install DirectShowSource.dll from link above to the latest build in my plugins folder I get a C++ exception when using avisynth+ffdshow.
I don't believe I'll use it anyway and have deleted it, but can someone quickly detail what features it provides?

[Reel.Deel]

If I install DirectShowSource.dll from link above to the latest build in my plugins folder I get a C++ exception when using avisynth+ffdshow.
I don't believe I'll use it anyway and have deleted it, but can someone quickly detail what features it provides?

The latest AviSynth+ releases incorporate pinterf's changes, as well as some bugs fixes, and also introduced support for 16/32 bit YUV formats. High bit depth is still a work-in-progress but there's already a handful of internal filters that support the new formats. Ultim is working on a longstanding MT issue and also mentioned that some MT optimizations are coming.

Will 1858 be the last unofficial build with legacy plugin compatibility?

There's nothing to worry about here, AviSynth+ still supports all the plugins it always has. The issue that MysteryX mentioned has been taken care of, the few affected plugins have been fixed and are working correctly. The latest nnedi3 (v0.9.4.22) is the only plugin currently not working but a fix is coming soon. Use an older version for the mean time.

[qyot27]

DirectShowSource is a source filter of last resort, because DirectShow support of X or Y format is often unstable (and the filter isn't frame accurate in general). Pretty much every other source filter does a better job for whatever format(s) they're designed to open, leaving DSS for extreme edge cases.

It was the only general-purpose source filter prior to 2007, but ever since FFmpegSource (and especially since FFMS2 and LSMASHSource/LwLibavSource), its importance has shrunk to a minimum.

Because it was one of the few plugins that had used IScriptEnv2, newer versions can only be used by newer versions of the AviSynth+ core. Pairing DirectShowSource.dll from AviSynth+ r2022 or r2043 with the core AviSynth.dll from r1858 or prior will, of course, fail spectacularly.

[pinterf]

Good evening.
New functions ported to 16 bit/float.


Info
ShowFrameNumber / ShowSMPTE / ShowTime
Subtitle


Info() additions:

display the name of the high bit-depth color spaces instead of Unknown color space.
display AVX CPU flag if detected.

[LigH]

Indeed, a good evening! :)

:thanks:

[real.finder]

does avs+ has same avs limit of 50 active plugins at one time?

[Chikuzen]

does avs+ has same avs limit of 50 active plugins at one time?

IIRC, the limit was gone after 2.57.
Both avs2.6 and avs+ has no imit of number of loading plugins.

[real.finder]

IIRC, the limit was gone after 2.57.
Both avs2.6 and avs+ has no imit of number of loading plugins.

it still existing in 2.6, I see it in some of my tests in complex script

[Groucho2004]

it still existing in 2.6, I see it in some of my tests in complex script
Indeed. In plugin.cpp (2.6 and also 2.6.1):
enum { max_plugins=50 };

The plugin loading in AVS+ is quite different and from what I've seen, there's no plugin limit in the code (or maybe I didn't look thoroughly).

[Myrsloik]

I will just put this link here (http://stevedower.id.au/blog/building-for-python-3-5-part-two/). Dlls are fun.

[ultim]

Indeed. In plugin.cpp (2.6 and also 2.6.1):
enum { max_plugins=50 };

The plugin loading in AVS+ is quite different and from what I've seen, there's no plugin limit in the code (or maybe I didn't look thoroughly).

In Avs+ there's no limit.

[ultim]

r2069 (http://avs-plus.net/builds) is out, and this build should be fun :) I encourage you all to take a look at it, as it brings some serious enhancements to MT, and then some. Let's see...

- First and foremost, I sincerely hope I can put issue #37 behind me, and unless somebody proves otherwise, plugins should now be able to reliably specify their MT-mode using the SetCacheHints() mechanism (for an example, see the usage of CACHE_GET_MTMODE here (https://github.com/AviSynth/AviSynthPlus/blob/MT/avs_core/filters/field.cpp#L618)). This means, there is no need any more to use IScriptEnv2, which is still unstable. With this method there is also no need for plugins to differentiate between Avs 2.6 and Avs+, and it allows you to specify different MT modes for your filter depending on the construction parameters. With one word: use this, not IScriptEnv2.

- The calculation of the final MT mode got a lot smarter. For filter calls which create a hierarchy of nested filters, it is often incorrect or at least sub-optimal to use the MT-modes as specified directly. Avs+ will smartly make adjustments in such cases to ensure reliable results. Unless of course the filter or the user used the “force” option in SetFilterMtMode(), so don't force unless reeeeally necessary (e.g. because of a bug in a filter).

- The behavior of MT_SERIALIZED (mode 3) changed. While the earlier implementation caused all filters that are called from the serialized filter to be also serialized, now it only serializes the one and only filter that it is specified for. This has a couple of important consequences:
-- If you have a mode 3 filter towards the end of your script, the speed penalty is much-much less, since earlier basically your whole script went into mode 3, whereas now other filters can still execute in parallel. The placement of mode 3 filters in your script just got un-critical!
-- This also means it is now a really bad idea to have a big lock/mutex inside your GetFrame() instead of marking it as mode 3, because your plugin will exhibit the old behavior and you won't be able to benefit from the potential improvements at all.
-- There is also a downside: The new mode 3 theoretically does not provide the same amount of MT-protection as the old one. However, I'm not sure it matters to many plugins at all. If it does, the old mode will be re-introduced as mode 4. So keep me up-to-date!

- Avs+ will now automatically recognize source filters. If it sees a source filter which has no MT-mode specified at all, it will automatically use mode 3 instead of the default MT mode. This is great for source filters as in their case it rarely hurts performance and they often need mode 3 anyway, and it will help yet unclassified source filters perform correctly without any user action. One step closer to the "it just works" target.

- Avs+ received a logging facility. You can enable it using SetLogParams(target, level) at the beginning of your script. 'target' can be either "stderr", "stdout", or a path to a file. Level is LOG_ERROR/LOG_WARNING/LOG_INFO/LOG_DEBUG (not strings), with increasing verbosity. Log messages can be output by scripts using LogMsg(msg, level). I went for Log() initially but it was already taken by the math function.

- If logging is enabled, Avs+ will output log messages by itself too. It will automatically log errors, and will issue warnings and notes to the user to inform him about potential problems, buggy plugins, suboptimal settings etcetera. There are a couple of these log messages and they come in various colors. How many can you find? Gotta catch 'em all!


Edit: Despite my obvious enthusiasm, this build is still a test build. Please treat it as such.

[Sparktank]

r1069 (http://avs-plus.net/builds)

*r2069 :devil:

[ultim]

*r2069 :devil:

lol, thx

[Sparktank]

:thanks: This is definitely going to be fun to try out over the next while.

Really like where the future is headed. :)

Thanks to everyone for getting involved.

[Groucho2004]

Avs+ received a logging facility. You can enable it using SetLogParams(target, level) at the beginning of your script. 'target' can be either "stderr", "stdout", or a path to a file. Level is LOGLEVEL_ERROR/WARNING/INFO/DEBUG (not strings), with increasing verbosity. Log messages can be output by scripts using LogMsg(msg, level). I went for Log() initially but it was already taken by the math function.
Just tried the SetLogParams(target, level) function, very cool:
https://s31.postimg.org/mibto65ff/Image1.png

However, I had to use "SetLogParams("stdout", 4), "LOGLEVEL_DEBUG" was not recognised.

[ultim]

Just tried the SetLogParams(target, level) function, very cool:
https://s31.postimg.org/mibto65ff/Image1.png

However, I had to use "SetLogParams("stdout", 4), "LOGLEVEL_DEBUG" was not recognised.

Ah, my bad. It is actually LOG_ERROR/WARNING..., not LOGLEVEL_... I corrected the post above. I mixed it up with the naming used by the C++ code. Thx!

[Groucho2004]

Ah, my bad. It is actually LOG_ERROR/WARNING..., not LOGLEVEL_... I corrected the post above.
That works, thanks.

[LigH]

You provided r2069 as a whole subdirectory (r2069-MT-test) in your "builds" base directory; its download returned a 51.3 MB ZIP, due to including both MSVC Redist installers. I guess you might add a 7zip archive of this directory, excluding both runtimes, in the "builds" base directory, so that people who already installed the runtimes may download a smaller archive instead.

[jpsdr]

and unless somebody proves otherwise, plugins should now be able to reliably specify their MT-mode using the SetCacheHints() mechanism (for an example, see the usage of CACHE_GET_MTMODE here (https://github.com/AviSynth/AviSynthPlus/blob/MT/avs_core/filters/field.cpp#L618))

If i understand properly, i just have to re-define the SetCacheHints function of my filter class, is it ?
This SetCacheHints function will be afterward use by avisynth core, i don't have to use it myself in my filter ?

[jpsdr]

I've done it for nnedi3, but i can't do this for nnedi3_rpow2 because this last one is not a class filter, only the function create exist. We'll have to wait a stable IScriptEnvironment2 to set its MT mode for this last one. It is disable for now, waiting, but shouldn't prevent it to work, because there's still the mutex for safety.

[ultim]

If i understand properly, i just have to re-define the SetCacheHints function of my filter class, is it ?
This SetCacheHints function will be afterward use by avisynth core, i don't have to use it myself in my filter ?

Correct. Just override the function, and return your MT mode when called with CACHE_GET_MTMODE.

[ultim]

I've done it for nnedi3, but i can't do this for nnedi3_rpow2 because this last one is not a class filter, only the function create exist. We'll have to wait a stable IScriptEnvironment2 to set its MT mode for this last one. It is disable for now, waiting, but shouldn't prevent it to work, because there's still the mutex for safety.

Then there is no need to specify an MT mode for nnedi3_rpow2. Its MT-mode will be determined dynamically based on the other filters it creates. With different words, don't use IScriptEnvironment2 for nnedi3_rpow2 even when it becomes stable, because you only need to set the MT mode for class filters. No need to wait for anything.

[pinterf]

ultim, thanks for the new mt stuff, does it have any measurable overhead (speedwise) for the already "well-behaving" scripts?

[tormento]

Just tried the SetLogParams(target, level) function, very cool:
https://s31.postimg.org/mibto65ff/Image1.png

However, I had to use "SetLogParams("stdout", 4), "LOGLEVEL_DEBUG" was not recognised.

Ehm... where is 2.3.1? :cool:

[yup]

Hi all!
Please advice how install test version?
yup.

[Groucho2004]

Ehm... where is 2.3.1? :cool:
On my hard drive. ;)

[Groucho2004]

Hi all!
Please advice how install test version?
yup.
Install this (https://www.dropbox.com/s/xrh84z02sm2hpg8/AviSynth%2B%20r2022.7z?dl=0) and overwrite the files with the ones from r2069.

[yup]

Groucho2004!
After install, I am get error during check with avsmeter -avsinfo
AVSMeter 2.3.0 (x86) - Copyright (c) 2012-2016 Groucho2004

Exception 0xC0000005 [STATUS_ACCESS_VIOLATION]
Module: Cannot determine module
Address: 0x00000001
All Microsoft dll installed.
At wsndows\system32 I am see Avisynth.dll dated 6 July.
yup.

[ultim]

ultim, thanks for the new mt stuff, does it have any measurable overhead (speedwise) for the already "well-behaving" scripts?

Not in general.

The "already well-behaving" part is tricky though, as it might be that, depending on implementation details in a specific filter, it might behave correctly, while a different one might not under the exact same conditions (same MT mode, same nesting etc.). The new MT "stuff" favors correctness in this sense, not speed. I'd be interested if anybody can show numbers as I don't yet have many, but I think performance degradations, if any at all, should be negligible and rare.

[Groucho2004]

After install, I am get error during check with avsmeter -avsinfo
AVSMeter 2.3.0 (x86) - Copyright (c) 2012-2016 Groucho2004

Exception 0xC0000005 [STATUS_ACCESS_VIOLATION]
Module: Cannot determine module
Address: 0x00000001
All Microsoft dll installed.
At wsndows\system32 I am see Avisynth.dll dated 6 July.
yup.
Define "after install". After installing r2022 or after copying over the r2069 files? Which version(s) do you want to install? What OS?

[yup]

Define "after install". After installing r2022 or after copying over the r2069 files? Which version(s) do you want to install? What OS?
After install Your package r2022, Windows 10 64.

[Groucho2004]

After install Your package r2022, Windows 10 64.
Did you install the latest runtimes (14.0.23506)?

[yup]

Did you install the latest runtimes (14.0.23506)?
No!
I can find only 14.0.23206.
Please give me link.
On my PC installed 14.0.24210
yup.

[Groucho2004]

No!
I can find only 14.0.23206.
Please give me link.
On my PC installed 14.0.24210
yup.
"14.0.24210" is indeed the latest, my mistake. As for your problem, I have no idea, try cleaning up the auto-load directory so you have only the DLLs installed with AVS+.

[ultim]

I fixed a false positive in the diagnostic messages and pulled pinterf's latest high bit-depth work in r2076.

[burfadel]

14.0.24210 is known to be buggy though in some scenarios.

[ultim]

No!
I can find only 14.0.23206.
Please give me link.
On my PC installed 14.0.24210
yup.

just did a clean install of avs+ using official installer from website, then replaced it with newest build from avs-plus.net/builds. works as expected.

i doubt it is the runtimes, probably some plugin. if you have a plugin from jpsdr, mysteryx or chikuzen, you will need a recent build of them to not crash. also make sure when you copy a new build of avs+, you also copy the plugin dlls that come with it into the correct folders.

[pinterf]

Today's Avisynth Plus news:

Blur and Sharpen ported to 16 bit/float.


P.S. is there anybody who runs avisynth plus on a non SSE2 capable processor?

For me the 32 bit version with compile option SSE2 instead of SSE yielded almost 10% gain. Maybe because this script uses high bitdepth routines that are mostly in C?

lsmashvideosource("13HoursCUT.mp4", format="YUV420P8")
Crop(0, 140, 0, -140)
Spline64Resize(400,340)
orig = last
x8=orig.Blur(1.0,1.5).Info()
x8d=orig.Sharpen(1.0, 1.0).Info()
x16=orig.ConvertTo16bit().Blur(1.0, 1.0).Info()
x16d=orig.ConvertTo16bit().Sharpen(1.0, 1.0).Info()
x32=orig.ConvertToFloat().Blur(1.0, 1.0).Info()
x32d=orig.ConvertToFloat().Sharpen(1.0, 1.0).Info()
StackHorizontal(\
StackVertical(x8.ConvertTo8bit(),x16.ConvertTo8bit(),x32.ConvertTo8bit()),\
StackVertical(x8d.ConvertTo8bit(),x16d.ConvertTo8bit(),x32d.ConvertTo8bit())\
)
ConvertTo8bit()

[TheFluff]

P.S. is there anybody who runs avisynth plus on a non SSE2 capable processor?
I dunno about avs+ specifically but if there's anywhere you can find people who actually own functioning non-SSE2 CPU's in 2016, it's doom9. This guy (http://forum.doom9.org/showthread.php?p=1764874#post1764874) turned up in the FFMS2 thread a few months ago, for example.

Still, SSE2 was introduced fifteen years ago so I think it's pretty reasonable to expect people who do CPU-intensive tasks like video encoding to have it. The only CPU that was even remotely popular that didn't have SSE2 after 2001 was the Athlon XP, and those things really aren't too common anymore.

[tedkunich]

snip...The only CPU that was even remotely popular that didn't have SSE2 after 2001 was the Athlon XP, and those things really aren't too common anymore.

I retired mine about 5 years ago.... :D

[ryrynz]

Hopefuly I will also find why Prefetch(1) is the same as Prefetch(0) and fix it.


Was this ever resolved?

[MysteryX]

Is there some documentation about the new 16-bit functions? What functions are supported, how to convert between formats, etc.

For example, how can I convert to 16-bit and then convert from Rec601 to Rec709, if that's supported?

Also several of the existing plugins will have to support 16-bit input and output in addition to lsb_in_out; shouldn't be hard to do when they already handle 16-bit but it just needs to be done.

[pinterf]

At the present state only YUV color spaces have high bit-depth support: 16 bit and float (32 bit).

In the last five weeks from the project start, we had no time for RGB48/64 and 10-12-14 bit support, but they will be done of course soon. At least defining the constants, names, and the basic conversions to and from. In order to let the filter authors play with them also.

Color space naming conventions:
8 bit:

Y8, YV12, YV16, YV24

16 bit:

Y16, YUV420P16, YUV422P16, YUV444P16

float:

Y32, YUV420PS, YUV422PS, YUV444PS


Bit-depth conversions (no dithering, no range conversion, etc...)

ConvertTo8bit()
ConvertTo16bit()
ConvertToFloat()

Color-space conversions within same bit-depths (also works for 8 bit)

ConvertToY()
ConvertToYUV420()
ConvertToYUV422()
ConvertToYUV444()

Their parameters are the same as at their 8 bit counterparts:

ConvertToY8(), ConvertToYV12(), ConvertToYV16(), ConvertToYV24()

Compatibility conversions for existing 16 bit hacked formats:

ConvertFromStacked()
ConvertToStacked()
ConvertFromDoubleWidth()
ConvertToDoubleWidth()

Plane swap

UToY(), VToY()
UToY8(), VToY8()
YToUV()

The UToY8 and VToY8 naming is still illogical at the moment, because it makes Y8 Y16 or Y32 clip depending on the source.
But with removing the '8' specifier from the name, it would collide with UToY and VToY

Internal filters.
I made a list from here (http://avisynth.nl/index.php/Internal_filters) where I saw Y8 or YUV support.

See the functions below that have NO 16bit/float port yet.

Color conversion and adjustment filters

ColorYUV
Invert
Levels
Limiter
MergeARGB / MergeRGB

Overlay and Mask filters

MaskHS
Overlay
Subtract

Geometric deformation filters

SkewRows (do we need it? affects only Y8?)

Debug filters

ColorBars / ColorBarsHD
Compare
Histogram


Output
See Chikuzen's avs2pipe mod (http://forum.doom9.org/showthread.php?p=1774532#post1774532)

I hope I have not missed important points, so please test, comment, (ask for features), and as ultim had said, treat it as a beta.

And remember that introducing high bit-depth into Avisynth+ was a must have but is not enough. Writing supporting filters and porting the old ones is very important. If you are not a programmer you can still force the otherwise boring authors :)

[vcmohan]

In this newer version of AVS+ how can a plugin know the bits per channel (apart from the unweildy names)? can any of the following calls
int (VideoInfo::*BitsPerPixel)() const;
int (VideoInfo::*BytesPerChannelSample)() const;
used to get info? Can one ask if it is planar and then bits pr channel? Presume that like vapoursynth 10,12,14 bit depth channels will be expanded to 16 bit and presented to the plugin to process.

[pinterf]

In this newer version of AVS+ how can a plugin know the bits per channel (apart from the unweildy names)? can any of the following calls
int (VideoInfo::*BitsPerPixel)() const;
int (VideoInfo::*BytesPerChannelSample)() const;
used to get info? Can one ask if it is planar and then bits pr channel? Presume that like vapoursynth 10,12,14 bit depth channels will be expanded to 16 bit and presented to the plugin to process.
VideoInfo has a new function: ComponentSize() which tells you how many bytes needed for a pixel sample.
1, 2 and 4 means: byte, uint16_t, and float pixel type, respectively.

The 10-12-14 bit versions are not implemented yet, but the ComponentSize() function for such colorspaces will return 2 bytes in the future.
Avisynth internal filters also use this function for deciding whether 8 bit / 16 bit / float processing should be done.
Alternatively (for YUV only) BytesFromPixels(1) will tell you the same.

Warning: using these functions of course will fail on classic avisynth or earlier avs+ builds.

So there will be a yet-to-be-named function for requesting the internal bit depth format of the specific color space.

What you wrote:
BitsPerPixel has other purposes, and cannot be used in a globally logical way, e.g. it returns 32 for RGB32, 24 for RGB24, etc.
BytesPerChannelSample is for audio.

One can of course make magic directly from the bitmap of pixel_type property, currently its the layout is under revision (but will remain compatible with the old things)

[ultim]

VideoInfo has a new function: ComponentSize() which tells you how many bytes needed for a pixel sample.
1, 2 and 4 means: byte, uint16_t, and float pixel type, respectively.

The 10-12-14 bit versions are not implemented yet, but the ComponentSize() function for such colorspaces will return 2 bytes in the future.
Avisynth internal filters also use this function for deciding whether 8 bit / 16 bit / float processing should be done.
Alternatively (for YUV only) BytesFromPixels(1) will tell you the same.

Warning: using these functions of course will fail on classic avisynth or earlier avs+ builds.

So there will be a yet-to-be-named function for requesting the internal bit depth format of the specific color space.

What you wrote:
BitsPerPixel has other purposes, and cannot be used in a globally logical way, e.g. it returns 32 for RGB32, 24 for RGB24, etc.
BytesPerChannelSample is for audio.

One can of course make magic directly from the bitmap of pixel_type property, currently its the layout is under revision (but will remain compatible with the old things)

When 10/12/14 get added, will BitsPerPixel() return the number of useful bits, or the number of bits used for storage? So for example, for 10bit video, should BitsPerPixel() return 10*NumComponents(), or 8*ComponentSize()*NumComponents() ?

Also, IMHO 10/12/14 should only be added to a few selected conversion filters so that it can be received and output, but not to other processing filters. For for most videos out in the wild, 10/12/14 can be processed as 16bit without any conversion at all, only at the output you need to mark the stream as the correct bit-depth so that other apps know what they are getting.

[ultim]

Was this ever resolved?

Not yet. I'm planning to have a sweep at the thread pools and it might turn something up, but the issue you mentioned was never important enough or had any direct consequences for the user for me to have look at.

[Chikuzen]

Also, IMHO 10/12/14 should only be added to a few selected conversion filters so that it can be received and output, but not to other processing filters. For for most videos out in the wild, 10/12/14 can be processed as 16bit without any conversion at all, only at the output you need to mark the stream as the correct bit-depth so that other apps know what they are getting.

10bit and 14bit will have the great difference for many filters which using SIMD.

[pinterf]

When 10/12/14 get added, will BitsPerPixel() return the number of useful bits, or the number of bits used for storage? So for example, for 10bit video, should BitsPerPixel() return 10*NumComponents(), or 8*ComponentSize()*NumComponents() ?

Also, IMHO 10/12/14 should only be added to a few selected conversion filters so that it can be received and output, but not to other processing filters. For for most videos out in the wild, 10/12/14 can be processed as 16bit without any conversion at all, only at the output you need to mark the stream as the correct bit-depth so that other apps know what they are getting.
In the core BitsPerPixel is used mostly in the RGB part, for calculating the byte size of a whole interleaved pixel (24>>8 = 3 bytes, 32>>8 = 4 bytes). I don't know how external plugins use it.
The 10-12-14 bit is mostly important for export/import. Although many basic external filters still do not support even the basic 8 bit color spaces, have issues at 64 bit environment, making them work at 16 bits is a dream. But let's don't cut the possibility if a filter is modern and can distinguish between 10-12-14 bits. Before we met, I had just looked at KNLMeansCL, and it used this bit count properly at its VapourSynth part.

Chikuzen, can you tell examples?
What I guess, smaller bit size can really have advantages, for 10 bits xy luts can work. At 14 bits we can use signed 16 bits in SIMD, unsigned 16 bit data sometimes requires SSE 4.2 or workarounds at SSE2. These are not frequent cases though, but when someone explicitely prepares his plugin for these bitdepth, he may really need them.

[tormento]

I fixed a false positive in the diagnostic messages and pulled pinterf's latest high bit-depth work in r2076.

mmm... video decoder errors with DGNV.

Can somebody please upload the previous version?

EDIT: confirmed... with r2043 (the only other in mirror) it works. Please upload r2069 back ;)

[pinterf]

mmm... video decoder errors with DGNV.

Can somebody please upload the previous version?

EDIT: confirmed... with r2043 (the only other in mirror) it works. Please upload r2069 back ;)
Refine that error report, please. Missing ConvertToPokemon() or what?

[tormento]

Refine that error report, please. Missing ConvertToPokemon() or what?

CUDA Error!

And then Unable to create Video Decoder.

P.S: As an Ingress agent, that is a bad word to me ;)

[Groucho2004]

CUDA Error!

And then Unable to create Video Decoder.

P.S: As an Ingress agent, that is a bad word to me ;)
How about posting the script? You should know the drill.

[tormento]

How about posting the script? You should know the drill.

Nothing changed, only AviSynth+ from r2069 to latest.

Anyhow:

SetMemoryMax(8000)
SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("ChangeFPS", 3)

SetFilterMTMode("DGSource", 3)
LoadPlugin("D:\eseguibili\media\DGDecNV\x64\DGDecodeNV.dll")
DGSource("E:\in\1_52 quinta onda, La\quinta.dgi")

ChangeFPS(last,last,true)

SMDegrain (tr=4,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,plane=4,chroma=true,lsb=true,mode=6,TV_range=true)

Prefetch(8)

Please, anybody, upload r2069 somewhere so I can test it back.

[Groucho2004]

SMDegrain (tr=4,PreFilter=4,thSAD=400,contrasharp=false,refinemotion=false,plane=4,chroma=true,lsb=true,mode=6,TV_range=true)
"SMDegrain does not have a named argument "TV_range""
So, which of the 357 versions of SMDegrain are you using?

Took out the "tv_range" parameter. With "Prefetch(2)" I'm already at 750 MB graphics memory. However, it runs.

[tormento]

"SMDegrain does not have a named argument "TV_range""
So, which of the 357 versions of SMDegrain are you using?

Remove that parameter. Anyhow I am using this (http://forum.doom9.org/showthread.php?p=1771735#post1771735)

Nobody has a r2069 copy on HD?

[Groucho2004]

Remove that parameter.
I edited my post. Your script works fine for me (XP64) but I have to lower the number of threads because of memory limits.

[ultim]

Remove that parameter. Anyhow I am using this (http://forum.doom9.org/showthread.php?p=1771735#post1771735)

Nobody has a r2069 copy on HD?

Please wait a few hours, will be fixed today. Pinky promise. (I'd rather give you a fixed build instead of having you test an older older version with other known flaws.)

[tormento]

Please wait a few hours, will be fixed today. Pinky promise. (I'd rather give you a fixed build instead of having you test an older older version with other known flaws.)

Have to encode a movie for tonight. :) r2069 is more than enough for me now

[ultim]

mmm... video decoder errors with DGNV.

Can somebody please upload the previous version?

EDIT: confirmed... with r2043 (the only other in mirror) it works. Please upload r2069 back ;)

remove SetFilterMTMode("DGSource", 3) until fix.

[tormento]

remove SetFilterMTMode("DGSource", 3) until fix.

Wow. That was fast and easy :)

[MysteryX]

I did some benchmark tests of various MT implementations here. (http://forum.doom9.org/showthread.php?p=1773672#post1773672)

Let's try again with r2076

Plain script

ColorBarsHD(width=800, height=600, pixel_type="YV24").killaudio().assumefps(25, 1)
SuperResXBR(Engines=1)
Prefetch(8)

MT_SERIALIZED
FPS (min | max | average): 2.450 | 1000000 | 26.85
Memory usage (phys | virt): 356 | 382 MiB
Thread count: 68
CPU usage (average): 4%
**it is instead using MT_MULTI_INSTANCE. If I set Force=true, it freezes on init.

MT_NICE_FILTER
FPS (min | max | average): 2.522 | 1000000 | 23.71
Memory usage (phys | virt): 245 | 264 MiB
Thread count: 28
CPU usage (average): 4%
**Was 23.51, it is slightly faster

2 Engines
FPS (min | max | average): 2.926 | 1000000 | 26.90
Memory usage (phys | virt): 289 | 309 MiB
Thread count: 33
CPU usage (average): 4%
**Same, but higher memory usage (309MB vs 279MB)


Let's try on my full script to upscale 288p to 768p. Script includes KNLMeans, 2x SuperResXbr, InterFrame and various 16-bit tools.

MT_SERIALIZED
Again, freezes if I force MT_SERIALIZED and it used MT_MULTI_INSTANCE instead.

MT_NICE_FILTER
FPS (min | max | average): 1.414 | 1000000 | 12.88
Memory usage (phys | virt): 966 | 1058 MiB
Thread count: 125
CPU usage (average): 29%
**Lower performance and higher memory usage. Before:
FPS (min | max | average): 3.436 | 1000000 | 13.27
Memory usage (phys | virt): 680 | 736 MiB
Thread count: 52
CPU usage (average): 27%

No point in setting 2 engines because there are already 2 shader functions


or let's try heavier GPU processing with complex CPU work

ColorBarsHD(width=1940, height=1080).killaudio().assumefps(25, 1).ConvertToYV12()
SMDegrain(thsad=200, prefilter=2, lsb=true)
SuperResXBR(5, 1, .15, fWidth=2600, fHeight=1500, fKernel="SSim", Engines=1)
Prefetch(8)

MT_SERIALIZED
** Cannot yet test

MT_NICE_FILTER
FPS (min | max | average): 0.347 | 1000000 | 3.176
Memory usage (phys | virt): 1125 | 1162 MiB
Thread count: 34
CPU usage (average): 29%
**Slightly higher performance with lower CPU usage

2 Engines
FPS (min | max | average): 0.233 | 1000000 | 2.715
Memory usage (phys | virt): 1197 | 1236 MiB
Thread count: 39
CPU usage (average): 31%
**Still the same lower performance anomaly


I want to test MT_SERIALIZED but it's not yet working for me.

The higher memory usage might be due to some filters running in MT_MULTI_INSTANCE instead of MT_SERIALIZED.

[ultim]

I did some benchmark tests of various MT implementations here. (http://forum.doom9.org/showthread.php?p=1773672#post1773672)
...

I'm home now finally, and am looking at the issue tormento reported in greater detail. I'll have a fix soon as it is not hard but the consequences of the problem were pretty severe. Please redo your tests with the build I'll publish soon.

[ultim]

Okay, r2082 (http://avs-plus.net/builds) has an important fix for a bug that made some filters use the default MT mode instead of the specified one under certain conditions. It was the cause for tormento's problem. Additionally another case of false positives was cured for the generated diagnostic logs, and pinterf's latest work is integrated adding support for high bit-depth blur and sharpen.

[tormento]

Okay, r2082 (http://avs-plus.net/builds) has an important fix for a bug that made some filters use the default MT mode instead of the specified one under certain conditions. It was the cause for tormento's problem. Additionally another case of false positives was cured for the generated diagnostic logs, and pinterf's latest work is integrated adding support for high bit-depth blur and sharpen.

Problem solved :thanks:

[ultim]

MysteryX, I took a quick look at your source of AviSynthShader to verify something. Whenever you call GetFrame() (https://github.com/mysteryx93/AviSynthShader/blob/master/Src/ExecuteShader.cpp#L115) to get your input frames, pull those calls out of your mutex lock! The way your filter operates right now is forcing the other filters it calls into mode 3! Not nice.

The occurance I linked to might not be the only one, it was just the first I've found.

[MysteryX]

MysteryX, I took a quick look at your source of AviSynthShader to verify something. Whenever you call GetFrame() (https://github.com/mysteryx93/AviSynthShader/blob/master/Src/ExecuteShader.cpp#L115) to get your input frames, pull those calls out of your mutex lock! The way your filter operates right now is forcing the other filters it calls into mode 3! Not nice.

The occurance I linked to might not be the only one, it was just the first I've found.
Oh! That is one is very easy to fix: move the unique_lock down a few lines.

Good catch, I never thought about that.

By the way, does the new 16-bit code have ASM optimization or is only C++ code?

[MysteryX]

Let's try the benchmarks again with r2082

Original results here (http://forum.doom9.org/showthread.php?p=1773672#post1773672)

First, this line doesn't work. SetLogParams("stderr", INFO). INFO or DEBUG is not recognized.

MT_SERIALIZED still freezes with the way I have GetFrame inside the lock. If I fix that in my code, then it works.

Plain script

ColorBarsHD(width=800, height=600, pixel_type="YV24").killaudio().assumefps(25, 1)
SuperResXBR(Engines=1)
Prefetch(8)

MT_SERIALIZED
FPS (min | max | average): 1.561 | 1000000 | 23.02 (was 22.75)
Memory usage (phys | virt): 257 | 277 MiB (was 215MB)
Thread count: 28
CPU usage (average): 2%

MT_NICE_FILTER
FPS (min | max | average): 2.510 | 1000000 | 23.70 (was 23.51)
Memory usage (phys | virt): 250 | 269 MiB (was 238mb)
Thread count: 28
CPU usage (average): 4%

2 Engines
FPS (min | max | average): 2.169 | 1000000 | 26.80
Memory usage (phys | virt): 281 | 300 MiB
Thread count: 33
CPU usage (average): 4%

Let's try on my full script to upscale 288p to 768p. Script includes KNLMeans, 2x SuperResXbr, InterFrame and various 16-bit tools.

MT_SERIALIZED
FPS (min | max | average): 1.778 | 1000000 | 13.03 (was 7.930)
Memory usage (phys | virt): 644 | 698 MiB (same as before)
Thread count: 52
CPU usage (average): 27%

MT_NICE_FILTER
FPS (min | max | average): 2.977 | 1000000 | 13.25
Memory usage (phys | virt): 679 | 734 MiB
Thread count: 53
CPU usage (average): 27%

No point in setting 2 engines because there are already 2 shader functions


or let's try heavier GPU processing with complex CPU work

ColorBarsHD(width=1940, height=1080).killaudio().assumefps(25, 1).ConvertToYV12()
SMDegrain(thsad=200, prefilter=2, lsb=true)
SuperResXBR(5, 1, .15, fWidth=2600, fHeight=1500, fKernel="SSim", Engines=1)
Prefetch(8)

I keep getting this warning
WARNING: Caches have been shrunk due to low memory limit. This will probably degrade performance. You can try increasing the limit using SetMemoryMax().

MT_SERIALIZED
FPS (min | max | average): 0.247 | 1000000 | 3.002 (was 1.729)
Memory usage (phys | virt): 1091 | 1121 MiB (was 1044mb)
Thread count: 34
CPU usage (average): 27%

MT_NICE_FILTER
FPS (cur | min | max | avg): 3.368 | 0.349 | 1000000 | 3.108
Memory usage (phys | virt): 1084 | 1117 MiB
Thread count: 34
CPU usage (current | average): 27% | 28%

2 Engines
FPS (min | max | average): 0.149 | 1000000 | 2.536 (was 2.713)
Memory usage (phys | virt): 1224 | 1261 MiB
Thread count: 39
CPU usage (average): 31%
** this last one has gone worse than before, I'm wondering what's going on here


MT_SERIALIZED is now working much better than before, and MT_NICE_FILTER with a lock still works better.

The under-utilization of the GPU when running a single engine has been improved, somehow.

[pinterf]

Could you benchmark the last one with
a.) higher SetMemoryMax(), e.g. 2500? In such low memory situation the continuous cache shrink can really degrade performance
b.) Prefetch sequence (4-5-6-7), maybe the sweet spot is not at 8, even if you feed the script into avsmeter instead of running an encoder after it.

New high bit-depth filter routines are mostly in c. The main goal now is to have a working version of them, later they can get simd optimalization.

[ultim]

Thanks for the tests. Nice to see the improvements to MT_SERIALIZED are really paying off, in your case they practically doubled the performance.

First, this line doesn't work. SetLogParams("stderr", INFO). INFO or DEBUG is not recognized.

Yep it doesn't, because you're using it wrong. As documented in the announcement post, the constants are called LOG_INFO, LOG_DEBUG etc.

I keep getting this warning
WARNING: Caches have been shrunk due to low memory limit. This will probably degrade performance. You can try increasing the limit using SetMemoryMax().

This is one of the many new warnings introduced in r2069, helping you diagnose performance and other problems. Having to call SetMemoryMax() in AviSynth to increase the available memory is nothing new and goes way back to before Avs+ even existed. What is new now is that now you get notified if using it would be beneficial.

[Groucho2004]

First, this line doesn't work. SetLogParams("stderr", INFO). INFO or DEBUG is not recognized.

I admit that there's a hint of ambiguity in ultim's description of the function but even a miniscule amount of common sense would compensate for it:
Avs+ received a logging facility. You can enable it using SetLogParams(target, level) at the beginning of your script. 'target' can be either "stderr", "stdout", or a path to a file. Level is LOG_ERROR/WARNING/INFO/DEBUG (not strings), with increasing verbosity.

How anyone would think that "ERROR" has a "LOG_" prefix but all the other levels don't is peculiar at best, particularly for someone who considers himself to be a developer.

[ultim]

I admit that there's a hint of ambiguity in ultim's description of the function but even a miniscule amount of common sense would compensate for it:


How anyone would think that "ERROR" has a "LOG_" prefix but all the other levels don't is peculiar at best, particularly for someone who considers himself to be a developer.

Ah, OK, I see where the confusion comes from. I'll go back and edit the post for more clarity.

[MysteryX]

I admit that there's a hint of ambiguity in ultim's description of the function but even a miniscule amount of common sense would compensate for it:


How anyone would think that "ERROR" has a "LOG_" prefix but all the other levels don't is peculiar at best, particularly for someone who considers himself to be a developer.
Good feedback for Ultim, but you never miss a chance to insult :)

Taking a puff will help relieve the stress.

[thescrapyard]

I use AVStoDVD that won't run correctly unless it detects AviSynth 2.6.x.x

If I install AviSynth, then install the latest release of AviSynth+ it fails complaining that AviSynth 2.6.x.x is not installed BUT if I install the first release of AviSynth+ its fine

If I install the latest release of AviSynth+ (r2076) by copying over the binaries overwriting the original avisynth.dll it once again refuses to run due to incorrect versions


The version is being report as avisynth.dll 0.1.0, so I'm assuming its now to match the new releases of avisynth+ but anything that specifically looks for the avisynth.dll 2.6.x.x. is going to fail

[MysteryX]

The version is being report as avisynth.dll 0.1.0, so I'm assuming its now to match the new releases of avisynth+ but anything that specifically looks for the avisynth.dll 2.6.x.x. is going to fail
You can try this
https://social.msdn.microsoft.com/Forums/vstudio/en-US/8392458e-c5dc-4fa4-a960-5b383b9aff2b/change-file-version-to-a-dll-without-recompile-it?forum=csharpgeneral

[Groucho2004]

You can try this
https://social.msdn.microsoft.com/Forums/vstudio/en-US/8392458e-c5dc-4fa4-a960-5b383b9aff2b/change-file-version-to-a-dll-without-recompile-it?forum=csharpgeneral
And you're complaining about insults? You're asking for them.

[real.finder]

I use AVStoDVD that won't run correctly unless it detects AviSynth 2.6.x.x

If I install AviSynth, then install the latest release of AviSynth+ it fails complaining that AviSynth 2.6.x.x is not installed BUT if I install the first release of AviSynth+ its fine

If I install the latest release of AviSynth+ (r2076) by copying over the binaries overwriting the original avisynth.dll it once again refuses to run due to incorrect versions


The version is being report as avisynth.dll 0.1.0, so I'm assuming its now to match the new releases of avisynth+ but anything that specifically looks for the avisynth.dll 2.6.x.x. is going to fail

you can install avs 2.6 and use mp_pipeline with ### dll: path with new avs+

I think avs+ should use another function to report version

something like PlusVersionNumber()

so the normal VersionNumber() will report the normal avs version that avs+ base on

[Groucho2004]

I use AVStoDVD that won't run correctly unless it detects AviSynth 2.6.x.x

If I install AviSynth, then install the latest release of AviSynth+ it fails complaining that AviSynth 2.6.x.x is not installed BUT if I install the first release of AviSynth+ its fine

If I install the latest release of AviSynth+ (r2076) by copying over the binaries overwriting the original avisynth.dll it once again refuses to run due to incorrect versions


The version is being report as avisynth.dll 0.1.0, so I'm assuming its now to match the new releases of avisynth+ but anything that specifically looks for the avisynth.dll 2.6.x.x. is going to fail
The Avisynth detection routine in AVS2DVD is flawed (as is the case with some other programs that attempt to detect Avisynth).

Most of these programs try something like this:
- Check if the registry pointer for the plug directory exists
- Check if the registry pointer for the install directory exists
- Check if "%ProgramFiles%"\Avisynth 2.5" exists
- Or - the worst I've seen - Check if "C:\Program Files\Avisynth 2.5" exists

All of the above methods are useless and don't even tell you if there's a working avisynth.dll and devil.dll in one of the directories to which the "%PATH%" environment variable points (i.e. system32/syswow64) which is all that's needed to have a working Avisynth environment.

Some, like AVS2DVD, do seem retrieve the file version of avisynth.dll but the detection fails elsewhere.

One can't properly detect Avisynth without some digging into the Win32 API and using IScriptEnvironment to get the file version, Avisynth interface version, etc.

[thescrapyard]

The Avisynth detection routine in AVS2DVD is flawed (and many other programs that attempt to detect Avisynth).

Most of these programs try something like this:
- Check if the registry pointer for the plug directory exists
- Check if the registry pointer for the install directory exists
- Check if "%ProgramFiles%"\Avisynth 2.5" exists
- Or - the worst I've seen - Check if "C:\Program Files\Avisynth 2.5" exists

All of the above methods are useless and don't even tell you if there's a working avisynth.dll and devil.dll in one of the directories to which the "%PATH%" environment variable points (i.e. system32/syswow64) which is all that's needed to have a working Avisynth environment.

Some, like AVS2DVD, do seem retrieve the file version of avisynth.dll but the detection fails elsewhere.

One can't properly detect Avisynth without some digging into the Win32 API and instantiating IScriptEnvironment to get the file version, Avisynth interface version, etc.



I've posted on the AVStoDVD forum, they are usually pretty quick with a response and fix if needed, suggesting to only check for the avisynth.dll and remove the version checks which would then allow me to use any release of avisynth+

[Groucho2004]

I've posted on the AVStoDVD forum, they are usually pretty quick with a response and fix if needed, suggesting to only check for the avisynth.dll and remove the version checks which would then allow me to use any release of avisynth+
MrC is already using AVSMeter to retrieve the clip properties, it should be simple to use it to get the Avisynth version details with the "-avsinfo" switch.

[ryrynz]

Not setting a default MT mode is giving me lower CPU time with one of my scripts than specifying mode 2 (mode 1 causes visual glitches and instability not surprisingly)
Another line removed from the script! That along with no longer needing to specify ffdshowsource's MT mode either is quite nice.

Just loving the stability & performance, so glad MT is in such great shape now. SEt's builds I think can now be laid to rest.
Could be about time for a release.

[MysteryX]

Not setting a default MT mode is giving me lower CPU time with one of my scripts than specifying mode 2 (mode 1 causes visual glitches and instability not surprisingly)
If it is neither 1 or 2, then what is the "default default"?

[ultim]

Not setting a default MT mode is giving me lower CPU time with one of my scripts than specifying mode 2

Is the difference really significant? I mean, are you sure it's not within the tolerance of measurement errors?

[Reel.Deel]

Ultim, there's a small problem with the latest release. If FFMS2 (v2.22) is in my autoload folder I get "Parse: Unrecognized exception!" with any script I to load. Even just a simple script with just ColorBars(). By removing FFMS2 it works as usual. I have not has this problem with prior Avs+ releases.

[Groucho2004]

Ultim, there's a small problem with the latest release. If FFMS2 (v2.22) is in my autoload folder I get "Parse: Unrecognized exception!" with any script I to load. Even just a simple script with just ColorBars(). By removing FFMS2 it works as usual. I have not has this problem with prior Avs+ releases.
Works fine for me (32 and 64 bit, XP64). Does AVSMeter -avsinfo reveal anything?

[Reel.Deel]

Works fine for me (32 and 64 bit, XP64). Does AVSMeter -avsinfo reveal anything?

No, I get the same "Parse: Unrecognized exception!" error.

[ultim]

No, I get the same "Parse: Unrecognized exception!" error.

Works for me too, both x86 and x64. For a more detailed inspection, I'm afraid I'm going to need to ask for your plugin directories. And make sure you're using r2082.

[Reel.Deel]

Ok, figured out the problem, I had FFMS2.avsi file in there as well from an earlier FFMS2 version. The odd thing is that is has always been there and have not had a problem until now.

Edit: The ffms2.avsi was from v2.21. updating to the latest script fixed it.

[Sparktank]

I've been getting "Parse: Unrecognized exception!", too.

Using Groucho's "Avisynth Version Switcher", but replacing with latest 2082 before running batch to 'install' AVSPLUS_x86.

Running just Avsmeter with no commands will crash and give the parse error.
Running AvisynthInfo will crash, too.

But, I notice, if I move all .avsi from the plugin folder to somewhere else not in the path, everything works.
I have to Import() manually for any of the .avsi (Dither_tools, v1.27.2), but everything still functions after that.

On a successful run of Avsmeter -info -log
Log created with: AVSMeter 2.3.1 (x86)
OS version: Windows 10 (x64) (Build 10586)

Avisynth version string: AviSynth+ 0.1 (r2082, MT, i386)
File version: 0.1.0.0
Avisynth Interface Version: 6
Muli-threading support: Yes
Linker/compiler version: 14.0
Avisynth DLL location: C:\Windows\SysWOW64\AviSynth.dll
Avisynth DLL time stamp: 2016-07-22, 20:10:12
PluginDir2_5 (HKCU, x86): D:\AVS_Ver\\AVSPLUS_x86\plugins
PluginDir2_5 (HKLM, x86): D:\AVS_Ver\\AVSPLUS_x86\plugins

EDIT: Also latest MSVC redist installed.
Trying to run the redist with 2082, it asks if I want to repair.

[Reel.Deel]

Another problem, eedi3 v0.9.2.1 (https://github.com/Elegant996/EEDI3/releases) crashes AVSMeter with the following script (only tried with 32-bit so far):

SetFilterMTMode("eedi3_rpow2", 2) # don't matter which one I set, both crash
#SetFilterMTMode("eedi3", 2)

ColorBars(pixel_type="YV12")

eedi3_rpow2(2)

Prefetch(4)

There's no other plugins in the autoload directory other than eedi3 in the "plugins" folder and the core plugins in the "plugins+" folder.

Edit: replacing eedi3_rpow2 with eedi3() in the script above also crashes. BUT if you add threads=1 to both of them it works. Again, this use to work with earlier Avs+ versions.

Edit: also does not work with earlier Avs+ version. So it's not something that just happened recently.

[ultim]

Ok, figured out the problem, I had FFMS2.avsi file in there as well from an earlier FFMS2 version. The odd thing is that is has always been there and have not had a problem until now.

Edit: The ffms2.avsi was from v2.21. updating to the latest script fixed it.

Ok, that helps. Fix in next build.

[Groucho2004]

Muli-threading support: Yes
Damn, I only now noticed that typo. Must have been there for quite a while.

[ryrynz]

Is the difference really significant? I mean, are you sure it's not within the tolerance of measurement errors?

I'm sure, I did multiple runs and each time the CPU usage was a few percent lower, significant.. not really but then this script is only using ~25% CPU so this equates to 10% less CPU.
I'll upload the pics from Task manager later and also perform it again with some settings that push the CPU harder.

The differences are significant when I increase the load by substituting spline36 with nnedi3, here's the script.

ffdshow_source()
input4x = last.nnedi3_rpow2(rfactor=2, nsize=4, nns=1).nnedi3_rpow2(rfactor=2, nsize=4, nns=1,cshift="Spline36Resize")
edgemask = last.aSobel.aBlur
aWarp4(input4x,edgemask,depth=2)
Prefetch(4)

With SetFilterMTMode("DEFAULT_MT_MODE", 2) at top of script
http://i.imgur.com/RmP5a7Xl.png

Without
http://i.imgur.com/9yPiuEcl.png

What's going on? Am using latest build 2082 with nnedi3 0.9.4.24 and pinterf's Awarpsharp.

[ultim]

I'm sure, I did multiple runs and each time the CPU usage was a few percent lower, significant.. not really but then this script is only using ~25% CPU so this equates to 10% less CPU.
I'll upload the pics from Task manager later and also perform it again with some settings that push the CPU harder.

The differences are significant when I increase the load by substituting spline36 with nnedi3, here's the script.

ffdshow_source()
input4x = last.nnedi3_rpow2(rfactor=2, nsize=4, nns=1).nnedi3_rpow2(rfactor=2, nsize=4, nns=1,cshift="Spline36Resize")
edgemask = last.aSobel.aBlur
aWarp4(input4x,edgemask,depth=2)
Prefetch(4)

...



Tried to reproduce it but cannot, with or without ffdshow_source.

https://cloud.pados.hu/index.php/apps/files_sharing/ajax/publicpreview.php?x=1920&y=779&a=true&file=ryrynz_sfmm.jpg&t=eYWUU07xwdC1sTe&scalingup=0

I also do not yet see how this could be possible. Anyone else seeing this on their computer?

[ryrynz]

I also do not yet see how this could be possible. Anyone else seeing this on their computer?

I am using ffdshow raw with 16 read ahead buffers and MPC-BE if it makes any difference.

[ultim]

r2085 (http://avs-plus.net/builds) solves "Parse: Unrecognized exception!", and the problem with eedi3 (actually any plugin that uses OpenMP).

[Wilbert]

Bit-depth conversions (no dithering, no range conversion, etc...)
[LIST]
ConvertTo8bit()
ConvertTo16bit()
ConvertToFloat()
[/L IST]


Btw, regarding the functions ConvertTo8Bits(), etc ...
What about replacing them with a single one:
ConvertToBitDepth(bit-depth=8/16/float, dither=none/random/ordered/...)
http://forum.doom9.org/showthread.php?p=1773217#post1773217

[pinterf]

http://forum.doom9.org/showthread.php?p=1773217#post1773217
Didn't forget. And since there seem to be more new functions, once hight bit-depth rgb, planar rgb and the 10-14 bit things get added, somehow we'll have to keep order.

[Sparktank]

r2085 (http://avs-plus.net/builds) solves "Parse: Unrecognized exception!", and the problem with eedi3 (actually any plugin that uses OpenMP).

:thanks: No more crashes with .avsi in plugin_dir.

[yup]

Hi all!
Please advice way overwrite existing Avisynth.dll under Windows 10.
I am try using Freecommander run like admin, I do not see Avisynth.dll Windows/system32, but windows search show me at Windows/system32.
On my PC also run Avira antivirus.
yup.

[LigH]

If you use a 32 bit application as file manager, you have only access to the 32 bit system directory which is camouflaged as "Windows\system32" to a 32 bit application, but instead is "Windows\SysWOW64" in the file system under a 64 bit Windows OS. You need to use a 64 bit application as file manager to have access to both locations if you have a 64 bit Windows OS.

Being old enough to have used the Norton Commander during the DOS era, I still enjoy the Far manager (http://www.farmanager.com). It is abailable as both 32 bit and 64 bit application.

Once again for a clarification:

a) You have a 32-bit version of Windows (usual up to Windows 7, later deprecated):

Windows\system32 is your system directory for 32 bit DLLs and tools.


b) You have a 64-bit version of Windows (most probable from Windows 8 on, although already available earlier):

Windows\system32 is your system directory for 64 bit DLLs and tools. Only 64 bit applications will see this directory at all. It is hidden from 32 bit applications.
Windows\SysWOW64 is your system directory for 32 bit DLLs and tools. Only 64 bit applications will see this directory with this name. 32 bit applications will see this with the fake name Windows\system32.

This technique will ensure that each kind of application (32 or 64 bit) will look for their matching system DLLs always in a directory named "Windows\system32", and only the matching one is visible to them under this name.

[yup]

LigH!

Thanks for clarification.
I am install Multi Commander 64 bit and lucky.

yup.

[yup]

"14.0.24210" is indeed the latest, my mistake. As for your problem, I have no idea, try cleaning up the auto-load directory so you have only the DLLs installed with AVS+.
Thanks for advice!
Problem was related with jpsdr build nnedi3, after update all O'k.
yup.

[burfadel]

"14.0.24210" is indeed the latest, my mistake. As for your problem, I have no idea, try cleaning up the auto-load directory so you have only the DLLs installed with AVS+.

14.0.24210 is buggy. Microsoft released an update for it, but have seemed to have stuffed up the distribution of it! The updated version is 14.0.24212.

You can use my Redist installer, it has all the last runtimes for 2005 through to 2015, x86 and x64 versions (including the new 24212):

Visual C++ Redist Installer V44 - https://1drv.ms/u/s!AmGuHbW3zvrBmJFCnPBSK-pMSdxshA

[jpsdr]

14.0.24210 is buggy. Microsoft released an update for it, but have seemed to have stuffed up the distribution of it! The updated version is 14.0.24212.


And so, how did you get it ?

[yup]

After update to last version avs+ i am changed my script from
SetMemoryMax(1536)
SetFilterMTMode("DEFAULT_MT_MODE",3)
Edibob=AVISource("pre14last.avi")## source YUY2 50 fps bobbed
SetFilterMTMode("DEFAULT_MT_MODE",2)
Edibob=Edibob.AssumeTFF()
Edibob.SeparateFields().SelectEvery(4,0,3).Weave().AssumeTFF()
QTGMC(Tuning= "DV-SD",preset="Slow", Ediext=Edibob, Edithreads=1, EZDenoise=6, Denoiser="dfttest", ChromaNoise=true, DenoiseMC=true, NoiseTR=2,dct=5, search=5)
nnedi3_rpow2(rfactor=2,nns=2, qual=1, fwidth=1004, fheight=752,cshift="Spline36Resize").Crop(22,16,-22,-16)
unsharp(varY=465,varC=232,strength=0.3,U=3,V=3)
ConvertToYV12(interlaced=false)
ColorMatrix(mode="Rec.601->Rec.709")
PreFetch(8)
to
Edibob=AVISource("pre14last.avi")## source YUY2 50 fps bobbed
Edibob=Edibob.AssumeTFF()
Edibob.SeparateFields().SelectEvery(4,0,3).Weave().AssumeTFF()
QTGMC(Tuning= "DV-SD",preset="Slow", Ediext=Edibob, Edithreads=1, EZDenoise=6, Denoiser="dfttest", ChromaNoise=true, DenoiseMC=true, NoiseTR=2,dct=5, search=5)
nnedi3_rpow2(rfactor=2,nns=2, qual=1, fwidth=1004, fheight=752,cshift="Spline36Resize").Crop(22,16,-22,-16)
unsharp(varY=465,varC=232,strength=0.3,U=3,V=3)
ConvertToYV12(interlaced=false)
ColorMatrix(mode="Rec.601->Rec.709")
PreFetch(8)
All work stable, speed little lower if comparing to Set Mt version, but stability more important.
I am using 32 bit version because not all plugin available for 64.
yup.

[burfadel]

And so, how did you get it ?

The 24212 runtime packages are available to download from Microsoft if you know where to look. It appears they haven't updated the articles properly, but there are Microsoft download links that direct to the new version.

[real.finder]

And so, how did you get it ?

14.0.24212-x86
http://download.microsoft.com/download/9/a/2/9a2a7e36-a8af-46c0-8a78-a5eb111eefe2/vc_redist.x86.exe
14.0.24212-x64
http://download.microsoft.com/download/2/a/2/2a2ef9ab-1b4b-49f0-9131-d33f79544e70/vc_redist.x64.exe

[Groucho2004]

I made a new installer (https://www.dropbox.com/s/t6yg2cc900tkcgz/AviSynth%2B%20r2085.7z?dl=0) with the latest r2085 binaries.
Also, ricktendo updated his AIO runtime installer (http://repacks.net/forum/viewtopic.php?f=6&t=125) to include the 14.0.24212 runtimes.

With ricktendo's installer you can also selectively install runtimes. I made a batch file for that:
@echo off
:VS2005
start/wait VBCRedist_AIO_x86_x64 /ai5
:VS2008
start/wait VBCRedist_AIO_x86_x64 /ai8
:VS2010
start/wait VBCRedist_AIO_x86_x64 /aiX
:VS2012
start/wait VBCRedist_AIO_x86_x64 /ai2
:VS2013
start/wait VBCRedist_AIO_x86_x64 /ai3
:VS2015
start/wait VBCRedist_AIO_x86_x64 /aiV
There are a few more options, use "VBCRedist_AIO_x86_x64 /?".

[tormento]

I made a new installer

:thanks:

[thescrapyard]

I use AVStoDVD that won't run correctly unless it detects AviSynth 2.6.x.x

If I install AviSynth, then install the latest release of AviSynth+ it fails complaining that AviSynth 2.6.x.x is not installed BUT if I install the first release of AviSynth+ its fine

If I install the latest release of AviSynth+ (r2076) by copying over the binaries overwriting the original avisynth.dll it once again refuses to run due to incorrect versions


The version is being report as avisynth.dll 0.1.0, so I'm assuming its now to match the new releases of avisynth+ but anything that specifically looks for the avisynth.dll 2.6.x.x. is going to fail


Installed avisynth+ again, using the latest package installer for r2085, AVStoDVD still insists its version 0.1.0 and won't run the avisynth code as its looking for version 2.6.0 and above

I've directly edited the fileversion using FVIE I found trying to find a way to change just the version numbers

http://www.carifred.com/fvie/

All I changed was the version numbers in the avisynth.dll to show 2.6.0.0 and saved the modified .dll and this works, not ideal but now AVStoDVD is accepting the avisynth.dll as a legitimate version

[LigH]

The "DLL version" is an attribute in the "manifest" addendum (IIRC), read by the operating system.

But the "AviSynth version" will probably rather be the return value of an API function; this you can't patch with a PE patcher. I wonder if AviSynth+ would need an override feature to camouflage its own version and pretend a compatible one.

[MysteryX]

All I changed was the version numbers in the avisynth.dll to show 2.6.0.0 and saved the modified .dll and this works, not ideal but now AVStoDVD is accepting the avisynth.dll as a legitimate version
Again, I was right :)

[LigH]

Oh, then I misread this post, sorry. :o

[Groucho2004]

The "DLL version" is an attribute in the "manifest" addendum (IIRC), read by the operating system.

But the "AviSynth version" will probably rather be the return value of an API function; this you can't patch with a PE patcher. I wonder if AviSynth+ would need an override feature to camouflage its own version and pretend a compatible one.
In case of AVS+, the FILEVERSION/PRODUCTVERSION (which are read by AVS2DVD) come from "version.h.in" (-> avisynth.rc -> avisynth.res -> link with avisynth.dll).

The Avisynth version string is indeed exported by IScriptEnvironment() ("VersionString").

[Groucho2004]

All I changed was the version numbers in the avisynth.dll to show 2.6.0.0 and saved the modified .dll and this works, not ideal but now AVStoDVD is accepting the avisynth.dll as a legitimate version
I'm glad it worked for you. Still, hacking the version info this way is generally a bad idea. There may be some scenarios where it will crash since the 2.6 and AVS+ APIs are not the same.
So, do it at your own risk and don't blame the developers if something goes wrong.

[Groucho2004]

Again, I was right :)
Yes, you were right. Giving terrible hacking advice is a great idea.

[ryrynz]

Oi.. ಠ_ಠ

[MysteryX]

I'm glad it worked for you. Still, hacking the version info this way is generally a bad idea. There may be some scenarios where it will crash since the 2.6 and AVS+ APIs are not the same.
So, do it at your own risk and don't blame the developers if something goes wrong.
AviSynth+ is designed to be compatible with AviSynth 2.6, that's its principal selling point.

Yes, you were right. Giving terrible hacking advice is a great idea.
A better idea is for the software developer to update its software, and until that's done, some temporary "hack" has to be applied. Not ideal, but it's just temporary. The idea is to get it working for now. It needs to be hacked some way or the other anyway.

Do you realize that for almost everything you insulted me on, it turns out that what you said was false and I was right?

You did give me great answers and feedback to various questions too, so I thank you for that. You make great contributions. Just a little bit of respect would be appreciated.

[qyot27]

Except that AVStoDVD has no problems using AviSynth+. thescrapyard isn't complaining about a fatal error, it's just a warning. MrC told them the exact same thing (http://forum.doom9.org/showpost.php?p=1775066&postcount=2968):
@thescrapyard

wait, if the AviSynth release check routine reports "0.1.0", then A2D will give you just a warning. Just ignore the warning and go ahead. Instead there is a show stop when AviSynth.dll is not found from the path taken from "HKEY_LOCAL_MACHINE\SOFTWARE\AviSynth" registy key.

Which is your case?
If it's a fatal error, then it's not the version check doing it. There's something else wrong.


And I also just independently verified this with AVStoDVD 2.8.4. It has no problem:
<7/30/2016 11:41:20 AM>
START PROCESS
<>

<7/30/2016 11:41:20 AM>
PROJECT SETTINGS

DVD Video Standard: NTSC
DVD Titles number: 1
DVD Size: 159/4450 MB (4%)
DVD Output Setup: DVD Folder
DVD Label: DVD
DVD Menu: No Menu
Output Folder: C:\Users\Stephen\Documents
Delete Temp Assets Files: Yes
Delete Temp Working Files: Yes
Edit Command Parameters: No
Post Process Task: Show Progress Status window

PREFERENCES

MultiThread: 1
AVS Video Source Filter: A2DSource
AVS Audio Source Filter: A2DSource
AVS UpSize/DownSize Filter: Lanczos4Resize/Spline16Resize
Frame Adjust Strategy: 0
FPS Hard Conversion: 0
PAL SpeedUp: 0
NTSC SlowDown: 0
Video Resolution: 0
Video Encoder: 0
Video BitRate Min: 2500
Video BitRate Max: 8500
Keep DVD Compliant Video: 1
AC3 Audio Encoder: 0
Force FFmpeg for Long Audio: 1
DVD Audio Format: 0
DVD Audio BitRate: 192
Keep DVD Compliant Audio: 1
Normalize Audio: 0
Auto Delay Audio: 1
DVD Audio Language (Primary): EN - English
DVD Audio Language (Secondary): EN - English
DVD Subs Language (Primary): EN - English
DVD Subs Language (Secondary): EN - English
DVD Subs Font: Tahoma 16pt (255,255,255)
Chapters Interval: 5
Use Source Chapters: 1
DVD Burning Drive:
DVD Burning Speed: 4x
Auto Erase DVD RW: 1
Execute with Elevated Privileges: 0
Unload ActiveMovie Library: 1
Adjust DirectShow Filters at runtime: 1
Save General Settings: 0

SYSTEM INFO

Processor Name: Intel(R) Atom(TM) CPU Z3735F @ 1.33GHz
Operating System: Windows 10 (10.0.10586) 32 bit
User has Admin Rights: YES
Running with Elevated Privileges: NO (3)
Available Output Disc Space: 4 GB
AviSynth is installed: YES (release 0.1.0)
LAV Filters is installed: YES (release 0.68.1)
ffdshow is installed: YES (release 1.3.4515)

CODECS REPORT

H.264/AVC: Enhanced Video Renderer {FA10746C-9B63-4B6C-BC49-FC300EA5F256}
Xvid: Enhanced Video Renderer {FA10746C-9B63-4B6C-BC49-FC300EA5F256}
DivX 4/5/6: Enhanced Video Renderer {FA10746C-9B63-4B6C-BC49-FC300EA5F256}
Other MPG4: Enhanced Video Renderer {FA10746C-9B63-4B6C-BC49-FC300EA5F256}
DV: Enhanced Video Renderer {FA10746C-9B63-4B6C-BC49-FC300EA5F256}
MPEG1: Enhanced Video Renderer {FA10746C-9B63-4B6C-BC49-FC300EA5F256}
MPEG2: Enhanced Video Renderer {FA10746C-9B63-4B6C-BC49-FC300EA5F256}
MP2: Microsoft DTV-DVD Audio Decoder {E1F1A0B8-BEEE-490D-BA7C-066C40B5E2B9}
MP3: MP3 Decoder DMO {BBEEA841-0A63-4F52-A7AB-A9B3A84ED38A}
AAC: Microsoft DTV-DVD Audio Decoder {E1F1A0B8-BEEE-490D-BA7C-066C40B5E2B9}
AC3: No Preferred Filter set

<>

<7/30/2016 11:41:20 AM>
TITLE 1 SOURCE FILES
Video: D:\test.avs
Info: AviSynth - 0 kbps - 1920x816 - DAR 2.353 - 23.976 fps (CFR) - 2:31 minutes - 3630 frames
Audio 1: D:\test.avs
Info: AviSynth - 0 kbps - CBR - 2 ch - 44100 Hz - 16 bit - 2:31 minutes (0 ms delay)
[AVSMeter.exe]
<>

<7/30/2016 11:41:20 AM>
AVISYNTH SCRIPT
Video = Import("D:\test.avs")
Audio = Import("D:\test.avs")

Video = Video.ConvertToYV12()
Video = Video.AddBorders(0,132,0,132)
Video = Video.Spline16Resize(720,480)
#PullDown: using DGPulldown/HCenc to upsize FPS

Audio = Audio.SSRC(48000)

AudioDub(Video, Audio)
<>

<7/30/2016 11:41:20 AM>
DIRECTSHOW AUDIO MIXER OPERATIONS:
No ffdshow mixer ON/OFF adjustment required at runtime
No ffdshow mixer SETTING adjustment required at runtime
No LAV Filters mixer ON/OFF adjustment required at runtime
<>

<7/30/2016 11:41:20 AM>
START VIDEO ENCODING OPERATIONS
Video Encoding Profile: FFmpeg CBR 1-pass
Target Video FileSize: 153 MB
Encoding Parameters: -i "C:\Users\Stephen\AppData\Local\Temp\DVD_test_1.avs" -threads 4 -aspect 16:9 -c:v mpeg2video -b:v 8500k -minrate 8500k -maxrate 8500k -bufsize 2000k -dc 10 -y "C:\Users\Stephen\Videos\DVD_test.m2v"
<>

<7/30/2016 11:43:06 AM>
END VIDEO ENCODING OPERATIONS
Created File: C:\Users\Stephen\Videos\DVD_test.m2v (153.4 MB)
OUTPUT VIDEO INFO: MPEG-2 Video - 8500 kbps - 720x480 - DAR 16:9 - 23.976 fps - Progressive - 2:31 minutes - 3630 frames
<>

<7/30/2016 11:43:06 AM>
START PULLDOWN OPERATIONS
DGPulldown Parameters: "C:\Users\Stephen\Videos\DVD_test.m2v" -srcfps 23.976 -destfps 29.97 -inplace -tff
<>

<7/30/2016 11:43:17 AM>
END PULLDOWN OPERATIONS
DGPulldown executed on File: C:\Users\Stephen\Videos\DVD_test.m2v (153.4 MB)
OUTPUT VIDEO INFO: MPEG-2 Video - 8500 kbps - 720x480 - DAR 16:9 - 23.976 fps - Progressive (2:3 Pulldown) - 2:31 minutes - 4534 frames
<>

<7/30/2016 11:43:17 AM>
START AUDIO ENCODING OPERATIONS (Track 1)
Wavi+Aften Parameters: "C:\Users\Stephen\AppData\Local\Temp\DVD_test_1.avs" - | "C:\Users\Stephen\Documents\AVStoDVD_284_NoInstall\Aften\aften.exe" -b 192 -pad 0 -dynrng 5 -bwfilter 0 - "C:\Users\Stephen\Videos\DVD_test_1.ac3"
<>

<7/30/2016 11:43:41 AM>
END AUDIO ENCODING OPERATIONS (Track 1)
Created File: C:\Users\Stephen\Videos\DVD_test_1.ac3 (3.5 MB)
OUTPUT AUDIO INFO: AC3 - 192 kbps - CBR - 2 ch - 48000 Hz - 2:31 minutes (0 ms delay)
<>

<7/30/2016 11:43:41 AM>
START DVD AUTHORING OPERATIONS
BatchMux Parameters: -arglist "C:\Users\Stephen\AppData\Local\Temp\DVD_BatchMux.ini"
BatchMux ini file:
-bmlog "C:\Users\Stephen\AppData\Local\Temp\DVD_BatchMux.log"
-d "C:\Users\Stephen\Documents\DVD\VIDEO_TS"
-mxp "C:\Users\Stephen\AppData\Local\Temp\DVD_MuxMan.mxp"
-l "C:\Users\Stephen\AppData\Local\Temp\DVD_MuxMan.log"
-muxman "C:\Users\Stephen\Documents\AVStoDVD_284_NoInstall\MuxMan"
-prio LOW
-palette "C:\Users\Stephen\AppData\Local\Temp\DVD_Palette.txt"
-v "C:\Users\Stephen\Videos\DVD_test.m2v"
-vidmode LB
-a1 "C:\Users\Stephen\Videos\DVD_test_1.ac3"
-a1lang en

<>

<7/30/2016 11:44:00 AM>
END DVD AUTHORING OPERATIONS
Created Folder: C:\Users\Stephen\Documents\DVD (159.5 MB)

CHECK DVD SIZE
DVD Folder (actual) Size: 159.5 MB
vs Assets Size: 156.8 MB -> OK
vs Estimated Size: 159 MB -> 0.3% oversize
<>

<7/30/2016 11:44:00 AM>
AVStoDVD Project ended successfully.
<>

<7/30/2016 11:44:00 AM>
Log file created by AVStoDVD Release 2.8.4
<>

[Groucho2004]

Do you realize that for almost everything you insulted me on, it turns out that what you said was false and I was right?
Do you realize that your opinions don't turn into facts just because you think you're always right?

[MysteryX]

Do you realize that your opinions don't turn into facts just because you think you're always right?
From now on I won't reply to any junk you throw at me; I'll leave your gifts to you.

I'm not here to argue as to who's right and who's wrong, and who's better than who. I'm here to contribute in what I can and share ideas. Taking other people's junk is not part of it.

Do whatever you want. I'll keep my center and focus. This is the last comment regarding any of your junk unless you really cross the line.

now AVStoDVD is accepting the avisynth.dll as a legitimate version
and there's no point in talking about a temporary problem that is already solved. At some point AVStoDVD will update their software. I certainly wouldn't hack AviSynth+'s source code to fix this.

[qyot27]

and there's no point in talking about a temporary problem that is already solved. At some point AVStoDVD will update their software. I certainly wouldn't hack AviSynth+'s source code to fix this.
There was no problem, temporary or otherwise, to 'solve' in the first place. What was being asked for was a frivolous revert of AviSynth+'s DLL versioning so that a harmless yellow warning sign and its corresponding warning message in AVStoDVD's GUI log widget would go away. A harmless warning sign/message that in no way stopped/stops the '0.1.0' versioned AviSynth+ from being used by AVStoDVD.

[thescrapyard]

There was no problem, temporary or otherwise, to 'solve' in the first place. What was being asked for was a frivolous revert of AviSynth+'s DLL versioning so that a harmless yellow warning sign and its corresponding warning message in AVStoDVD's GUI log widget would go away. A harmless warning sign/message that in no way stopped/stops the '0.1.0' versioned AviSynth+ from being used by AVStoDVD.

Sorry, but on my version of AVStoDVD 2.8.4 (very latest portable release) it was stopping me doing anything. All I hacked was the version being reported. It worked for me until things get updated or altered

The question should be why is avisynth+ version being reported as 0.1.0 and not 2.6.x if its based on avisynth. Without starting a slanging match .... if its to avoid confusion between avisynth and avisynth+ I understand that but why is there not something that reports it as avisynth 2.6.x so other software recognises it as such. Either the avisynth+.dll is at fault or the software trying to read the version coding is at fault

[Reel.Deel]

@thescrapyard

Maybe you should of posted these links ([1] (http://forum.doom9.org/showpost.php?p=1775061&postcount=2199), [2] (http://forum.doom9.org/showpost.php?p=1775067&postcount=2201)) in the AVSToDVD thread.

[Chikuzen]

The question should be why is avisynth+ version being reported as 0.1.0 and not 2.6.x if its based on avisynth. Without starting a slanging match .... if its to avoid confusion between avisynth and avisynth+ I understand that but why is there not something that reports it as avisynth 2.6.x so other software recognises it as such. Either the avisynth+.dll is at fault or the software trying to read the version coding is at fault

avisynth and avs+ have three value about version.

1. AVISYNTH_INTERFACE_VERSION
This can access by plugins or applications which operates avisynth.dll directly.

2. VersionNumber
This is the float value you can access by VersionNumber().
avs+ always returns 2.6000.

3. VersionString
This is the string you will see with Version().

It seems that AVS2DVD using VersionString to recognize dll version.
I don't know why that author using not VersionNumber but VersionString.

[Groucho2004]

avisynth and avs+ have three value about version.

1. AVISYNTH_INTERFACE_VERSION
This can access by plugins or applications which operates avisynth.dll directly.

2. VersionNumber
This is the float value you can access by VersionNumber().
avs+ always returns 2.6000.

3. VersionString
This is the string you will see with Version().

It seems that AVS2DVD using VersionString to recognize dll version.
I don't know why that author using not VersionNumber but VersionString.
You forgot the FILEVERSION/PRODUCTVERSION that is stored in the DLL version resource. This is for example "2.6.0.6" for 2.6 release and "0.1.0.0" for AVS+.
This is also what AVS2DVD checks since it does not use the Avisynth API.

[qyot27]

Sorry, but on my version of AVStoDVD 2.8.4 (very latest portable release) it was stopping me doing anything. All I hacked was the version being reported. It worked for me until things get updated or altered

The question should be why is avisynth+ version being reported as 0.1.0 and not 2.6.x if its based on avisynth. Without starting a slanging match .... if its to avoid confusion between avisynth and avisynth+ I understand that but why is there not something that reports it as avisynth 2.6.x so other software recognises it as such. Either the avisynth+.dll is at fault or the software trying to read the version coding is at fault
As I demonstrated above with the NoInstall package of AVStoDVD 2.8.4, it could recognize and use AviSynth+ (I was using a personal build ca. r2067) without any problem. Windows 10 Home 32-bit, with AviSynth+ installed in Program Files and AVStoDVD unpacked to a folder in Documents. So neither AVStoDVD's version detection nor AviSynth+'s change of versioning are at fault there. Version checks don't spontaneously work on one setup and fail on another in a case like this, unless there's something else in your personal configuration causing a problem, and it's whatever that problem is that's the real issue.

When reporting bugs, report everything about your setup, no matter how trivial you think it might be. Windows version, AviSynth+ build version (the revision number reported by Version(), not the stable release number), version of AVStoDVD if relevant. Whether you're using Administrator or User restricted privileges, where the programs are installed. If you've troubleshooted by moving the contents of AviSynth's plugins away from the autoload folder to ensure any one of those aren't causing an issue.


AviSynth+ changed its versioning during the early stages of the forking process because it had added so many new things that it no longer counted as merely a superset of AviSynth 2.6 but increasingly as its own project. Since the approved methods of checking the version number do not include the DLL versioning metadata, that was eventually also changed to match the canonical AviSynth+ versioning as well.

[Groucho2004]

As I demonstrated above with the NoInstall package of AVStoDVD 2.8.4, it could recognize and use AviSynth+ (I was using a personal build ca. r2067) without any problem. Windows 10 Home 32-bit, with AviSynth+ installed in Program Files and AVStoDVD unpacked to a folder in Documents. So neither AVStoDVD's version detection nor AviSynth+'s change of versioning are at fault there. Version checks don't spontaneously work on one setup and fail on another in a case like this, unless there's something else in your personal configuration causing a problem, and it's whatever that problem is that's the real issue.
I finally figured why AVS2DVD always complained that Avisynth is not installed. It checks the existence of this registry key:
[HKEY_LOCAL_MACHINE\SOFTWARE\AviSynth]

I'm using my Avisynth switcher which writes this key:
[HKEY_LOCAL_MACHINE\SOFTWARE\Avisynth]

See the difference? The check is case sensitive and therefore fails. I still stand by what I wrote in this (http://forum.doom9.org/showpost.php?p=1775061&postcount=2199) post about how to properly validate an Avisynth install.

[MysteryX]

avisynth and avs+ have three value about version.

1. AVISYNTH_INTERFACE_VERSION
This can access by plugins or applications which operates avisynth.dll directly.

2. VersionNumber
This is the float value you can access by VersionNumber().
avs+ always returns 2.6000.

3. VersionString
This is the string you will see with Version().

It seems that AVS2DVD using VersionString to recognize dll version.
I don't know why that author using not VersionNumber but VersionString.
In my own software, I also have a AVS version check and I implemented it the same way as AVStoDVD: check the DLL version. Why? Because it's much simpler than referencing the DLL and calling its API, and it gives me what I want.

As for what value it returns, it's doing what it should: returning its version number. It may have the AviSynth 2.6 interface, but it's AviSynth+, and that's what I wanted to know.

If a software is specifically checking for an AviSynth version and it's not what it expects, then it's that software that must be udpated.

I finally figured why AVS2DVD always complained that Avisynth is not installed. It checks the existence of this registry key:
[HKEY_LOCAL_MACHINE\SOFTWARE\AviSynth]

I'm using my Avisynth switcher which writes this key:
[HKEY_LOCAL_MACHINE\SOFTWARE\Avisynth]

See the difference? The check is case sensitive and therefore fails. I still stand by what I wrote in this (http://forum.doom9.org/showpost.php?p=1775061&postcount=2199) post about how to properly validate an Avisynth install.
I personally wouldn't use this because AviSynth.dll can work as a stand-alone DLL. But if one wants to know if it's "installed", which is different than "whether an AviSynth DLL is available", then yes that's the way to do it.

[Groucho2004]

In my own software, I also have a AVS version check and I implemented it the same way as AVStoDVD: check the DLL version. Why? Because it's much simpler than referencing the DLL and calling its API, and it gives me what I want.

As for what value it returns, it's doing what it should: returning its version number. It may have the AviSynth 2.6 interface, but it's AviSynth+, and that's what I wanted to know.

...

I personally wouldn't use this because AviSynth.dll can work as a stand-alone DLL.
All that won't tell you if all dependencies are present. Not just the VC runtimes, the "official" Avisynth depends on devil.dll being present in the same directory.

So, I certainly wouldn't call avisynth.dll a "standalone" DLL (whatever that means).

Don't forget the first axiom for developers:
"Assumption is the mother of all f*ck-ups" :D

[LigH]

So, I certainly wouldn't call avisynth.dll a "standalone" DLL (whatever that means).

Don't forget the first axiom for developers:
"Assumption is the mother of all f*ck-ups" :D

Still, I assume :sly: ... that he may mean: The avisynth.dll does not necessarily need to be installed and hooked into the VfW API; an application may as well load it dynamically and use it via native interface.

[Groucho2004]

Still, I assume :sly: ... that he may mean: The avisynth.dll does not necessarily need to be installed and hooked into the VfW API; an application may as well load it dynamically and use it via native interface.
I can't bring myself to call a DLL stand-alone even if it is statically linked and has no dependencies (apart from system DLLs like kernel.dll). The DLL can't do anything on its own, it has to be loaded by an application.
Semantics - perhaps.

[LigH]

Well, yes ... maybe rather call it "indirect use" (using a system-wide registered DLL via VfW API) versus "direct use" (using a local DLL via native AviSynth interface, regardless of its system-wide installation into the VfW API).

[MysteryX]

Yeah, just copy AviSynth.dll and Devil.dll into either the system folder or the app folder and you're good to go.

Or more common, AviSynth 2.6 (or perhaps even 2.5.8) was installed and the DLL got replaced by AviSynth+ (before the new installer got released). In that case I wouldn't rely on the way the installer sets things up.

[TheFluff]

In my own software, I also have a AVS version check and I implemented it the same way as AVStoDVD: check the DLL version. Why? Because it's much simpler than referencing the DLL and calling its API, and it gives me what I want.

That's retarded. It doesn't give you what you or the user wants at all. What you want is to know if you can load and successfully use the DLL. Checking metadata does not tell you anything at all about that and will lead to both false positives and false negatives (like in this AVS2DVD case).

The robust way to do feature detection is to try it and see if it works. Doing it this way also gives you graceful error handling unless you're being actively terrible about it.

[MysteryX]

That's retarded. It doesn't give you what you or the user wants at all. What you want is to know if you can load and successfully use the DLL. Checking metadata does not tell you anything at all about that and will lead to both false positives and false negatives (like in this AVS2DVD case).

The robust way to do feature detection is to try it and see if it works. Doing it this way also gives you graceful error handling unless you're being actively terrible about it.
No, what I want to know is whether to generate scripts using the 2.6 MT syntax or the AVS+ MT syntax. There are small script differences.

"Try and see" won't tell me this.

Plus in .NET, I cannot instantiate the DLL to call its API unless there is a DLL wrapper to expose its interface, and I don't use it directly in my code. I generate the script, then call avs2yuv or x264 or ffmpeg

[jpsdr]

As we are with internal mode creations (like uint16 and float), i would like to make a suggestion : An RGB planar mode.
This could be interesting for people who work with RGB video, don't want to convert them in YUV, but want good speed processing, because RGB32/RGB24 mode are not the easier data storage mode to process. The work will be minimal, because an RGB planar mode is somehow exactly the same thing than YV24. Your picture has 3 planes of the same size. You call for YV24 and RGBplanar exactly the same functions with the exact same parameters. Except, of course, format convertion functions.
What do you think ?

[qyot27]

As we are with internal mode creations (like uint16 and float), i would like to make a suggestion : An RGB planar mode.
This could be interesting for people who work with RGB video, don't want to convert them in YUV, but want good speed processing, because RGB32/RGB24 mode are not the easier data storage mode to process. The work will be minimal, because an RGB planar mode is somehow exactly the same thing than YV24. Your picture has 3 planes of the same size. You call for YV24 and RGBplanar exactly the same functions with the exact same parameters. Except, of course, format convertion functions.
What do you think ?
https://github.com/AviSynth/AviSynthPlus/pull/84

The big pixel type pull request, opened on July 26th. Not everything in there is working yet, but Planar RGB was there from the start.

[jpsdr]

Ah... Ok...

[ultim]

r2150 (http://avs-plus.net/builds) integrates work from chikuzen, pinterf, and qyot27. The colorspaces are further extended with initial support for planar RGB and alpha channel, new SSE2 and other optimizations are available, support for building with VS2013 is improved, there are some small fixes here and there, and of course a bunch of cleanups. API support for negative ("forced") alignment of video frames is deprecated and disabled, we think this is safe and have seen no regressions during testing, but just in case, there is a new diagnostic warning in the recently added logging system if a plugin is found relying on it.

Code for the new colorspaces added in the past weeks is still in a flux, so keep in mind this is a work in progress. Still, large and usable parts are already done, like support in the API, in various conversion functions, and in many-many internal filters. As always, please write to this thread if you see any regressions or have any other feedback.

[MysteryX]

Perhaps the one thing missing to make the new 16-bit code actually usable is dithering back to 8-bit. Until then, it's academic work that can't be used for production.

P.S. Slightly off-topic but... Ultim, I find it a strange coincidence that our avatar is the same circle with the same border width. Yours is empty though.

[Groucho2004]

P.S. Slightly off-topic but... Ultim, I find it a strange coincidence that our avatar is the same circle with the same border width. Yours is empty though.
You should write about it in your blog (https://www.spiritualselftransformation.com/blog/).

[Chikuzen]

I updated RawSourcePlus and avs2pipemod to support r2150 new features.

RawSourcePlus (https://github.com/chikuzen/RawSource_2.6x/releases/tag/20160814)

avs2pipemod (https://github.com/chikuzen/avs2pipemod/releases/tag/1.1.1)

These are also experimental because the new features are still experimental.
When input and output aren't supported, it isn't possible to be a victim.
Therefore I announce to only the people watching this thread.

[Reel.Deel]

Perhaps the one thing missing to make the new 16-bit code actually usable is dithering back to 8-bit. Until then, it's academic work that can't be used for production.


There's already these:


Bit-depth conversions (no dithering, no range conversion, etc...)

ConvertTo8bit()
ConvertTo16bit()
ConvertToFloat()



No dithering but for that you can always use Dither:
16-bit source
ConvertToStacked()
DitherPost()

or f3kdb:
16-bit source
ConvertToStacked()
f3kdb(input_mode=1, input_depth=16, output_depth=8)

----

MysteryX, did you ever fix this?

MysteryX, I took a quick look at your source of AviSynthShader to verify something. Whenever you call GetFrame() (https://github.com/mysteryx93/AviSynthShader/blob/master/Src/ExecuteShader.cpp#L115) to get your input frames, pull those calls out of your mutex lock! The way your filter operates right now is forcing the other filters it calls into mode 3! Not nice.

The occurance I linked to might not be the only one, it was just the first I've found.

Oh! That is one is very easy to fix: move the unique_lock down a few lines.

Good catch, I never thought about that.

[Chikuzen]

or f3kdb:
16-bit source
ConvertToStacked()
f3kdb(input_mode=1, input_depth=16, output_depth=8)


16-bit source
ConvertToDoubleWidth()
f3kdb(input_mode=2, input_depth=16, output_depth=8)
ConvertToDoubleWidth() is zero cost.
You shoudn't use Stack16 if filter support DoubleWidth(Interleaved) formats.

[Groucho2004]

It seems that CreateScriptEnvironment() is not exported for 64 bit.

Edit: I see it's fixed in r2151, thanks.

[ultim]

ConvertToStacked()/ConvertToDoubleWidth() provide a hack to be able to interface existing dither functions. I'd like to kill these two (and their counterparts) ASAP, so if any of you can find the time, please consider adding proper high bit-depth support to dithertools and f3kdb, at least to the functions for dithering down.

edit: give a note if you decide to help out with these, so that others won't start on it too.

[MysteryX]

MysteryX, did you ever fix this?
Fixed? Yes. Released? No.

There were are few other things that still need to be fixed.

Thanks for the reminder, I forgot about that one.

[real.finder]

16-bit source
ConvertToDoubleWidth()
f3kdb(input_mode=2, input_depth=16, output_depth=8)
ConvertToDoubleWidth() is zero cost.
You shoudn't use Stack16 if filter support DoubleWidth(Interleaved) formats.

and he can use


f3kdb_dither(mode=1, stacked=false, input_depth=16)


for only dithering without debanding

[burfadel]

I can't get 2151 x64 to work, instant fail on loading any file using any filter. r2085 works fine.

Yes, I did replace avisynth in system32 and the plugin files :). I even tried redownloading the 2151 files, but no success.

If I run it from the command prompt (not through Staxrip) I get the following message:

http://i.imgur.com/BxegTXp.jpg

I did also use Chikuzen's updated avs2pipemod, however this isn't the cause. If opening a file in Staxrip regardless of the source filter (L-SMash-Works, FFMS2 etc), with no other filters it still fails.

[Groucho2004]

I can't get 2151 x64 to work, instant fail on loading any file using any filter. r2085 works fine.
I suggest you try without any re-direction, feeding the script directly to a client.
Run "AVSMeter -avsinfo". If that doesn't produce any errors, run your script with AVSMeter.

Edit: By the way, "output various data from avs to stdout" is what Windows considers the name of the application (avs2pipemod). This is because Windoze in its infinite wisdom pulls the name from the "FileDescription" entry in the version resources instead of something that would make sense like "ProductName".
In case of avs2pipemod, it's "output various data from avs to stdout" (https://github.com/chikuzen/avs2pipemod/blob/master/src/avs2pipemod.rc#L69).

[jpsdr]

Some critical issue with r2151 made me back to r2085. Unable to use DGSource anymore error message is :
AVI Import filter error: (Unknown) (80040154).
Maybe it's related to the issue burfadel has.

[Groucho2004]

Some critical issue with r2151 made me back to r2085. Unable to use DGSource anymore error message is :
AVI Import filter error: (Unknown) (80040154).
Maybe it's related to the issue burfadel has.
No problem with DGSource here (x86/x64, XP64).

[burfadel]

This is what happens with Avsmeter with a simple script.

http://i.imgur.com/cENNFp9.jpg

First run is multithreaded mode with 2085. The second is multithreaded mode with 2151, exact same script. Third run is the same script WITHOUT the set MT mode and prefetch set, so running single thread.

It's repeatable and at the same fault addresses. In multithread mode the error is always identical to other multithread runs, and in single thread mode it is always identical to other single thread runs.

The script I am using is a basic one:
SetFilterMTMode("DEFAULT_MT_MODE", 2)
colorbars(width = 1920, height = 1080, pixel_type = "yv12").killaudio().assumefps(25, 1)
deveed()
prefetch(4)

I chose deveed because it works fine on any other avisynth, just not this one. Some filters in its place did work, including desaltpepper, nirmalam, adaptivemedian, and cnr2. What didn't work is deveed in that line single or multithread (probably others as well), or loading any file with LWLibavVideoSource, DSS2, FFMS2, or Directshowsource.

[Chikuzen]

AVI Import filter error: (Unknown) (80040154).
It's not related DGSource.
VDub64 can't open any avs after this commit (https://github.com/AviSynth/AviSynthPlus/commit/76474e653ab8440c7d21a5e8567052aeb38bd413).

[Groucho2004]

This is what happens with Avsmeter with a simple script.

http://i.imgur.com/cENNFp9.jpg
Since it works with r2085 and not with r2151 it's fair to assume that one of the commits between those revisions caused the incompatibility with deveed. Maybe ultim can figure out which one.

[burfadel]

Since it works with r2085 and not with r2151 it's fair to assume that one of the commits between those revisions caused the incompatibility with deveed. Maybe ultim can figure out which one.

It's not only Deveed, that just that happens to be one filter that causes it. There was no point using a filter that was working! However, as any source filter causes it as well it's not as simple as just not using deveed. The only reason why it was working with some filters is the script was just a modified one from the knclmeans performance test, so no source file (thus therefore no source filter) was used.

[ultim]

It's not related DGSource.
VDub64 can't open any avs after this commit (https://github.com/AviSynth/AviSynthPlus/commit/76474e653ab8440c7d21a5e8567052aeb38bd413).

This is now fixed in r2157 (not uploaded), it affected users on x64 if loading an .avs script as an AVI file. The surprise for me is that some COM functions can *only* be exported using a .def file, so I had to add it back for x64, sob.

I'm still looking into burfadel's problem, I will upload a build once I have this fixed too. But now I need to eat.

[ultim]

r2161 (http://avs-plus.net/builds) fixes the issue reported by jpsdr, and some additional problems that affected only the recently added new color formats (more specifically those with an alpha channel, and Y10/12/14).

The problem that burfadel saw is a bug in DeVeed. DeVeed caused a memory corruption, and it seems the memory contents of avs+ changed between 2085 and 2151 in a way such that the corruption wasn't silent anymore but raised an exception by pure chance. I uploaded a fixed build of DeVeed under the same URL in the "External_Plugins" folder (until vcmohan integrates the fix into his own sources). The fix is to replace line 229 in DeVeed.cpp by:
val += wpp[offset[i + span2]] * kr[i + span2];

Edit: Since earlier DeVeeds caused a silent corruption, if you are using this filter I recommend you upgrade to this DeVeed build even if it appeared to work earlier.

[burfadel]

I tried the 2161 that was just uploaded. It still fails at the same addresses with avsmeter64, however now it loads in Staxrip. You just can't do anything further once loaded! In the preview windows, same error address appears in read at the top of the screen, full message:
CAVIStreamSynth: System exception - Access Violation at 0x00007FFCC2FF79A8

As I said, the errors in multithread and single thread modes are repeatable :).

[ultim]

I tried the 2161 that was just uploaded. It still fails at the same addresses with avsmeter64, however now it loads in Staxrip. You just can't do anything further once loaded! In the preview windows, same error address appears in read at the top of the screen, full message:
CAVIStreamSynth: System exception - Access Violation at 0x00007FFCC2FF79A8

As I said, the errors in multithread and single thread modes are repeatable :).

Did you also install the fixed DeVeed that more than half of my previous post was about?

[burfadel]

Did you also install the fixed DeVeed that more than half of my previous post was about?

Apologies for that! I downloaded 2161 before you posted about it. Out of curiosity I thought I'd check and see if a build had been uploaded.

The new Deveed works fine! So all good now. Thankyou for looking into it so promptly!

[ultim]

Apologies for that! I downloaded 2161 before you posted about it. Out of curiosity I thought I'd check and see if a build had been uploaded.

The new Deveed works fine! So all good now. Thankyou for looking into it so promptly!

No problem, thx for reporting bugs. Let us know if you find anything else :D

[Chikuzen]

I got a bug report from an avs2pipemod user.

SetLogParams("stderr", LOG_INFO)
ColorBarsHD()
ScriptClip("SubTitle(String(current_frame))")
prefetch(4)

When "DEFAULT_MT_MODE" is not set to 3, ScriptClip causes access violation.
I think this should be prevented.

[burfadel]

I got a bug report from an avs2pipemod user.

SetLogParams("stderr", LOG_INFO)
ColorBarsHD()
ScriptClip("SubTitle(String(current_frame))")
prefetch(4)

When "DEFAULT_MT_MODE" is not set to 3, ScriptClip causes access violation.
I think this should be prevented.

I tried all MT modes, and yes only mode 3 worked. The access violation on one of the tests seems to be at the same address as I had with my issue with deveed. This isn't exactly repeatable though, the first crash in mode 1 was only repeatable once, most times the crashes in modes 1 and 2 just causes avsmeter64 to fully crash or crash and pause with a whole heap of output like (small excerpt):
pâ³
([ScriptClip], line -1735100535)
ERROR: Þâ³
([ScriptClip], line -1736150327)
---------------------------------------------------------------------
ERROR: ---------------------------------------------------------------------
System exception - Access Violation
------------------------------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------
ERROR: ERROR:
System exception - Access Violation
ERROR: System exception - Access Violation
à³
([ScriptClip], line -1728810999)
ERROR: ---------------------------------------------------------------------
---------------------------------------------------------------------
System exception - Access Violation
ERROR: ERROR: Hà³
([ScriptClip], line -1736150327)pà³
([ScriptClip], line -1729857847)
---------------------------------------------------------------------

ERROR: ---------------------------------------------------------------------└à³

I copied this directly from the command prompt. You can do that in modern Windows, just highlight and press ctrl+c.

This is what I get with MT mode set to 1 when it did throw a meaningful error. I know 1 is 'unreliable', I included it for comparison:
Exception 0xC0000005 [STATUS_ACCESS_VIOLATION]
Module: C:\Windows\System32\KernelBase.dll
Address: 0x00007FFCC2FF79A8

With mode 2:
---------------------------------------------------------------------
ERROR: System exception - Access Violation
---------------------------------------------------------------------
ERROR: |═
([ScriptClip], line 531728591)

Exception 0xC0000005 [STATUS_ACCESS_VIOLATION]
Module: C:\Windows\System32\AviSynth.dll
Address: 0x00007FFC8DB00E75

The issue lies with ScriptClip, the following works:
SetFilterMTMode("DEFAULT_MT_MODE", 1)
SetFilterMTMode("ScriptClip", 3)
SetLogParams("stderr", LOG_INFO)
ColorBarsHD()
ScriptClip("SubTitle(String(current_frame))")
prefetch(4)

I guess it makes sense, there is a message that says:
---------------------------------------------------------------------
WARNING: AviSynth_ScriptClip() has no MT-mode set and will use the default MT-mode. This might be dangerous.
---------------------------------------------------------------------

[vcmohan]

r2161 (http://avs-plus.net/builds)
The problem that burfadel saw is a bug in DeVeed. DeVeed caused a memory corruption, and it seems the memory contents of avs+ changed between 2085 and 2151 in a way such that the corruption wasn't silent anymore but raised an exception by pure chance. I uploaded a fixed build of DeVeed under the same URL in the "External_Plugins" folder (until vcmohan integrates the fix into his own sources). The fix is to replace line 229 in DeVeed.cpp

Thanks for finding the bug. I corrected and uploaded on to my page.

[ultim]

Last update for this week, r2172 (http://avs-plus.net/builds). The main feature is that it makes MT work for ScriptClip and friends (only ScriptClip tested, please report on ConditionalFilter/Select).
Also interesting could be the new warning diagnostic that fires when you try to set an MT-mode for a script function.

Plus there are some other miscellaneous fixes not even worth mentioning... except that now you can build Avs+ using MinGW! Well, technically you can, but due to the different ABI of GCC you still must use MSVC++ if you want a functioning library for Windows. Nevertheless, this is yet another step towards cross-platform support. I am not going to invest a lot more time to this end, but if you want to make Avs+ work on Linux, the compiler won't stand in your way anymore. If anybody wants to tackle what remains, this is a good starting point. Post here if you need tips on specifics.

Oh, and keep the reports coming.

[qyot27]

Plus there are some other miscellaneous fixes not even worth mentioning... except that now you can build Avs+ using MinGW! Well, technically you can, but due to the different ABI of GCC you still must use MSVC++ if you want a functioning library for Windows.
At which point is it not functional on Windows? The library won't work at all, or it won't load C++ plugins, or something else? Wouldn't C plugins (since they're often built with GCC) or C programs that access AviSynth.dll through the C interface (like FFmpeg and x264) still work?

I mean, yeah, it does severely limit usefulness if C++ plugins can't be used, but aside from that.


And speaking of MinGW, I'll have to whip that CMake install patch into shape against MT.

[ultim]

At which point is it not functional on Windows? The library won't work at all, or it won't load C++ plugins, or something else? Wouldn't C plugins (since they're often built with GCC) or C programs that access AviSynth.dll through the C interface (like FFmpeg and x264) still work?

I mean, yeah, it does severely limit usefulness if C++ plugins can't be used, but aside from that.

It is not functional in that you surely cannot access the library over the C++ interface for one, which is what most applications and plugins do (for that to work those apps and plugins would also need to be compiled using the same MinGW compiler). I haven't tested with the C-interface, but you are right, theoretically that could work. If you are among the bold and the brave, here (http://www11.zippyshare.com/v/2dXF6SMX/file.html) is a debug version built with MinGW.

[qyot27]

It is not functional in that you surely cannot access the library over the C++ interface for one, which is what most applications and plugins do (for that to work those apps and plugins would also need to be compiled using the same MinGW compiler). I haven't tested with the C-interface, but you are right, theoretically that could work. If you are among the bold and the brave, here (http://www11.zippyshare.com/v/2dXF6SMX/file.html) is a debug version built with MinGW.
I saw the --std=gnu++14 in CMakeLists.txt - are we using C++14 features there? I'm asking mostly because we should note somewhere what the minimum (or a ballpark estimation since GCC didn't implement all the features at once) version of GCC that can be used is.

I always use the latest stable version (currently 6.1.0), so I don't have to worry about it, but not everyone stays that up-to-date. 5.x is probably a good estimate if you look at the chart on the conformance page (https://gcc.gnu.org/projects/cxx-status.html#cxx14), but that still kind of leaves the possibility that 4.8 or 4.9 might work too.

[ultim]

I saw the --std=gnu++14 in CMakeLists.txt - are we using C++14 features there? I'm asking mostly because we should note somewhere what the minimum (or a ballpark estimation since GCC didn't implement all the features at once) version of GCC that can be used is.

I always use the latest stable version (currently 6.1.0), so I don't have to worry about it, but not everyone stays that up-to-date. 5.x is probably a good estimate if you look at the chart on the conformance page (https://gcc.gnu.org/projects/cxx-status.html#cxx14), but that still kind of leaves the possibility that 4.8 or 4.9 might work too.

C++14 might not even be needed. For example at some point I was making use of make_unique which is C++14, and I know then I removed some unique_ptrs, maybe all, maybe not. I think if we depend on C++14, it is due to the std-library and not due to language syntax, and even then only in very few cases. Should this turn out to be a problem, I am very positive we can easily go back to C++11. But it is equally possible you can just flip the switch to C++11 right now.

Anyway, I wouldn't worry too much about the exact GCC version needed unless we can produce a working library with it. And if that happens at all, it won't be for Windows. Porting to GCC though makes it easier for somebody to pick up the porting efforts from here, and it even allowed me to find some bugs.

[qyot27]

I have some weird results with the MinGW builds. None of them - a cross-compiled AviSynth+ built under Ubuntu with MinGW-w64 4.0.6 and GCC 6.1.0, one built under msys2 with GCC 5.4.0 (I don't know which MinGW-w64 version), or the build ultim provided above - works with FFmpeg. However, the msys2 build and ultim's do at least have FFmpeg error out the same way it does if the proper MSVC runtime can't be found, while the one built on 6.1.0 just up and crashes.

I think part of it might have to do with function decorations. Or compiler optimizations that I tried enabling on the 6.1.0 build. It'll get worked out eventually.

[jpsdr]

@qyot27 : How do you get the gcc5.4.0 version under msys2 ? When i've updated my packages using "standard pacman" method, i've jumped directly to 6.1.0 from 5.3.0.

Otherwise about other higher bit depth formats colors, the 16 bits for exemple, whatever memory organisation you used (interlaced, stacked verticaly, etc...), unless it's allready done, it should be interesting to have the possibility to tag, without converting, a video.
For exemple a 16 bits video 300x200 stacked verticaly, it will result in a 300x400 video, with the first 300x200 the LSB part, and the second 300x200, the MSB part. If with VDub i save (with a lossless codec, of course) this video, and re-open it with another script, is there the possibility to said in AVISource the fact that video is allready in this format ? If not, a tag function for these new formats wich are probably not yet fully handle with actual codecs is something i think very usefull.
To continue the exemple, the file you first open it as a standard 8bits 300x400, and then after you just tag it saying, "no, indeed it's a 300x200 16bits stacked verticaly".
The interest in this is for people (like me... ;) ) who split their step process. I personnaly do all the pre-processing and then save it on a lossless format, and, after, i do the encode on this saved file. Because if (for any reason, one of them is because the file is 40kB too big to fit on the Blu-Ray... :sly: ) i have to redo the encode, i redo only it, not also the pre-processing, this will avoid a waste of time. And don't mistake, sometime pre-processing can have time not negligeable compared to encode time.
For now, i'm not using it, i don't know when neither if i'll use them in the future, but i realy think this is a feature which could be added, and as it's only to tag a video, not convert it, my guess is that it will probably not be a too much work to do it.

Unless... Such a feature allready exists :confused:

[MysteryX]

Otherwise about other higher bit depth formats colors, the 16 bits for exemple, whatever memory organisation you used (interlaced, stacked verticaly, etc...), unless it's allready done, it should be interesting to have the possibility to tag, without converting, a video.
Although it is possible to add custom metadata to a video file, that's not the job of AviSynth+. After you encode a video, you sure can add a tag to it (or maybe the encoding tool you use has a parameter to add custom tags).

To read that tag, however, will be the responsibility of the source plugin designer. Perhaps one, such as L-SMASHSOURCE, will decide to support that feature, but I'd expect that to be a specialized feature implemented in 1 or 2 source filters at most; if at all.

And consider this: stacked format is doomed to hell. Every effort is being made at killing that bitch from hell that shouldn't exist, I don't think anyone will put any effort in adding more support for it :)

[MysteryX]

Here is something odd. I'm editing AvisynthShader to use SetCacheHints instead of the Env2 interface, and using the latest build.

Normally, running in MT mode 2 gives about the same performance but MUCH higher memory usage. This time, however... well... look for yourself


ColorBarsHD(width=1940, height=1080).killaudio().assumefps(25, 1).ConvertToYV12()
SuperResXBR(2, 1, .15, fWidth=2600, fHeight=1500, engines=1)
Prefetch(8)


MT_NICE_FILTER (and Engines=2)

FPS (min | max | average): 0.516 | 1000000 | 4.451
Memory usage (phys | virt): 728 | 746 MiB
Thread count: 33
CPU usage (average): 4%


MT_MULTI_INSTANCE

FPS (cur | min | max | avg): 0.485 | 0.246 | 1000000 | 2.921
Memory usage (phys | virt): 886 | 865 MiB
Thread count: 70
CPU usage (current | average): 6% | 6%


The thread count suggests that the MT mode is being properly applied. However, the memory usage with MT_MULTI_INSTANCE used to be a LOT higher, and performance should also be much higher.

What's going on here?

Edit: I ran it again with MT_MULTI_INSTANCE and 4 threads instead of 8. Now it looks better; in fact performance is surprisingly good. It was most likely a repeated cache flushing issue.


FPS (min | max | average): 1.000 | 1000000 | 4.795
Memory usage (phys | virt): 512 | 540 MiB
Thread count: 46
CPU usage (average): 3%


and with MT_NICE_FILTER (Engines=2)

FPS (cur | min | max | avg): 1.333 | 0.889 | 1000000 | 4.720
Memory usage (phys | virt): 472 | 489 MiB
Thread count: 31
CPU usage (current | average): 3% | 3%


I don't understand why the thread overhead when using 8 vs 4 thread in MT_NICE_FILTER causes such a big memory difference (746MB vs 489MB), while 4 instances of the DX9 engine take 540MB and 2 instances take 489MB; each instance used consume a lot of memory. Something is different in the way memory is being managed.

For the records, 4 threads in MT_SERIALIZED:

FPS (min | max | average): 0.800 | 1000000 | 4.621
Memory usage (phys | virt): 342 | 356 MiB
Thread count: 26
CPU usage (average): 4%


Cache flushing appears to be a major killer. There's probably a way to handle that in a nicer way.

[DJATOM]

Well, I think it's possible create a hacky extension of y4m and put such metadata to flag that kind of video. But isn't ConvertFromStacked/ConvertToStacked better if you need to split your processing and store HBD information in your lossless files? I think it's better to bring native HBD support rather than implement hacky stuff.

[jpsdr]

Although it is possible to add custom metadata to a video file, that's not the job of AviSynth+

It seems i've been greatly misunderstood... :(
I'm not talking about adding a tag/metadata to a video, just transform the data, without conversion.
There is the same thing in VDub, it calls it "alias", except that in VDub it's just working for REC format color.
Just, if you have opened a video in a format "X", transforming WITHOUT converting, saying, no, it's not "X", it's "Y".
Like ConvertToFloat(), create a TransformToFloat(), this will just said "finaly, my YV24 1200x200 8 bits video is a 300x200 float video".
And stacked was just an exemple.
If you want a more actual exemple : With a 1rst script i create a 16bits (whatever format it is, stacked or not, it's not relevant here, it's absolutely not the point !) YV12 300x200 video, and want to save it in a lossless or uncompressed avi file.
Then, with a second script, i open and work on the result of the 1rst script... and eventualy feeds it to x264.
Personnaly, the only way i would have to do this is saving the file with VDub in ... lossless codec if you're sure the codec will not screw up the 0-15/236-255 part, or uncompressed avi (this shouldn't mess the data) resulting in a 600x200 YV12 8bits video.
And then, in the second script, opening it with AVISource. But unless i'm wrong, you can't tell AVISource "it's a 300x200 YV12 16bits video", you have to open it as a 600x200 YV12 8bits video, and then, after, with for exemple a TransformTo16bit(), saying "finaly, the data you have is not a 600x200 YV12 8bits, but it's a 300x200 YV12 16bits".
Now... If you see another way of doing this, i'm all ears... (well, eyes here... ;) ).

[shekh]

What about this: on 1st pass you write uncompressed y4m file with planar 16bit.

On 2nd pass you feed that y4m to encoder.

Compressing stacked is impossible even in lossless codec as it cannot make sense out of stacked format

[Chikuzen]

you have to open it as a 600x200 YV12 8bits video, and then, after, with for exemple a TransformTo16bit(), saying "finaly, the data you have is not a 600x200 YV12 8bits, but it's a 300x200 YV12 16bits".

What is the difference in it and ComvertFromDoubleWidth() ?
https://github.com/AviSynth/AviSynthPlus/commit/d25373a8ca35b0f3bba5d3a14392b524416d9f2e

[jpsdr]

What about this: on 1st pass you write uncompressed y4m file with planar 16bit.

With what ? On what i'm feeding the avs script ?

What is the difference in it and ComvertFromDoubleWidth() ?

It seems it answers the question "Unless... Such a feature allready exists ?".

[qyot27]

@qyot27 : How do you get the gcc5.4.0 version under msys2 ? When i've updated my packages using "standard pacman" method, i've jumped directly to 6.1.0 from 5.3.0.
Easy. The last time I updated it was in June.

[shekh]

With what ? On what i'm feeding the avs script ?


avs2pipe or avs2yuv (dont know which)

[jpsdr]

r2161 (http://avs-plus.net/builds) fixes the issue reported by jpsdr
BTW, i forgot but a big :thanks: for all your work, you, pinterf and all the others.

[Chikuzen]

With what ? On what i'm feeding the avs script ?

Latest avs2pipemod allows you to save 10/12/14/16bit YUV as y4m with ffmpeg's extension.
And latest RawSourcePlus can read those files.

http://forum.doom9.org/showpost.php?p=1777068&postcount=2265

[MasterNobody]

I released Avs2YUV 0.24 BugMaster's mod 5 (https://github.com/MasterNobody/avs2yuv/releases/tag/v0.24bm5) with support for AviSynth+ high bit-depth pixel formats.
Also I made patch for x264: link (http://git.videolan.org/?p=x264/x264-sandbox.git;a=commit;h=c65dc4e9c2bc906013cdaf7c3de93a38aa175725)

btw. avs_is_rgb48 and avs_is_rgb64 names are missing in avisynth.def and so are mangled in i386 dll-exports (_avs_is_rgb48@4 and _avs_is_rgb64@4 due the use of __stdcall calling convension).

[ultim]

Here is something odd. I'm editing AvisynthShader to use SetCacheHints instead of the Env2 interface, and using the latest build.

I'm not sure what you mean by a cache flushing issue, but I don't see anything obviously wrong when I look at your measurements. Due to how MT works in Avs+, I'd intuitively expect an approximately linear (though not necessarily with a factor of 1.0) growth of memory usage as the thread count goes up. I have told about this when I first introduced the new caching system a long while ago (2014-2015?), and I see this more or less mirrored in your numbers.

On the contrary, it is counterintuitive for me how memory grows only so little when you increase the number of engines from 4 to 8, since the load on the caches should increase by the same amount as if you used the core's MT. One possible explanation is I have a wrong understanding of what your "engines" do and how they work in parallel.

[ultim]

I released Avs2YUV 0.24 BugMaster's mod 5 (https://github.com/MasterNobody/avs2yuv/releases/tag/v0.24bm5) with support for AviSynth+ high bit-depth pixel formats.
Also I made patch for x264: link (http://git.videolan.org/?p=x264/x264-sandbox.git;a=commit;h=c65dc4e9c2bc906013cdaf7c3de93a38aa175725)

btw. avs_is_rgb48 and avs_is_rgb64 names are missing in avisynth.def and so are mangled in i386 dll-exports (_avs_is_rgb48@4 and _avs_is_rgb64@4 due the use of __stdcall calling convension).

Thank you very much for the x264 patches, and also for bringing the missing export definitions into attention. They will be added right away, and the decorated names will cease to exist. Thumbs up for x264 taking both versions into account :D

[Groucho2004]

One possible explanation is I have a wrong understanding of what your "engines" do and how they work in parallel.I would not waste time analysing "issues" that involve this avisynthshader monstrosity.

[MasterNobody]

ultim
Also imho "#ifdef MSVC" change in capi.h (https://github.com/AviSynth/AviSynthPlus/blob/MT/avs_core/include/avs/capi.h#L42) is wrong because apps compiled with MinGW using this header (avisynth_c.h i.e. C inteface) wouldn't be compatible with standard (MSVS) AviSynth+ because they will try to call functions with __cdecl instead of __stdcall calling convention.

[Sparktank]

Phew. So many updates for a lot of stuff.

I love the progress. A lot. Everything looks so promising.

Great work, guys. The world is changing.

[ultim]

ultim
Also imho "#ifdef MSVC" change in capi.h (https://github.com/AviSynth/AviSynthPlus/blob/MT/avs_core/include/avs/capi.h#L42) is wrong because apps compiled with MinGW using this header (avisynth_c.h i.e. C inteface) wouldn't be compatible with standard (MSVS) AviSynth+ because they will try to call functions with __cdecl instead of __stdcall calling convention.

You're right. Unwillingly but I keep forgetting about the C-interface. I undefined __stdcall for MinGW because I thought it is only for future Linux-support anyway, and anybody else will have to be using MSVC on Windows. But this doesn't hold for the C interface. I'll patch this up too.

[MysteryX]

On the contrary, it is counterintuitive for me how memory grows only so little when you increase the number of engines from 4 to 8, since the load on the caches should increase by the same amount as if you used the core's MT. One possible explanation is I have a wrong understanding of what your "engines" do and how they work in parallel.
An Engine is an instance of a DirectX device that processes a chain of commands. Such device can only be used by a thread at once. Because it holds all the graphic card textures, it tends to take a lot of memory (twice more in x64 for an unknown reason).

What was giving me best performance was running Avisynth with 4 or 8 threads and splitting out the work between 2 DX engines (which saturates the GPU). Something is now different in the way memory behaves, but I can't pin-point what's different.

[Groucho2004]

Access Violation using LoadPlugin nnedi.dll
Wow, I didn't think that the original nnedi was still being used.

Anyway, this bug report is retarded.
- No mentioning of the Avisynth+ revision used
- No script
- No client with which the error occurred specified
- Access violation in which module?

Since you consider yourself a programmer, you should know better.

[ultim]

Access Violation using LoadPlugin nnedi.dll

Hi rean, please send me:
- your script
- the Avs+ revision that was used
- your nnedi plugin dll

[jpsdr]

I have a question about running external plugin. When is the destructor called ? If i have several external filters (from several dll files), is it possible that a destructor of a filter A is called when frames of another filter B are still do be processed (but all frames of A are finished), or are the destructors begin to be called ONLY when ALL the frames of ALL the filters are being processed ? (When everything is finished). This last seems the more logical, but i can't take it for granted.

[MasterNobody]

Can someone explain me use cases for 10/12/14 bit pixel types? imho for processing it easier to use either 8-bit or 16-bit if higher precision is needed (there is no point to make processing at >8 and <16 bits as it would have same speed as 16-bit and will need special casing algorithms). Or this pixel types are really 16-bit and this is only metadata which doesn't really change position of most significant bit (i.e. 10-bit have real bits at 6..15 and zeroes at bits 0..5 and not real bits at 0..9 and zeroes at 10..15)? If this is not metadata than I don't understand why ConvertTo16bits() and ConvertTo16bits(bits=10) results in same byte output. Also why ConvertToYUV420/YUV422/YUV444 from 10-bit pixel type results in 16-bit pixel type.

[ultim]

Can someone explain me use cases for 10/12/14 bit pixel types? imho for processing it easier to use either 8-bit or 16-bit if higher precision is needed (there is no point to make processing at >8 and <16 bits as it would have same speed as 16-bit and will need special casing algorithms). Or this pixel types are really 16-bit and this is only metadata which doesn't really change position of most significant bit (i.e. 10-bit have real bits at 6..15 and zeroes at bits 0..5 and not real bits at 0..9 and zeroes at 10..15)? If this is not metadata than I don't understand why ConvertTo16bits() and ConvertTo16bits(bits=10) results in same byte output. Also why ConvertToYUV420/YUV422/YUV444 from 10-bit pixel type results in 16-bit pixel type.


10/12/14 formats follow Microsofts VUV description for higher bit-depths (https://msdn.microsoft.com/en-us/library/windows/desktop/bb970578(v=vs.85).aspx), and store valid bits in the MSBs of the two bytes for each pixel.

These formats are not meant for processing in Avisynth, they just exist so that they can be output to (and be read from). So basically only conversion functions will have support for them.

If you mean that based on your testing, some 16bit and 10bit conversion functions have the same output, I think that is because the implementation is not yet finished and code is still missing to handle all cases. But pinterf can provide more insight in this matter than me. He's still in the middle of implementation, he only seems inactive recently because he's on holidays with his family.

[Wilbert]

I have a question about running external plugin. When is the destructor called ? If i have several external filters (from several dll files), is it possible that a destructor of a filter A is called when frames of another filter B are still do be processed (but all frames of A are finished), or are the destructors begin to be called ONLY when ALL the frames of ALL the filters are being processed ? (When everything is finished). This last seems the more logical, but i can't take it for granted.
Neither. Otherwise non-linear access wouldn't be possible, so there is not really a last frame. The deconstructor of a filter is called, when the filter is destroyed. This happens when ScriptEnvironment is destroyed and that happens when your script is closed.

[real.finder]

10/12/14 formats follow Microsofts VUV description for higher bit-depths (https://msdn.microsoft.com/en-us/library/windows/desktop/bb970578(v=vs.85).aspx), and store valid bits in the MSBs of the two bytes for each pixel.

These formats are not meant for processing in Avisynth, they just exist so that they can be output to (and be read from). So basically only conversion functions will have support for them.

If you mean that based on your testing, some 16bit and 10bit conversion functions have the same output, I think that is because the implementation is not yet finished and code is still missing to handle all cases. But pinterf can provide more insight in this matter than me. He's still in the middle of implementation, he only seems inactive recently because he's on holidays with his family.

so if we has a 10 bit source and work on it without convert it to 16 bit will get error message? or it will convert to 16 bit silently and get process and then convert to 10 bit silently again?

[MasterNobody]

10/12/14 formats follow Microsofts VUV description for higher bit-depths (https://msdn.microsoft.com/en-us/library/windows/desktop/bb970578(v=vs.85).aspx), and store valid bits in the MSBs of the two bytes for each pixel.
OK. So this formats differ from memory layout used for yuv 10-bit layout used by x264, ffmpeg and avs2yuv (yuv4mpeg extension). And so this apps should really ignore it and use them as 16-bit or refuse to accept it? Then I would need to change avs2yuv and x264 patch.

btw. what the point of this formats i.e. why not always mark them as 16-bit.

[qyot27]

The individual 10/12/14 pix_fmt constants (AVS_CS_YUV422P10, etc.) are there mostly to ease auto-selection with applications like FFmpeg so the user doesn't have to second-guess swscale/avutil. For example, AVS_CS_YUV422P10 is directly matched to AV_PIX_FMT_YUV422P10 in the libavformat AviSynth demuxer (http://ffmpeg.org/pipermail/ffmpeg-devel/2016-August/197888.html), and there's no need for the user to invoke -pix_fmt and override anything. That's what the intention was for those constants.

Also, because existing implementations (f3kdb*, Dither**) are capable of outputting those depths directly, so the reconstituted output is reported as the same depth, given to FFmpeg as the same depth, and processed there in the same depth.

*output_depth parameter
*Dither_quantize (http://avisynth.nl/index.php/Dither_tools#Dither_quantize)

[MasterNobody]

The individual 10/12/14 pix_fmt constants (AVS_CS_YUV422P10, etc.) are there mostly to ease auto-selection with applications like FFmpeg so the user doesn't have to second-guess swscale/avutil. For example, AVS_CS_YUV422P10 is directly matched to AV_PIX_FMT_YUV422P10 in the libavformat AviSynth demuxer (http://ffmpeg.org/pipermail/ffmpeg-devel/2016-August/197888.html), and there's no need for the user to invoke -pix_fmt and override anything. That's what the intention was for those constants.
Which doesn't conform to suggestion of Microsofts VUV description for higher bit-depths (https://msdn.microsoft.com/en-us/library/windows/desktop/bb970578(v=vs.85).aspx) because this are different formats that can't be directly mapped to current AV_PIX_FMT_*s.

[Wilbert]

Which doesn't conform to suggestion of Microsofts VUV description for higher bit-depths (https://msdn.microsoft.com/en-us/library/windows/desktop/bb970578(v=vs.85).aspx) because this are different formats that can't be directly mapped to current AV_PIX_FMT_*s.

Looks the same to me: https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/pixfmt.h


/**
* The following 12 formats have the disadvantage of needing 1 format for each bit depth.
* Notice that each 9/10 bits sample is stored in 16 bits with extra padding.
* If you want to support multiple bit depths, then using AV_PIX_FMT_YUV420P16* with the bpp stored separately is better.
*/
...
AV_PIX_FMT_YUV420P10BE,///< planar YUV 4:2:0, 15bpp, (1 Cr & Cb sample per 2x2 Y samples), big-endian
AV_PIX_FMT_YUV420P10LE,///< planar YUV 4:2:0, 15bpp, (1 Cr & Cb sample per 2x2 Y samples), little-endian

Stored as 16 bit with extra padding means stored as MSB.

[MasterNobody]

Looks the same to me: https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/pixfmt.h


/**
* The following 12 formats have the disadvantage of needing 1 format for each bit depth.
* Notice that each 9/10 bits sample is stored in 16 bits with extra padding.
* If you want to support multiple bit depths, then using AV_PIX_FMT_YUV420P16* with the bpp stored separately is better.
*/
...
AV_PIX_FMT_YUV420P10BE,///< planar YUV 4:2:0, 15bpp, (1 Cr & Cb sample per 2x2 Y samples), big-endian
AV_PIX_FMT_YUV420P10LE,///< planar YUV 4:2:0, 15bpp, (1 Cr & Cb sample per 2x2 Y samples), little-endian

Stored as 16 bit with extra padding means stored as MSB.
This comment doesn't say if padding is in MSB or LSB. You should look at AVComponentDescriptor definition (https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/pixdesc.h#L31) (especially at "shift" field which is 4-th field in struct):
/**
* Number of least significant bits that must be shifted away
* to get the value.
*/
int shift;
and than at real descrioption of AV_PIX_FMT_YUV420P10LE/AV_PIX_FMT_YUV420P10BE formats (https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/pixdesc.c#L1262):
[AV_PIX_FMT_YUV420P10LE] = {
.name = "yuv420p10le",
.nb_components = 3,
.log2_chroma_w = 1,
.log2_chroma_h = 1,
.comp = {
{ 0, 2, 0, 0, 10, 1, 9, 1 }, /* Y */
{ 1, 2, 0, 0, 10, 1, 9, 1 }, /* U */
{ 2, 2, 0, 0, 10, 1, 9, 1 }, /* V */
},
.flags = AV_PIX_FMT_FLAG_PLANAR,
},
[AV_PIX_FMT_YUV420P10BE] = {
.name = "yuv420p10be",
.nb_components = 3,
.log2_chroma_w = 1,
.log2_chroma_h = 1,
.comp = {
{ 0, 2, 0, 0, 10, 1, 9, 1 }, /* Y */
{ 1, 2, 0, 0, 10, 1, 9, 1 }, /* U */
{ 2, 2, 0, 0, 10, 1, 9, 1 }, /* V */
},
.flags = AV_PIX_FMT_FLAG_BE | AV_PIX_FMT_FLAG_PLANAR,
},
as you see all "shift" fields are 0 i.e. it means that value is in LSB and zero padding is in MSB.

[Wilbert]

You are right: plane = 0/1/2, step = 2 (2 bytes for a pixel), offset = 0, shift = 0, depth = 10 (and the last three members are deprecated).

That's confusing. So the layout is not conform the s274m standard (http://car.france3.mars.free.fr/HD/INA-%2026%20jan%2006/SMPTE%20normes%20et%20confs/s274m.pdf) where it is stored in the MSB:

7.7 Digital R', G', B', Y' components shall
be computed as follows:
L'd = int(219DC'+16D+0.5); D = 2^(n-8)
where L' is the component value in abstract terms
from zero to unity, n takes the value 8 or 10
corresponding to the number of bits to be represented,
and L'd is the resulting digital code.

7.8 Digital C'B and C'R components of the Y'C'BC'R
set shall be computed as follows:
C'd = int(224DC'+128D+0.5); D = 2^(n-8)
where C' is the component value in abstract terms
from -0.5 to +0.5 and C'd is the resulting digital code.

[shekh]

That's confusing. So the layout is not conform the s274m standard (http://car.france3.mars.free.fr/HD/INA-%2026%20jan%2006/SMPTE%20normes%20et%20confs/s274m.pdf) where it is stored in the MSB:

Is this manual relevant to image memory layout at all?

"NOTE -- This scaling places the extrema of R′, G′, B′, and
Y′components at codewords 64 and 940 in a ten-bit
representation"

[qyot27]

Considering the fact that the FFmpeg patch produces a correct image when the AV_PIX_FMT_* and corresponding AVS_CS_* constants are tethered together, either the formats are not different and there's a breakdown in the description(s) somewhere, or any differences between them are trivial and ultimately do not matter. The conversion routines inside AviSynth+ haven't been completely fleshed out*, but using the external plugins that can resample and scale bitdepth, the content can be reconstructed into a proper image.

*this is what I mean (all seen through opening the script in ffplay):
Version().ConvertToYV12().ConvertTo16bit() = correct image
Version().ConvertToYV12().ConvertTo16bit(bits=10) = hot pink and white incorrect image
Version().ConvertToYV12().f3kdb(output_depth=10,output_mode=2).ConvertFromDoubleWidth(10) = correct image
Version().ConvertToYV12().Dither_convert_8_to_16().Dither_quantize(10,reducerange=true).Dither_out().ConvertFromDoubleWidth(10)>test.avs = correct image

Also consistent with these results, is that using a value in ConvertFromDoubleWidth that does not match what the clip was scaled to in f3kdb or Dither results in an incorrect image.

[qyot27]

What's probably happening is that ConvertTo16bit() is just simply outputting the wrong depth/byte size/memory location for anything other than 16 - in other words, that particular filter has a bug/is still WIP and needs to be fixed for 10/12/14. The vi.BitsPerPixel values that the libavformat demuxer relies on are correctly sized for X bit depth and do report the right sizes.

[pinterf]

What's probably happening is that ConvertTo16bit() is just simply outputting the wrong depth/byte size/memory location for anything other than 16 - in other words, that particular filter has a bug/is still WIP and needs to be fixed for 10/12/14. The vi.BitsPerPixel values that the libavformat demuxer relies on are correctly sized for X bit depth and do report the right sizes.
Work in progress. 10-12-14 bit conversions only change the pixel format flag, there is a yet-not-implemented parameter that converts the range to real 10-12-14 bits. I focused only on implementing the existance of the new formats before I left for holiday two weeks ago. Next week I'm going to continue the work.

[Wilbert]

Is this manual relevant to image memory layout at all?

"NOTE -- This scaling places the extrema of R′, G′, B′, and
Y′components at codewords 64 and 940 in a ten-bit
representation"
You are right, it isn't. Should have seen that.

I'm a bit confused by this though. I was looking at the h.264 specs and didn't see anything about whether the padding should be stored in the msb or in the lsb part. Then again it is a 800 page document, so maybe i didn't look properly.

Do all decoders assume the padding is stored in the msb, or is that info stored in the bitstream somewhere (and the decoder has to read that info)?

[shekh]

I'm a bit confused by this though. I was looking at the h.264 specs and didn't see anything about whether the padding should be stored in the msb or in the lsb part. Then again it is a 800 page document, so maybe i didn't look properly.

Do all decoders assume the padding is stored in the msb, or is that info stored in the bitstream somewhere (and the decoder has to read that info)?

Hope someone educated can comment. My understanding is that decoder output is application specific / not part of bitstream specs.

[jpsdr]

Question : If an env->ThrowError is called by a filter object, but not inside his constructor, after (when filter instance is finished properly), during the process, in that case, the destructor of the object will be properly called ?

[ultim]

Question : If an env->ThrowError is called by a filter object, but not inside his constructor, after (when filter instance is finished properly), during the process, in that case, the destructor of the object will be properly called ?

Yes, a ThrowError will not prevent the destructor being called at a later time. The destructor is in general always called when the filter's reference count reaches zero, no matter if an error was thrown or not. It is of course possible that a filter's destructor will be called indirectly as an effect of a thrown error, due to stack unwinding and/or other cleanup logic, but otherwise there is no direct relation between the two events.

[burfadel]

With 2172 I am still having issues with the encode. This time it may just finish prematurely, without showing an error code etc. The end result is the video only being (for example) 75 percent encoded. It doesn't happen all the time though.

I am using LWLibavVideoSource (FFMS also fails so not the cause), yadifmod2, decimate, crop, deveed, tweak, smoothd2, adaptivemedian, colorYUV, shader, resize8, SuperResXBR, awarpsharp2, f3kdb, msharpen, repair. I did set MT mode for several filters, however I also disabled MT mode and there were still issues.

Yes, the filter combination may seem a bit strange but it's with purpose. The discussion isn't about what filters I am using in this particular script and whether you think it's necessary or not, it's about the fact that one of these is causing crashes. I did try whittling it down but couldn't come to a conclusion. In preview in Staxrip, if you move the slider back and forward enough with 2172 and a selection of filters, you may get it to crash. It even happened when I tried a whole lot less filters, but I don't think I tried eliminating all of them. I'm back on the older 2085 in the meantime.

In 2085 I can move the slider quickly back and forward, full-screen, then normal screen, add cut points, more moving the slider etc, something you wouldn't normally do in terms of the quickly moving the slider left and right etc, and no issues. This simply isn't the case in 2172.

[ultim]

This week and the next is somewhat stressful for me, with more than enough work, business-related traveling, and cross-border moving, so my contributions for one more week are limited to some basic forum lurking. Nevertheless, I do read posts, and if you look at the GitHub activity, you can see that others are actively working on polishing the new colorspace formats :)

@burfadel: Please, post script. I'm gonna look at it once my RL allows again. A list of filter names is not really useful.

[burfadel]

This week and the next is somewhat stressful for me, with more than enough work, business-related traveling, and cross-border moving, so my contributions for one more week are limited to some basic forum lurking. Nevertheless, I do read posts, and if you look at the GitHub activity, you can see that others are actively working on polishing the new colorspace formats :)

@burfadel: Please, post script. I'm gonna look at it once my RL allows again. A list of filter names is not really useful.

All good! I've actually changed the script a little since mentioning it this morning. I probably wasn't as tactful in my last post as I usually am (that is, more informative than semi-dictatorial). I guess that happens before 9 am on a Saturday! I didn't want to post my script simply because people would be wondering why I did it in such a way, but it works well for what I want it to do, whereas existing 'solutions' didn't.

Anyways, here it is:

LoadPlugin("H:\Stuff\Sharing Stuff\Codecs, Players\Staxrip64\Apps\Plugins\avs\aWarpSharp2\aWarpSharp.dll")
LoadPlugin("H:\Stuff\Sharing Stuff\Codecs, Players\Staxrip64\Apps\Plugins\avs\Decomb\Decomb.dll")
LoadPlugin("H:\Stuff\Sharing Stuff\Codecs, Players\Staxrip64\Apps\Plugins\both\ffms2\ffms2.dll")
LoadPlugin("H:\Stuff\Sharing Stuff\Codecs, Players\Staxrip64\Apps\Plugins\avs\flash3kyuu_deband\flash3kyuu_deband.dll")
LoadPlugin("H:\Stuff\Sharing Stuff\Codecs, Players\Staxrip64\Apps\Plugins\avs\FluxSmooth\FluxSmoothSSSE3.dll")
LoadPlugin("H:\Stuff\Sharing Stuff\Codecs, Players\Staxrip64\Apps\Plugins\avs\MSharpen\msharpen.dll")
LoadPlugin("H:\Stuff\Sharing Stuff\Codecs, Players\Staxrip64\Apps\Plugins\avs\RgTools\RgTools.dll")
LoadPlugin("H:\Stuff\Sharing Stuff\Codecs, Players\Staxrip64\Apps\Plugins\avs\vinverse\vinverse.dll")
LoadPlugin("H:\Stuff\Sharing Stuff\Codecs, Players\Staxrip64\Apps\Plugins\avs\yadifmod2\yadifmod2.dll")
FFVideoSource("D:\Scrubs\1\1-2\DVD-02\VTS_01\Titles\Scrubs 1x09.m2v", cachefile = "D:\Scrubs\1\1-2\DVD-02\VTS_01\Titles\\a\Scrubs 1x09.ffindex")
yadifmod2().decimate()
deblock_qed()
crop(4, 4, -4, -42)
deveed(ry=true,pry=10,nry=10,pgu=10,ngu=10,pbv=10,nbv=10,str=8)
crop(0, 16, -0, -0)
unproc=tweak(sat=1.03,cont=1.04)
proc=fluxsmootht(temporal_threshold = 8)
repair(proc,unproc)
vinverse2(sstr=3.5)
ColorYUV(gain_v=-4,gain_y=8,cont_v=3,cont_u=5,off_u=1,cont_y=8,gamma_y=16)
input = ConvertToShader()
Shader("hdr.hlsl")
Shader("vibrance.hlsl")
last.ExecuteShader(input)
ConvertFromShader(format="yv12")
SuperResXBR(4, 0.65, xbrStr=2.5, xbrSharp=0.9,fwidth=864,fheight=480,fkernel="ssim")
awarpsharp2(depth=7,thresh=75)
msharpen(threshold=3,strength=30)
f3kdb(dither_algo=3,grainc=96,grainy=195,cb=38,cr=38,y=38)
Prefetch(4)

To others, remember the discussion is about issues with 2172, not whether you agree with my script or not for this particular set of batch encodes :).

EDIT: I was doing some testing with avsmeter64, I didn't realise that you could just whack prefetch(4) on the end of the script without calling the MT mode and have it work without any mention to the MT mode at the top of the script. I guess when doing this it relies on the plugin's setting for MT, if present? In any case, just whacking prefetch(4) on the end of the script without any other MT stuff seemed to yield the same performance for me as putting SetFilterMTMode("DEFAULT_MT_MODE", 2) at the top of the script. It seems to work fine so I'll use that. In build 2172 the problem is there regardless of MT settings. Even if I remove MT stuff entirely from the script including prefetch(4) at the end, if I run avsmeter64 enough times on it, it will still crash. I was using a frame range of 2000 frames for testing.

It's also not the code that I am using now to encode, it was just mucking around with a whole heap of different things.

In any case, I found by making the script 'single threaded' by not stating prefetch makes it perfecly stable even with 2172. Yes, in avsmeter64 it is much slower, but it hasn't affected my encode speed at all. I should point out the script I'm actually using is a fair bit more complex than that one, and it still works perfectly in 2172 without MT. Seems anytime I MT 2172 it doesn't like it, and I also came across very much less frequent but still have crashes in 2043 as well. By the time x265 with decent settings (with the addition of --amp primarily, from what I mentioned another thread) is done, I guess any slowdown in the script in terms of feeding the output doesn't matter in this case. Having the encoding in the high teen's considering, is quite okay for me in this case.

[jpsdr]

I have (for a change...) some questions. :p

This is, rough extracted, a part of the code of nnedi3 :

PVideoFrame __stdcall nnedi3::GetFrame(int n, IScriptEnvironment *env)
{
...
copyPad(field>1?(n>>1):n,field_n,env);
...
}

void nnedi3::copyPad(int n, int fn, IScriptEnvironment *env)
{
const int off = 1-fn;
PVideoFrame src = child->GetFrame(n, env);

... after src is only used in stuff like this :

for (int b=0; b<3; ++b)
env->BitBlt(srcPF->GetPtr(b)+srcPF->GetPitch(b)*(6+off)+32,
srcPF->GetPitch(b)*2,
src->GetReadPtr(plane[b])+src->GetPitch(plane[b])*off,
src->GetPitch(plane[b])*2,src->GetRowSize(plane[b]),
src->GetHeight(plane[b])>>1);

...
}


So, the thing i'm having big trouble with is the PVideoFrame src = child->GetFrame(n, env);, which create some kind of recursive call.
What exactly this is doing, compared to the GetFrame it's comming from ? I don't think this is realy a true recursive call, otherwise there should be no end to it.
Is there a way to avoid this GetFrame call ? By for exemple adding a parameter to the copyPad function and getting what it needs directly from data avaible from the GetFrame calling copyPad ?

[Wilbert]

PVideoFrame InvertNeg::GetFrame(int n, IScriptEnvironment* env) {

This method is called to make your filter produce frame n of its output.

int m = field>1 ? 2*n : n;
PVideoFrame src = child->GetFrame(m, env);
...

I changed the code a bit (for better readability, but the functionality is the same).
For creating the output frame n, it requests and copies a part of the input frame n (for field > 1) to srcPF, or 2*n (for field = 0,1; so the odd frames are never used??; i guess this is for field-based material where the input frames is twice the number of output frames).

See for example http://avisynth.nl/index.php/Filter_SDK/InvertNeg and http://avisynth.nl/index.php/Filter_SDK

When modifying a filter, i surely hope you know what the filter exactly does ...

[Gavino]

So, the thing i'm having big trouble with is the PVideoFrame src = child->GetFrame(n, env);, which create some kind of recursive call.
What exactly this is doing, compared to the GetFrame it's comming from ? I don't think this is realy a true recursive call, otherwise there should be no end to it.
child->GetFrame() gets a frame from the previous filter in the chain, ie the source clip to nnedi3.
There's no recursion as the GetFrame() is being called on a different object, not on 'this'.

Almost all filters will include a call to child->GetFrame(), either in their own GetFrame() or (as here) in a function called from there.

[jpsdr]

child->GetFrame() gets a frame from the previous filter in the chain, ie the source clip to nnedi3.
Ok... With this, everything is clear, and i understand now the issue i had...

Edit
Stupid me..!!!
Often (but not all the time obviously), it looks more like this :

PVideoFrame __stdcall Whatereverfilter::GetFrame(int n, IScriptEnvironment* env)
{
PVideoFrame src = child->GetFrame(n,env);
PVideoFrame dst = env->NewVideoFrame(vi);


So, when this was put in a function called a little later, i thought it was doing something different than the standard way... I didn't realised it wasn't indeed not done yet...
Really, sometimes when you're focussing on an issue, you don't see the pink elephant in front of you...

[tormento]

I have tried to convert an animated GIF into AviSynth script using:

ImageSourceAnim("E:\in\CoprimiTutto.gif")

Problem is it is 529 MB and script simply hangs.

Any idea?

[Wilbert]

Could you upload the image somewhere?

[tormento]

Could you upload the image somewhere?


Do you know a file hosting that let you download such a big file without being premium?

[LigH]

Try MediaFire. You could pack it in an archive, compression won't be important, just to camouflage the extension so that downloading will be preferred over displaying.

[ChaosKing]

or MEGA. 50gb free and it's very fast.

[Groucho2004]

Problem is it is 529 MB and script simply hangs.

Any idea?
What do you use to load/run the script? Are you sure it hangs and is not silently running without progress indication?

[tormento]

What do you use to load/run the script? Are you sure it hangs and is not silently running without progress indication?


VirtualDub for preview and x264 Launcher for encoding.

[tormento]

or MEGA. 50gb free and it's very fast.

https://mega.nz/#!dxowVRCR!j5OaMcXwt3s174UHjVKcOfB-Y4DfcRXapah-UKQJlP0

[qyot27]

It's been weighing on my mind lately, because I really have no clue how this part works (mostly because I end up worrying about how to properly set up a Wine64 testing environment).

How does AviSynth+ keep the 64-bit and 32-bit plugin loading sufficiently separate so that it doesn't cause errors when being opened in other programs? I mean, the ability to specify multiple directories doesn't seem to discriminate between directories for 32-bit plugins and directories for 64-bit plugins, so does the 32-bit or 64-bit AviSynth.dll just simply ignore plugins with the wrong bittage if they were placed in the 'wrong' directory? An example would be placing a 64-bit plugin in plugins or plugins+ rather than plugins64 or plugins64+ (or vice-versa). How exactly does it know whether a given plugin .dll is the correct 32/64-bit type needed by the 32/64-bit core? Or is it Windows itself that makes the determination?

[AzraelNewtype]

Use lwlibavsource() from lsmashsource. It'll probably still hang for a bit as it indexes, but then it'll be fine. Probably. I mean, I just did it to a 1mb gif, because I'm not an insane person who has >500mb gifs, but as a proof of concept it seems sound?

This may not play nicely with non-linear access, so you should honestly just render it out to a lossless sane video format first, then do any real processing on that.

[qyot27]

Also, it would appear that VS2015 builds work with Wine 1.9.17 now, if msvcp140.dll is specifically overridden to native,builtin in winecfg and the VS2015 redist is installed. The only issue is, that version of Wine is still -devel, so it may not be a good idea yet to rely on (and if we want a 'just works' solution there before dropping VS2013, it probably shouldn't require overrides or installing the redist package).

[Groucho2004]

How exactly does it know whether a given plugin .dll is the correct 32/64-bit type needed by the 32/64-bit core? Or is it Windows itself that makes the determination?
I have not looked at the current code but as far as I remember it works like this:

Avisynth simply throws "there is no function..." if a DLL with the wrong bittage is in the auto-load directory and a function from that DLL is called.

If loading that DLL explicitly through LoadPlugin(), this happens:
Cannot load file 'f:/TNLMeans64.dll'. Platform returned code 193:
%1 is not a valid Win32 application.

I'm not sure why the '%1' placeholder is not filled with the module name.

I'm thinking that a bit more pre-parsing of the plugins could lead to less ambiguous error messages. This can be done with "MapAndLoad()" and evaluating the "LOADED_IMAGE" structure. "MapAndLoad()" can load 64 bit DLLs from a 32 bit client and vice versa.

[tormento]

Use lwlibavsource() from lsmashsource.
The AVS script, very simple one, works in VirtualDub and not in Simple x264 Launcher.

AVS script:

SetMemoryMax(8000)
LoadPlugin("D:\Programmi\media\AviSynth+\plugins64\LSMASHSource-903_20160815.dll")
LWLibavVideoSource("E:\in\CoprimiTutto.gif")


Complete log:

Simple x264 Launcher (Build #1038), built 2016-07-18

Job started at 2016-08-29, 12:25:17.

Source file : E:\in\CoprimiTutto.avs
Output file : E:\in\CoprimiTutto.mkv

--- SYSTEMINFO ---

Binary Path : D:\eseguibili\media\x264 launcher
Avisynth : Yes
VapourSynth : No

--- SETTINGS ---

Encoder : x264 (AVC/H.264), 64-Bit (x64), 8-Bit
Source : Avisynth (avs)
RC Mode : CRF
Preset : slow
Tuning : <None>
Profile : High
Custom : --level 4.1 --keyint 240 --vbv-bufsize 78125 --vbv-maxrate 62500 --aq-mode 2 --sar 1:1

--- CHECK VERSION ---

Detect video encoder version:

Creating process:
"D:\eseguibili\media\x264 launcher\toolset\x64\x264_8bit_x64.exe" --version

x264 0.148.2705kMod 3f5ed56
(libswscale 4.1.100)
(libavformat 57.40.101)
(ffmpegsource 2.22.0.1)
built by Komisar on Jun 26 2016, gcc: 4.9.2 (multilib.generic.Komisar)
x264 configuration: --bit-depth=8 --chroma-format=all
libx264 configuration: --bit-depth=8 --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later

Detect video source version:

Creating process:
"D:\eseguibili\media\x264 launcher\toolset\x64\avs2yuv_x64.exe"

Avs2YUV 0.24bm3

> x264 revision: 2705 (core #148) - with custom patches!
> Avs2YUV version: 0.24.3

--- GET SOURCE INFO ---

Creating process:
"D:\eseguibili\media\x264 launcher\toolset\x64\avs2yuv_x64.exe" -frames 1 E:\in\coprimitutto.avs NUL

error: Cannot load file 'D:/Programmi/media/AviSynth+/plugins64/LSMASHSource-903_20160815.dll'. Platform returned code 127:
Impossibile trovare la procedura specificata.
(E:\in\coprimitutto.avs, line 17)

PROCESS EXITED WITH ERROR CODE: 1

[AzraelNewtype]

Then don't use Simple X264 Launcher? Render it out with some vfw lossless right in VDub like UTVideo and never, ever touch the gif again. Deal with final usable video after you stop using an insane source.

[Groucho2004]

SetMemoryMax(8000)
:confused:

[Clip info]
Number of frames: 434
Length (hh:mm:ss.ms): 00:00:52.080
Frame width: 1920
Frame height: 1080
Framerate: 8.333 (25/3)
Colorspace: RGB32


[Runtime info]
Frames processed: 434 (0 - 433)
FPS (min | max | average): 1.109 | 25.15 | 23.22
Memory usage (phys | virt): 47 | 50 MiB
Thread count: 7
CPU usage (average): 49%

Time (elapsed): 00:00:18.694


[Script]
LWLibavVideoSource("CoprimiTutto.gif")

[Groucho2004]

Deal with final usable video after you stop using an insane source.There's nothing special about the source, just a simple animated gif.

[Reel.Deel]

SetMemoryMax(8000)



:confused:

I wonder how much of the following statement still applies to to AVS+?

Where are people getting the crazy idea that a big SetMemoryMax is ever a good idea.

I have searched the forum numerous times looking for any fud and misinformational posts and I do not find any, all I find are the occasional post advising to turn it down. and lots of posts with people using insanely high values and having problems.

SetMemoryMax just sets the size of the Avisynth frame cache!

It does not control any other memory usage!

The frame cache only needs to be just large enough to hold the temporal requirements of the script. If a script has no temporal requirements, i.e. a frame that is required more than once in some part of the script then the cache is completely useless and may prevent some other memory usage from being able to malloc the memory that it needs to work.

A 1920x1080 YV12 video frame is ~3meg, as RGB32 it is 8meg, you can hold 64 such frames in 512meg. YV12 720x480 frames are only 0.5meg you can hold 1024 in 512 meg.

It takes some resources to manage the frame cache so doing a SetMemoryMax(2048) for a SD video and having 4000 odd buffers in play is just stupid and will actually slow the script processing down a little bit.

Advise :- SetMemoryMax, Turn it down!

[AzraelNewtype]

There's nothing special about the source, just a simple animated gif.

There is nothing ordinary about a nearly CD sized animated gif.

[Groucho2004]

There is nothing ordinary about a nearly CD sized animated gif.
CDs - a sweet memory from simpler times.

[tormento]

Render it out with some vfw lossless right in VDub like UTVide
It did its dirty job.

I hoped there was some glitch in AviSynth+ to fix about image import ;)

[TheFluff]

I see AviSynth+ is based on the memory allocation code of legacy AviSynth and should have the same problems as legacy AviSynth and AviSynth MT.

I'm pretty sure it's been substantially rewritten in the last few years but since I don't actually use it nor code on it I'll leave it to others to sort you out.

Also, how about you migrate to x64 to process your gigantic video frames without worrying about the antique memory limit?

[Groucho2004]

I wonder how much of the following statement still applies to to AVS+?
I ran the same script with SetMemoryMax(1500), no change in memory consumption or speed, no matter if AVS+ or classic 2.6.

[Motenai Yoda]

I ran the same script with SetMemoryMax(1500), no change in memory consumption or speed, no matter if AVS+ or classic 2.6.

classic 2.6 will crash if it go over 2GB (easy with many threads and some ram hugry stuff), avs+ can handle up to 3.5

[Groucho2004]

classic 2.6 will crash if it go over 2GB (easy with many threads and some ram hugry stuff), avs+ can handle up to 3.5Could you elaborate on "go over 2GB", "handle up to 3.5" and especially "many threads" with classic 2.6? Are you talking about SetMemoryMax()? 32 bit or 64 bit? Process memory available to Avisynth?

I can't decipher your statement.

[tormento]

Also, how about you migrate to x64 to process your gigantic video frames without worrying about the antique memory limit?

I am already on x64 encoding ambient. Never had idea of which value put there, if any use.

[Groucho2004]

I am already on x64 encoding ambient. Never had idea of which value put there, if any use.
I just found it odd that you put such a high value considering the low memory requirements of that particular script.
You may have to increase the default (512 MB) if you have a script with a large temporal range but you would test with small increments, 256 ~ 512.

[TheFluff]

I am already on x64 encoding ambient. Never had idea of which value put there, if any use.

I was talking to rean, who insists on 32-bit. No offense intended (to you).

[Groucho2004]

Also, how about you migrate to x64 to process your gigantic video frames without worrying about the antique memory limit?
---->
X64 build is not possible, because AviSynth includes assembler code that does not compatible with a x64 compiler.

[TheFluff]

Oh dear, such an insurmountable problem... I sure wish someone would do something about it.

[tormento]

I just found it odd that you put such a high value considering the low memory requirements of that particular script.

You may have to increase the default (512 MB) if you have a script with a large temporal range but you would test with small increments, 256 ~ 512.



It comes from my SMDegrain 6 frames span script + KNLMeans.

No idea of how AviSynth+ x64 deals with memory. I have plenty of it. I read that too much SetMemory could be negative too but it referred to old AviSynth. If any of the active devolver could clarify this aspect, would be very useful.

[shekh]

Tried to wrap VD filter through avs with avsplus-r1858-pfmod


Avisynth open failure:
rgb_levels has an invalid parameter string (bug in filter)


the script:

AviSource("E:\vd_dev\data\cfhd-high.avi")
LoadPlugin("E:\vd_dev\vd\VDubFilter.dll")
LoadVirtualdubplugin("E:\vd_dev\vd\plugins32\rgb_levels.vdf", "rgb_levels")


filter (nothing really special): https://sourceforge.net/projects/vdfiltermod/files/plugins/rgb%20levels/version%202/

arg_list from filter definition: "ddddddddd" (9 floats)

What`s wrong?

[ultim]

The memory and cache management in Avs+ is completely different from Avs 2.6. It has been redesigned and rewritten from scratch, though I was uncomfortably constrained by the existing API which resulted in half-assed code for memory reclamation in some (hopefully not too common) cases. Anyway, the caches in Avs+ are highly adaptive and self-learning, and do not use any caching hints like 2.6 in general to perform their jobs well. Also, as long as there is enough memory to satisfy all memory requests, even uncapped caches should not cause significant slowdowns, because caches will only grow if needed, not as long as there is free memory.

The default setting to SetMemoryMax() can be up to 1GB in Avs+, but may be lower depending on your amount of RAM. I know in earlier Avs 2.6 alpha/2.5 it was necessary to keep SetMemoryMax() low because if too high it resulted in funny caching behavior, leaving users with phenomena like slowdowns and/or unreasonably high memory usage. Avs+ should not suffer from anything like that, and SetMemoryMax() really just sets an (approximate) upper cap. If your script does not need that much memory though, a high upper limit (even if too high) does zero harm. In Avs+, the only use of constraining memory is to prevent paging. The justification is that often it is faster to recompute frames than to trash your rotational paging HDD (ofc if you have an SSD you'll have to reevaluate this claim). Another (similar) justification is, even if you had enough RAM, encodes often take many hours and sometimes even days, and if you want to keep using your computer in the background without hitting the paging limit, you might want to constrain the memory consumption of the encoding process.

But this is all TL;DR. The important takeaway is that in Avs+, a high SetMemoryMax() only hurts if otherwise your script causes excessive paging to a slow hard disk. Pro tipp: If you enable logging in Avs+, it will automatically notify you if you can speed up your script by setting your SetMemoryMax() higher ;) Edit: The optimal setting of SetMemoryMax() in Avs+ is anywhere in the range where it is higher than what your script wants to use, but lower than the value where it would cause paging. This range is often very broad, so only those will have trouble setting it who have either low RAM, or extremely hungry scripts. This is just a "rule of thumb" though, and its applicability will depend on your script and hardware.

[TheFluff]

Speaking of which, does Avs+ reuse framebuffers like the OG Avisynth does?

[ultim]

Speaking of which, does Avs+ reuse framebuffers like the OG Avisynth does?

Depends. Probably. Dunno what you mean exactly by "reuse".

[ultim]

I see AviSynth+ is based on the memory allocation code of legacy AviSynth...
Nope, not at all. See above.

[TheFluff]

Depends. Probably. Dunno what you mean exactly by "reuse".

(this is from memory, might be completely wrong)
OG Avisynth refcounted vfb's and when the refcount reached zero, instead of freeing the buffer it was kept around and a subsequent call to NewVideoFrame for a suitably sized frame could use that buffer instead of allocating a new one.

I'm asking because as far as I know VS didn't bother with this and I seem to remember Myrsloik stating that simple free/new malloc for "small buffers" worked "well enough". I'm curious how much the buffer reuse technique helps, especially for larger video frame sizes.

[ultim]

(this is from memory, might be completely wrong)
OG Avisynth refcounted vfb's and when the refcount reached zero, instead of freeing the buffer it was kept around and a subsequent call to NewVideoFrame for a suitably sized frame could use that buffer instead of allocating a new one.

I'm asking because as far as I know VS didn't bother with this and I seem to remember Myrsloik stating that simple free/new malloc for "small buffers" worked "well enough". I'm curious how much the buffer reuse technique helps, especially for larger video frame sizes.

Yes that technique is still there, and admittedly I intend to keep it around. Not because of some speed argument, but because it improves reliability. Simply put, it prevents memory fluctuation. It ensures that once Avs+ allocated a buffer, the same size can be allocated again after the previous instance is dereferenced. If Avs+ was to free each buffer whose refcount falls to zero, there'd be a chance that due to some other thread or application also allocating memory, Avisynth wouldn't be able to get a new buffer anymore, even though its total memory consumption didn't increase. This means without this technique there is a higher chance that your encode goes OutOfMemory in the middle, only because some other process or application thread had a sudden (maybe even temporary) memory spike.

[Groucho2004]

Yes that technique is still there, and admittedly I intend to keep it around. Not because of some speed argument, but because it improves reliability. Simply put, it prevents memory fluctuation. It ensures that once Avs+ allocated a buffer, the same size can be allocated again after the previous instance is dereferenced. If Avs+ was to free each buffer whose refcount falls to zero, there'd be a chance that due to some other thread or application also allocating memory, Avisynth wouldn't be able to get a new buffer anymore, even though its total memory consumption didn't increase. This means without this technique there is a higher chance that your encode goes OutOfMemory in the middle, only because some other process or application thread had a sudden (maybe even temporary) memory spike.
Thank you for that insight.

[bilditup1]

Moving from r1858_pfmod to r2172, I've been getting the following error when attempting to preview a fairly simply script in AvsPmod:
"Only a single prefetcher is allowed per script." (path_to_script.avs, line 13)
This is the script, which isn't particularly complex:

Import("C:\blu\MeGUI\tools\avisynth_plugin\reel.deel\mt_modes_latest.avsi")
LoadPlugin("C:\blu\MeGUI\tools\dgindex\DGDecode.dll")
LoadPlugin("C:\blu\MeGUI\tools\avisynth_plugin\jpsdr\x86\Release_Intel_W7_Core2_SSE4.2\nnedi3.dll")
LoadPlugin("C:\blu\MeGUI\tools\avisynth_plugin\tp7\RgTools.dll")
LoadPlugin("C:\blu\MeGUI\tools\avisynth_plugin\tp7\MaskTools2.dll")
LoadPlugin("C:\blu\MeGUI\tools\avisynth_plugin\pinterf\MvTools2.7.0.22d.dll")
Import("C:\blu\MeGUI\tools\avisynth_plugin\real_finder\QTGMC.avsi")
DGDecode_mpeg2source("d2v-path-here") # 1080i30 mpeg2 src
AssumeBFF()
QTGMC(Preset="Fast", ShowSettings=False)
Spline36Resize(1280,720)
Trim(0,3000)
Prefetch(4)

I checked the scripts I was importing - reel.deel's mt modes list and QTGMC - but Prefetch() is never called in them.
This error message must be a recent change, as in r2161, AvsPmod just crashes entirely, and when attempting to encode, the thread simply stalls and makes no progress (the same thing).
Removing the Prefetch call allows the script to be processed, in both r2161 and r2172, but I don't think mt is invoked, as it runs at st speeds (6.5fps vs 8.91).
I thought this was a problem with jpsdr's nnedi3, which I had to update to r25/r26 from r22 in order to avoid a memory violation with these new releases. But I reduced to script to merely this:

LoadPlugin("C:\blu\MeGUI\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("d2v-path-here") # 1080i30 mpeg2 src
Prefetch(4)

And still get the same error. Is this somehow a quirk of dgdecode? Is mt broken? Is it enabled differently now? Or is something else at work here?

ED: It is in fact DGDecode.dll. Using DGDecodeIM.dll and a dgi instead did not present this error - not only that but the encode goes some 50% faster (from 9 to 13.5 fps) than the original script did under r1858_pfmod and DGDecode (though the first time I tried it, it quit after one frame with a typical memory access error.)
Does anybody know what's going on with DGDecode? I guess it could be considered legacy software by now, and presume that maintaining compatibility with it probably is not a priority, but this strikes me as odd behavior all the same.

ED2: Part of the higher speed and memory access errors I had been experiencing appears to be because I had erroneously switched to using the XP compatible build of nnedi3. The W7_SSE4.2 build still goes faster than before but less dramatically (12fps instead of 13.5fps, and trying the XP build again just now I only managed to reach 12.6fps, weirdly), and you pay for it with the danger of a memory problem. I've also experienced what I believe are memory issues when using nnedi3 with jpsdr's ResampleMT (latest) - iow encode just stops in the middle but without quitting or throwing an error, just sticks at a certain frame - though not consistently: when it does work then it brings the speed back up to 13.5 even whilst using the W7_SSE4.2 builds of both it and nnedi3. (Will also post about it in jpsdr's threads, I suppose, if someone hasn't already pointed this out.)

ED3: Groucho2004's build of DGDecode has the same problem as neuron2's.

[ultim]

Moving from r1858_pfmod to r2172, I've been getting the following error when attempting to preview a fairly simply script in AvsPmod:
"Only a single prefetcher is allowed per script." (path_to_script.avs, line 13)

This should be a regression in Avs+ in the recent build. I'll take care of it by the weekend.

[bilditup1]

This should be a regression in Avs+ in the recent build. I'll take care of it by the weekend.

Wow, thanks for quick reply. Looking fwd to fix. Unfortch I've just discovered that TDecimate does not work with MT enabled, whether using tritical's original TIVTC.dll or groucho2004's build. Works fine in r1858_pfmod, quits with "internal error during prebuffering!" in r2085, r2161, r2172.

[tormento]

The default setting to SetMemoryMax() can be up to 1GB in Avs+
So, having 16+ GB of RAM and a x64 environment, which is the maximum value we can set?

Is it of any use or we can write scripts without allocating memory?

[Groucho2004]

I've been getting the following error when attempting to preview a fairly simply script in AvsPmod:
...
This is the script, which isn't particularly complex:

Import("C:\blu\MeGUI\tools\avisynth_plugin\reel.deel\mt_modes_latest.avsi")
LoadPlugin("C:\blu\MeGUI\tools\dgindex\DGDecode.dll")
LoadPlugin("C:\blu\MeGUI\tools\avisynth_plugin\jpsdr\x86\Release_Intel_W7_Core2_SSE4.2\nnedi3.dll")
LoadPlugin("C:\blu\MeGUI\tools\avisynth_plugin\tp7\RgTools.dll")
LoadPlugin("C:\blu\MeGUI\tools\avisynth_plugin\tp7\MaskTools2.dll")
LoadPlugin("C:\blu\MeGUI\tools\avisynth_plugin\pinterf\MvTools2.7.0.22d.dll")
Import("C:\blu\MeGUI\tools\avisynth_plugin\real_finder\QTGMC.avsi")
DGDecode_mpeg2source("d2v-path-here") # 1080i30 mpeg2 src
AssumeBFF()
QTGMC(Preset="Fast", ShowSettings=False)
Spline36Resize(1280,720)
Trim(0,3000)
Prefetch(4)

The script is far from simple, have a look at the content of qtgmc.avsi. As for your stability problems (aside from a AVS+ issue), see also here (http://forum.doom9.org/showthread.php?p=1779384#post1779384).

[shekh]

Tried to wrap VD filter through avs with avsplus-r1858-pfmod

Avisynth open failure:
rgb_levels has an invalid parameter string (bug in filter)
...


same with 2172

[burfadel]

Ultim, I hope I wasn't 'out-of-line' PM'ing you earlier with the script sample, I just wanted to avoid stoking the fire of the other threads regarding upsampling, changing resolutions etc., seeing as the script did involve some manipulation in that regard. I hope that it does prove useful though in what I mentioend regarding single thread and multithreaded modes etc, and also how it can run quite fast.

Is my assumption wrong in that any script either becomes all multithreaded on the avisynth side, even with MT mode 3 on the plugins, or single threaded on the Avisynth side when prefetch is not stated, but still multithreaded invidividual plugins if the plugins are multithreaded? If the former isn't right, it does seem to exhibit that behaviour.

[bilditup1]

The script is far from simple, have a look at the content of qtgmc.avsi.

Yes, I'm aware that QTGMC itself is complex. I meant that my snippet was legible, straightforward and didn't have much of my own more-likely-to-be-faulty logic in it. In any case, QTGMC's presence was ultimately irrelevant.

[Wilbert]

https://mega.nz/#!dxowVRCR!j5OaMcXwt3s174UHjVKcOfB-Y4DfcRXapah-UKQJlP0
What Groucho2004 said. You have to be patience. I imported your script in Virtualdub and compressed it to Xvid but it took me 10 hours on my slow laptop (2.2 GHz). I used plain AviSynth though, but that probably doesn't matter. Btw, it consists of 324 images (iirc).

[Groucho2004]

Btw, it consists of 324 images (iirc).Should be 434 (http://forum.doom9.org/showthread.php?p=1779098#post1779098).

[qyot27]

There is nothing ordinary about a nearly CD sized animated gif.
I've noticed this happening on image hosting sites that offer a gif version and a webm version of whatever the animated image sequence is. The gifs in those cases are sometimes outlandishly sized, because I assume what's going on is the image host offers the ability to upload video, so the user uploads a video file, and then the image host compresses it to webm and to gif. But the gif's resolution hasn't been reduced, so you end up with ridiculous 1920x1080 animated gifs alongside a smaller, higher quality normal video file.

I keep asking myself what the use case of that could possibly be vs just using a video host, but I've never come up with a satisfactory answer. Because even meme sites like these gif posts probably are intended for should really have no issues embedding video files in 2016, and if your computer is so old that it can't decode one of those VP8 or VP9 webm files, is your browser going to somehow not choke on a 1080p gif?

[Wilbert]

Should be 434 (http://forum.doom9.org/showthread.php?p=1779098#post1779098).
Yup, my encoding has 434 frames. Should have checked before recalling from my bad memory ;)

[gaak]

Hi,

In trying AVISynth+ r2085 i386 in MT mode with this script on a 1080p source:

SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("DGSource", 3)
LoadPlugin("C:\MKVideo Encoder NV\DGDecNV\DGDecodeNV.dll")
DGSource("C:\MKVideo Files\Input_Video_File.dgi")
Spline144Resize(1280, 720)
RoboCrop(Laced=False)
LSFmod(defaults="slow", preblur="DeGrainMedian(limitY=4, limitUV=6, mode=1, interlaced=false)")
FineDehalo(rx=2.0, ry=2.0, thmi=80, thma=128, thlimi=50, thlima=100, darkstr=1.0, brightstr=1.0, showmask=0, contra=0.0, excl=true)
src=last
dr=src.RemoveGrain(4, 2)
src.HQDeringmod(dr, drrep=13, sharp=1, thr=14.0, darkthr=0, Y=3, U=3, V=3)
return(last)
Prefetch(8)

I get the same results (about 6 fps on an i7 930) if I run in single thread mode. What am I doing wrong?

[Groucho2004]

Hi,

In trying AVISynth+ r2085 i386 in MT mode with this script on a 1080p source:

SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("DGSource", 3)
LoadPlugin("C:\MKVideo Encoder NV\DGDecNV\DGDecodeNV.dll")
DGSource("C:\MKVideo Files\Input_Video_File.dgi")
Spline144Resize(1280, 720)
RoboCrop(Laced=False)
LSFmod(defaults="slow", preblur="DeGrainMedian(limitY=4, limitUV=6, mode=1, interlaced=false)")
FineDehalo(rx=2.0, ry=2.0, thmi=80, thma=128, thlimi=50, thlima=100, darkstr=1.0, brightstr=1.0, showmask=0, contra=0.0, excl=true)
src=last
dr=src.RemoveGrain(4, 2)
src.HQDeringmod(dr, drrep=13, sharp=1, thr=14.0, darkthr=0, Y=3, U=3, V=3)
return(last)
Prefetch(8)

I get the same results (about 6 fps on an i7 930) if I run in single thread mode. What am I doing wrong?
Remove "return last" or move it to the end of the script. Prefetch never gets called.

[gaak]

Remove "return last" or move it to the end of the script. Prefetch never gets called.

Thanks!

[Groucho2004]

I imported your script in Virtualdub and compressed it to Xvid but it took me 10 hours on my slow laptop (2.2 GHz).I just tried the same with Xvid 1.22 and it took 30 seconds. Even on my really ancient laptop it takes only 2 or 3 minutes. Your 10 hours are bizarre.

[Groucho2004]

Min. installer (w/o MS runtimes) for the latest build (r2172) (https://www.dropbox.com/s/aqlcgzdsh76akki/AviSynth%2B%20r2172.7z?dl=0)
Latest All-In-One runtimes (if needed) (http://repacks.net/forum/viewtopic.php?f=6&t=125)

[Wilbert]

Which doesn't conform to suggestion of Microsofts VUV description for higher bit-depths (https://msdn.microsoft.com/en-us/library/windows/desktop/bb970578(v=vs.85).aspx) because this are different formats that can't be directly mapped to current AV_PIX_FMT_*s.
Some news. The layout of this P010 format is planar luma with packed chroma (see description in the link above, i missed that earlier on). It is actually supported in ffmpeg with the flag AV_PIX_FMT_P010LE:

P010 is the 10-bit variant of NV12 (planar luma, packed chroma), using two bytes per component to store 10-bit data plus 6-bit zeroes in the LSBs.
See https://patches.libav.org/patch/60979/ and https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/pixdesc.c#L2015. There is no 12/14 bit analog of this format. So it makes sense not to use that in AviSynth.

[qyot27]

Some news. The layout of this P010 format is planar luma with packed chroma (see description in the link above, i missed that earlier on). It is actually supported in ffmpeg with the flag AV_PIX_FMT_P010LE:


See https://patches.libav.org/patch/60979/ and https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/pixdesc.c#L2015. There is no 12/14 bit analog of this format. So it makes sense not to use that in AviSynth.
Huh? We're not using P010, so the lack of 12- or 14- bit variants of it doesn't matter. The 10-bit formats we're using are the all-planar ones: YUV(A)***P10, GBR(A)P10. Or YUV(A)***P12/14, GBR(A)P12/14, respectively. To my understanding, P010 is mostly a format used by graphics cards and screen output types of jobs, not one that should be getting used for practically anything else. It's like NV12/NV21.

And the patch to add the new pix_fmts to FFmpeg's AviSynth demuxer was already committed close to a week ago. (http://git.videolan.org/?p=ffmpeg.git;a=blobdiff;f=libavformat/avisynth.c;h=1fe8e083be552f2d3efcce6821d0982f6a5ae3d7;hp=04ac2576cc68c14e31d9a8f114aff7490e4719f4;hb=92916e8542e425ca20daddb490261a5818643206;hpb=ac028794ad702375c27143bd86d459534ef6fc2f) The planar RGB formats and ConvertTo16bit's 10/12/14 conversions don't quite work yet; you need the pull request that pinterf is currently working on (https://github.com/AviSynth/AviSynthPlus/pull/101) for those to be fixed on our side, plus another patch that's on the FFmpeg-devel mailing list (http://ffmpeg.org/pipermail/ffmpeg-devel/2016-August/198570.html) to make sure the Planar RGB formats are output correctly.

Zeranoe's FFmpeg-git builds (https://ffmpeg.zeranoe.com/builds/) should work with them just fine now, with the caveats I mentioned above. However, you can get proper 10/12/14 YUV output if you use f3kdb or Dither to scale them up and then ConvertFromDoubleWidth/Stacked. The alpha-enabled formats and Planar RGB were a deeper issue that had to be resolved by exposing them through the C interface first (r2172 doesn't do that yet, that's why the pull request's changes are needed).

[Wilbert]

Huh? We're not using P010, so the lack of 12- or 14- bit variants of it doesn't matter. The 10-bit formats we're using are the all-planar ones: YUV(A)***P10, GBR(A)P10. Or YUV(A)***P12/14, GBR(A)P12/14, respectively. To my understanding, P010 is mostly a format used by graphics cards and screen output types of jobs, not one that should be getting used for practically anything else. It's like NV12/NV21.
I know you are not using P010. I was explaining to MasterNobody why it is not used. At first i thought (and i guess MasterNobody too) that the only difference was the location of the zero padding, but as you repeated the chroma is packed too in P010.

[pinterf]

Hi, just a short project report on the high bit depth part.

Probably you know, that instead of the the original plans (YUV 16 bit/float 4:2:0, 4:2:2 and 4:4:4) we finally decided to support more formats.

Avisynth core got support (at least on my workbench) for
- YUV 10-12-14 bits (and of course the 16 bit and float format)
- RGB48 and 64 (RGB24 and RGB32 16-bit counterparts)
- Planar RGB and Planar RGBA (8-10-12-14-16 bit integers and float)
- YUVA (YUV with a 4th alpha channel) with the same options as YUV.

Most of the filters and functions are ported and support all these new formats.

Not much left
- Invert
- Overlay and Mask filters (all)
- SkewRows (not priority)
- GeneralConvolution for RGB32

And there are planned refinements.
- There should be only one bitdepth converting function, instead of existing ConvertTo8bit/16bit/Float
- Dithering for 8/10 bit conversion
- more functions to use SIMD (SSE2)

Some filters that are working with lookup tables internally (Limits, RGBAdjust) are not available for float video formats.

10-14 bit formats are mainly for export/import, but a few filter can already use them natively (Limits, RGBAdjust, text-overlay, etc)

That's all for now, the work is going on...

[Groucho2004]

This applies only to AVS+ 64 bit. Test release: r2172

Script:
colorbars(width = 1280, height = 720, pixel_type = "yv12").killaudio().assumefps(50, 1)
Dummy()

"Dummy()" is my test plugin that simply triggers a 0xC0000094 / STATUS_INTEGER_DIVIDE_BY_ZERO exception, download here (https://www.dropbox.com/s/slusj7lrfddmxcr/Dummy64.7z?dl=0)

AVSMeter reports the correct module:
AVSMeter 2.3.8 (x64) - Copyright (c) 2012-2016, Groucho2004
AviSynth+ 0.1 (r2172, MT, x86_64) (0.1.0.0)

Exception 0xC0000094 [STATUS_INTEGER_DIVIDE_BY_ZERO]
Module: E:\Apps\VideoTools\AVSPlugins\AutoLoad64\Dummy64.dll
Address: 0x0000000004CE14A5
However, if I put "Prefetch(x)" at the end of the script, this is the result:
AVSMeter 2.3.8 (x64) - Copyright (c) 2012-2016, Groucho2004
AviSynth+ 0.1 (r2172, MT, x86_64) (0.1.0.0)

Exception 0xC0000094 [STATUS_INTEGER_DIVIDE_BY_ZERO]
Module: D:\WINNT\system32\kernel32.dll
Address: 0x0000000077D67DDD

[LigH]

May be interesting in which system function. Possibly in a threading management routine? That may require a detailed crash dump with stack trace.

[Groucho2004]

May be interesting in which system function. Possibly in a threading management routine? That may require a detailed crash dump with stack trace.
Well, AVSMeter catches the exception so there is no crash dump. :D
I'll try with MPC-HC.

Edit: MPC-HC crash dump (http://pastebin.com/QYfg7JXS)

[LigH]

You might add the *.pdb file for access to symbols ... but the appearance of "ntdll!NtWaitForMultipleObjects" and "kernel32!ReleaseSemaphore" in the stack trace seem to support my suspicion that the thread scheduling gets disturbed by the exception. Yet, I am no expert, so no warranties... :o

[qyot27]

A couple previous posts of mine getting clarified:
I have some weird results with the MinGW builds. None of them - a cross-compiled AviSynth+ built under Ubuntu with MinGW-w64 4.0.6 and GCC 6.1.0, one built under msys2 with GCC 5.4.0 (I don't know which MinGW-w64 version), or the build ultim provided above - works with FFmpeg. However, the msys2 build and ultim's do at least have FFmpeg error out the same way it does if the proper MSVC runtime can't be found, while the one built on 6.1.0 just up and crashes.

I think part of it might have to do with function decorations. Or compiler optimizations that I tried enabling on the 6.1.0 build. It'll get worked out eventually.
This was almost certainly the capi.h issue MasterNobody brought up. (http://forum.doom9.org/showthread.php?p=1777515#post1777515)

I attempted it from a different angle, and that's if the ifdef was changed to accept MSVC OR MINGW, then the MinGW-GCC build of AviSynth+ with that change and the build of Libav depending on that header were suddenly okay (so long as I kept the autoload folders empty of .dlls).

Unfortunately, the MinGW-GCC build of FFMS2's C plugin did not work, likely because it was using a much older version of the header. So C plugins will probably need to update against it to work right as well. Whether they'll remain backward compatible with AviSynth 2.6 in that case, I don't know. I also didn't test MSVC builds against the expanded ifdef, so those might still fail to work.

All that to say, it's encouraging that a program that uses the C interface to talk to AviSynth can indeed use MinGW-GCC builds of AviSynth+. It's still early in fleshing out the support there (since there's bound to be conflicts to hammer out), but at least there's confirmation that one configuration of it actually works.

Also, it would appear that VS2015 builds work with Wine 1.9.17 now, if msvcp140.dll is specifically overridden to native,builtin in winecfg and the VS2015 redist is installed. The only issue is, that version of Wine is still -devel, so it may not be a good idea yet to rely on (and if we want a 'just works' solution there before dropping VS2013, it probably shouldn't require overrides or installing the redist package).
I spoke a bit too soon on this. 32-bit builds work as I described there, but Wine 1.9.x is still not compatible with the 64-bit builds, even if you've installed the 64-bit VS2015 redist.

[Motenai Yoda]

mergechroma and rgbadjust are bugged only for me?

[pinterf]

mergechroma and rgbadjust are bugged only for me?

Last week I was working on porting RgbAdjust to RGB48/64 and planar RGB 8-16 bit formats and found a bug, that would cause buffer overflow when creating the lookup table.
If you specify dither=true, it should not occur.

What is the problem with MergeChroma?

[Motenai Yoda]

Last week I was working on porting RgbAdjust to RGB48/64 and planar RGB 8-16 bit formats and found a bug, that would cause buffer overflow when creating the lookup table.
If you specify dither=true, it should not occur.
thanks
What is the problem with MergeChroma?
the weight part on yv12

[StainlessS]

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

Perhaps it did not make it into AVS+

EDIT: And MergeLuma used LumaWeight, also added the Weight alias. [EDIT: About v2.6 Alpha 3, period].

EDIT: @ Motenai Yoda Below post:
OK, I think you just added the stuff in blue, the weight part on yv12.

[Motenai Yoda]

@StainlessS doesn't seems the same issue
http://1.t.imgbox.com/h6HLHoeR.jpg (http://imgbox.com/h6HLHoeR)

[qyot27]

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

Perhaps it did not make it into AVS+

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

[pinterf]

thanks
the weight part on yv12

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

[jpsdr]

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

[pinterf]

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

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

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

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

[ajp_anton]

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

[pinterf]

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

[real.finder]

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

even in Y8?

[pinterf]

even in Y8?
Yes.

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

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

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

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

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

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

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

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

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

[THEAST]

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

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

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

For the former, the compilation stops here:

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

And this is the error:

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

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

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

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

The error is:

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

Any idea how to fix these issues?

[pinterf]

For the former, the compilation stops here:

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

And this is the error:

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


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


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

The error is:

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

Any idea how to fix these issues?

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

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

[THEAST]

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

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

[pinterf]

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

[qyot27]

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

[THEAST]

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

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

[pinterf]

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

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

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

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

[kypec]

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

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

[THEAST]

@kypec, bad assumption on my part. ;p

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

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

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

[LigH]

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

[THEAST]

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

[Groucho2004]

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

[Sm3n]

Hi, here is my issue,

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

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

my scripts:

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

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


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

[Groucho2004]

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

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

...

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

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

[Sm3n]

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

Cheers! I thought I was using the last AVS+

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

[StainlessS]

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

[Sm3n]

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

Thank you. That's what I did.

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

thank you all :)

[qyot27]

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

[pinterf]

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

[qyot27]

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

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

[pinterf]

Could not reproduce.

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

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

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

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

[qyot27]

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

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

Expression: ("Incorrect format specifier", 0)

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

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

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

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

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


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

8 Warning(s)
1 Error(s)

Time Elapsed 00:01:32.37

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

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

Expression: ("Incorrect format specifier", 0)

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

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

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

[pinterf]

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

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

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

[pinterf]

I have to look at something.

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

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

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

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

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

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

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

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

[qyot27]

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

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



I have to look at something.

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

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

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

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

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

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

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

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

[Sm3n]

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

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

[THEAST]

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

[pinterf]

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

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

Regarding the optimizations:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

C Code:

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


Avisynth 32 with SSE option:

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


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


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

[Motenai Yoda]

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

[Myrsloik]

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


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

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

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


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

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

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

[pinterf]

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

[THEAST]

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

[pinterf]

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

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

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

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

[THEAST]

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

[ryrynz]

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

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

[ajp_anton]

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

[pinterf]

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


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

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

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


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

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

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

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

I just copy/paste here the pull request comment

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

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

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

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

[LigH]

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

[Myrsloik]

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

I just copy/paste here the pull request comment

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

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

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

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

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

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

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

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

[pinterf]

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

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

[ajp_anton]

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

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

[Myrsloik]

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

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

[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

[qyot27]

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

AFAIK, all RGB formats exit AviSynth+ the same way it stores RGB: bottom-first. The cases in FFmpeg's AviSynth demuxer (https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/avisynth.c#L667) demonstrate this, as the existing 2.6-era check for flipping BGR/BGRA worked as-is with BGR48/BGRA64. Even the planar formats need to be flipped by the receiving application (to use FFmpeg as an example again, the check for Planar RGB in the AviSynth demuxer uses the exact same method to flip the video, but has to be separated from the packed RGB check simply because it has to be hidden from 2.6 for compatibility reasons).

Whether AviSynth(+) flips top-first RGB data when input so that it's bottom-first internally, I don't know.

[qyot27]

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)
colors_rgb.avsi?

Although, I'm not sure whether there was some kind of regression which makes AviSynth+ not autoload colors_rgb.avsi even though it's in an autoload directory (might be because it sets global values?). You have to manually Import() it to get avsplus to recognize the color constants, but specifying them manually (color=$VALUE) does work, script loaded or not.

It also seems to work regardless of bit depth. Painting a frame as color_crimson - or its corresponding $VALUE in colors_rgb.avsi - in BlankClip outputs the same shade of red whether you're on YUV420P10, GBRP12, YUV444P16, etc. Unless, of course, that's just a deficiency of my computer monitor.

[real.finder]

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 duplicate color in colors_rgb_avsi should have been fixed in v2.6, but not in above GIF.

colors_rgb.avsi?

Although, I'm not sure whether there was some kind of regression which makes AviSynth+ not autoload colors_rgb.avsi even though it's in an autoload directory (might be because it sets global values?). You have to manually Import() it to get avsplus to recognize the color constants, but specifying them manually (color=$VALUE) does work, script loaded or not.

It also seems to work regardless of bit depth. Painting a frame as color_crimson - or its corresponding $VALUE in colors_rgb.avsi - in BlankClip outputs the same shade of red whether you're on YUV420P10, GBRP12, YUV444P16, etc. Unless, of course, that's just a deficiency of my computer monitor.

thank you both, but I mean as new color format that has one plane with 16 and 24 or more bits, to use it in Motion Analyze for instance

[Ignus2]

AFAIK, all RGB formats exit AviSynth+ the same way it stores RGB: bottom-first. The cases in FFmpeg's AviSynth demuxer (https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/avisynth.c#L667) demonstrate this, as the existing 2.6-era check for flipping BGR/BGRA worked as-is with BGR48/BGRA64. Even the planar formats need to be flipped by the receiving application (to use FFmpeg as an example again, the check for Planar RGB in the AviSynth demuxer uses the exact same method to flip the video, but has to be separated from the packed RGB check simply because it has to be hidden from 2.6 for compatibility reasons).

Whether AviSynth(+) flips top-first RGB data when input so that it's bottom-first internally, I don't know.

In avs+ it does for AviSource but it doesn't for DirectShowSource currently (doesn't flip if the height is negative), so for DSSource that's a bug I know of, but I'll fix that.

The question precisely is:
In avi/vfw/dshow for fccs BGR0 (BGR[48]) and BRA@ (BRA[64])

should we assume that they are bottom-first for positive height and top-first for negative height like DIB formats (BI_RGB 24/32 bits) are, OR
should we assume that they are always top-first regardless of the sign of the height?


There really is no precedent in this case, so I believe it will be as we define, and I'd like to have opinions on this.
My take would be point 2. above.

BTW, it doesn't matter how avisynth stores it internally to decide the above question (as it's about how to expect data in avi/vfw/dshow for the above fccs, not about how avisynth stores it). The flipping you referenced in ffmpeg has to deal with flipping as it's directly accessing avisynth's internal representation (and yes, it will be correct for CS_BGR48 and CS_BGR64 too).

Greets,
I.

[pinterf]

colors_rgb.avsi?

Although, I'm not sure whether there was some kind of regression which makes AviSynth+ not autoload colors_rgb.avsi even though it's in an autoload directory (might be because it sets global values?). You have to manually Import() it to get avsplus to recognize the color constants, but specifying them manually (color=$VALUE) does work, script loaded or not.

It also seems to work regardless of bit depth. Painting a frame as color_crimson - or its corresponding $VALUE in colors_rgb.avsi - in BlankClip outputs the same shade of red whether you're on YUV420P10, GBRP12, YUV444P16, etc. Unless, of course, that's just a deficiency of my computer monitor.
8 bit colors constants are automatically scaled for high bit-depth.
When I was porting that part for high bit-depth, there came the first surprise: could't use 64 bit values.

So there is no int64 in avisynth. I then wanted to introduce "double" floating point type, when I fixed double usage for Virtualdub filters, and encountered the same barrier.

Later ultim told me why this is normal: AVSValue struct has no place for 64 bit integer in 32 bit Avisynth. Under 64 bit Avisynth, the pointers are 8 bit, so they are the biggest placeholders, and we would use long long or double. But under 32 bit Avisynth, the pointers are 32 bit, so there is no place for double or int64.

I had to put a nice comment in order not to spend hours again with the impossible mission.

AVSValue struct:
short type; // 'a'rray, 'c'lip, 'b'ool, 'i'nt, 'f'loat, 's'tring, 'v'oid, or RFU: 'l'ong ('d'ouble)
short array_size;
union {
IClip* clip;
bool boolean;
int integer;
float floating_pt;
const char* string;
const AVSValue* array;
#ifdef X86_64
// if ever, only x64 will support. It breaks struct size on 32 bit
__int64 longlong; // 8 bytes
double double_pt; // 8 bytes
#endif


The second surpise I experienced came two days ago. I wanted to specify exact 16 bit color values for BlankClip, but I could't of course, and decided to introduce a new parameter.
I decided to use an array, because I'm fed up with the zillions of parameter names. I wanted to use a simple parameter usage like colors = [65535, 65535, 65535]. Failed.

Searched topics, but I found no evidence of arrays in native Avisynth scripting language. Internally there exists an array type for AVSValue.
So my question: is it possible to use arrays somehow, without any external hack?

[pinterf]

AFAIK, all RGB formats exit AviSynth+ the same way it stores RGB: bottom-first. The cases in FFmpeg's AviSynth demuxer (https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/avisynth.c#L667) demonstrate this, as the existing 2.6-era check for flipping BGR/BGRA worked as-is with BGR48/BGRA64. Even the planar formats need to be flipped by the receiving application (to use FFmpeg as an example again, the check for Planar RGB in the AviSynth demuxer uses the exact same method to flip the video, but has to be separated from the packed RGB check simply because it has to be hidden from 2.6 for compatibility reasons).

Whether AviSynth(+) flips top-first RGB data when input so that it's bottom-first internally, I don't know.

Planar RGB is not flipped, packed RGB formats are flipped internally (and causing headaches sometimes :) )

[jpsdr]

A little question...
Where (or when) resizer_h_ssse3_as_avx_generic_int16_float is used ? Maybe i've missed it but don't see it in horizontal GetResampler function.

[pinterf]

A little question...
Where (or when) resizer_h_ssse3_as_avx_generic_int16_float is used ? Maybe i've missed it but don't see it in horizontal GetResampler function.
resample.cpp.
Use my repo (https://github.com/pinterf/AviSynthPlus/tree/MT), that is the current one, including avisynth.h, etc..
AVX/AVX2/SSE2 functions can be compiled with avx or avx2 flag per file, while the whole project can support only SSE2.
In such modules we can use SSE2 intrinsics using AVX/AVX2 features (less used registers, optimized intrinsics) that may run faster.
Even if we are not using mm256 intrinsics. (And don't forget _mm256_zeroupper() at the end to avoid AVX-SSE2 transition penalties)

[jpsdr]

Ok, i'll check, thanks.

[pinterf]

Ok, i'll check, thanks.
Oh, I can see, it's RFU.
Tried to compile the existing SSSE3 code under avx flag, but did not use it finally, there was no measurable speed gain for me. Maybe I give it another test for it.

[LigH]

Just to mention a related issue here, even though it may be the responsibility of the source filters after all:

AviSynth+ may support high bit depths. But reading source videos with high bit depth may not be simple in every case. Source filters may have to be aware of AviSynth+ being able to support HBD. AviSynth+ may have to request HBD output of source filters if desired. Native source plugins based on libavcodec may be able to support HBD but indexing intra-frame only HBD source formats (like Apple ProRes) could require a lot of preparation time and either disk space or RAM, depending on where the index is kept. Source filters relying on Windows provided APIs (VfW, DirectShow) may access such files faster but will depend on the ability of these APIs to provide HBD decoding results.

Unfolding these dependencies may require some deeper insight in the AviSynth(+) kernel, and probably also cooperation with authors of plugins like DirectShowSource, FFMS2, L-SMASH Works, or DSS2Mod (which can use both DS and LAV API).

This thread may or may not be the optimal location to discuss this matter further; your decision...

[leoenc]

It would be very helpful if DirectShowSource could support 10-bit from LAV filters.
That would enable skipping the indexing, which is taking really long with big ProRes files.

See discussion here: http://forum.doom9.net/showthread.php?p=1784106#post1784106

[jpsdr]

Euh... ... ... No... I don't konw what RFU mean, and i'm not able to figure out, even if i have an idea of the meaning.

[pinterf]

Reserved for future use. I left there for experimenting

[Stephen R. Savage]

Is there an avs2avi, avs2pipemod, etc. for AVS+? How can it be piped or dumped to RAW file?

[Reel.Deel]

Is there an avs2avi, avs2pipemod, etc. for AVS+? How can it be piped or dumped to RAW file?

See here: https://github.com/chikuzen/avs2pipemod/releases

[qyot27]

Is there an avs2avi, avs2pipemod, etc. for AVS+? How can it be piped or dumped to RAW file?
FFmpeg can be used for this as well. The new pix_fmts are supported by FFmpeg-git and 3.2. The only limiting factor being whether FFmpeg actually supports dumping X format to RAW.

A mostly equivalent patch for Libav is on their mailing list. Not as many of the new pix_fmts are supported as with FFmpeg, due to Libav just not having those formats in swscale/avutil yet. Of course, neither of them support *all* of the new formats (neither project has GRAY10/12/14 or Float formats).

The most recent x264 builds also support some of the new formats on the YUV side, which for some users and usecases would obviate the need for piping.

[Stephen R. Savage]

Here's some info about PINTERF resizer:


Resize 4:4:4 from 1280x720 to 1920x1080
Intel(R) Xeon(R) CPU E3-1230 v3 @ 3.30 GHz
16.0 GB DDR3-2400

AVS+ r2294 (pinterf) ST
Taps BYTE WORD HALF FLOAT
0 183.117 82.142 N/A 108.707
1 153.657 69.759 N/A 97.38
2 126.769 61.851 N/A 86.828
3 110.12 55.154 N/A 76.412
4 97.542 49.995 N/A 68.442

VapourSynth R35 ST
Taps BYTE WORD HALF FLOAT
0 157.44 200.08 256.02 190.77
1 153.82 196.2 220.86 176.05
2 122.25 148.96 183.66 152.78
3 105.39 126.4 149.01 132.08
4 91.5 106.28 125.43 114.43

AVS+ r2294 (pinterf) MT
Taps BYTE WORD HALF FLOAT
0 795.545 364.365 N/A 345.453
1 668.338 303.398 N/A 273.654
2 569.314 267.255 N/A 266.011
3 489.536 233.877 N/A 262.123
4 429 210.537 N/A 251.525

VapourSynth R35 MT
Taps BYTE WORD HALF FLOAT
0 679.12 802.75 881 451.18
1 675.3 782.14 818.08 437.35
2 535.58 662.38 744.48 432.46
3 446.2 539.06 651.33 418.06
4 379.52 453.13 563.34 403.91


Looks like the new code paths could use some work. Maybe it's because of the lack of softWIRE?

[pinterf]

Here's some info about PINTERF resizer:


Resize 4:4:4 from 1280x720 to 1920x1080
Intel(R) Xeon(R) CPU E3-1230 v3 @ 3.30 GHz
16.0 GB DDR3-2400

AVS+ r2294 (pinterf) ST
TapsBYTEWORDHALFFLOAT
0183.11782.142N/A108.707
1153.65769.759N/A97.38
2126.76961.851N/A86.828
3110.1255.154N/A76.412
497.54249.995N/A68.442

VapourSynth R35 ST
TapsBYTEWORDHALFFLOAT
0157.44200.08256.02190.77
1153.82196.2220.86176.05
2122.25148.96183.66152.78
3105.39126.4149.01132.08
491.5106.28125.43114.43

AVS+ r2294 (pinterf) MT
TapsBYTEWORDHALFFLOAT
0795.545364.365N/A345.453
1668.338303.398N/A273.654
2569.314267.255N/A266.011
3489.536233.877N/A262.123
4429210.537N/A251.525

VapourSynth R35 MT
TapsBYTEWORDHALFFLOAT
0679.12802.75881451.18
1675.3782.14818.08437.35
2535.58662.38744.48432.46
3446.2539.06651.33418.06
4379.52453.13563.34403.91


Looks like the new code paths could use some work. Maybe it's because of the lack of softWIRE?
Thank you for the benchmarks! Resizers do have intrinsics, but for 10-16 bits they use float internally, it was the fastest solution at that time replacing pure C. As jpsdr also revealed, I left yet-not-live parts in the code for I was experimenting.

Sure, phase#2 will be about making things faster and smarter and also avx2 friendly. Just give hints what function needs polishing (o.k. many of them, a lot of 10+ bit code paths don't have optimizazions). I'd better put behind rarely used filters in the queue.

[Stephen R. Savage]

Thank you for the benchmarks! Resizers do have intrinsics, but for 10-16 bits they use float internally, it was the fastest solution at that time replacing pure C. As jpsdr also revealed, I left yet-not-live parts in the code for I was experimenting.

Sure, phase#2 will be about making things faster and smarter and also avx2 friendly. Just give hints what function needs polishing (o.k. many of them, a lot of 10+ bit code paths don't have optimizazions). I'd better put behind rarely used filters in the queue.

I took a look at resample.cpp. The biggest change you could make that would improve performance is to combine FilteredResizeH and FilteredResizeV into a FilteredResize2D wrapper. Instead of having the individual kernels process the entire plane, make them generate scanline bundles and work from a temporary buffer. This pipeline operation is one of the big tricks in z.lib used by VapourSynth. Adding AVX integer paths is not as beneficial as it might seem, because of high overhead in unpacking across the vector lanes.

...You could also just link in z.lib into your project instead of writing it all again.

BTW: It's very confusing how you have both MT and MT-pinterf branch (and how MT is the real branch).

[vcmohan]

Some help needed. I tried on my laptop windows 10 home edition to place in the system32 and systemwow64 folders the avisynth dll from the avisynthplus latest build. Both folders I got error messages from 7zip by which I am trying to extract. I tried deleting the older version manually, ( it disappeared from view alright) but 7zip still finds it and asks me whether I should replace. After yes, it again gives error. Now I do not find the older avisynth.dll in the system32 folder even if I search for it, but 7zip always finds the old one. What should I do?
In the zip file there are devil.dll in folders named system. Are these to be placed in plugins folders?

[LigH]

Your confusion sounds like those of 64 bit system files being shadowed from 32-bit applications.

If you use a 32-bit 7-zip, it can only access the SysWOW64 folder, which is camouflaged as system32 for all 32-bit applications. Are you sure you use a 64-bit 7-zip?

There are file managers which do not depend as much on the result of Windows system calls, but prefer showing the disk content as it is stored. Also they support privilege escalation if required to overwrite UAC protected files. Being old enough to have used the Norton Commander long ago, I enjoy the Far manager v3.0 in 64 bit in these days. It supports many archive formats internally, like a sub-directory, including 7-zip. And in addition, the 7-zip "extra" pack even provides an always up-to-date Far plugin.

[jpsdr]

I took a look at resample.cpp. The biggest change you could make that would improve performance is to combine FilteredResizeH and FilteredResizeV into a FilteredResize2D wrapper.

When i take a look at the 1rst (or original) version of the code, there was only the resizev (if i remember properly). It took me a while to understand the "why", until i realise that it was just a trick, to handle the same way interleaved standard (RGB24, YUYV for exemple) than you process planar mode, without the need to change/convert them.
Because if horizontaly the pixel may not be "related" according the format, they are always verticaly.
But i agree that for planar modes probably improvements are possible.
Don't forget that a lot of planar mode has been added since the original, so the choice of vertical only at the time may not have been a so bad idea.
The actual situation is a progressive evolution from the original situation, not a rewrite from scratch.

[Reel.Deel]

...You could also just link in z.lib into your project instead of writing it all again.
.

+1, it'll be nice if we had the zimg (http://forum.doom9.org/showthread.php?t=171334) for AviSynth+. I know you've mentioned this before but you have a weird tendency of deleting your post :devil:.

[bilditup1]

Now that there's a new build out - does anybody know if DGIndex is working again?

[Groucho2004]

Now that there's a new build out - does anybody know if DGIndex is working again?
I assume that you mean dgdecode, dgindex doesn't use Avisynth. Why don't you just try it?

[Reel.Deel]

Now that there's a new build out - does anybody know if DGIndex is working again?

Ultim went on break right after you reported (http://forum.doom9.org/showthread.php?p=1779373#post1779373) this issue so I don't think he fix it. However, pinterf did submit a similar issue (https://github.com/AviSynth/AviSynthPlus/issues/103) with a hotfix. Like Groucho2004 suggested, try it out, see if it works and report back :).

[Groucho2004]

Min. installer (w/o docs/MS runtimes) for the latest build (r2290) (https://www.dropbox.com/s/4oesnhc4nb3nops/AviSynth%2B%20r2290.7z?dl=0)
Latest All-In-One runtimes (if needed) (http://repacks.net/forum/viewtopic.php?f=6&t=125)

[sl1pkn07]

Groucho2004. the installer install the plugins dlls in root of C:/

https://sl1pkn07.wtf/paste/view/0bc0fb36

[Groucho2004]

Groucho2004. the installer install the plugins dlls in root of C:/
I can't reproduce that. I tested on XP32 and XP64. All good.

[sl1pkn07]

win7 here

EDIT: false alarm. uninstall the old (by uninstaller) and reinstall the new, solve the problem

greetings

[Reel.Deel]

Min. installer (w/o docs/MS runtimes) for the latest build (r2290) (https://www.dropbox.com/s/4oesnhc4nb3nops/AviSynth%2B%20r2290.7z?dl=0)
Latest All-In-One runtimes (if needed) (http://repacks.net/forum/viewtopic.php?f=6&t=125)


Hate to be that guy but latest release is r2294 (https://github.com/pinterf/AviSynthPlus/releases).

Edit: ↓ ↓ ↓ Thanks Groucho.

[Groucho2004]

Hate to be that guy but latest release is r2294 (https://github.com/pinterf/AviSynthPlus/releases).
Sorry, here is r2294:

Min. installer (w/o docs/MS runtimes) for the latest build (r2294) (https://www.dropbox.com/s/f0a55fixmvagroa/AviSynth%2B%20r2294.7z?dl=0)
Latest All-In-One runtimes (if needed) (http://repacks.net/forum/viewtopic.php?f=6&t=125)

[bilditup1]

Ultim went on break right after you reported (http://forum.doom9.org/showthread.php?p=1779373#post1779373) this issue so I don't think he fix it. However, pinterf did submit a similar issue (https://github.com/AviSynth/AviSynthPlus/issues/103) with a hotfix. Like Groucho2004 suggested, try it out, see if it works and report back :).
Yeah I noticed he'd gone on hiatus but before that in his followup to me ultim said he would take care of it 'by the weekend' so I was hoping that that happened, and was basically just waiting for someone to make a new build as I don't want to try building myself, heh.
I assume that you mean dgdecode, dgindex doesn't use Avisynth. Why don't you just try it?
Yessiree, DGDecode. And you guys are right, I should have just tried it myself. So: I'm happy to report that DGDecode now works in MT, both your build and neuron2's :)

TDecimate() in MT is still out of commission though - results in "TDecimate: major internal error. Please report this to tritical ASAP!" or "TDecimate: internal error during prebuffering" error messages. I just tried going back to r2172 and seeing what happens, and it's weird: last time I tried to use TDecimate() with MT (http://forum.doom9.org/showthread.php?p=1779374#post1779374), it threw basically the same errors as it does now. But this time using r2172, it ends up throwing the "Only a single prefetcher is allowed per script" error even if TDecimate() is commented out and only TFM() is called (using DGDecodeIM as source filter, of course). Not sure what accounts for this, I thought maybe I switched TIVTC builds or something (between tritical's and groucho2004's) but that wasn't it. So perhaps this is still progress, of sorts, as at least TFM() runs without the 'single prefetcher' error in r2294. In any case, yeah, TDecimate() is still out for MT as of now.

[pinterf]

I was so annoyed on missing array type variables and function parameters in Avisynth, that I had to experiment a bit.

I don't know if it breaks anything but I had to try that.
Treat it as my fun part of the work. If you say that nobody will use it, I leave it out. If it breaks plugin compatibility, I will also undo it. Still have to work on it.

This is already working:

defining Array expressions
(not nice, [] would be o.k. but I'm glad I could get it work this way
Array nesting
Access by index 0..ArraySize-1
Access by Name
use arrays in function parameters (like my colors parameter in BlankClip)


clip=clip.ConvertBits(16)

black_yuv_16 = Array( 0,32768,32768)
white_yuv_16 = Array(65535,32768,32768)
aSelectColors = Array(Array("black", black_yuv_16), Array("white", white_yuv_16))

test_array2 = Array(99, 1.0, "this is a string") # mixed types
test_array = test_array2
n = ArraySize(test_array) # 3
clip = clip.SubTitle("Array size = " + String(n) +\
" [0]=" + String(ArrayGet(test_array,0)) + \
" [1]=" + String(ArrayGet(test_array,1)) + \
" [2]=" + ArrayGet(test_array,2))

black=blankClip(clip, length=1, colors = ArrayGet(aSelectColors,"black")) # value lookup by name
white=blankClip(clip, length=1, colors = aSelectColors.ArrayGet("white")) # value lookup by name, another syntax
#white=blankClip(clip, length=1, colors = Array(65535,32768,32768)) # or direct array



Opinions?

[StainlessS]

I sure hope that you can get the arrays working without problems, Avisynth+/Standard are in dire need of built-in arrays. Good Luck.

Edit: string memory garbage collection really needs some attention too. Would still though have to comply with current SaveString (or whatever its called), only new plugs could use some alternative function to alloc mem and give [EDIT: total] ownership to avisynth.
Mobile.

[pinterf]

Does Avisynth have problems with strings?

[StainlessS]

String memory is only released when avisynth closes down. Strings allocated in functions (local) survive until 'the end', I was personally shocked when I discovered how greedy avisynth is on string memory.
Mobile.

Edit: scriptclip can be terribly wastefull.

[Gavino]

use arrays in function parameters (like my colors parameter in BlankClip)
What about arrays as parameters to user-written functions?
This would require introduction of a new type-identifier (eg 'array') to rank alongside 'clip', 'int', 'float', etc in the function definition.

Overall, your idea seems like a good one, but careful thought (which I haven't yet had time for) is required to ensure that it doesn't break anything or introduce language inconsistencies of some kind.

[StainlessS]

Ooooow, pinterf and the big G, both considering type Array, you guys got me excited http://www.cosgan.de/images/smilie/musik/c060.gif

[qyot27]

Does Avisynth have problems with strings?
What kind of problem(s) exactly? tp7 mentioned the probable need to add something better in the core (https://github.com/AviSynth/AviSynthPlus/issues/28) to deal with string formatting and concatenation a couple years ago, but that may not be the same thing you're referring to.

[StainlessS]

I was referring to memory usage, ie not freeing of temporary strings, strings used in eg any single instance of a Scriptclip frame
are not released until Avisynth closure, despite them never being used again. We should be able to automatically release local strings that are
created in any script function and are not returned as the function result. I dont know if memory used for other non string local variables
additionally are not released until closure.
EDIT: Plugin writers can rely upon strings returned via SaveString() to be still available later on, so to be able to release strings
allocated via plugins, there must be another function akin to SaveString() that hands over total ownership to Avisynth and such
memory cannot be later accessed by the plugin. The original SaveString(), copies the string into Avisnth allocated memory.
How to return Strings (I'm guessin that you dont need this, perhaps some do):- http://forum.doom9.org/showthread.php?p=1633936&highlight=SaveString#post1633936


Creating an expanded system environment string + file is not I think such a big problem, (does not need to be implemented in core,
although GetSystemEnv() could be a good idea).


AVSValue __cdecl RT_GetSystemEnv(AVSValue args, void* user_data, IScriptEnvironment* env) {
// char * myName="RT_GetSystemEnv: ";
const char *s=args[0].AsString();
char * sysenv = getenv(s);
if(sysenv==NULL)
sysenv="";
return env->SaveString(sysenv);
}


fn=RT_GetSystemEnv("HOMEPATH") + "\MyFile.xyz" although that aint exactly bullet proof.


this is string formatting as implemented in RT_Stats RT_string


AVSValue __cdecl RT_String(AVSValue args, void* user_data, IScriptEnvironment* env) {
char *myName="RT_String: ";
const char *s = args[0].AsString(); // text
int arrsz = args[1].ArraySize();
int esc = args[2].AsInt(1);

if(esc < 0 || esc > 2)
env->ThrowError("%sEsc range 0 -> 2 only",myName);

enum {
CHICKEN=64
};

// what size buffer we need ?
int i,mem=strlen(s) + 1 + CHICKEN;
for(i=0;i<arrsz;++i) {
if(args[1][i].IsString()) {
const char *st=args[1][i].AsString();
mem += strlen(st) + 1 + CHICKEN;
} else {
mem += 8 + CHICKEN; // no particular reason why so big, just chicken factor.
}
}

char *pbuf = new char[(mem+1)*2];
if(pbuf==NULL)
env->ThrowError("%sCannot allocate memory",myName);

char *ptem=pbuf+(mem+1); // temp buffer

const unsigned char * r= (const unsigned char *)s;
char *p=pbuf;
int c,ix=0;
int t=0;

// Parse text and insert variables
while(c=*r) {
if(c=='%') {
++r;
if(*r=='\0') {
*p++ ='%';
} else if(*r=='%') {
*p++=*r++; // replace escaped double % with single
} else {
if(ix>=arrsz) {
delete [] pbuf;
env->ThrowError("%sExpecting data arg (%d)",myName,ix+1);
}
char *tp=ptem;
*tp++='%';
if(*r=='-' || *r=='+' || *r=='0' || *r==' ' || *r=='#') // flags
*tp++=*r++;
if(*r=='*') { // int holds length
t=args[1][ix].IsBool() ?1: \
args[1][ix].IsString() ?2: \
args[1][ix].IsInt() ?3: \
args[1][ix].IsFloat() ?4: \
0;
if(t!=3) {
delete [] pbuf;
env->ThrowError("%sUnsupported data type, Expecting Width as Int (%d)",myName,ix+1);
}
tp+=sprintf(tp,"%d",args[1][ix].IsInt());
++r; // skip '*'
++ix; // next data
} else {
while(*r>='0' && *r<='9') {
*tp++ = *r++;
}
}
if(*r=='.') {
*tp++ = *r++; // precision prefix
if(*r=='*') { // int holds length
t=args[1][ix].IsBool() ?1: \
args[1][ix].IsString() ?2: \
args[1][ix].IsInt() ?3: \
args[1][ix].IsFloat() ?4: \
0;
if(t!=3) {
delete [] pbuf;
env->ThrowError("%sUnsupported data type, Expecting Precision as Int (%d)",myName,ix+1);
}
tp+=sprintf(tp,"%d",args[1][ix].AsInt());
++r; // skip '*'
++ix; // next data
} else {
while(*r>='0' && *r<='9') {
*tp++ = *r++;
}
}
}
t=args[1][ix].IsBool() ?1: \
args[1][ix].IsString() ?2: \
args[1][ix].IsInt() ?3: \
args[1][ix].IsFloat() ?4: \
0;
// type
if( (*r=='c' ) || (*r=='C' ) || // char as int
(*r=='d' || *r=='i') || // int
(*r=='o' || *r=='u' || *r=='x' || *r=='X')) { // unsigned int
if(t!=3) {
delete [] pbuf;
env->ThrowError("%sType='%c', Expecting Int data (%d)",myName,*r,ix+1);
}
*tp++=*r++;
*tp='\0';
p+=sprintf(p,ptem,args[1][ix].AsInt());
++ix; // next data
} else if(*r=='e' || *r=='E' || *r=='f' || *r=='g' || *r=='G') { // double
if(t!=4&&t!=3) {
delete [] pbuf;
env->ThrowError("%sType='%c', Expecting Float (%d)",myName,*r,ix+1);
}
*tp++=*r++;
*tp='\0';
p+=sprintf(p,ptem,args[1][ix].AsFloat());
++ix; // next data
} else if((*r=='s')||(*r=='S')) { // string
if(t!=2&&t!=1) {
delete [] pbuf;
env->ThrowError("%sType='s', Expecting String (%d)",myName,ix+1);
}
*tp++=*r++;
*tp='\0';
if(t==1) { // Bool
p+=sprintf(p,ptem,args[1][ix].AsBool()?"True":"False");
} else { // String
p+=sprintf(p,ptem,args[1][ix].AsString());
}
++ix; // next data
} else {
delete [] pbuf;
env->ThrowError("%sUnknown format type '%c' (%d)",myName,*r,ix+1);
}
}
} else if(c == '\\' && esc == 1) {
++r;
c=*r;
// abfnrtv
switch (c) {
case '\0' : *p++='\\'; break; // copy single backslash at end of string
case '\\' : *p++=*r++; break; // replace double backslash with single backslash
case 'n' : ++r; *p++='\n'; break;
case 'r' : ++r; *p++='\r'; break;
case 't' : ++r; *p++='\t'; break;
case 'v' : ++r; *p++='\v'; break;
case 'f' : ++r; *p++='\f'; break;
case 'b' : ++r; *p++='\b'; break;
case 'a' : ++r; *p++='\a'; break;
default : *p++='\\'; *p++=*r++; break; // anything else we copy backslash and whatever follows
}
} else {
*p++=*r++;
}
}
*p=0; // nul term

if(ix<arrsz) {
delete [] pbuf;
env->ThrowError("%sUnexpected data arg (%d)",myName,ix+1);
}

// dprintf("RT_String: MEM Estimate=%d : Actual=%d\n",mem+1,strlen(pbuf));

if(esc==2) {
p=pbuf;
r=(const unsigned char*)p;
while(c=*r) {
if(c=='\\') {
++r;
c=*r;
// abfnrtv
switch (c) {
case '\0' : *p++='\\'; break; // copy single backslash at end of string
case '\\' : *p++=*r++; break; // replace double backslash with single backslash
case 'n' : ++r; *p++='\n'; break;
case 'r' : ++r; *p++='\r'; break;
case 't' : ++r; *p++='\t'; break;
case 'v' : ++r; *p++='\v'; break;
case 'f' : ++r; *p++='\f'; break;
case 'b' : ++r; *p++='\b'; break;
case 'a' : ++r; *p++='\a'; break;
default : *p++='\\'; *p++=*r++; break; // anything else we copy backslash and whatever follows
}
} else {
*p++=*r++;
}
}
*p=0; // nul term
}
AVSValue ret = env->SaveString(pbuf,p-pbuf);
delete [] pbuf;
return ret;



Much better than the basic Avisynth String() function.

[pinterf]

What about arrays as parameters to user-written functions?
This would require introduction of a new type-identifier (eg 'array') to rank alongside 'clip', 'int', 'float', etc in the function definition.

Overall, your idea seems like a good one, but careful thought (which I haven't yet had time for) is required to ensure that it doesn't break anything or introduce language inconsistencies of some kind.
Yes, there were heavy side-effects.

A couple of hours I went on a bad direction.

First I was thinking about using an existing feature: unnamed function parameters already accepted array-like parameter values, by the '+' specifier, e.g. in StackHorizontal, Spline or Select.

{ "StackHorizontal", BUILTIN_FUNC_PREFIX, "cc+", StackHorizontal::Create },
{ "Spline", BUILTIN_FUNC_PREFIX, "[x]ff+[cubic]b", Spline },
{ "Select", BUILTIN_FUNC_PREFIX, "i.+", Select },


But it is only for one level.
And the broader support in AVSValue mechanism (constructor, etc.) failed. When I wanted to return such an array value, e.g. store it in a variable, the content of the array disappeared outside the internal method, because after instancing a function or method the array member AVSValues were freed up.

Another problem was that the existing array parameter type has special handling internally, the array content is "flattened" at some point.

So I had to introduce a "real" script array type, now I call it "A" in order not to mix it with the existing 'a' internal array specifier.
It is a vector<AVSValue>

Because of the working mechanism of '+' parameter specifier, which is putting together a one-level array AVSValue (type=='a') for the functions, I introduced a # (since it resembles the + sign) specifier that results a new script-array (type=='A') instead of that.

In my sample, BlankClip can have a real array, that can be used for a named parameter. The definition is like this (A= the new script array type)
{ "BlankClip", BUILTIN_FUNC_PREFIX, "[]c*[length]i[width]i[height]i[pixel_type]s[fps]f[fps_denominator]i[audio_rate]i[channels]i[sample_type]s[color]i[color_yuv]i[clip]c[colors]A", Create_BlankClip },


and the other array specific functions are defined as
{ "Array", BUILTIN_FUNC_PREFIX, ".#", ArrayCreate }, // # instead of +: creates script array
{ "IsArray", BUILTIN_FUNC_PREFIX, ".", IsArray2 },
{ "ArrayGet", BUILTIN_FUNC_PREFIX, "Ai", ArrayGet },
{ "ArrayGet", BUILTIN_FUNC_PREFIX, "As", ArrayGet },
{ "ArraySize", BUILTIN_FUNC_PREFIX, "A", ArraySize },


It works as-is, parameter type is nicely checked against type 'A'.
Script function can check the script-array type with IsArray2 at the moment.
At least I had a little insight to the parser, too. Anyhow, this part was nicely written, I hope I can easily change to [] for definition and indexing arrays.

A little off-topic, but I relaxed with this problem after my weekend 85K trail running race :) Fun after fun.

BTW did you know that there is built-in for and while?

[Gavino]

{ "Array", BUILTIN_FUNC_PREFIX, ".#", ArrayCreate }, // # instead of +: creates script array
Perhaps # should be allowed to also match zero or more values (like the existing * rather than +), so that you can create empty arrays. Or maybe you want another new symbol in addition to #, to be the equivalent of * for arrays.

Actually, on further thought, I'm not sure you really need # anyway.
Can't the built-in Array() function be defined as ".*", and simply copy its arguments into an new type 'A' AVSValue?

BTW did you know that there is built-in for and while?
Yes (in Avisynth+).
In the early stages of development, I gave ultim permission to incorporate my GScript code into Avisynth+.

[may24]

Hi all,

I recently swapped avisynth for avisynth+

Yesterday I modified one of my avs Scripts. Just added some new pics - basically three more ImageSource(...)

But now I got: "Could not map shared memory into local space" in VirtualDub.

Any ideas ?

EDIT: I fall back to std. Avisynth 2.6.1 ... no problems anymore ...

[pinterf]

Hi all,

I recently swapped avisynth for avisynth+

Yesterday I modified one of my avs Scripts. Just added some new pics - basically three more ImageSource(...)

But now I got: "Could not map shared memory into local space" in VirtualDub.

Any ideas ?

EDIT: I fall back to std. Avisynth 2.6.1 ... no problems anymore ...

Anyway, needed the
- avs script
- whether the script works alone w/o vdub (to rule out avs+ install problems, such as missing VS2015 update 3 redistributables)
- type and size of the images
- virtualdub version
- avisynth+ version

[LigH]

- whether the script works alone w/o vdub (to rule out avs+ install problems, such as missing VS2015 update 3 redistributables)

:confused: AviSynth scripts (no matter which fork of AviSynth) will always need a host application. The minimum is probably AVSMeter (which also may print more useful error messages). In case of AviSynth+ as engine, may24 can (and should!) test both the 32 bit and 64 bit version of AVSMeter as host.

If I understood may24 correctly, the script worked well with a few images less loaded, but he crossed some threshold by adding some more sources?

[pinterf]

:confused: AviSynth scripts (no matter which fork of AviSynth) will always need a host application. The minimum is probably AVSMeter (which also may print more useful error messages). In case of AviSynth+ as engine, may24 can (and should!) test both the 32 bit and 64 bit version of AVSMeter as host.

If I understood may24 correctly, the script worked well with a few images less loaded, but he crossed some threshold by adding some more sources?
AVSMeter or x264 was in my mind (other than virtualdub).
I found that error message (http://read.pudn.com/downloads9/sourcecode/multimedia/34422/VirtualDub/source/FilterSystem.cpp__.htm) and all I could see that a MapViewOfFile after a successful CreateFileMapping has failed with a specific buffer size.

[jpsdr]

@pinterf :
Where is _MM_PACKUS_EPI32 defined ?
When i tried to build, the compiler complained that it can't find it.
I've not been able to find it either, at leat in the resample source files.

[pinterf]

@pinterf :
Where is _MM_PACKUS_EPI32 defined ?
When i tried to build, the compiler complained that it can't find it.
I've not been able to find it either, at leat in the resample source files.
internal.h, it was used at several places

[jpsdr]

Just when i finaly found it...
Thanks anyway.
Now, i have to figure out why... why... why... the compiler don't want to compile minmax.h anymore, throwing me a lot of errors about the template T ! :confused:
And i have to implement a test for detecting VS version, because i still want to be able to compile with VS2010, which the avx intrinsic don't allow anymore...
But first, i have to be able to build with VS2015. I can workaround minmax with #define macros, but i would better understand why sudenly it don't want to build anymore...

[pinterf]

Just when i finaly found it...
Thanks anyway. Now, i have to figure out why... why... why... the compiler don't want to compile minmax.h anymore, throwing me a lot of errors about the template T ! :confused:
The types inside min, max or std::clamp are not similar. All parameters have to be the same int, short or float (or pixel_t in templates).

PS, I have cleaned up the resizers a bit (after you found unused avx path test code) and added a real avx2 path, I bet it is still not as fast as zimg, but at least it got cleaner. Just have commited, check my MT repo.

[jpsdr]

The types inside min, max or std::clamp are not similar. All parameters have to be the same int, short or float (or pixel_t in templates).

The problem is that i haven't touched the code where minmax is used... So for now, i have absolutely no idea why there is suddenly this error.:(

PS, I have cleaned up the resizers a bit (after you found unused avx path test code) and added a real avx2 path, I bet it is still not as fast as zimg, but at least it got cleaner. Just have commited, check my MT repo.
Argh....... After all that hard work... Nooooooooooooooooooooooooo...:sly:

zimg... If it works with direct full square ... (argh... don't remember the word now), it will be impossible to multi-thread by splitting.

And a more general question.
In image/video processing, the 1rst idea (at least, for me) which comes to mind when talking of multi-threading is splitting the picture, not multiply it.
So, my question is : Why when introducing multi-threading in avisynth, nobody seems to have thought at the 1rst obvious idea, internaly MT the core filters by splitting the picture,
instead of trying to run several GetFrame at the same time...?
Filters that are pure memory transfert (like doubleweave, or TurnL/R) may not benefit of MT (there is more chances of memory bandwith ... again don't remember the correct word ... issue,struggle), but the others may.
So... Why...?

[pinterf]

8 bit was not affected, and the changes are not huge. Avx and avx2 is basically the same, only their templates are different you dont have to look for other differences

[jpsdr]

Ok, thanks.

[jpsdr]

The minmax.h issue is solved : I must remove the #include within resample.cpp otherwise compiler throws me errors.

[TheFluff]

No, jpsdr, you didn't suddenly come up with the obvious solution that nobody else has considered. There are reasons nobody uses slice based threading. The most obvious one is that if you're working with video you already have your input split up in neat discrete chunks for you: they're called frames. Splitting these chunks further just adds complexity for no real gain at all. I'm pretty sure it's also worse performance wise (for many reasons, especially for spatial filters where you might have to handle overlapping slices) but I haven't benchmarked it.

[LigH]

Even worse, slices will limit the motion vector search for redundancies the codec could have used to increase efficiency.

[ajp_anton]

ArrayGet(test_array,0)Opinions?Why not
test_array(0)
?

[Stephen R. Savage]

Why not
test_array(0)
?

Wouldn't that conflict with a function named test_array? AVS does not prevent creating variables with the same name as functions.

[pinterf]

Wouldn't that conflict with a function named test_array? AVS does not prevent creating variables with the same name as functions.
Yes, there would be conflict.
Final solution should be something like that

black = [0,128,128]
test_array = [ ["ciao", black], ["hello",[1,1,2.718281]], ["null", []] ]
test_array = test_array + ["dummy"]
item = test_array[0]
item2 = test_array["hello"]
e = item2[2]


Provided the [ and ] symbols are not reserved.
Or { and }. Language experts will decide.

[Gavino]

Provided the [ and ] symbols are not reserved.
Or { and }. Language experts will decide.
[ and ] are currently used only for nestable block comments [* ... *].
Although technically possible, I recommend not using { and } as these are already well established as code block delimiters, whereas [] is familiar from other languages as indicating array indexing.

You could argue for using a different symbol, like { ... }, for array creation (as in C/C++ and Java), but I would prefer [] for both indexing and creation. There is no problem in distinguishing the two contexts in the parser even if the same symbol is used for both.

On a wider note...
You have so far shown examples of how the array features would be used in the script language.
From the plugin writer's point of view, I would also like to see a list of proposed API changes.
I imagine there will be changes to the public interface of AVSValue and possibly new ScriptEnvironment functions.

[pinterf]

On a wider note...
You have so far shown examples of how the array features would be used in the script language.
From the plugin writer's point of view, I would also like to see a list of proposed API changes.
I imagine there will be changes to the public interface of AVSValue and possibly new ScriptEnvironment functions.
I agree with [ and ].
I also wonder how can I do that with keeping backward compatibility. Anyway, I will return to the problem later, this will definitely need more time than that day I spent on it so far.

[Gavino]

I agree with [ and ].
I also wonder how can I do that with keeping backward compatibility.
Since [ and ] are currently illegal in scripts (except for [* and *]), what problem do you see with backward compatibility?

[pinterf]

Since [ and ] are currently illegal in scripts (except for [* and *]), what problem do you see with backward compatibility?
Sorry, I was thinking forward on AVSValue things and the possible interface additions.

[Gavino]

Sorry, I was thinking forward on AVSValue things and the possible interface additions.
Yes, that's certainly an area where careful thought will be required (although at the moment I can't see any specific problems).

[stranno]

I'm getting a "display error" with r2294 using ProRes 422LT source. Pre-2000 releases work fine. I have seen r2003+ releases support high bit depth colorspace so i'm not sure whats the problem.

Edit: I'm using FFMS2 2.23.

[pinterf]

I'm getting a "display error" with r2294 using ProRes 422LT source. Pre-2000 releases work fine. I have seen r2003+ releases support high bit depth colorspace so i'm not sure whats the problem.

Edit: I'm using FFMS2 2.23.
Pre r2294 versions did not support 10,12 and 14 bit depths. Could you please try with the latest (http://forum.doom9.org/showthread.php?p=1784354#post1784354) version?

[tuanden0]

I have a problem with Avisynth Plus r2294, can someone help me :scared:

I coppied the Avisynth.dll to System32 but i still error :(

http://i.imgur.com/IsdqpbX.png

[pinterf]

If you have installed 32 bit avisynth+ and have a 64 bit windows, the avisynth.dll must be placed to the SysWOW64 folder.
On 32 bit windows, system32 is O.K. for 32 bit avisynth.
But the installer should do this instead of you.
I suppose, there is another avisynth.dll somewhere, can it be set in avspmod?

[tuanden0]

If you have installed 32 bit avisynth+ and have a 64 bit windows, the avisynth.dll must be placed to the SysWOW64 folder.
On 32 bit windows, system32 is O.K. for 32 bit avisynth.
But the installer should do this instead of you.
I suppose, there is another avisynth.dll somewhere, can it be set in avspmod?

Yah, my fault, i forgot that :p:p

Thank you very much :cool:

[ajp_anton]

Wouldn't that conflict with a function named test_array? AVS does not prevent creating variables with the same name as functions.Yes, there would be conflict
But as mentioned, you can already create those conflicts with variable names. What makes array-name conflicts any different? Either you ignore the problem (allow conflicts), or you do something about it (throw error when conflicts happen, or require ()-brackets for functions), but you do the same thing with variable names and array names (aren't arrays also some kind of "variables"?).

Though I agree that []-brackets are better for arrays.

[Aktan]

I have an interesting problem. I have a Lagarith source AVI in RGB32 colorspace with the resolution of 350x240. If I open this AVI with AVS+, I get distorted video. From Info(), I noticed the video pitch is wrong. Then I realized 350 is not mod 4. Is this a known problem?

[Reel.Deel]

I have an interesting problem. I have a Lagarith source AVI in RGB32 colorspace with the resolution of 350x240. If I open this AVI with AVS+, I get distorted video. From Info(), I noticed the video pitch is wrong. Then I realized 350 is not mod 4. Is this a known problem?

What AVS+ version are you using?

[Aktan]

What AVS+ version are you using?

r1576, x64

Edit: Well I guess it's an old version? lol.

[Reel.Deel]

r1576, x64

IIRC someone reported a similar problem way back. I believe it was fixed, try updating to the latest version (http://avisynth.nl/index.php/AviSynth%2B#Downloads). Report your findings :).

Edit: maybe this? https://github.com/AviSynth/AviSynthPlus/issues/36

[Aktan]

IIRC someone reported a similar problem way back. I believe it was fixed, try updating to the latest version (http://avisynth.nl/index.php/AviSynth%2B#Downloads). Report your findings :).

Thanks, will do!

Edit: r2294 works fine =)

[Stephen R. Savage]

But as mentioned, you can already create those conflicts with variable names. What makes array-name conflicts any different? Either you ignore the problem (allow conflicts), or you do something about it (throw error when conflicts happen, or require ()-brackets for functions), but you do the same thing with variable names and array names (aren't arrays also some kind of "variables"?).

Though I agree that []-brackets are better for arrays.

There are no function pointers, so I believe AVS will use the presence of the parentheses token to identify a function name instead of a variable.

[Gavino]

There are no function pointers, so I believe AVS will use the presence of the parentheses token to identify a function name instead of a variable.
It does indeed, but in principle it could be extended to try x(1) as an array indexing if it finds that there is no function named x - just as now, when it finds plain 'x' and there is no variable called x, it tries to treat it as a parameterless function call x().

However, I don't think that would be a good idea and the availability of [] makes it unnecessary.

[jpsdr]

A little question.
If i am with an YUVA 4:4:4 mode (for exemple), will IsYV24() still be true ?

[pinterf]

A little question.
If i am with an YUVA 4:4:4 mode (for exemple), will IsYV24() still be true ?
No. There is an Is444() which is bit-depth independent and also works for YUVA.
When using my latest Avisynth.h, this Is444 call is mapped silently to IsYV24 if the relevant avisynth host has no Is444() implemented.

[jpsdr]

Ah... Ok i've seen

So, it means there is no 4:1:1 with alpha channel ?

[pinterf]

Ah... Ok i've seen

So, it means there is no 4:1:1 with alpha channel ?
No. We are lucky then :)

[Reel.Deel]

Can we add a straightforward way to get the chroma width and height? Right now we have to do something like UToY8().Width(). Maybe something like Width(chroma=true) or uv=true. Thoughts?

[pinterf]

Avisynth arrays status report:

Implemented empty arrays and [] syntax for array creation


clip=ffms2(film).ConvertBits(16)

empty_array = []
empty_array_2 = empty_array
#n3 = empty_array_2.ArrayGet(0) # array index out of range error!

black_yuv_16 = [0,32768,32768] # or black_yuv_16 = Array( 0,32768,32768)
grey_yuv_16 = [32768,32768,32768]
white_yuv_16 = [65535,32768,32768]
# getting deeper: nested arrays
aSelectColors = [\
["black", black_yuv_16],\
["grey", grey_yuv_16],\
["white", white_yuv_16],\
["empty", empty_array]\
]
test_array = [99, 1.0, "this is a string"] # mixed types
test_array2 = [199, 2.0, "This is a string"]

n = ArraySize(test_array) # 3
n2 = ArraySize(empty_array_2) # 0

clip = clip.SubTitle("Array size = " + String(n) +\
" Empty array size = " + String(n2) +\
" [0]=" + String(ArrayGet(test_array,0)) + \
" [1]=" + String(ArrayGet(test_array,1)) + \
" [2]=" + ArrayGet(test_array,2))

black=blankClip(clip, length=1, colors = ArrayGet(aSelectColors,"black")) # value lookup by name
white=blankClip(clip, length=1, colors = aSelectColors.ArrayGet("white")) # value lookup by name
grey=blankClip(clip, length=1, colors = [32768,32768,32768]) # or direct array

blackwhite = black+grey+white+black+grey+white
n=3
clip = clip.Trim(0,n) + blackwhite + clip.Trim(n+1,499)
clip


Back to work. It would be nice to have indexing with []

[mcjordan]

3> limiter.cpp
3>C:\AviSynthPlus\avs_core\filters\limiter.cpp(107): error C3861: '_mm_max_epu16': identifier not found
3>C:\AviSynthPlus\avs_core\filters\limiter.cpp(108): error C3861: '_mm_min_epu16': identifier not found
...
//min and max values are 16-bit unsigned integers
inline void limit_plane_uint16_sse4(BYTE *ptr, unsigned int min_value, unsigned int max_value, int pitch, int height) {
__m128i min_vector = _mm_set1_epi16(min_value);
__m128i max_vector = _mm_set1_epi16(max_value);
BYTE* end_point = ptr + pitch * height;

while(ptr < end_point) {
__m128i src = _mm_load_si128(reinterpret_cast<const __m128i*>(ptr));
src = _mm_max_epu16(src, min_vector);
src = _mm_min_epu16(src, max_vector);
_mm_store_si128(reinterpret_cast<__m128i*>(ptr), src);
ptr += 16;
}
}
...
This break compilation process ?! Help?

[pinterf]

3> limiter.cpp
3>C:\AviSynthPlus\avs_core\filters\limiter.cpp(107): error C3861: '_mm_max_epu16': identifier not found
3>C:\AviSynthPlus\avs_core\filters\limiter.cpp(108): error C3861: '_mm_min_epu16': identifier not found
...

This break compilation process ?! Help?
Indeed, until I update it, put
#include <smmintrin.h> // for sse41
at the top of limiter.cpp

[mcjordan]

Thank you, pinterf! Works like a charm!

[Gavino]

It would be nice to have indexing with []
I would do this by changing the parser's ParseOOP() function - in the two places it currently calls ParseFunction(), it would instead call a new function ParseIndex(), which would look like this:
PExpression ScriptParser::Parseindex(PExpression context)
{
PExpression result = ParseFunction(context);
while (tokenizer.IsOperator('[') {
tokenizer.NextToken();
result = new ExpIndex(result, ParseConditional());
Expect(']');
}
return result;
}

This allows things like:
- x.f(2)[3], where f is a function returning an array (no need to put brackets round x.f(2))
- a[1]["white"], where a is a multi-dimensional array
- a[1].f(2), equivalent to f(a[1], 2)

ExpIndex is a new Expression subtype whose Evaluate() function calls the built-in ArrayIndex function.

[pinterf]

I would do this by changing the parser's ParseOOP() function - in the two places it currently calls ParseFunction(), it would instead call a new function ParseIndex(), which would look like this:
PExpression ScriptParser::Parseindex(PExpression context)
{
PExpression result = ParseFunction(context);
while (tokenizer.IsOperator('[') {
tokenizer.NextToken();
result = new ExpIndex(result, ParseConditional());
Expect(']');
}
return result;
}

This allows things like:
- x.f(2)[3], where f is a function returning an array (no need to put brackets round x.f(2))
- a[1]["white"], where a is a multi-dimensional array
- a[1].f(2), equivalent to f(a[1], 2)

ExpIndex is a new Expression subtype whose Evaluate() function calls the built-in ArrayIndex function.
Thanks, I'm doing it with inserting ParseOOP an additional '[' check, that can call ParseFunction with either . or [, plus the context. If it works, I try to separate it, to be nice (like your proposed ParseIndex.
All other things are done, now I'm doing compound index formats e.g. a[1,2,3]; a[1][2][3] is working already

[jpsdr]

I've looked on post #2484, but don't find an answer.

If i have a planar YUV mode with alpha channel, and i'm doing the following :

vu = env->Invoke("UtoY8",v).AsClip();
vv = env->Invoke("VtoY8",v).AsClip();
v = env->Invoke("ConvertToY8",v).AsClip();

Where is my alpha channel ?
Is it still on v ?
If still on Y, is doing the following, putting everything back :

AVSValue ytouvargs[3] = {vu,vv,v};
v=env->Invoke("YtoUV",AVSValue(ytouvargs,3)).AsClip();

If not, what should i do when handling this case ?

[pinterf]

I've looked on post #2484, but don't find an answer.

If i have a planar YUV mode with alpha channel, and i'm doing the following :

vu = env->Invoke("UtoY8",v).AsClip();
vv = env->Invoke("VtoY8",v).AsClip();
v = env->Invoke("ConvertToY8",v).AsClip();

Where is my alpha channel ?
Is it still on v ?
If still on Y, is doing the following, putting everything back :

AVSValue ytouvargs[3] = {vu,vv,v};
v=env->Invoke("YtoUV",AVSValue(ytouvargs,3)).AsClip();

If not, what should i do when handling this case ?
UtoY8, VtoY8 and ConvertToY8 functions create greyscale image.

Then there became too much color formats after having Planar RGB and A channel.
Instead of making AtoY8, RtoY8, GtoY8, BtoY8, there is a PlaneToY(plane_string) in Avisynth+ that creates a greyscale clip from the relevant channel.

E.g. PlaneToY("A), PlaneToY("R")
PlaneToY accepts any plane identifier (Y,U,V,A,R,G,B)

PlaneToY("U") is equivalent to UToY8
PlaneToY("V") is equivalent to VToY8
PlaneToY("Y") is equivalent to ConvertToY (ConvertToY8)

All the above functions keep the current bitdepth, the Y8 ending is just because UToY and VToY was already existing functions.

Regarding the back conversion, YtoUV only has U,V and an optional Y clip parameter. To answer on your question, it seems, there is no function for putting A channel back to a YUVA clip.

I always wanted to make a general way mixing together arbitrary planes, something like ShufflePlanes in VapourSynth.

Albeit there is MergeRGB and MergeARGB for packed and planar RGB, it seems that making the same for YUV is missing.
On more reason for implementing a general MergePlanes or something like that. Now I'm considering that.

[jpsdr]

Ok. Meaning that for now, in nnedi3 i can only support YUVA 4:4:4, because for YUV other than 4:4:4 i have to split the planes to process them, and pull back after.

[pinterf]

Ok. Meaning that for now, in nnedi3 i can only support YUVA 4:4:4, because for YUV other than 4:4:4 i have to split the planes to process them, and pull back after.
What is the reason that you have to split the planes then put them together? Bacause nnedi3 can only work internally with identical plane dimensions?

[jpsdr]

Because there is shift to make on chroma only for other modes than 4:4:4, and use of turnleft/right, so need to separate planes in 4:2:2 to have things done properly.
But, this is only for nnedi3_rpow indeed, not nnedi3.

[jpsdr]

Just to be sure, according from what i've understood, IsYUY2 is not only for 8 bits.

[pinterf]

Just to be sure, according from what i've understood, IsYUY2 is not only for 8 bits.
YUY2 is a non-friendly format, and only exists as 8 bit.

[jpsdr]

Ok, thanks for all of these tips.
Now, just 'waiting' (and it will happen when it happens...) for a way to put back alpha channel in YUV mode.

[pinterf]

Ok, thanks for all of these tips.
Now, just 'waiting' (and it will happen when it happens...) for a way to put back alpha channel in YUV mode.

Preliminary information on some future avisynth plus features.
Driven by the popular demand :) I prepared some new stuffs for those who are mixing planes as a daily routine.

Since it is still not released, you can comment it freely and make wish-list.

20161110 Avisynth plus additions

New functions

AToY8 , same as PlaneToY("A") for planar RGBA or YUVA
RToY8 , same as PlaneToY("R") for planar RGB
GToY8 , same as PlaneToY("G") for planar RGB
BToY8 , same as PlaneToY("B") for planar RGB

They work the same way as UToY8 and VToY8 and ConvertToY did.
The functions convert to greyscale, keeping the original bit-depth, not only 8 bits!
Y8 naming was kept, because UToY and VToY already existed.

Extended function syntax
old: YToUV(clip clipU, clip clipV [, clip clipY ] )
new: YToUV(clip clipU, clip clipV [, clip clipY [, clip clipA] ] )

YToUV accepts optional alpha clip after Y clip

Example
U = source.UToY8()
V = source.VToY8()
Y = source.ConvertToY()
A = source.AddAlphaPlane(128).AToY8()
# swaps V, U and A, Y
YToUV(V,U,A,Y).Histogram("levels").Info().RemoveAlphaPlane()


New function
CombinePlanes(clip1 [,clip2, clip3, clip4], string planes [, string source_planes, string pixel_type, string sample_clip])

Combines planes of source clip(s) into a target clip.
Similar to ShufflePlanes in Vapoursynth.

clip sample_clip (optional)
If sample_clip is given, target clip properties are copied from that clip
If no sample_clip is provided, then clip1 provides the template for target clip

string pixel_type (optional)
An optional pixel_type string (e.g."YV24", "YUV420PS", "RGBP8") can override the base video format.

clip clip1, ... clip4
If the source clip count is less than the given planes defined, then the last available clip is used as a source for all later planes

string planes
the target plane order (e.g. "YVU", "YYY", "RGB")
missing target planes will be undefined in the target

string source_planes (optional)
the source plane order, defaulting to "YUVA" or "RGBA" depending on the video format

Source clips can even be mixed from greyscale, YUV, YUVA, planar RGB(A), the only rule that the relevant source plane character should match with the clip format, respectively.

Example#1
#combine greyscale clips into YUVA clip
source=source.AddAlphaPlane(128)
U8 = source.UToY8()
V8 = source.VToY8()
Y8 = source.ConvertToY()
A8 = source.AToY8()
CombinePlanes(Y8, U8, V8, A8, planes="YUVA", source_planes="YYYY", sample_clip=source) #pixel_type="YUVA420P8"

Example#2
# Copy planes between planar RGB(A) and YUV(A) without any conversion
# useful if you have a filter that accepts only YUV input
# yuv 4:4:4 <-> planar rgb
source = last.ConvertBits(32) # 4:4:4
cast_to_planarrgb = CombinePlanes(source, planes="RGB", source_planes="YUV", pixel_type="RGBPS")
# get back a clip identical with "source"
cast_to_yuv = CombinePlanes(cast_to_planarrgb, planes="YUV", source_planes="RGB", pixel_type="YUV444PS")

Example#3
#create a black and white planar RGB clip using Y channel
#source is a YUV clip
grey = CombinePlanes(source, planes="RGB", source_planes="YYY", pixel_type="RGBP8")

Example#4
#copy luma from one clip, U and V from another
#source is the template
#sourceY is a Y or YUV clip
#sourceUV is a YUV clip
clip = CombinePlanes(sourceY, sourceUV, planes="YUV", source_planes="YUV", sample_clip = source)

[ajp_anton]

"RToY8" etc, don't they already exist in "ShowRed" etc?
And since they all end with Y8, does this mean they only work for 8bit?

[pinterf]

"RToY8" etc, don't they already exist in "ShowRed" etc?
And since they all end with Y8, does this mean they only work for 8bit?
O.k. those Y8 ended names will kill me, I've written that they do work, only the name is Y8-ended, but now I will either remove them or give them a more conveniant naming.
E.g. ExtractR, ExtractB, ExtractA, etc...
Anyway, with CombinePlanes you can do everything (in next release)

ShowXXX defaults to RGB output, and work on packed rgb formats, although I made it work for planar RGB inputs. But you have to specify "Y8" parameter for the output, and afaik, it is not too optimized, while the UToY8, VToY8, and the others are working on planar YUV clips and they are fast, using a subframe trick.

[vcmohan]

I use virtualdub to check my plugins. I have to convert back to 8 bits all higher bit formats, planarRGB formats to packed RGB and because of this sometimes I miss to see small differences. Is there a software video player ( or a codec that can be used with vdub) that can accept various formats avisynth+ is capable to process?

[dipje]

'virtualdub filtermod' or 'vdfiltermod' is a modified virtualdub that has some more things like builtin-ffmpeg input/output of some sorts, but more importantly, high bitdepth support. I don't know if it supports all that Avisynth+ can these days, but v210 (YUV422 10bit) and b64a (RGB 16bit with 16bit-alpha) are supported. Do note that you're still reviewing your output in 8bit so it gets dithered down or truncated somewhere.. but big issues or flaws should at least jump out :).

'Vapoursynth Editor' fills this role at the Vapoursynth camp, turning any kind of output format into something 'displayable'. Maybe use a Vapoursynth-wrapper script to load your AVS plugin? :P

[fAy01]

I use virtualdub to check my plugins. I have to convert back to 8 bits all higher bit formats, planarRGB formats to packed RGB and because of this sometimes I miss to see small differences. Is there a software video player ( or a codec that can be used with vdub) that can accept various formats avisynth+ is capable to process?

http://umezawa.dyndns.info/archive/utvideo/utvideo-17.1.0-readme.en.html

http://www.videohelp.com/software/Ut-Video-Codec-Suite

[qyot27]

I use virtualdub to check my plugins. I have to convert back to 8 bits all higher bit formats, planarRGB formats to packed RGB and because of this sometimes I miss to see small differences. Is there a software video player ( or a codec that can be used with vdub) that can accept various formats avisynth+ is capable to process?
FFmpeg 3.2 or git, or rather FFplay. mpv built against FFmpeg 3.2 or git.

Not all of the new pixel formats are supported, just most of them. ffv1 and ffvhuff also support many of them.

[vcmohan]

Reading the documentation, I understood that these players really reduce the input finally to an 8bit color values pixels and so are displayable on the PC screen. If it is so then what I am doing is akin to that and I need not bother to use these. Am I correct?

[Wilbert]

Are there no players then which will render the footage at 10 bit, or dither to 10 bit when the footage has a higher bit depth?

[sneaker_ger]

madVR and possibly mpv (as mentioned by qyot27).

[dipje]

@Wilbert: Do you have 10bit display then? Mostly that requires special display-API stuff to work with or custom Adobe / Avid support or stuff like that.

[Groucho2004]

I think AVS+ should limit the number of plugins it enumerates during initialization just as 2.6.x. I just tried it with about 500 plugins (only about 60 unique plugins but renamed several times) and VDub, AVSMeter, mpc-hc either crash, stop working without error message or tell you they can't load the script.
The limit in 2.6.x is 50, so 100 may be a sensible number.

Edit: It seems to simply run out of memory (I tested on a 32 bit OS).

[qyot27]

with about 500 plugins (only about 60 unique plugins but renamed several times
How many AviSynth plugins do we know are even in existence where we could genuinely hit such high numbers of autoloaded plugins?

On such an obviously-artificial test like that, though, for me it actually raises a different question:

Shouldn't we have some kind of check which verifies plugins aren't just copies of the same file(s) and not allocate memory to the duplicates? The only downside might be dragging down startup performance, unless we cheat a little and allow fuzzy matching (like only checking filesize and a couple of bits of the file header, rather than a full checksum comparison operation).

And if there truly are such high numbers of plugins, maybe we should emit a warning that it could run out of memory. That way if the user decides to treat warnings as errors (does the new logging system support that?), it'll do it cleanly. Or have a SetPluginMax/SetPluginMemoryMax function that the user can use to force either a hard number limit of plugins or a hard memory limit (percentage-based, since 64-bit can obviously sustain more) for the plugin loader that would make sure the plugin loader is not the source of out-of-memory crashes.

IMO, ultim removing the plugin limit was a good change, but we obviously need some better guarding behavior, and ability to better control it through the logging and debugging structures.

[Groucho2004]

How many AviSynth plugins do we know are even in existence where we could genuinely hit such high numbers of autoloaded plugins?I just used that large number to test the limits.

Shouldn't we have some kind of check which verifies plugins aren't just copies of the same file(s) and not allocate memory to the duplicates? The only downside might be dragging down startup performance, unless we cheat a little and allow fuzzy matching (like only checking filesize and a couple of bits of the file header, rather than a full checksum comparison operation).Each binary has a unique checksum. When you compile a DLL, the content will be different with every build even if nothing has changed in the code/compiler settings. The difference is already in the .obj files, I think the compiler adds a time stamp based marker. This makes it difficult to determine what code a plugin is based on. That's why a version resource is very useful but strangely, very few people add it to their plugins.

And if there truly are such high numbers of plugins, maybe we should emit a warning that it could run out of memory. That way if the user decides to treat warnings as errors (does the new logging system support that?), it'll do it cleanly. Or have a SetPluginMax/SetPluginMemoryMax function that the user can use to force either a hard number limit of plugins or a hard memory limit (percentage-based, since 64-bit can obviously sustain more) for the plugin loader that would make sure the plugin loader is not the source of out-of-memory crashes.These are all good ideas.

[real.finder]

I think AVS+ should limit the number of plugins it enumerates during initialization just as 2.6.x. I just tried it with about 500 plugins (only about 60 unique plugins but renamed several times) and VDub, AVSMeter, mpc-hc either crash, stop working without error message or tell you they can't load the script.
The limit in 2.6.x is 50, so 100 may be a sensible number.

Edit: It seems to simply run out of memory (I tested on a 32 bit OS).

by using AVSMeter -avsinfo?

because avs (at least the normal not the plus one) load all plugins one by one with unload the loaded one in autoload iirc, but if you call a lot of functions from a lot plugins in the encode script then avs will show you the 50 plugins limit message

[Groucho2004]

by using AVSMeter -avsinfo?

because avs (at least the normal not the plus one) load all plugins one by one with unload the loaded one in autoload iirc, but if you call a lot of functions from a lot plugins in the encode script then avs will show you the 50 plugins limit message
AVSMeter invokes "LoadPlugin()" for each plugin during the plugin tests.

[Myrsloik]

The number of plugins you can load is actually impossible to determine before it's too late. Things that can cause loading to fail:

1. Out of memory (extremely unlikely since dlls can be swapped out)
2. Out of address space (also quite unlikely since plugins normally are loaded before frames are allocated)
3. Out of magic jelly beans to store thread state in (I forget the exact name, basically every dll that statically links the visual studio runtime consumes this resource, the max is about 100 and programs immediately terminate if it's hit and you can never know if it'll happen ahead of time)

Have fun. Any "solution" you propose will be worse than the problem.

I also find it extremely unlikely that you encountered #1.

[real.finder]

AVSMeter invokes "LoadPlugin()" for each plugin during the plugin tests.

and this (http://forum.doom9.org/showthread.php?t=170647)? it was ok with more than 50 plugins

[Groucho2004]

and this (http://forum.doom9.org/showthread.php?t=170647)? it was ok with more than 50 pluginsThat tool also used "LoadPlugin()" for each DLL but created/released the script environment every time which made it very slow.
AVSMeter is basically doing the same as a script that manually loads all plugins with "LoadPLugin()".

[Groucho2004]

3. Out of magic jelly beans to store thread state in (I forget the exact name, basically every dll that statically links the visual studio runtime consumes this resource, the max is about 100 and programs immediately terminate if it's hit and you can never know if it'll happen ahead of time)Also rather unlikely since most plugin coders use IDE defaults which means dynamic linking against the runtimes.

Any "solution" you propose will be worse than the problem.Maybe you're right. It just goes against the grain not having a safeguard against users creating a script with 250 "LoadPlugin()" calls that will crash badly without explanation. This is not even that far fetched since there are probably people who think that having all plugins in existence available is convenient so they make a .avsi that loads all of them.

[Khanattila]

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.
About 16-bit RGB support, is it 5-6-5 or x-5-5-5 (RGB)? Other formats are absolutely useless.

However for what I do I'm just wondering if other developers decide to support it.

[vivan]

About 16-bit RGB support, is it 5-6-5 or x-5-5-5 (RGB)? Other formats are absolutely useless.Of cource it's 16 bit per channel because no one sane is going to implement 5-bit rgb in 2016.

[Khanattila]

Of cource it's 16 bit per channel because no one sane is going to implement 5-bit rgb in 2016.

Oops, I really misunderstood.

[pinterf]

I just tried it with about 500 plugins
Do you usually do extreme sports? :)

Regarding avisynth things, I'm still waiting for more error reports.
jpsdr already found two of them.

The development version on my git contains the following changes:

New: arrays (you can read about them at a few pages back)
New: CombinePlanes, like ShufflePlanes in Vapoursynth
(though I like the ShufflePlanes name more)
ExtractY, ExtractU, ... V, R, G, B, A:
shortcuts for extracting single planes from planar YUV(A) or RGB(A) (ExtractU/V is UToY8/VToY8)
VirtualDubFilter: really allow param type 'd' and 'l' (maps them into 'f' and 'i' for avisynth - we don't have double and long types)
YToUV accepts an extra alpha clip source if target is YUVA
much faster YUV444<->Planar RGB conversion
fix: planar RGB(A) turnleft/turnright
fix: PlaneToY("Y")


Then there is a new RgTools (waiting for release), forked from tp7's repository.
The new version supports 10,12,14,16 bit and float formats, and accepts planar RGB besides YUV (with all valid bit-depths of course)

[StainlessS]

Do you usually do extreme sports? :)


I have been known to have about 260 plugs in-situ, although more recently is limited to about 160 (+ specials on occasion)

New: arrays (you can read about them at a few pages back)

You have given New Hope, thank you kind sir, may all of your memories, be good ones. :)

EDIT: (I'm still sticking currently with Standard AVS, but am quite excited because of all of your Good Stuff, will swap one day)
Peace and Love :)

[ilko]

Hi there, I can finally post after one week…

Using NSIS, I've compiled an alternative avs+ installer based on the latest r2294 release. Basically this was for my personal use but maybe some people will find it interesting.

Note : x64 systems only.


Additional features

FFMpegSource2 v2.23


Optional :

A selection of plugins with their documentation
A selection of scripts (incl. Interframe2, QTGMC)
A basic script template ready to use
New icons, black for regular scripts, blue for auto-load scripts or classic original style
New context menu entry for the templates
Open scripts with Notepad++
Open .ass with Notepad++
Open .ass files in Aegisub menu item
Full integration of .ass subtitle files (incl. a dedicated icon)
AviSynth+ language syntax recognition file for Notepad++


https://1.bp.blogspot.com/-l496FNn_0X0/WDNLjRaeokI/AAAAAAAAAUQ/D26KxqujpHURB6cV1rDVlJ8ZS32CWyE8wCPcB/s1600/AviSynth%252B_com.jpg

Downloads (http://d-h.st/users/Ilko/avisynth_64)

Any feedback will be appreciated. Thanks.

[pinterf]

I think AVS+ should limit the number of plugins it enumerates during initialization just as 2.6.x. I just tried it with about 500 plugins (only about 60 unique plugins but renamed several times) and VDub, AVSMeter, mpc-hc either crash, stop working without error message or tell you they can't load the script.
The limit in 2.6.x is 50, so 100 may be a sensible number.

Edit: It seems to simply run out of memory (I tested on a 32 bit OS).

Using avsmeter 2.44, x86 avisynth+ r2318 internal build
0.) Renaming the given dll to xx_100.DLL .. xx_600.dll
1.) Run a simple script using avsmeter
2.) Get avsmeter - avsinfo

Summary
- avsmeter -avsinfo has problems with too much DLLs
- Loading DLL's consume memory, it depends on the plugin.
e.g. I don't know why 500 pcs of RgTools eat a relatively large memory
- nice to have feature from avsmeter: list approx idle memory consumption after DLL loading

Test #1 (mvtools2.dll 2.7.5.22)
1.) avsmeter testscript.avs
Memory consumption was 242MB with, 168 MB without the 500+ DLL's

2.) avsmeter -avsinfo

Listed all CPP 26 plugins, even the last one
...
C:\Program Files (x86)\AviSynth\plugins\xx_599.dll [2.7.5.22]
C:\Program Files (x86)\AviSynth\plugins\xx_600.dll [2.7.5.22]

Then
Cannot load file 'C:/Program Files (x86)/AviSynth/plugins/xx_138.dll'. Platform returned code 1114:
dynamic link library (DLL) intialization routine failed.

Cannot load file 'C:/Program Files (x86)/AviSynth/plugins/xx_139.dll'. Platform returned code 1114:
dynamic link library (DLL) intialization routine failed.

Test #2 (rgtools.dll 0.93)
1.) avsmeter testscript.avs worked
Memory consumption was 1045MB with, 168 MB without the 500+ DLL's

2.) avsmeter -avsinfo

Listed all CPP 26 plugins, even the last one

..
C:\Program Files (x86)\AviSynth\plugins\xx_599.dll [0.9.3.0]
C:\Program Files (x86)\AviSynth\plugins\xx_600.dll [0.9.3.0]

There were NO avsmeter error messages like with mvtools2

Test #3 (nnedi3.dll 0.9.4.30)
1.) avsmeter testscript.avs worked (but spent a few minutes in "Querying avisynth info")
Memory consumption was 181MB with, 168 MB without the 500+ DLL's

2.) avsmeter -avsinfo

It took some minutes until I got the list (that nnedi3 DLL is huge)

Same, as with mvtools2, I got
Cannot load file 'C:/Program Files (x86)/AviSynth/plugins/xx_138.dll'. Platform returned code 1114:
dynamic link library (DLL) intialization routine failed.

Cannot load file 'C:/Program Files (x86)/AviSynth/plugins/xx_139.dll'. Platform returned code 1114:
dynamic link library (DLL) intialization routine failed.

Test #4 (knlmeanscl.dll)
1.) avsmeter testscript.avs worked
Memory consumption was 227MB with, 168 MB without the 500+ DLL's

2.) avsmeter -avsinfo

There were NO avsmeter error messages like with mvtools2 and nnedi3

[Groucho2004]

Test #1 (mvtools2.dll 2.7.5.22)
1.) avsmeter testscript.avs
Memory consumption was 242MB with, 168 MB without the 500+ DLL's

2.) avsmeter -avsinfo

Listed all CPP 26 plugins, even the last one
...
C:\Program Files (x86)\AviSynth\plugins\xx_599.dll [2.7.5.22]
C:\Program Files (x86)\AviSynth\plugins\xx_600.dll [2.7.5.22]

Then
Cannot load file 'C:/Program Files (x86)/AviSynth/plugins/xx_138.dll'. Platform returned code 1114:
dynamic link library (DLL) intialization routine failed.

Cannot load file 'C:/Program Files (x86)/AviSynth/plugins/xx_139.dll'. Platform returned code 1114:
dynamic link library (DLL) intialization routine failed.
That's most likely due to static linking of this DLL, see Myrsloik's comment above in #2615.


Test #2 (rgtools.dll 0.93)
1.) avsmeter testscript.avs worked
Memory consumption was 1045MB with, 168 MB without the 500+ DLL's
That may be a memory leak in RGTools, but it's just a wild guess.


Test #3 (nnedi3.dll 0.9.4.30)
1.) avsmeter testscript.avs worked (but spent a few minutes in "Querying avisynth info")
Memory consumption was 181MB with, 168 MB without the 500+ DLL's

2.) avsmeter -avsinfo

It took some minutes until I got the list (that nnedi3 DLL is huge)

Same, as with mvtools2, I got
Cannot load file 'C:/Program Files (x86)/AviSynth/plugins/xx_138.dll'. Platform returned code 1114:
dynamic link library (DLL) intialization routine failed.

Cannot load file 'C:/Program Files (x86)/AviSynth/plugins/xx_139.dll'. Platform returned code 1114:
dynamic link library (DLL) intialization routine failed.
See comment on mvtools2

[pinterf]

That's most likely due to static linking of this DLL, see Myrsloik's comment above in #2615.


That may be a memory leak in RGTools, but it's just a wild guess.


See comment on mvtools2

I don't know either what can leak there.
In this phase, only PluginInit is called, right?
Functions implemented in the DLL are added to Avisynth's function list. Only 6 of them exist:
env->AddFunction("RemoveGrain", "c[mode]i[modeU]i[modeV]i[planar]b", Create_RemoveGrain, 0);
env->AddFunction("Repair", "cc[mode]i[modeU]i[modeV]i[planar]b", Create_Repair, 0);
env->AddFunction("Clense", "c[previous]c[next]c[grey]b", Create_Clense, 0);
env->AddFunction("ForwardClense", "c[grey]b", Create_ForwardClense, 0);
env->AddFunction("BackwardClense", "c[grey]b", Create_BackwardClense, 0);
env->AddFunction("VerticalCleaner", "c[mode]i[modeU]i[modeV]i[planar]b", Create_VerticalCleaner, 0);


The test script uses nothing from rgtools.

[Groucho2004]

I don't know either what can leak there.
In this phase, only PluginInit is called, right?Correct. Not even the constructors are called.
One explanation would be that the other two DLLs are statically linked and Avisynth stops enumerating after the first DLL initialization failure. Have you tried building mvtools2 with dynamic linking to the MS runtimes? It might turn out that it uses just as much memory as RGTools if the enumeration finishes.

[jpsdr]

nnedi3 is build with runtime library option /MT, not /MD.
I must said that i don't realy know very precisely what's the difference, but i've read once that it would be better. I don't remember exactly what the "better" was, probably not having to install redistribuables, but not sure.
Now, if you said that finaly /MD is better, i don't mind switching for the next releases.

[real.finder]

nnedi3 is build with runtime library option /MT, not /MD.
I must said that i don't realy know very precisely what's the difference, but i've read once that it would be better. I don't remember exactly what the "better" was, probably not having to install redistribuables, but not sure.
Now, if you said that finaly /MD is better, i don't mind switching for the next releases.

http://forum.doom9.org/showthread.php?p=1736106#post1736106

in my opinion for icl make it MT and for msvc make it MD

[Groucho2004]

nnedi3 is build with runtime library option /MT, not /MD.
I must said that i don't realy know very precisely what's the difference, but i've read once that it would be better. I don't remember exactly what the "better" was, probably not having to install redistribuables, but not sure.
Now, if you said that finaly /MD is better, i don't mind switching for the next releases.
There are at least 3 reasons I can think of why dynamically linking DLLs against the MS runtimes is preferable:

1. It consumes less system resources when the DLL is loaded multiple times

2. See this article (https://msdn.microsoft.com/en-us/library/abx4dbyh(v=vs.140).aspx) on MSDN, particularly these paragraphs:
Using the statically linked CRT implies that any state information saved by the C runtime library will be local to that instance of the CRT. For example, if you use strtok, _strtok_l, wcstok, _wcstok_l, _mbstok, _mbstok_l when using a statically linked CRT, the position of the strtok parser is unrelated to the strtok state used in code in the same process (but in a different DLL or EXE) that is linked to another instance of the static CRT. In contrast, the dynamically linked CRT shares state for all code within a process that is dynamically linked to the CRT. This concern does not apply if you use the new more secure versions of these functions; for example, strtok_s does not have this problem.

Because a DLL built by linking to a static CRT will have its own CRT state, it is not recommended to link statically to the CRT in a DLL unless the consequences of this are specifically desired and understood. For example, if you call _set_se_translator in an executable that loads the DLL linked to its own static CRT, any hardware exceptions generated by the code in the DLL will not be caught by the translator, but hardware exceptions generated by code in the main executable will be caught.

...

If you have more than one DLL or EXE, then you may have more than one CRT, whether or not you are using different versions of Visual C++. For example, statically linking the CRT into multiple DLLs can present the same problem. Developers encountering this problem with static CRTs have been instructed to compile with /MD to use the CRT DLL. If your DLLs pass CRT resources across the DLL boundary, you may encounter issues with mismatched CRTs and need to recompile your project with Visual C++.


3. Dynamic linking makes sure that the code of the latest runtimes is used (provided that the latest runtimes are installed).

[Groucho2004]

in my opinion for icl make it MT and for msvc make it MD
I'd like to know how you came to that assessment. The Intel compiler uses the same libraries as the MS compiler and therefore requires the same runtimes (and additional Intel runtime libs).

[jpsdr]

Interesting informations, thanks. According to theses, I'll switch to /MD for next releases.
Never thought of reason number 3, even if when you realise it, it's obvious...

[dipje]

3. Dynamic linking makes sure that the code of the latest runtimes is used (provided that the latest runtimes are installed).


Not always true these days with the side-by-side system. Look at the side of the WinSxS folder, a lot of versions of the same DLL files are kept there just to prevent the old Win95/98 DLL hell problem :).

[Groucho2004]

Not always true these days with the side-by-side system. Look at the side of the WinSxS folder, a lot of versions of the same DLL files are kept there just to prevent the old Win95/98 DLL hell problem :).
That nightmare was abandoned by MS with the introduction of VS2010. It's only relevant for VS2005/8.

[pinterf]

O.K., as we have MvTools 10-16 bit, RgTools 10-16bit + float + planar RGB, let's get back to Avisynth+.

For those who can't wait until I prepare a proper release and documentation, please find here a r2337 test build.
edit: replaced the link to the latest dev version

http://www.mediafire.com/file/h6nlacgg1y0pla8/avsplus-r2337.7z

Changes since r2294:

20161208 r2337dev

C interface array compatibility vol#2 (zero size arrays) (AvsPMod)
Merge, MergeChroma, MergeLuma: AVX2 (planar)
Possibly a bit faster text overlay


20161207 r2333dev

Overlay fix


20161206 r2331dev

YUY2 PlaneToY finally works
C interface compatible array-type AVSValue handling (avspmod issue)


20161205 r2327dev

BlankClip parameter "colors" accepts exact color values to use
Color order: Y,U,V,A or R,G,B(,A)
These color values are used as-is, not scaled or converted in any way.
Reason: old colors parameter is int (32 bit) cannot hold three or four 16 bit or float values
Example: BlankClip(width=1920,height=1080,length=1000,pixel_type="RGB64", colors=[64000,32768,1231,65535])
ExtractY, PlaneToY("Y") accepts YUY2 clip
ExtractR, ExtractG, ExtractB, ExtractA,
and
PlaneToY("R"), PlaneToY("G"), PlaneToY("B"), PlaneToY("A")
functions are accepting packed RGB input (RGB24/32/48/64)
They are converted to planar RGB on-the-fly before plane extraction
Histogram "levels" works from Planar RGB.
Color legends show R, G and B.
bits=8..12 parameter is still available for finer ultra-wide histogram display


20161201 r2322dev

constant script arrays
array_variable = [[1,2,3],[4,5,8],"hello"]
dictionary = [["one",1],["two",2]]
empty = []
subarray = array_variable[0]
val = subarray[2]
val2 = array_variable[1,3]
str = array_variable[2]
n = ArraySize(array_variable) #3
n2 = ArraySize(empty) #0
val3 = dictionary["two"]

arrays as filter parameters (named and unnamed):
new 'a' type or use '.' (any) and check AVSValue IsArray()
todo: maybe .+ or *+ syntax?
Planar RGB <-> YUV: SSE2 (SSE4)
Planar RGB <-> Packed RGB32/64: SSE2



20161120:

make PlanarRGB TurnLeft, TurnRight work again.
(too strict check in PlaneToY)


20161116

new functions for plane extraction
ExtractX, where X = R,G,B,Y,U,V,A
Extended function
old: YToUV(clip clipU, clip clipV [, clip clipY ] )
new: YToUV(clip clipU, clip clipV [, clip clipY [, clip clipA] ] )

YToUV accepts optional alpha clip after Y clip

Example
U = source.UToY8()
V = source.VToY8()
Y = source.ConvertToY()
A = source.AddAlphaPlane(128).PlaneToY("A")
# swaps V, U and A, Y
YToUV(V,U,A,Y).Histogram("levels").Info().RemoveAlphaPlane()

New function
CombinePlanes(clip1 [,clip2, clip3, clip4], string planes [, string source_planes, string pixel_type, string sample_clip])

Combines planes of source clip(s) into a target clip

If sample_clip is given, target clip properties are copied from that clip
If no sample_clip is provided, then clip1 provides the template for target clip
An optional pixel_type string (e.g."YV24", "YUV420PS", "RGBP8") can override the base video format.

If the source clip count is less than the given planes defined, then the last available clip is used as a source.

string planes
the target plane order (e.g. "YVU", "YYY", "RGB")
missing target planes will be undefined in the target

string source_planes (optional)
the source plane order, defaulting to "YUVA" or "RGBA" depending on the video format

Example#1
#combine greyscale clips into YUVA clip
U8 = source.UToY8() # or ExtractU
V8 = source.VToY8() # or ExtractV
Y8 = source.ConvertToY() # or ExtractY
A8 = source.AddAlphaPlane(128).PlaneToY("A") # or ExtractA
CombinePlanes(Y8, U8, V8, A8, planes="YUVA", source_planes="YYYY", sample_clip=source) #pixel_type="YUV444P8"

Example#2
# Copy planes between planar RGB(A) and YUV(A) without any conversion
# yuv 4:4:4 <-> planar rgb
source = last.ConvertBits(32) # 4:4:4
cast_to_planarrgb = CombinePlanes(source, planes="RGB", source_planes="YUV", pixel_type="RGBPS")
# get back a clip identical with "source"
cast_to_yuv = CombinePlanes(cast_to_planarrgb, planes="YUV", source_planes="RGB", pixel_type="YUV444PS")

Example#3
#create a black and white planar RGB clip using Y channel
#source is a YUV clip
grey = CombinePlanes(source, planes="RGB", source_planes="YYY", pixel_type="RGBP8")

Example#4
#copy luma from one clip, U and V from another
#source is the template
#sourceY is a Y or YUV clip
#sourceUV is a YUV clip
grey = CombinePlanes(sourceY, sourceUV, planes="YUV", source_planes="YUV", sample_clip = source)



edit: test version updated

[LigH]

http://cosgan.de/images/smilie/froehlich/e035.gif How much faster could "benchmark" scripts like QTGMC be when optimized for all these new features? Just starting with support of planar YUV with fine chroma subsampling... http://cosgan.de/images/smilie/froehlich/e015.gif

[Motenai Yoda]

with this last test build avspmod doesn't work, at least on my spec

[pinterf]

with this last test build avspmod doesn't work, at least on my spec
I'm trying this version (x86) and it works, at least I'm getting the right preview.
http://forum.doom9.org/showpost.php?p=1733655&postcount=1148

However there is an error window:
Error parsing ArrayGet plugin parameters: unknown character 'a'
Error parsing ArrayGet plugin parameters: unknown character 'a'
Error parsing ArraySize plugin parameters: unknown character 'a'
Error parsing BlankClip plugin parameters: unknown character 'a'
Error parsing BlankClip plugin parameters: unknown character 'a'
Exception WindowsError: 'exception: access violation reading 0x4049D7D0' in
<bound method AVS_Value.__del__ of [None, None, None]> ignored
Exception WindowsError: 'exception: access violation reading 0x4030FFF0' in
<bound method AVS_Value.__del__ of [None, None, None]> ignored

AvsPMod is enumerating all internal functions and parses their parameters. This parameter type 'a' is new to this Avisynth Plus version, it is for array-type parameters. But it seems it didn't break AvsPMod for me.
As for the exceptions, I cannot tell what they are meaning.
Any other experiences?

Edit:
regarding the exceptions.
it must be a C interface that may interfere with the array handling. Array-type AVSValue now copies all array elements when assigned to another AVSValue.

The old AVSValue stores only a pointer on the child AVSValue elements.
When AVSValue is free'd the elements are still held in memory and won't get freed.

For the new behaviour, AVSValue can hold elements that can also be arrays, they can even be nested. All AVSValue elements of an array are copied, not just the reference. When a child element is array, it is also copied, etc.... What happens when an array-type AVSValue is freed? Avisynth core now resursively frees up all AVSValue within an array, because it can do it safely, as the array creation and copy ensures that the elements were really copied.

I guess that when C Interface uses avs_release_value, this interferes with this logic.
AvsPMod allocates the main array-type AVSValue, allocates array element AVSValues on its own. When avs_release_value is called, it tries to free up array elements that were not allocated by avs core. It's not clear for me, what happens, never used C interface, but this is my assumption, I have to investigate this.

[pinterf]

Ok, let's try this one:

http://www.mediafire.com/file/90d7qa1kqj6in07/avsplus-r2331.7z

Changes since r2294: see above. Last change:

20161206 r2331dev

YUY2 PlaneToY
C interface compatible array-type AVSValue handling (avspmod issue)

[mp3dom]

I'm getting some problems loading a transparent PNG (a logo) and add it on a video using overlay.
The alpha from the PNG seems to be read just fine, but it's the "24bit" of the full 32bit PNG itself that are read with lots of artefacts (mainly "blocks" not available in the original image).
ImageSource and ImageReader both gives the same output.
With regular AVS 2.6 the same PNG/overlay works as expected.

Syntax:
logo=imagesource("logo.png",pixel_type="rgb32")
overlay(video,logo,mask=logo.showalpha())

[LigH]

ImageSource and ImageReader both gives the same output.

Of course, for most input formats they are just aliases of one single function. A difference might exist if you change the decoder, e.g. using DevIL or not.

Do you have samples of such wrong results (original image + wrong overlay result in a script)? I wonder where such issues appear, I could imagine in areas which should be completely transparent: Here the alpha channel may hide the fact that there are areas of full transparent color A next to full transparent color B, which would appear visibly if the transparency is incomplete by mistake. But then it may be rather in Overlay than in ImageSource.

Just a wild guess: Alpha channels are usual rather in RGB formats and should not have coring applied, even when the overlay result is in YUV format.

[pinterf]

I'm getting some problems loading a transparent PNG (a logo) and add it on a video using overlay.
The alpha from the PNG seems to be read just fine, but it's the "24bit" of the full 32bit PNG itself that are read with lots of artefacts (mainly "blocks" not available in the original image).
ImageSource and ImageReader both gives the same output.
With regular AVS 2.6 the same PNG/overlay works as expected.

Syntax:
logo=imagesource("logo.png",pixel_type="rgb32")
overlay(video,logo,mask=logo.showalpha())
Tried it with a sample png from here (http://bellard.org/bpg/gallery2.html) and I can see no garbage.
Which Avisynth Plus version are you using?

[pinterf]

http://cosgan.de/images/smilie/froehlich/e035.gif How much faster could "benchmark" scripts like QTGMC be when optimized for all these new features? Just starting with support of planar YUV with fine chroma subsampling... http://cosgan.de/images/smilie/froehlich/e015.gif
I don't expect speed gain, unless the heavily used filters are optimized further. Maybe you can omit some YUY2<->YV16 conversions.

[mp3dom]

I'm using r2294.
Original image:
https://www.sendspace.com/file/ad7xdd

This is the alpha (correct):
http://116.imagebam.com/download/hau94MFLNxU91YNOiKHdeg/51897/518962355/Alpha.png

This is the image without alpha (wrong):
http://115.imagebam.com/download/QWDJ8-0ybxLB_02_Bb03eg/51897/518962359/Image.png

Final result with overlay (wrong):
http://116.imagebam.com/download/4mopaW-366YWLIqF7xow5w/51897/518962366/Overlay.png

[pinterf]

I'm using r2294.
Original image:
https://www.sendspace.com/file/ad7xdd

This is the alpha (correct):
http://116.imagebam.com/download/hau94MFLNxU91YNOiKHdeg/51897/518962355/Alpha.png

This is the image without alpha (wrong):
http://115.imagebam.com/download/QWDJ8-0ybxLB_02_Bb03eg/51897/518962359/Image.png

Final result with overlay (wrong):
http://116.imagebam.com/download/4mopaW-366YWLIqF7xow5w/51897/518962366/Overlay.png
Thanks, this PNG fails.

[pinterf]

mp3dom, thank you for the bug report.

New build, r2333 with Overlay fix:
http://www.mediafire.com/file/u44zj6jixidn3ez/avsplus-r2333.7z

[mp3dom]

Thank you pinterf for the quick check, but I'm still getting the same result :confused:

[pinterf]

Try with pc_range=true

[mp3dom]

Setting pc_range=true, indeed, fixed the output in the right way, thanks!

Just asking: Is it right that when opening the png (either 32bit or forcing 24bit) with imagesource (without applying any overlay), the image is still blocky like in my previous example?

[shekh]

Setting pc_range=true, indeed, fixed the output in the right way, thanks!

Just asking: Is it right that when opening the png (either 32bit or forcing 24bit) with imagesource (without applying any overlay), the image is still blocky like in my previous example?

png must be multiplied by alpha, this is normal

[pinterf]

Yes, this png have only 0 and 255 values in rgb, the greyshades are only in the mask , alpha channel.

[mp3dom]

Ok! Thanks again for the quick fix :thanks:

[Motenai Yoda]

Ok, let's try this one:

http://www.mediafire.com/file/90d7qa1kqj6in07/avsplus-r2331.7z

still get nothing than circle cursor and nothing else after launching avspmod x86 or x64 (same r452 ver)
with avsmeter it seems to work

[Groucho2004]

still get nothing than circle cursor and nothing else after launching avspmod x86 or x64 (same r452 ver)
with avsmeter it seems to work
AVSMeter does not use the C interface.

[ajp_anton]

fadein/fadeout don't work:
"BlankClip: color count 13 does not match to component count 3"

[burfadel]

fadein/fadeout don't work:
"BlankClip: color count 13 does not match to component count 3"

Yes, I've come across that as well when trying to use LSFmod.

[ajp_anton]

Suggestion to CombinePlanes: if source clip only has a Y plane and "source_planes" is not set, use the Y plane.
Also, if "planes" is set, why do we need "pixel_type"? Can't "pixel_type" be figured out automatically, or am I missing some case when it can't?

[fAy01]

Ok, let's try this one:

http://www.mediafire.com/file/90d7qa1kqj6in07/avsplus-r2331.7z

Changes since r2294: see above. Last change:

20161206 r2331dev

YUY2 PlaneToY
C interface compatible array-type AVSValue handling (avspmod issue)


I updated to the latest r3333 build. Avspmod is still not working.

Error parsing ArrayGet plugin parameters: unknown character 'a'
Error parsing ArrayGet plugin parameters: unknown character 'a'
Error parsing ArraySize plugin parameters: unknown character 'a'
Error parsing BlankClip plugin parameters: unknown character 'a'
Error parsing BlankClip plugin parameters: unknown character 'a'
Error parsing BlankClip plugin parameters: unknown character 'a'
Error parsing BlankClip plugin parameters: unknown character 'a'

[pinterf]

I updated to the latest r3333 build. Avspmod is still not working.

Error parsing ArrayGet plugin parameters: unknown character 'a'
Error parsing ArrayGet plugin parameters: unknown character 'a'
Error parsing ArraySize plugin parameters: unknown character 'a'
Error parsing BlankClip plugin parameters: unknown character 'a'
Error parsing BlankClip plugin parameters: unknown character 'a'
Error parsing BlankClip plugin parameters: unknown character 'a'
Error parsing BlankClip plugin parameters: unknown character 'a'

These are not fatal errors.
I have just tried 64 bit avspmod and it was producing me an exception and exited before start and was able to debug avisynth. After one more modification it works for me, those error-like warnings are still there of course.

[pinterf]

Daily nightly build: r2337
http://www.mediafire.com/file/h6nlacgg1y0pla8/avsplus-r2337.7z

20161208 r2337dev

C interface array compatibility vol#2 (zero size arrays) (AvsPMod)
Merge, MergeChroma, MergeLuma: AVX2 (planar)
Possibly a bit faster text overlay


Could someone with AVX2 processor check please, whether there is a speed gain in the merge functions? I have only AVX, and using the intel sde emulator is 10 times slower, so I cannot profile.

e.g. for weight=0.3 and 0.5 (this is special: averaging)
a = MergeLuma(x,x2,weight=weight)
b = MergeChroma(x,x2,weight=weight)
c = Merge(x,x2,weight=weight)

Thanks.

[ChaosKing]

I think a found another bug in Overlay. Try negative values for y -> y=-20. x is ok.
The mask is not moving in y direction!?

I used the Test.png from above https://www.sendspace.com/file/ad7xdd


logo = ImageSource("d:\Test.png",pixel_type="rgb32")
overlay(x=60, y=-20, logo, mask=logo.showalpha(), pc_range=true)

[mp3dom]

Hi,
I'm getting an "Access violation - System Exception" in VDub (on both x86/x64) using xy-vsfilter (3.0.0.306) and "MaskSub" function:


MaskSub("Subtitle.ass", 1920, 1080, 23.976, 34000)


Tnx.

[jpsdr]

Log created with: AVSMeter 2.4.4 (x64)
Script file: F:\Pluggin_Tests\TestBench.avs
Command line switches: -l


[OS/Hardware info]
Operating system: Windows 7 (x64) Service Pack 1 (Build 7601)
CPU (brand string): Intel(R) Core(TM) i7-6950X CPU @ 3.00GHz
CPU (code name): Broadwell-E (Core i7)
CPU clock (measured): 4124 MHz
CPU cores / Logical cores: 10 / 20


[Avisynth core info]
VersionString: AviSynth+ 0.1 (r2331, MT, x86_64)
VersionNumber: 2.60
File version: 0.1.0.0
Interface Version: 6
Multi-threading support: Yes
Linker/compiler version: 14.0
Avisynth.dll location: C:\Windows\System32\AviSynth.dll
Avisynth.dll time stamp: 2016-12-06, 14:42:15 (UTC)
PluginDir+ (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64+
PluginDir2_5 (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64


[Clip info]
Number of frames: 10000
Length (hh:mm:ss.ms): 00:06:40.000
Frame width: 3840
Frame height: 2160
Framerate: 25.000 (25/1)
Colorspace: YV12
Audio channels: n/a
Audio bits/sample: n/a
Audio sample rate: n/a
Audio samples: n/a


[Runtime info]
Frames processed: 10000 (0 - 9999)
FPS (min | max | average): 519.1 | 646.0 | 633.5
Memory usage (phys | virt): 53 | 49 MiB
Thread count: 41
CPU usage (average): 5%

Time (elapsed): 00:00:15.785


[Script]
a=Colorbars(width=1920*2,height=1080*2,pixel_type="yv12").killaudio().assumefps(25,1).trim(0,9999)
Merge(a,a,0.5)


Log created with: AVSMeter 2.4.4 (x64)
Script file: F:\Pluggin_Tests\TestBench.avs
Command line switches: -l


[OS/Hardware info]
Operating system: Windows 7 (x64) Service Pack 1 (Build 7601)
CPU (brand string): Intel(R) Core(TM) i7-6950X CPU @ 3.00GHz
CPU (code name): Broadwell-E (Core i7)
CPU clock (measured): 4124 MHz
CPU cores / Logical cores: 10 / 20


[Avisynth core info]
VersionString: AviSynth+ 0.1 (r2337, MT, x86_64)
VersionNumber: 2.60
File version: 0.1.0.0
Interface Version: 6
Multi-threading support: Yes
Linker/compiler version: 14.0
Avisynth.dll location: C:\Windows\System32\AviSynth.dll
Avisynth.dll time stamp: 2016-12-08, 14:45:04 (UTC)
PluginDir+ (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64+
PluginDir2_5 (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64


[Clip info]
Number of frames: 10000
Length (hh:mm:ss.ms): 00:06:40.000
Frame width: 3840
Frame height: 2160
Framerate: 25.000 (25/1)
Colorspace: YV12
Audio channels: n/a
Audio bits/sample: n/a
Audio sample rate: n/a
Audio samples: n/a


[Runtime info]
Frames processed: 10000 (0 - 9999)
FPS (min | max | average): 505.4 | 662.4 | 648.3
Memory usage (phys | virt): 53 | 49 MiB
Thread count: 41
CPU usage (average): 6%

Time (elapsed): 00:00:15.424


[Script]
a=Colorbars(width=1920*2,height=1080*2,pixel_type="yv12").killaudio().assumefps(25,1).trim(0,9999)
Merge(a,a,0.5)

If before AVX2 you allready had AVX, i'm not sure if the difference will be huge.

[pinterf]

I think a found another bug in Overlay. Try negative values for y -> y=-20. x is ok.
The mask is not moving in y direction!?

I used the Test.png from above https://www.sendspace.com/file/ad7xdd


logo = ImageSource("d:\Test.png",pixel_type="rgb32")
overlay(x=60, y=-20, logo, mask=logo.showalpha(), pc_range=true)
Confirmed, fixed.

Mask is converted to greyscale (Y only, w/o U and V) unless the greymask parameter is set to false.

Internally everything is YUV 4:4:4, and with greymask=true (default) the clip's U and V plane is faked from the Y plane. But only the frame pointers were faked, the pitch of U and V planes (which are zero for a greyscale clip) were still used for y shift calculation (mask_offsetU/V = original_mask_offset + x + y*pitchUV which obviously ignores y when pitchUV is zero)

[pinterf]

[Script]
a=Colorbars(width=1920*2,height=1080*2,pixel_type="yv12").killaudio().assumefps(25,1).trim(0,9999)
Merge(a,a,0.5)

If before AVX2 you already had AVX, i'm not sure if the difference will be huge.
Thanks, could you test it with 0.3, please?

Because 0.5 is a special case: read 2x32 bytes, average them (single command), write 1x32 bytes. It seems, that the memory access is the bottleneck, there is not much difference.

For 0.3 it uses the 0.3 and 0.7 weights for clip1 and clip2 then sums it up, so multiplication and addition takes place.

Regarding AVX, this instruction set has only float (single) 256 bit support. From AVX2 we have integer routines like in SSE2 with double (256 bit e.g. 32 bytes) data width. The original version used SSE2.

[jpsdr]

Thanks, could you test it with 0.3, please?

Results are indeed more interesting.


Log created with: AVSMeter 2.4.4 (x64)
Script file: F:\Pluggin_Tests\TestBench.avs
Command line switches: -l


[OS/Hardware info]
Operating system: Windows 7 (x64) Service Pack 1 (Build 7601)
CPU (brand string): Intel(R) Core(TM) i7-6950X CPU @ 3.00GHz
CPU (code name): Broadwell-E (Core i7)
CPU clock (measured): 4124 MHz
CPU cores / Logical cores: 10 / 20


[Avisynth core info]
VersionString: AviSynth+ 0.1 (r2331, MT, x86_64)
VersionNumber: 2.60
File version: 0.1.0.0
Interface Version: 6
Multi-threading support: Yes
Linker/compiler version: 14.0
Avisynth.dll location: C:\Windows\System32\AviSynth.dll
Avisynth.dll time stamp: 2016-12-06, 14:42:15 (UTC)
PluginDir+ (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64+
PluginDir2_5 (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64


[Clip info]
Number of frames: 10000
Length (hh:mm:ss.ms): 00:06:40.000
Frame width: 3840
Frame height: 2160
Framerate: 25.000 (25/1)
Colorspace: YV12
Audio channels: n/a
Audio bits/sample: n/a
Audio sample rate: n/a
Audio samples: n/a


[Runtime info]
Frames processed: 10000 (0 - 9999)
FPS (min | max | average): 252.5 | 390.1 | 384.1
Memory usage (phys | virt): 53 | 50 MiB
Thread count: 41
CPU usage (average): 5%

Time (elapsed): 00:00:26.033


[Script]
a=Colorbars(width=1920*2,height=1080*2,pixel_type="yv12").killaudio().assumefps(25,1).trim(0,9999)
Merge(a,a,0.3)


Log created with: AVSMeter 2.4.4 (x64)
Script file: F:\Pluggin_Tests\TestBench.avs
Command line switches: -l


[OS/Hardware info]
Operating system: Windows 7 (x64) Service Pack 1 (Build 7601)
CPU (brand string): Intel(R) Core(TM) i7-6950X CPU @ 3.00GHz
CPU (code name): Broadwell-E (Core i7)
CPU clock (measured): 4124 MHz
CPU cores / Logical cores: 10 / 20


[Avisynth core info]
VersionString: AviSynth+ 0.1 (r2337, MT, x86_64)
VersionNumber: 2.60
File version: 0.1.0.0
Interface Version: 6
Multi-threading support: Yes
Linker/compiler version: 14.0
Avisynth.dll location: C:\Windows\System32\AviSynth.dll
Avisynth.dll time stamp: 2016-12-08, 14:45:04 (UTC)
PluginDir+ (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64+
PluginDir2_5 (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64


[Clip info]
Number of frames: 10000
Length (hh:mm:ss.ms): 00:06:40.000
Frame width: 3840
Frame height: 2160
Framerate: 25.000 (25/1)
Colorspace: YV12
Audio channels: n/a
Audio bits/sample: n/a
Audio sample rate: n/a
Audio samples: n/a


[Runtime info]
Frames processed: 10000 (0 - 9999)
FPS (min | max | average): 420.9 | 546.9 | 536.8
Memory usage (phys | virt): 53 | 49 MiB
Thread count: 41
CPU usage (average): 6%

Time (elapsed): 00:00:18.630


[Script]
a=Colorbars(width=1920*2,height=1080*2,pixel_type="yv12").killaudio().assumefps(25,1).trim(0,9999)
Merge(a,a,0.3)

[real.finder]

hi pinterf

I check to see if this bug http://forum.doom9.org/showpost.php?p=1736293&postcount=55 still in avs+ after all this work on avs+ then I see it's still not fixed

beside the Dither_convert_rgb_to_yuv(cplace ="dv",interlaced=true) I made this for YV16 to test


Function do_PAL_dv (c)
{
c
assert(isyv16(), "only yv16 is allowed.")
SeparateFields()
y=last
B=UToY8()
R=VToY8()

YToUV(b.BicubicResize(b.Width(), Height()/2, src_top= 0.5),r.BicubicResize(r.Width(), Height()/2, src_top=-0.5),y)
Weave()
}

[fAy01]

Daily nightly build: r2337
http://www.mediafire.com/file/h6nlacgg1y0pla8/avsplus-r2337.7z

20161208 r2337dev

C interface array compatibility vol#2 (zero size arrays) (AvsPMod)
Merge, MergeChroma, MergeLuma: AVX2 (planar)
Possibly a bit faster text overlay


Could someone with AVX2 processor check please, whether there is a speed gain in the merge functions? I have only AVX, and using the intel sde emulator is 10 times slower, so I cannot profile.

e.g. for weight=0.3 and 0.5 (this is special: averaging)
a = MergeLuma(x,x2,weight=weight)
b = MergeChroma(x,x2,weight=weight)
c = Merge(x,x2,weight=weight)

Thanks.

Try opening an h264 stream with ffms2. It won't display.

[pinterf]

Chroma placement things and interlaced parameter are not valid for yv16 now. Interlaced is silently set to false if source is not 4:2:0. This may be too strict.
For yv12 test in the link: how do you know which is the correct one?

[ajp_anton]

Do you have any plans on Layer/Overlay? Would it be possible to add colorspaces to Layer, to be able to use it without the forced conversions of Overlay?

[Wilbert]

@pinterf, the bug real.finder is pointing to is fixed in the csv tree of regular AviSynth.

[pinterf]

@pinterf, the bug real.finder is pointing to is fixed in the csv tree of regular AviSynth.
Thanks, I asked it (how can we know which one is wrong - avs or dither tools?), because yes, I can see the visual difference between Dither tools conversion and avisynth conversion, for dv target chroma placement. And I also checked the 2.6.1 source and there was no difference in constants between avs+ and 2.6.1. (I checked convert_planar.cpp Aug.01, 2015). Is there any other place I should check against?

edit: found it

[Sm3n]

Sorry if it's not the right place to talk about that. Dunno if the source of my issue is avisynth+.

About a week now that my x264 encoding process does crazy stuff. After hours of encoding in the middle of a process my cpu which reach most of the time the 100% falls about 20-30%.
I tried to run my avs script directly into x264, using avs4x26x, or piping it using avs2yuv_x64. Same result.
My logic would say it's due to a bad script which makes process to fail (I wonder why because it appears with no reason):

SetMemoryMax(1600)
DGSource("Test1.dgi",fieldop=0,deinterlace=0)
QTGMC(preset="Medium", FPSDivisor=2, DftThreads = 1, EdiThreads = 1)
#crop(2, 2, -2, -2)
Spline36Resize(1280,720)
prefetch(4)

I tried avs+ 2172 and the last mod found here. Here are my avsmeter logs x86 & x64:

AVSMeter 2.3.8 (x86) - Copyright (c) 2012-2016, Groucho2004

[OS/Hardware info]
Operating system: Windows 8.1 (x64) (Build 9600)
CPU: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz
Ivy Bridge (Core i7)
CPU clock (measured): 4346 MHz
CPU cores / Logical cores: 4 / 8

VersionString: AviSynth+ 0.1 (r2337, MT, i386)
VersionNumber: 2.60
File version: 0.1.0.0
Interface Version: 6
Multi-threading support: Yes
Linker/compiler version: 14.0
Avisynth.dll location: C:\Windows\SysWOW64\AviSynth.dll
Avisynth.dll time stamp: 2016-12-08, 18:02:40
PluginDir+ (HKLM, x86): C:\Program Files (x86)\AviSynth+\plugins+
PluginDir2_5 (HKLM, x86): C:\Program Files (x86)\AviSynth+\plugins


[Avisynth CPP 2.6 plugins]
C:\Program Files (x86)\AviSynth+\plugins+\ConvertStacked.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins+\DirectShowSource.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins+\ImageSeq.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins+\Shibatch.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins+\TimeStretch.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins+\VDubFilter.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins+\yadifmod2.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins+\yadifmod2_avx2.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\avss_26.dll (2.0.0.13)
C:\Program Files (x86)\AviSynth+\plugins\DGDecodeNV.dll (0.0.0.2052)
C:\Program Files (x86)\AviSynth+\plugins\DirectShowSource.dll (2.6.1.0)
C:\Program Files (x86)\AviSynth+\plugins\ffms2.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\masktools2.dll (2.1.0.0)
C:\Program Files (x86)\AviSynth+\plugins\MSharpen.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\mvtools2.dll (2.7.0.22)
C:\Program Files (x86)\AviSynth+\plugins\nnedi3.dll (0.9.4.32)
C:\Program Files (x86)\AviSynth+\plugins\RgTools.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\TCPDeliver.dll (2.6.1.0)


[Avisynth CPP 2.5 plugins]
C:\Program Files (x86)\AviSynth+\plugins+\flash3kyuu_deband.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\AddGrainC.dll (1.5.2.0)
C:\Program Files (x86)\AviSynth+\plugins\AudioLimiter.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\avss.dll (2.0.0.13)
C:\Program Files (x86)\AviSynth+\plugins\avstp.dll (1.0.3.0)
C:\Program Files (x86)\AviSynth+\plugins\aWarpSharp.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\BassAudio.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\ColorMatrix.dll (2.5.0.0)
C:\Program Files (x86)\AviSynth+\plugins\Convolution3DYV12.dll (1.0.0.5)
C:\Program Files (x86)\AviSynth+\plugins\DctFilter.dll (0.0.1.4)
C:\Program Files (x86)\AviSynth+\plugins\deblock.dll (1.2.0.0)
C:\Program Files (x86)\AviSynth+\plugins\Decomb.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\dfttest.dll (1.9.4.0)
C:\Program Files (x86)\AviSynth+\plugins\DGDecode.dll (1.5.8.0)
C:\Program Files (x86)\AviSynth+\plugins\dither.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\EEDI2.dll (0.9.2.0)
C:\Program Files (x86)\AviSynth+\plugins\EEDI2.dll_back (0.9.2.0)
C:\Program Files (x86)\AviSynth+\plugins\eedi3.dll (0.9.1.0)
C:\Program Files (x86)\AviSynth+\plugins\FFT3DFilter.dll (2.1.1.0)
C:\Program Files (x86)\AviSynth+\plugins\FFT3dGPU.dll (0.8.2.0)
C:\Program Files (x86)\AviSynth+\plugins\FillMargins.dll (1.0.2.0)
C:\Program Files (x86)\AviSynth+\plugins\FluxSmooth.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\gradfun2db.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\GRunT.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\LeakKernelDeint.dll (1.5.4.0)
C:\Program Files (x86)\AviSynth+\plugins\MDeblock.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\MDeblockS.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\NicAudio.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\nnedi.dll (1.3.0.0)
C:\Program Files (x86)\AviSynth+\plugins\nnedi2.dll (1.6.0.0)
C:\Program Files (x86)\AviSynth+\plugins\RemoveGrainSSE2.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\RemoveGrainSSE3.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\RemoveGrainSSE3.dll_back (n/a)
C:\Program Files (x86)\AviSynth+\plugins\RepairSSE2.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\RepairSSE3.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\Rotate.dll (1.3.4.0)
C:\Program Files (x86)\AviSynth+\plugins\SSE2Tools.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\TDeint.dll (1.1.0.0)
C:\Program Files (x86)\AviSynth+\plugins\TDeint.dll_back (1.1.0.0)
C:\Program Files (x86)\AviSynth+\plugins\TIVTC.dll (1.0.5.0)
C:\Program Files (x86)\AviSynth+\plugins\TomsMoComp.dll (0.0.1.8)
C:\Program Files (x86)\AviSynth+\plugins\TTempSmooth.dll (0.9.4.0)
C:\Program Files (x86)\AviSynth+\plugins\UnDot.dll (0.0.1.1)
C:\Program Files (x86)\AviSynth+\plugins\unsharpHQ_v05_x86.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\VariableBlur.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\VerticalCleanerSSE2.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins\VSFilter.dll (3.0.0.306)
C:\Program Files (x86)\AviSynth+\plugins\warpsharp.dll (n/a)


[Avisynth C 2.5 plugins]
C:\Program Files (x86)\AviSynth+\plugins\yadif.dll (1.7.0.0)
C:\Program Files (x86)\AviSynth+\plugins\yadif.dll_bak (1.7.0.0)

AVSMeter 2.3.8 (x64) - Copyright (c) 2012-2016, Groucho2004

[OS/Hardware info]
Operating system: Windows 8.1 (x64) (Build 9600)
CPU: Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz
Ivy Bridge (Core i7)
CPU clock (measured): 4346 MHz
CPU cores / Logical cores: 4 / 8

VersionString: AviSynth+ 0.1 (r2337, MT, x86_64)
VersionNumber: 2.60
File version: 0.1.0.0
Interface Version: 6
Multi-threading support: Yes
Linker/compiler version: 14.0
Avisynth.dll location: C:\Windows\System32\AviSynth.dll
Avisynth.dll time stamp: 2016-12-08, 15:45:04
PluginDir+ (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64+
PluginDir2_5 (HKLM, x64): C:\Program Files (x86)\AviSynth+\plugins64


[Avisynth CPP 2.6 plugins]
C:\Program Files (x86)\AviSynth+\plugins64+\ConvertStacked.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins64+\DirectShowSource.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins64+\ImageSeq.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins64+\Shibatch.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins64+\TimeStretch.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins64+\VDubFilter.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins64+\yadifmod2.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins64+\yadifmod2_avx2.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins64\DGDecodeNV.dll (0.0.0.2052)
C:\Program Files (x86)\AviSynth+\plugins64\masktools2.dll (2.1.0.0)
C:\Program Files (x86)\AviSynth+\plugins64\msharpen.dll (n/a)
C:\Program Files (x86)\AviSynth+\plugins64\mvtools2.dll (2.7.0.22)
C:\Program Files (x86)\AviSynth+\plugins64\nnedi3.dll (0.9.4.32)
C:\Program Files (x86)\AviSynth+\plugins64\RgTools.dll (n/a)


[Avisynth CPP 2.5 plugins]
C:\Program Files (x86)\AviSynth+\plugins64\TIVTC.dll (1.0.5.0)


[Avisynth CPP 2.0 plugins]
C:\Program Files (x86)\AviSynth+\plugins64\VSFilter.dll (3.0.0.306)


[Plugin errors]
---------------------------------------------------------------------------

Error loading "C:\Program Files (x86)\AviSynth+\plugins64\DGDecode.dll"
Cannot load 32 bit DLL with 64 bit Avisynth

---------------------------------------------------------------------------

"C:\Program Files (x86)\AviSynth+\plugins64\mvtools2.dll"

Dependencies that couldn't be loaded:
libfftw3f-3.dll

Note: libfftw3f-3.dll can be downloaded here:
http://www.fftw.org/install/windows.html

Could it be a hardware failure? (RAM) Or a too high settings for SetMemoryMax and prefetch?

I really need to understand for fixing it. I'd love to have your help.

[pinterf]

Hi,
I'm getting an "Access violation - System Exception" in VDub (on both x86/x64) using xy-vsfilter (3.0.0.306) and "MaskSub" function:


MaskSub("Subtitle.ass", 1920, 1080, 23.976, 34000)


Tnx.
It turned out that it is a filter using avisynth 2.5 plugin interface.

I'm not happy, now I have a deeper clue about the caveats of keeping the backward compatibility with that what is called "baked code".

In its current form I am not able to keep the compatibility between avisynth 2.5 interface and my new AVSValue handling schema. The problem affects arrays (and such, the filter parameter passing). Although the array creation is transparent when 2.6 interface is used and automatically uses the new mechanism for creating and copying AVSValue types, but plugins using "baked code" avs 2.5 interface are not knowing about the feature and use the array creation codes hardcoded in the 2.5 interface.

And since I simply not able to check, what kind of interface made a call to ScriptEnvironment::Invoke, I have to revert that array feature. O.K. having script arrays are only a nice addition to the language but there was quite a bit of work with this feature.

So it seems that I have to revert my nice new array mechanism, even from the dev version of my builds. As there are still some plugins out there with the 2.5 interface, I cannot make avs+ incompatible with them and cause users inconveniance.

[pinterf]

Sorry if it's not the right place to talk about that. Dunno if the source of my issue is avisynth+.

About a week now that my x264 encoding process does crazy stuff. After hours of encoding in the middle of a process my cpu which reach most of the time the 100% falls about 20-30%.
I tried to run my avs script directly into x264, using avs4x26x, or piping it using avs2yuv_x64. Same result.
My logic would say it's due to a bad script which makes process to fail (I wonder why because it appears with no reason)
[...]

Could it be a hardware failure? (RAM) Or a too high settings for SetMemoryMax and prefetch?

I really need to understand for fixing it. I'd love to have your help.
There was a topic some month ago on such a mysterious case.
The solution was that the processor got too hot after a while, and an automatic thermal throttle was kicking in. Try monitoring the processor, and check the heatsink and fan.

[pinterf]

Or there is memory leak somewhere but it needs running your script with avsmeter, perhaps with logging enabled to see whether the slowdown occurs after a specific frame count or memory consumption.

[pinterf]

New week, new build, new adventures.
This time I had to remove the script array feature that has caused me and you headaches.
http://www.mediafire.com/file/gbpdu52cv3azvrq/avsplus-r2343.7z

20161211 r2343dev

Overlay: use y offset when greymask=true (fix)
Fix DV chroma positioning (UV swapped), interlaced parameter check for 4:2:0
(fix by IanB in classic Avisynth)
BitBlt in 32 bit Avisynth:
for processors with AVX or better ignore tricky isse memcpy replacement, trust in memcpy (test)
(x64 is O.K., it always used memcpy)
Merge: use stream_load for AVX2
VDubFilter.dll (now bundled):
convert 'd' double and 'l' long typed parameters to 'f' float and 'i' int for poor AviSynth, thus allowing the usage of such virtualdub filters
remove script array (new AVSValue schema) feature, cannot make it compatible with Invoke from v2.5 plugins until I figure out a workaround or such plugins would slowly distinct. <sniff> <sniff>

[Sm3n]

There was a topic some month ago on such a mysterious case.
The solution was that the processor got too hot after a while, and an automatic thermal throttle was kicking in. Try monitoring the processor, and check the heatsink and fan.

Or there is memory leak somewhere but it needs running your script with avsmeter, perhaps with logging enabled to see whether the slowdown occurs after a specific frame count or memory consumption.

I'll look into it and post you the log if needed.
:thanks:

[pinterf]

Results are indeed more interesting.


[OS/Hardware info]
Operating system: Windows 7 (x64) Service Pack 1 (Build 7601)
CPU (brand string): Intel(R) Core(TM) i7-6950X CPU @ 3.00GHz
CPU (code name): Broadwell-E (Core i7)
CPU clock (measured): 4124 MHz
CPU cores / Logical cores: 10 / 20

VersionString: AviSynth+ 0.1 (r2331, MT, x86_64)
FPS (min | max | average): 252.5 | 390.1 | 384.1

VersionString: AviSynth+ 0.1 (r2337, MT, x86_64)
FPS (min | max | average): 420.9 | 546.9 | 536.8

[Script]
a=Colorbars(width=1920*2,height=1080*2,pixel_type="yv12").killaudio().assumefps(25,1).trim(0,9999)
Merge(a,a,0.3)


Thanks for the test. That is spectacular difference, I wish every script has tons of Merge :)
One last request: could you repeat this test with the r2343?

[real.finder]

New week, new build, new adventures.
This time I had to remove the script array feature that has caused me and you headaches.
http://www.mediafire.com/file/gbpdu52cv3azvrq/avsplus-r2343.7z

20161211 r2343dev

Overlay: use y offset when greymask=true (fix)
Fix DV chroma positioning (UV swapped), interlaced parameter check for 4:2:0
(fix by IanB in classic Avisynth)
BitBlt in 32 bit Avisynth:
for processors with AVX or better ignore tricky isse memcpy replacement, trust in memcpy (test)
(x64 is O.K., it always used memcpy)
Merge: use stream_load for AVX2
VDubFilter.dll (now bundled):
convert 'd' double and 'l' long typed parameters to 'f' float and 'i' int for poor AviSynth, thus allowing the usage of such virtualdub filters
remove script array (new AVSValue schema) feature, cannot make it compatible with Invoke from v2.5 plugins until I figure out a workaround or such plugins would slowly distinct. <sniff> <sniff>


that fix the problem of PAL DV :thanks:

[fAy01]

New week, new build, new adventures.
This time I had to remove the script array feature that has caused me and you headaches.
http://www.mediafire.com/file/gbpdu52cv3azvrq/avsplus-r2343.7z

20161211 r2343dev

Overlay: use y offset when greymask=true (fix)
Fix DV chroma positioning (UV swapped), interlaced parameter check for 4:2:0
(fix by IanB in classic Avisynth)
BitBlt in 32 bit Avisynth:
for processors with AVX or better ignore tricky isse memcpy replacement, trust in memcpy (test)
(x64 is O.K., it always used memcpy)
Merge: use stream_load for AVX2
VDubFilter.dll (now bundled):
convert 'd' double and 'l' long typed parameters to 'f' float and 'i' int for poor AviSynth, thus allowing the usage of such virtualdub filters
remove script array (new AVSValue schema) feature, cannot make it compatible with Invoke from v2.5 plugins until I figure out a workaround or such plugins would slowly distinct. <sniff> <sniff>


FFms2 is still not working with the new avs+ build. Avspmod still cannot display the video. Whereas, yatta throws this error when I try to open any 10bit h264 ffms2 indexed stream: http://i.imgur.com/anIgSP9.png

[pinterf]

As the error says. Ffms2 opens the video in native 10 bits. Use ConvertBits(8) after ffms2 or specify a 8 bit format if your filter chain is 8 bit only. Or when using avspmod.

[pinterf]

Suggestion to CombinePlanes: if source clip only has a Y plane and "source_planes" is not set, use the Y plane.
Also, if "planes" is set, why do we need "pixel_type"? Can't "pixel_type" be figured out automatically, or am I missing some case when it can't?
You don't need that.
From my earlier post:

CombinePlanes(clip1 [,clip2, clip3, clip4], string planes [, string source_planes, string pixel_type, string sample_clip])

Combines planes of source clip(s) into a target clip

If sample_clip is given, target clip properties are copied from that clip
If no sample_clip is provided, then clip1 provides the template for target clip
An optional pixel_type string (e.g."YV24", "YUV420PS", "RGBP8") can override the base video format.

[mcjordan]

Compilation break issue:

8> merge_avx2.cpp
8>C:\AviSynthPlus\avs_core\filters\merge_avx2.cpp(75): error C2664: '__m128i _mm_stream_load_si128(__m128i *)': cannot convert argument 1 from 'const __m128i *' to '__m128i *'
8> C:\AviSynthPlus\avs_core\filters\merge_avx2.cpp(75): note: Conversion loses qualifiers
8> C:\AviSynthPlus\avs_core\filters\merge_avx2.cpp(98): note: see reference to function template instantiation 'void average_plane_avx2<uint8_t>(BYTE *,const BYTE *,int,int,int,int)' being compiled

Help?

[pinterf]

Compilation break issue:

8> merge_avx2.cpp
8>C:\AviSynthPlus\avs_core\filters\merge_avx2.cpp(75): error C2664: '__m128i _mm_stream_load_si128(__m128i *)': cannot convert argument 1 from 'const __m128i *' to '__m128i *'
8> C:\AviSynthPlus\avs_core\filters\merge_avx2.cpp(75): note: Conversion loses qualifiers
8> C:\AviSynthPlus\avs_core\filters\merge_avx2.cpp(98): note: see reference to function template instantiation 'void average_plane_avx2<uint8_t>(BYTE *,const BYTE *,int,int,int,int)' being compiled

Help?
Comment on git copied here:
Strange, here
https://msdn.microsoft.com/en-us/library/bb531393(v=vs.120).aspx
__m128i _mm_stream_load_si128(__m128i *p);
is mentioned, and you are seeing that.

However, in my smmintrin.h I can see:
__m128i _mm_stream_load_si128(const __m128i*);

Maybe the header (smmintrin.h) has been changed since vs2013?

Try removing the 'const' from cast body.

[mcjordan]

Thank you, pinterf. I'll try asap.

[ajp_anton]

You don't need that.
From my earlier post:

CombinePlanes(clip1 [,clip2, clip3, clip4], string planes [, string source_planes, string pixel_type, string sample_clip])

Combines planes of source clip(s) into a target clip

If sample_clip is given, target clip properties are copied from that clip
If no sample_clip is provided, then clip1 provides the template for target clip
An optional pixel_type string (e.g."YV24", "YUV420PS", "RGBP8") can override the base video format.

But for example if I want to join three Y8 clips into RGB, I have to specify "RGB" twice: planes="RGB", pixel_type="RGB".

This is how I'd imagine it working:
version.converttoy8
combineplanes(last,last,last,planes="RGB")"CombinePlanes: too many target planes (3)! Target video plane count is 1!"
Why would the target have 1 plane, when I obviously want to map them into RGB?
version.converttoy8
combineplanes(last,last,last,planes="RGB",pixel_type="RGB")I know that just "RGB" is not a pixel type, but consequently there's no way to specify just "RGB". It has to be precise in both planar/packed as well as bits. If I write it wrong, the function won't convert it to what I wrote, it will just say it's wrong. Why ask me to specify it if it already knows what it's supposed to be?
version.converttoy8
combineplanes(last,last,last,planes="RGB",pixel_type="RGBP8")"Source has no such plane "U""
Why not use the only available plane as default, if I don't purposefully try to access an unexisting plane?
version.converttoy8
combineplanes(last,last,last,planes="RGB",source_planes="YYY",pixel_type="RGBP8")This I'm assuming is finally supposed to work, but it crashes both VirtualDub (filtermod) and x264, the two programs I have that can handle Avisynth. Anything I can do to help identify the cause? This is with r2343, both 32- and 64-bits.

[pinterf]

But for example if I want to join three Y8 clips into RGB, I have to specify "RGB" twice: planes="RGB", pixel_type="RGB".

This is how I'd imagine it working:
version.converttoy8
combineplanes(last,last,last,planes="RGB")"CombinePlanes: too many target planes (3)! Target video plane count is 1!"
Why would the target have 1 plane, when I obviously want to map them into RGB?

version.converttoy8
combineplanes(last,last,last,planes="RGB",pixel_type="RGBP8")"Source has no such plane "U""
Why not use the only available plane as default, if I don't purposefully try to access an unexisting plane?
version.converttoy8
combineplanes(last,last,last,planes="RGB",source_planes="YYY",pixel_type="RGBP8")This I'm assuming is finally supposed to work, but it crashes both VirtualDub (filtermod) and x264, the two programs I have that can handle Avisynth. Anything I can do to help identify the cause? This is with r2343, both 32- and 64-bits.
Don't forget that RGBP8 is unknown for these softwares.
In order to make it work or get it shown in VirtualDub, you have to do a ConvertToRGB32().

As the special case when inputs are greyscale, it is indeed a good idea not defaulting source planes to YUV, your proposal is logical.

edit:

version.converttoy8
combineplanes(last,last,last,planes="RGB",pixel_type="RGB")I know that just "RGB" is not a pixel type, but consequently there's no way to specify just "RGB". It has to be precise in both planar/packed as well as bits. If I write it wrong, the function won't convert it to what I wrote, it will just say it's wrong. Why ask me to specify it if it already knows what it's supposed to be?.
This is a very special rule: Wwen inputs are greyscale _and_ planes="RGB" (or RGBA) then the output could be planar RGB or RGBA, keeping the bit-depth of the input clips.

[ajp_anton]

Don't forget that RGBP8 is unknown for these softwares.
In order to make it work or get it shown in VirtualDub, you have to do a ConvertToRGB32().Oh. And I could've sworn it crashed also with a ConvertToYV12, but now it doesn't. Nevermind then =).

This is a very special rule: Wwen inputs are greyscale _and_ planes="RGB" (or RGBA) then the output could be planar RGB or RGBA, keeping the bit-depth of the input clips.
Do we need a special rule here? If planes has any permutation of RGB or RGBA, there's only one thing to do: combine the inputs. Throw an error if bitdepths or resolutions don't match.
If it has any permutation of YUV or YUVA, same thing, except also check if the U/V resolutions match 4:2:2 or 4:2:0 before throwing an error.

Also, I would go even further by making source_planes always default to Y if the source clip is YUV(A), because that's what you're usually processing before combining them, and that's what you're actually seeing when previewing anything. If there's at least one RGB source, then require the source_planes string.

[pinterf]

RGBA and YUVA permutations are working already.
But this latter idea can be confusing, e.g. you can specify only one YUV clip, and the default source plane order is YUV, which is good enough I think.
There is a rule that you can specify less input clips, and if no more clips found in the list, but there are still planes to process, the last one will be automatically used further on.

[ajp_anton]

RGBA and YUVA permutations are working already.
How so? Or did you misunderstand?
If planes="RGB" or "BARG" or "AVYU" (weird examples), why does it need pixel_type? There's only one string that's ever going to be accepted by the filter anyway, why not use that? Does there exist a scenario where the user can actually choose between two different pixel_type strings?

[pinterf]

Sorry, I mean they are working because meanwhile I have done it. Specify planes=RRG or GBRA, it will map to planar rgb. pixel_type is good only when single Y or A target is specified or want a target with alpha plane but not filling all 4 planes.

[fAy01]

As the error says. Ffms2 opens the video in native 10 bits. Use ConvertBits(8) after ffms2 or specify a 8 bit format if your filter chain is 8 bit only. Or when using avspmod.

Why do I have to convert my encode from 10bit to 8bit? It worked fine before. Please help :)

[real.finder]

re did same test here http://forum.doom9.org/showthread.php?p=1745799&highlight=qtgmc#post1745799 but with MP_Pipeline and after edit this http://publishwith.me/ep/pad/view/ro.rDkwcdWn4k9/latest

MP_Pipeline("""
### platform: win64
ColorBars(width=720, height=480, pixel_type="RGB32")
ConvertToYV12()
QTGMC(InputType=1, Ezdenoise=2)
LSFMod(strength=66)
gradfun3()
Prefetch(12)
### ###
""")


and get ~38 fps :goodpost:

[real.finder]

I note that GScriptClip is incompatible with avs+ mt, with mode 2 not work at all and with mode 3 gave random scriptcilp errors

[jpsdr]

If Prefetch is used in a script, is it possible in a plugin to retrieve the value used?
If yes:
- how?
- Is this value allready avaible when AvisynthPluginInit3 is called, or should i have to wait to be within the Create_xxxx to have the value?

[Groucho2004]

If Prefetch is used in a script, is it possible in a plugin to retrieve the value used?
If yes:
- how?
- Is this value allready avaible when AvisynthPluginInit3 is called, or should i have to wait to be within the Create_xxxx to have the value?
See here (http://forum.doom9.org/showthread.php?p=1666404#post1666404) and here (http://forum.doom9.org/showthread.php?p=1666414#post1666414).

[jpsdr]

This answer half... But i still can make tests, to chek if using GetProperty(AEP_FILTERCHAIN_THREADS) inside AvisynthPluginInit3 will allready give me the correct value.

[Groucho2004]

This answer half... But i still can make tests, to chek if using GetProperty(AEP_FILTERCHAIN_THREADS) inside AvisynthPluginInit3 will allready give me the correct value.
GetProperty() is part of IScriptEnvironment2 and not supported by IScriptEnvironment as far as I know. That should answer your second question.

[jpsdr]

I've made some tests, and i'm screwed, as i was afraid. As i suspected, the fact that Prefetch must be at the end of the script made me unable to get the value using GetProperty(AEP_FILTERCHAIN_THREADS) inside AvisynthPluginInit3, or, in worst case, inside Create_xxxx. I'll probably get the information only within GetFrame, but it's too late.
Using the value of the size of the internal threadpool is not interesting because it may lead to create too much threads, so, for now, i'll use the workaround to add a prefetch parameter to my plugins (the purpose is to try to speed-up things with script using prefecth).

[qyot27]

Why do I have to convert my encode from 10bit to 8bit? It worked fine before. Please help :)
You mean it worked fine before high bit depth support was added to FFMS2's AviSynth interface and it downscaled everything to 8bit on its own?

Report the issue in the avspmod or YATTA threads. That's where the problems are, not here.

[real.finder]

if I have 2 mvtools2.dll one that work with 2.5 in non plus folder and one that work with 2.6 in plugins+ I note that the one in the non plus folder is used in encode! is this normal?

[Groucho2004]

if I have 2 mvtools2.dll one that work with 2.5 in non plus folder and one that work with 2.6 in plugins+ I note that the one in the non plus folder is used in encode! is this normal?It should load from the "+" directory first. Run "AVSMeter -avsinfo -log" and post the created log file.

[real.finder]

It should load from the "+" directory first.

Isn't better to have it opposite? first non plus then plus

in AVSMeter -avsinfo show the non plus first then plus one!

whether in avsdeps.log or in avsinfo.log

[jpsdr]

Isn't better to have it opposite? first non plus then plus


I think it's the way avs+ is designed.
The plugins+ directory is "only" for the avs+ system plugins, the plugins directory is for the user plugins. "Theoricaly", you shouldn't put plugins in the plugins+ directory. As it's where are supposed to be the system plugins, it's (from my point of view) normal to have this directory read first.

[Groucho2004]

I think it's the way avs+ is designed.
The plugins+ directory is "only" for the avs+ system plugins, the plugins directory is for the user plugins. "Theoricaly", you shouldn't put plugins in the plugins+ directory. As it's where are supposed to be the system plugins, it's (from my point of view) normal to have this directory read first.
Here's (http://avisynth.nl/index.php/AviSynth%2B#AviSynth.2B.27s_Plugin_Autoloader) how the whole thing works in AVS+. In addition to the plugins that ship with AVS+ you're supposed to put the ones that won't work with classic Avisynth for some reason into the "+" directories.

[tormento]

I usually put 2.6 plugins in + dir and 2.5 in normal.

[real.finder]

Here's (http://avisynth.nl/index.php/AviSynth%2B#AviSynth.2B.27s_Plugin_Autoloader) how the whole thing works in AVS+. In addition to the plugins that ship with AVS+ you're supposed to put the ones that won't work with classic Avisynth for some reason into the "+" directories.

I think this will be better

PluginDir2_5 in Software/Avisynth in HKEY_LOCAL_MACHINE
PluginDir2_5 in Software/Avisynth in HKEY_CURRENT_USER
PluginDir+ in Software/Avisynth in HKEY_LOCAL_MACHINE
PluginDir+ in Software/Avisynth in HKEY_CURRENT_USER

[jpsdr]

Question about the float format. Is there some kind of "rule/limitation", or are value totaly free, and it's normal to have a pixel with value for exemple of 10e-8 or +1e10 or -5000000 ?

[Groucho2004]

Question about the float format. Is there some kind of "rule/limitation", or are value totaly free, and it's normal to have a pixel with value for exemple of 10e-8 or +1e10 or -5000000 ?Do you mean the limits of the float data type? They are defined in "float.h":
#define FLT_DIG 6 /* # of decimal digits of precision */
#define FLT_EPSILON 1.192092896e-07F /* smallest such that 1.0+FLT_EPSILON != 1.0 */
#define FLT_GUARD 0
#define FLT_MANT_DIG 24 /* # of bits in mantissa */
#define FLT_MAX 3.402823466e+38F /* max value */
#define FLT_MAX_10_EXP 38 /* max decimal exponent */
#define FLT_MAX_EXP 128 /* max binary exponent */
#define FLT_MIN 1.175494351e-38F /* min positive value */
#define FLT_MIN_10_EXP (-37) /* min decimal exponent */
#define FLT_MIN_EXP (-125) /* min binary exponent */
#define FLT_NORMALIZE 0
#define FLT_RADIX 2 /* exponent radix */
#define FLT_ROUNDS 1 /* addition rounding: near */

[jpsdr]

No, i mean the limit of the value a pixel can have in a float format.
I should take a look at the avisynth code which convert float to 8bits (if i found it), i think i'll have the answer i'm looking for.

[pinterf]

Float is 0.0 to 1.0 for all planes. Usually not clamped. But the range may change if it is against silent standards, e.g. -0.5 to 0.5 for U and V planes. Now there is no danger of change unless zillions of plugins appear supporting it

[feisty2]

No, i mean the limit of the value a pixel can have in a float format.
I should take a look at the avisynth code which convert float to 8bits (if i found it), i think i'll have the answer i'm looking for.

there SHOULD be no clamping for floating point samples, to make sure that all intermediate data are mathematically correct..
the only exception would be a floating point mask clip, which should be clamped to 0.0 - 1.0

[Myrsloik]

Float is 0.0 to 1.0 for all planes. Usually not clamped. But the range may change if it is against silent standards, e.g. -0.5 to 0.5 for U and V planes. Now there is no danger of change unless zillions of plugins appear supporting it

Why u use offset float 4 uv? Whyyyyyy?

[LigH]

Because U (Cb) and V (Cr) are defined as "difference away from neutral gray" towards blue/yellow or red/green. So it's quite intuitive. A default chrominance in short integer is unfortunately not 0 (between -128 and 127, as signed short int) but 128; it's unsigned short int (Pascal type: Byte).

[feisty2]

Because U (Cb) and V (Cr) are defined as "difference away from neutral gray" towards blue/yellow or red/green. So it's quite intuitive. A default chrominance in short integer is unfortunately not 0 (between -128 and 127, as signed short int) but 128; it's unsigned short int (Pascal type: Byte).

unsigned short int = uint16_t
unsigned char = uint8_t

[LigH]

Oops ... still have Pascal in my mind. :o

[jpsdr]

Float is 0.0 to 1.0 for all planes.
Ok, i'll work with that. I'm trying to see if i can change nnedi3 to support extended format. So far, results are not good, i have to continue to work/test, but i'm affraid that neural network is trained for range value of 0-255. Every input out of this range will produce improper result. For now, my next step will be to put all values in the 0-255 range, but in float format. So if input is float, multiply by 255, if input is integer more than 8 bits, convert to float by 255*(value/valuemax) (all in float of course).
This will be my next thing to try.

[feisty2]

Ok, i'll work with that. I'm trying to see if i can change nnedi3 to support extended format. So far, results are not good, i have to continue to work/test, but i'm affraid that neural network is trained for range value of 0-255. Every input out of this range will produce improper result. For now, my next step will be to put all values in the 0-255 range, but in float format. So if input is float, multiply by 255, if input is integer more than 8 bits, convert to float by 255*(value/valuemax) (all in float of course).
This will be my next thing to try.

floating point support has been added to vaporsynth nnedi3 since, forever. (I'm actually the one who did it, and the original vaporsynth nnedi3 author then merged my floating point patches)

just do some copy-paste work from vaporsynth nnedi3 and ur good to go

[pinterf]

Why u use offset float 4 uv? Whyyyyyy?
To tell the truth I didnt know. I had no experience or prejudice about these expert formats. That's why I mentioned 'now' because you guys who have the knowledge, can propose the right way, it's not too late.

[jpsdr]

@feisty2
I'm doing the 16bits for now, i'll see for the floats latter.
@pinterf
I don't understand. I thought you said all the planes in floats were 0.0-1.0, so the U/V planes are also the same, or have i missed something (because of some english part i may have misunderstood) ?

[pinterf]

Yes. All planes are 0-1.0 at the moment. But it seems that this is unusual.

[Myrsloik]

Yes. All planes are 0-1.0 at the moment. But it seems that this is unusual.

Use -0.5 to 0.5 for UV and it'll match VS. Will make compatibility so much easier...

[jpsdr]

@feisty2
I have a question, just to ask if it's normal :
In evalFunc_0 you use prescreener >=2 only if pixelsize=1, wich is normal, but the way the tests are made, if you ask prescreener=2 with pixelsize>1, you fall in "no prescreener". Isn't better to go back to "original" instead ? I mean, somehow you have asked for a prescreener. But in that case, the constructor/Init would have to be adjusted according to this.

[feisty2]

@feisty2
I have a question, just to ask if it's normal :
In evalFunc_0 you use prescreener >=2 only if pixelsize=1, wich is normal, but the way the tests are made, if you ask prescreener=2 with pixelsize>1, you fall in "no prescreener". Isn't better to go back to "original" instead ? I mean, somehow you have asked for a prescreener. But in that case, the constructor/Init would have to be adjusted according to this.

didn't quite get what you were saying... (not sure what you meant by "go back to original")
anyways, pscrn could only be 0 or 1 for high bitdepth samples (as new prescreeners were trained for byte inputs). 2 is illegal for them.

[pinterf]

I note that GScriptClip is incompatible with avs+ mt, with mode 2 not work at all and with mode 3 gave random scriptcilp errors
This was not forgotten, but I cannot help with it right now, could you post a test script and a hint what is special in GScriptClip (I have read some info about it but it is still not clear for me, never used)

[jpsdr]

@pinterf
Use -0.5 to 0.5 for UV and it'll match VS. Will make compatibility so much easier...
Let me know what you think you'll be doing in final, and if you're doing -0.5/+0.5 for UV, confirm that a PlaneToY will still produce 0.0/1.0.

@feisty2
Ok.
I mean, actualy in the code, from what i've understood, if you've set a value of 2 for the prescrener with high bitdepth, it switches to 0. Maybe it may switche to 1. Just a little thought.

[feisty2]

@feisty2
Ok.
I mean, actualy in the code, from what i've understood, if you've set a value of 2 for the prescrener with high bitdepth, it switches to 0. Maybe it may switche to 1. Just a little thought.

it should pop out an error message, not silently switch to another mode without notifying the user

[pinterf]

@pinterf

Let me know what you think you'll be doing in final, and if you're doing -0.5/+0.5 for UV, confirm that a PlaneToY will still produce 0.0/1.0.

Good catch, I was thinking about the same theoretical problem. I wonder if VS has special treatments for this in ShufflePlanes, but I don't think so.

[Myrsloik]

Good catch, I was thinking about the same theoretical problem. I wonder if VS has special treatments for this in ShufflePlanes, but I don't think so.

Any float value is always valid (except nan and inf) so no special handling at all. If the user wants weird luma they can have it.

There's also no guarantee that the luma channel stays in the 0-1 range so it doesn't matter.

[real.finder]

This was not forgotten, but I cannot help with it right now, could you post a test script and a hint what is special in GScriptClip (I have read some info about it but it is still not clear for me, never used)


ColorBars(width=640, height=480, pixel_type="yv12")
srestore (http://avisynth.nl/images/Srestore_27h.avsi)
Prefetch(6)


it used in Srestore and others

[jpsdr]

Well, let me know the final result of float decision, it will decide if i work or not to use float format in nnedi3.
The luma (or grey) plane in nnedi3 is clipped to 0.0-1.0 (and chroma planes are clipped to -0.5/+0.5). So, if you split an YUV format in 3 Y,U,V planes, and feed them separately in nnedi3, and the splitted plane U,V are in -0.5/+0.5 instead of 0.0-1.0 usual grey plane, your result will be messed up. So, if a splitted/extracted planar chroma plane is not shifted to match an usual Y/grey plane, you can't properly use nnedi3 in float format without adding a parameter to specify the the range of the float of the "grey" planar.
For now, even with the code of vapoursynth, i'm still unable to make it work with 16 bits.... :angry:

[feisty2]

Well, let me know the final result of float decision, it will decide if i work or not to use float format in nnedi3.
The luma (or grey) plane in nnedi3 is clipped to 0.0-1.0 (and chroma planes are clipped to -0.5/+0.5). So, if you split an YUV format in 3 Y,U,V planes, and feed them separately in nnedi3, and the splitted plane U,V are in -0.5/+0.5 instead of 0.0-1.0 usual grey plane, your result will be messed up. So, if a splitted/extracted planar chroma plane is not shifted to match an usual Y/grey plane, you can't properly use nnedi3 in float format without adding a parameter to specify the the range of the float of the "grey" planar.
For now, even with the code of vapoursynth, i'm still unable to make it work with 16 bits.... :angry:

NO!!!
WHYYYYYYYYYYYY DID YOU DO THAT???
overflow is practically nonexistent to floating points, the MAIN reason to use floating point samples is to avoid clipping to have a more mathematically correct result.

CLIPPING IS TOXIC

[pinterf]

ColorBars(width=640, height=480, pixel_type="yv12")
srestore (http://avisynth.nl/images/Srestore_27h.avsi)
Prefetch(6)


it used in Srestore and others
Could you try this one?
GRunT-1.0.2 (avisynth+ and 2.6, x86 and x64) (http://www.mediafire.com/file/77uromd0j0z56ap/GRunT-1.0.2tst.7z)
I suppose I only made it self register as a NICE_FILTER for Avisynth+.
That means that it doesn't run under avs 2.5x.
And if I had work with it, I made a 64bit version also.

[jpsdr]

NO!!!
WHYYYYYYYYYYYY DID YOU DO THAT???

Heu... Sorry, i've done nothing yet, take a look at your nnedi3.cpp lines 338, 641.
Did i misunderstood something ?

[feisty2]

Heu... Sorry, i've done nothing yet, take a look at your nnedi3.cpp lines 338, 641.
Did i misunderstood something ?

https://github.com/dubhater/vapoursynth-nnedi3/blob/master/src/nnedi3.cpp
correct link

[jpsdr]

Ok, thanks. But i'm still struggling with integer for now... ;)

Edit :
If you have any idea/comment about the potentiel issue i've posted in the nnedi3 thread.

[real.finder]

Could you try this one?
GRunT-1.0.2 (avisynth+ and 2.6, x86 and x64) (http://www.mediafire.com/file/77uromd0j0z56ap/GRunT-1.0.2tst.7z)
I suppose I only made it self register as a NICE_FILTER for Avisynth+.
That means that it doesn't run under avs 2.5x.
And if I had work with it, I made a 64bit version also.

it show random things in the top of frame
http://i.imgur.com/3GSte8V.png

[pinterf]

Yes, there is garbage. I was blind or I don't know. But it seems to be a very hard problem, at least haven't seen those avisynth internal parts that I have to debug now. First I'm struggling with the source of those hieroglyphs, which show: "ERROR: I don't know what 'current_frame' means." (Put this line at the beginning of the script: SetLogParams("log.txt", LOG_DEBUG))
And why it appears: ScriptClip errors (exception text with source module and line number) are overlayed on the current frame.
For some reason when formatting the error message, the C++ variadic parameter list (va_list) becomes corrupt between calls or after using vsnprintf. But only in this case. Now I'm reinstalling my VS2015.
But that is only the problem of the weird error message rendering. The real problem is the scope of variables, this plugin sets global paramers run-time, and this is somehow different in AVS+ than is classic AVS.

[pinterf]

As Avisynth+ project is demanding modernized filters, my next port will be masktools2.

Meantime I had a look at tp7's masktools project. As it was mentioned, there is a 16 bit branch, which is in quite a good shape, a lot of filters are basically ready, supporting stacked and 'doublewidth' hacked formats. This latter is basically the normal 16 bit way, how Avisynth+ works. This branch is a little behind over the latest masktools b2 release.

The extensions are 16 bit only, so the 10, 12, 14 bit support have to be inserted in. For practicing I have modded mt_binarize16 to have 10-14 bits, as the easiest part. After several hours it is still very hard for me to understand the framework, very general, very C++, macro magics, and those are somehow producing a working avisynth filter.

My goal will also be to have one filter name that works for all video formats, so there will be no separate mt_binarize and mt_binarize16.

[Motenai Yoda]

Shouldn't be faster starting off Firesledge's dither_tools mt functions? also there is CLExpr which can be a good point to add heterogeneous computing too

[Gavino]

The real problem is the scope of variables, this plugin sets global paramers run-time, and this is somehow different in AVS+ than is classic AVS.
Does the standard ScriptClip work correctly under mt?
Since GScriptClip is essentially a wrapper around the original function, its multithreading characteristics should be the same. However it does have some differences which may or may not be significant - current_frame is made a global variable, and the function may (depending on parameters) start a new scope level with env->PushContext().

How do variables work under mt?
I don't see how functions like ScriptClip, which relies on 'current_frame', can ever be thread-safe (unless somehow each thread has its own set of variables?)

[pinterf]

Does the standard ScriptClip work correctly under mt?
Since GScriptClip is essentially a wrapper around the original function, its multithreading characteristics should be the same. However it does have some differences which may or may not be significant - current_frame is made a global variable, and the function may (depending on parameters) start a new scope level with env->PushContext().

How do variables work under mt?
I don't see how functions like ScriptClip, which relies on 'current_frame', can ever be thread-safe (unless somehow each thread has its own set of variables?)
Standard ScriptClip works under mt, and the filter itself is NICE_FILTER, but I don't know how the derived mt behaviour is figured out by the content.
As for the variables, there is a TLS (thread-local storage) for each thread. They have their own context of local and global variables. When a thread-locale variable is not found in the there, it looks out for the core level variables.
See here (https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/core/ScriptEnvironmentTLS.h#L51)

The problem that I don't understand, that why I have "end of file reached without matching }" in the debug log.

EDIT:
There was a bug when an avisynth exception came from the thread-local environment, the variadic sprintf-like formatting was not correct, and it would corrupt the stack or the exception rollback mechanism somehow.
-- end of edit --

The error chain is thrown from this srestore.avsi line:
Try { global Srestore_InstanceNumber = Srestore_InstanceNumber+1 } catch(err) { global Srestore_InstanceNumber = 1 }


Original error comes from the try block. The error lines are growing as the exceptions are re-thrown back to one level.

Then follows the "file end reached" error and this is what I don't understand.

And the log:
ERROR: I don't know what 'Srestore_InstanceNumber' means.
---------------------------------------------------------------------
ERROR: I don't know what 'Srestore_InstanceNumber' means.
(C:/Program Files (x86)/AviSynth/plugins/SRestore_27.avsi, line 80)
---------------------------------------------------------------------
ERROR: Script error: end of file reached without matching }
---------------------------------------------------------------------
ERROR: Script error: end of file reached without matching }
((null), line 50, column 0)
---------------------------------------------------------------------
ERROR: Script error: end of file reached without matching }
((null), line 50, column 0)
(C:/Program Files (x86)/AviSynth/plugins/SRestore_27.avsi, line 320)
---------------------------------------------------------------------
ERROR: Script error: end of file reached without matching }
((null), line 50, column 0)
(C:/Program Files (x86)/AviSynth/plugins/SRestore_27.avsi, line 320)
(.\s1.AVS, line 8)

[pinterf]

New dev build
Download: Avisynth plus r2347 (http://www.mediafire.com/file/h1znw337movpwpu/avsplus-r2347.7z)

20161222 r2347dev

CombinePlanes: setting target to default RGBP(A)/YUV(A), when inputs are greyscale and no source planes are given
Decision is made by the target plane characters, if they are like R,G,B then target video format will be planar RGB
Same logic applies for YUV.
Example:
Y1, Y2 and Y3 are greyscale clips
Old, still valid: CombinePlanes(Y1, Y2, Y3, planes="RGB", source_planes="YYY", pixel_type="RGBP8")
New: CombinePlanes(Y1, Y2, Y3, planes="RGB") # result: Planar RGB
Fix: ScriptClip would show garbage text when internal exception occurs instead of the showing human readable error message

[vcmohan]

I tried script clip and ran into problem.My input is colorbars. I was continuously getting some large line number on top of the input image. I found that prefetch is the cause of this. After commenting out this I could run script clip correctly.

[pinterf]

Still getting large numbers with r2347? Or did your Scriptsclip sample work for you in MT before this latest build?

[vcmohan]

I was using r2294

[vcmohan]

Now I am on r2347. With the statement prefetch(4) , I get an error message now readable as "invalid arguments to ....". But commenting out prefetch the script runs fine without any error.

[pinterf]

That will be difficult. Visible error message is only the first stage of a possible fix. Now my test is srestore. I made a modification (post 2347) that affects global variables in scriptclip runtime. Now it does not display the exception, finally goes on, but is turning into deadlock somewhere in the handling of the multithread guard mutexes. And I think this is the real problem to be solved.

Can you strip your script to a short one that is still showing the error?

[vcmohan]

I found that if any parameter other than clip is specified it is giving an error. The parameter need not be calculated in the script. I found that placing Reformer(last, last) was ok, but Reformer(last,last, qr = true) raises error.

[real.finder]

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


ComponentCount not existing, it give me "There is no function named 'ComponentCount'"

and it will be more easy if we have "HasAlpha()"

[LigH]

No reason for a full quote. :)

[ajp_anton]

Found this weird problem...

http://ajpanton.se/avsbug/source.mkv (~4.2MB)

Script:
ffms2("source.mkv")

vectors = msuper().manalyse(isb = false)
mdata = mdepan(vectors, zoom=true, rot=true)
depanstabilize(data=mdata, dxmax=100, dymax=100, rotmax=2.0, mirror=15)

Using the old 1.13 version of DePan and Avisynth+ r2347 (and pinterf's latest mvtools). I can test with "vanilla" Avisynth tomorrow, as I'm again posting when I should go to sleep...

VirtualDub (FilterMod) handles this fine, the video is smooth. Laptop isn't fast enough for realtime playback, but I can encode it using VD into a smooth video. However, opening the .avs file in both x264 (cli) and avs2pipemod somehow result in really jerky video.

[pinterf]

ComponentCount not existing, it give me "There is no function named 'ComponentCount'"

and it will be more easy if we have "HasAlpha()"
Indeed. And it should be named the same as in the VideoInfo: NumComponents.

So I created a HasAlpha, NumComponents and IsPackedRGB script functions (no build yet).

[ajp_anton]

Feature requests:
1. Function "Info": Add a second clip as an optional argument. Write the info of the first clip onto the second clip (or vice versa, whichever is better/easier/more logical).
2. Function "Default": If the variable in the first argument is defined, don't try to evaluate the second argument. I have a function that has arguments for width, height and aspect ratio, but only two are needed. In Default(w,h*ar) I get an unnecessary error if either "h" or "ar" is the only one being left undefined.
3. The ability to add comments at the end of a line that continues on the next line using \.

[StainlessS]

2. Function "Default": If the variable in the first argument is defined, don't try to evaluate the second argument. I have a function that has arguments for width, height and aspect ratio, but only two are needed. In Default(w,h*ar) I get an unnecessary error if either "h" or "ar" is the only one being left undefined.


Default() must be a function, moving into the Parser as you suggest would likely result in a lot of work for printerf, and for no real reason, you can easily get around that (EDIT: rare) 'problem' yourself.

EDIT: Also, (1) whats wrong with y=x.info() ?

No problem with (3) [EDIT: I quite like the idea].

[LigH]

1. is probably asking for a chance to overlay the Info() details over a blank clip, for better readability. Well ... BlankClip(reference_clip) could be a base with mostly identical attributes, to display Info text onto. Except for the case that the clip has too small dimensions for the Info text to render completely; in that case it may indeed need a larger area than the original clip.

[Sm3n]

Hi,

I'm looking for a script capable to change the color of a harcoded subtitle. Here is a sample: https://framadrop.org/r/znJhfsO4lW#RLppqRZQ6Fk75G1JaNFT4WguyQN+syTNXzdQlpmmqi8=

I found something similar on videohelp: http://forum.videohelp.com/threads/364577-AviSynth-Color-exchange
So I tweaked a bit but I can't properly change the grey subtitles into white. And there is lot of artefact created on the picture and/or around the outline sub.

My script:

mask=MaskHS(30,30, 20,5).mt_expand().BilinearResize(last.width, last.height)
overlay(last, GreyScale().ColorYUV(cont_y=100), 0, 0, mask)

cheers

[qyot27]

Except for the case that the clip has too small dimensions for the Info text to render completely; in that case it may indeed need a larger area than the original clip.
That's no longer an issue, technically; you can choose font and text size for Info() now (https://github.com/AviSynth/AviSynthPlus/pull/101/commits/b09bc11ad347aaebe592a848f3d3ea19d7c68430).

(Although it was actually proposed because the default size made the output unreadable when dealing with 4K) (https://github.com/AviSynth/AviSynthPlus/issues/99)

[ajp_anton]

Default() must be a function, moving into the Parser as you suggest would likely result in a lot of work for printerf, and for no real reason, you can easily get around that (EDIT: rare) 'problem' yourself.Well, (2) isn't that important, I'm just using a simple "if" (? and :) to get around it. Took a while to be desperate enough to try it though, because I though that's basically how Default did it and it wasn't working there.

1. is probably asking for a chance to overlay the Info() details over a blank clip, for better readability. Well ... BlankClip(reference_clip) could be a base with mostly identical attributes, to display Info text onto. Except for the case that the clip has too small dimensions for the Info text to render completely; in that case it may indeed need a larger area than the original clip.Yes, I was thinking of the dimensions. Sure, can get around it by resizing, assuming that the clip dimension is not what you're interested in.

No problem with (3) [EDIT: I quite like the idea].Not sure what idea you quite like, because I just noticed that the forum messed up my (3) =). Apparently you can't put a \ between "". I now edited my previous post.
Basically, what I meant is that you could write
a = somefunction(argument1 #comment for arg1
\, argument2) #another commentor
a = somefunction(argument1,\ #comment for arg1
argument2) #another comment

[StainlessS]

Not sure what idea you quite like, because I just noticed that the forum messed up my (3) =). Apparently you can't put a \ between "". I now edited my previous post.
Basically, what I meant is that you could write
a = somefunction(argument1,\ #comment for arg1
argument2) #another comment

That is what I took you to mean :)

[raffriff42]

>1. Function "Info": Add a second clip as an optional argument.
## show information on clip 'C' over base clip 'B'
function Info(clip B, clip C)
{
return B.Overlay(
\ C.Levels(0, 1, 0, 0, 0) [* make black BG *]
\ .Info [* show info *]
\ .Crop(0, 0, 384, 240), [* crop to size *]
\ opacity=1.0 [* overlay *]
\ )
}

Can't support an optional second clip as this collides with built-in Info(clip C).

>3. The ability to add comments at the end of a line that continues on the next line
See above :)

[ajp_anton]

>1. Function "Info": Add a second clip as an optional argument.
## show information on clip 'C' over base clip 'B'
function Info(clip B, clip C)
{
return B.Overlay(
\ C.Levels(0, 1, 0, 0, 0) [* make black BG *]
\ .Info [* show info *]
\ .Crop(0, 0, 384, 240), [* crop to size *]
\ opacity=1.0 [* overlay *]
\ )
}

Can't support an optional second clip as this collides with built-in Info(clip C).

>3. The ability to add comments at the end of a line that continues on the next line
See above :)Nope, "you cannot use crop to enlarge or 'shift' a clip".
And the "CPU detected" line goes on even further than that 384, so an even bigger area is needed. I know, totally not important, but it looks ugly. Not to mention that the whole black rectangle is really ugly. So not really a "nice" solution.

Didn't know you could comment like that. Though I still prefer # because it's easier to keep track of.

[StainlessS]

from Docs

Avisynth ignores anything from a # character to the end of that line. This can be used to add comments to a script.

# comment

In v2.58 it is possible to add block and nested block comments in the following way:


# block comment:
/*
comment 1
comment 2
*/



# nested block comments:
[* [* a meaningful example will follow later :) *] *]

Avisynth ignores anything from an __END__ keyword (with double underscores) to the end of the script file. This can be used to disable some last commands of script.


Version()
__END__
ReduceBy2()
Result is not reduced and we can write any text here



Seems that we are still awaiting a meaningful example, since v2.58.

But below produces "Parse Error: orphan block comment closing */". [The 1st */ ends the comment]

/* /* something */ */

whereas

[* [* something *] *]

does not.

EDIT: (1) Perhaps new function InfoText() or Info_Text() would be easy to implement (as for Subtitle, with '\n').

[jpsdr]

Is there a way with the CPU flags to detect FMA4 ? I've seen there's allready FMA3, but didn't seen FMA4.

[Foja]

Hello,

since long time I am a silent reader in this discussion. I am using the plug-in RemoveDirt in the 8-bit version of avisynth for many years. I am very satisfied with this plug-in.
Now I am starting to use avisynth+ for my cleaning script, all plugins which i normaly use in the 8-bit version are already available exept "RemoveDirt".
RemoveDirt is for me a important plugin which I don't want to miss in my cleaning script for avisynth+.

Is there the plan to convert the plugin "RemoveDirt" to the new version avisynth+?

Thanks for the great work and for providing such a powerful software. :thanks:

Best wishes from Germany and a Happy New Year!

[LigH]

Hi, thanks, and same to you, from Germany as well.

In the AviSynth Wiki for RemoveDirt (http://avisynth.nl/index.php/RemoveDirt) I read that it "has now become a script function which involves RestoreMotionBlocks and various filters from the RemoveGrain (http://avisynth.nl/index.php/RemoveGrain) package." And if you substitute them with RgTools (http://avisynth.nl/index.php/RgTools), I guess it should be possible to run it with equivalent results and better speed in AviSynth+ ... so much guesswork from me; but other members may know it better.

[pinterf]

I didn't include fma4 in CPU flags. But it seems I will have to.

[Foja]

Hi, thanks, and same to you, from Germany as well.

In the AviSynth Wiki for RemoveDirt (http://avisynth.nl/index.php/RemoveDirt) I read that it "has now become a script function which involves RestoreMotionBlocks and various filters from the RemoveGrain (http://avisynth.nl/index.php/RemoveGrain) package." And if you substitute them with RgTools (http://avisynth.nl/index.php/RgTools), I guess it should be possible to run it with equivalent results and better speed in AviSynth+ ... so much guesswork from me; but other members may know it better.

Thanks for your reply. Unfortunately, the "RestoreMotionBlocks" function is part of RemoveDirt and not the RemovGrain or RgTools package. Although there is an x64 version (RemoveDirt v1.0 pre-release x64), but this is not running under Avisynth +. The error message "System exeption - Access Violation" are shown.
I guess for the support of a bit depth of 10 - 16 bit, RemoveDirt is likely to be completely revised??!

Best wishes!

[feisty2]

Thanks for your reply. Unfortunately, the "RestoreMotionBlocks" function is part of RemoveDirt and not the RemovGrain or RgTools package. Although there is an x64 version (RemoveDirt v1.0 pre-release x64), but this is not running under Avisynth +. The error message "System exeption - Access Violation" are shown.
I guess for the support of a bit depth of 10 - 16 bit, RemoveDirt is likely to be completely revised??!

Best wishes!

takes ~10min to make it work on higher bit depth integer samples, just reinterpret_cast all uint8_t * to uint16_t * and append "/ sizeof(uint16_t)" after all stride variables and you're done, do it yourself

[LigH]

takes ~10min to make it work on higher bit depth integer samples, just reinterpret_cast all uint8_t * to uint16_t * and append "/ sizeof(uint16_t)" after all stride variables and you're done, do it yourself

What kind of programmer do I have to be to understand these instructions? And which kind of compiler do I have to know to use?

[videoh]

C or C++. It's very basic. As they say, google is your friend.

[Reel.Deel]

takes ~10min to make it work on higher bit depth integer samples, just reinterpret_cast all uint8_t * to uint16_t * and append "/ sizeof(uint16_t)" after all stride variables and you're done, do it yourself

~10 min? I call BS on that. Have you even looked at the source code? I'm no programmer but I've heard other knowledgeable people describe Kasandro's code as pure spaghetti. If it was so easy why was it not done here: https://github.com/handaimaoh/removedirtvs

Edit:
Thanks for your reply. Unfortunately, the "RestoreMotionBlocks" function is part of RemoveDirt and not the RemovGrain or RgTools package. Although there is an x64 version (RemoveDirt v1.0 pre-release x64), but this is not running under Avisynth +. The error message "System exeption - Access Violation" are shown.


The RemoveDirt script also uses SCSelect fucntion from the RemoveDirt plugin. Regarding the x64 version on the wiki, there's a note on there that says it's incompatible with AviSynth.

For the mean time you can use a similar workaround as described here: http://forum.doom9.org/showthread.php?p=1599783#post1599783


o16 = last #Stack16 video

o = DitherPost(mode=-1)
o.RemoveDirt(...)

dif = mt_makediff(last, o, y=3, u=3, v=3)
dif16 = dif.Dither_convert_8_to_16()
o16.Dither_add16(dif16, dif=true)

[feisty2]

~10 min? I call BS on that. Have you even looked at the source code? I'm no programmer but I've heard other knowledgeable people describe Kasandro's code as pure spaghetti.


Lol ur full of crap, it doesn't matter how messed up the code is cuz ur not rewriting the whole plugin, simply modifying it a tiny little bit.

If it was so easy why was it not done here: https://github.com/handaimaoh/removedirtvs
Because unlike c and c++ which are easy to modify, assembly is an evil bitch

[tuanden0]

I'm using filter MCTemporalDenoise.avsi (http://forum.doom9.org/showthread.php?t=139766)
Can everyone tell me what is the MT mode of this?

[tormento]

I'm using filter MCTemporalDenoise.avsi (http://forum.doom9.org/showthread.php?t=139766)
Can everyone tell me what is the MT mode of this?

I warmly suggest you to use SMDegrain.

[pinterf]

Happy New Year!

After having spent many days with understanding how multithreading works with runtime scripts I felt myself so miserable and tired that I had to abandon that investigation a bit. I have searched for an area with more success factor instead.

New dev build:
Download Avisynth Plus r2359 (http://www.mediafire.com/file/r6s3xs6eert41n9/avsplus-r2359.7z)

Changes since r2347:

Avisynth plus r2359dev (20170104)

Overlay:
new parameter: bool use444 (default true for compatibility/until under construction, etc...)

Parameter is valid only for "blend" at the moment
When set to false, and base clip/overlay clip is 420/422/Planar RGB, no conversion occurs to and back from YV24 (4:4:4 in general)

Mask can be either greyscale or can be any planar YUV when greymask=true (default)

Works for Planar RGB, so blending is basically lossless for this format (no YUV conversion)
todo: support for other modes, convert packed RGB to planar RGB internally instead of YUV
Overlay:
Add fast 4:2:0<->4:4:4 conversion, e.g. YV16<->YV24 (only fast YUY2 and YV12 existed so far)
instead of invoking generic core conversion
Overlay:
10-16bit SSE2/SSE4 for 420/422<->444 conversions
Info() made a bit more compact.
Bit depth info moved after color space info
Does not display pre-SSE2 CPU flags when at least AVX is available.
AVX512 flags in separate line (would be too long)
new CPU feature constants (see cpuid.h and avisynth_c.h)
Detect FMA4 and AVX512F,DQ,PF,ER,CD,BW,VL,IFMA,VBMI
new script function:
string ReplaceStr(string s, string pattern, string replacement)
Function is case sensitive, parameters are unnamed
new script function
int NumComponents(clip)
returns 1 for grayscale, 3 for YUVxxx, YUY2, planar RGB or RGB24/RGB48, 4 for YUVAxxx, Planar RGBA or RGB32/64
new script function:
bool HasAlpha(clip)
returns true when clip is YUVA, Planar RGBA, or packed RGB32 or RGB64

[real.finder]

Happy New Year!

After having spent many days with understanding how multithreading works with runtime scripts I felt myself so miserable and tired that I had to abandon that investigation a bit. I have searched for an area with more success factor instead.

New dev build:
Download Avisynth Plus r2359 (http://www.mediafire.com/file/r6s3xs6eert41n9/avsplus-r2359.7z)


Happy New Year and :thanks:

what about make AddAlphaPlane accept clip too?

[pinterf]

It was planned then forgotten :)

[ryrynz]

:thanks:


Could you please avoid quoting entire posts when there's no reason to? Also your post is directly after pinterf's post which makes it even worse.

Thanks for the new build pinterf!

[Wilbert]

new script function:
bool IsPackedRGB(clip)
returns true when clip is RGB24/32/48/64
This function is redundant. Please use IsInterleaved(clip) and IsRGB(clip) instead. (There is no IsPackedYUV(clip) either.)

and similarly IsPlanar(clip) and IsRGB(clip) / IsYUV(clip).

-----

With respect to this post: http://forum.doom9.org/showthread.php?p=1791946#post1791946

I think it would be great if (at least) the formats RGB64, YUV422P10 and YUV422P16 would be exposed through the VfW interface. Then we can open such scripts in Virtualdub and encode straight to MagicYUV (without any color conversion).

[pinterf]

This function is redundant. Please use IsInterleaved(clip) and IsRGB(clip) instead. (There is no IsPackedYUV(clip) either.)

and similarly IsPlanar(clip) and IsRGB(clip) / IsYUV(clip).

I think you are right, IsYUV does not follow this logic, as it applies to YUY2, too.


With respect to this post: http://forum.doom9.org/showthread.php?p=1791946#post1791946

I think it would be great if (at least) the formats RGB64, YUV422P10 and YUV422P16 would be exposed through the VfW interface. Then we can open such scripts in Virtualdub and encode straight to MagicYUV (without any color conversion).
BGR[48] and BRA[64] is already available, ignus2 has done it
https://github.com/pinterf/AviSynthPlus/commit/e10dcb8f640b2a1562dff75af3c6ee125243c82c

[shekh]

BGR[48] and BRA[64] is already available, ignus2 has done it
https://github.com/pinterf/AviSynthPlus/commit/e10dcb8f640b2a1562dff75af3c6ee125243c82c

But is this patch for source (not for output)?

[gaak]

Hello all,

When trying to encode a clip I get the following error:

avs [info]: AviSynth+ 0.1 (r2359, MT, i386)
avs [info]: Video colorspace: YV12
avs [info]: Video resolution: 988x720
avs [info]: Video framerate: 24000/1001
avs [info]: Video framecount: 121878
avs4x26x [info]: "C:\MKVideo Encoder\EXEs\x264_x64.exe" - --preset medium --tune
film --crf 18 --profile high --level 4.1 --open-gop --quiet --threads 0 --threa
d-input -o Output_Video_File.h264 --frames 121878 --fps 24000/1001 --input-res
988x720 --input-csp i420
avs [error]: Filter Error: Filter attempted to break alignment of VideoFrame. occurred while reading frame 0

I've tried earlier builds, only r1858 works for me.

The script follows:

SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("DGDecodeNV", 3)
LoadPlugin("C:\MKVideo Encoder\FFMS2\ffms2.dll")
Import("C:\MKVideo Encoder\AVS Scripts\LoadPlugins.avs")
FFVideoSource(source = "C:\MKVideo Files\Input_Video_File.mkv")
Spline144Resize(1280, 720)
RoboCrop(Laced=False)
LSFmod(defaults="slow", preblur="DeGrainMedian(limitY=4, limitUV=6, mode=1, interlaced=false)")
Prefetch(3)

Thanks for any help.

[pinterf]

But is this patch for source (not for output)?
Yes. Avisource and DirectShowSource.

[BakaProxy]

Hello all,

When trying to encode a clip I get the following error:

avs [info]: AviSynth+ 0.1 (r2359, MT, i386)
avs [info]: Video colorspace: YV12
avs [info]: Video resolution: 988x720
avs [info]: Video framerate: 24000/1001
avs [info]: Video framecount: 121878
avs4x26x [info]: "C:\MKVideo Encoder\EXEs\x264_x64.exe" - --preset medium --tune
film --crf 18 --profile high --level 4.1 --open-gop --quiet --threads 0 --threa
d-input -o Output_Video_File.h264 --frames 121878 --fps 24000/1001 --input-res
988x720 --input-csp i420
avs [error]: Filter Error: Filter attempted to break alignment of VideoFrame. occurred while reading frame 0

I've tried earlier builds, only r1858 works for me.

The script follows:

SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("DGDecodeNV", 3)
LoadPlugin("C:\MKVideo Encoder\FFMS2\ffms2.dll")
Import("C:\MKVideo Encoder\AVS Scripts\LoadPlugins.avs")
FFVideoSource(source = "C:\MKVideo Files\Input_Video_File.mkv")
Spline144Resize(1280, 720)
RoboCrop(Laced=False)
LSFmod(defaults="slow", preblur="DeGrainMedian(limitY=4, limitUV=6, mode=1, interlaced=false)")
Prefetch(3)

Thanks for any help.
First off try without MT before you start complaining online.

Verstuurd vanaf mijn SM-A500FU met Tapatalk

[pinterf]

avs [error]: Filter Error: Filter attempted to break alignment of VideoFrame. occurred while reading frame 0

I've tried earlier builds, only r1858 works for me.

The script follows:

SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("DGDecodeNV", 3)
LoadPlugin("C:\MKVideo Encoder\FFMS2\ffms2.dll")
Import("C:\MKVideo Encoder\AVS Scripts\LoadPlugins.avs")
FFVideoSource(source = "C:\MKVideo Files\Input_Video_File.mkv")
Spline144Resize(1280, 720)
RoboCrop(Laced=False)
LSFmod(defaults="slow", preblur="DeGrainMedian(limitY=4, limitUV=6, mode=1, interlaced=false)")
Prefetch(3)
One of the filters used SubFrame or SubframePlanar and specified plane offsets and/or pitches that are incompatible with recent versions of Avisynth+. This prevention was introduced because Avisynth+ core and filters in general assume proper alignment for processing the frame. Avisynth plus' default alignment is 32 bytes. One of the filter is using the subframe function with frame properties that are aligned for less than 32 bytes.

I suspect the RoboCrop function in the script, try to use it with align=true

Internally Avisynth+'s Crop is alignment-safe. It checks whether alignment is o.k. for the fast SubFrame. If not, it creates a new frame instead (guaranteed to have proper alignment) and copies the cropped area there.

[MysteryX]

Hey folks, I haven't been around for a while (been busy with other things), and I'm glad the development has progressed.

Converting my auto-generated scripts to native 16-bit is something I'd like to do (and adapting AviSynthShader to support conversion to/from native 16-bit), but where I have hesitation is in compromising quality in doing so. Is there now a way of performing these 2 operations without DitherTools?
- Dithering with Floyd-Steinberg
- Resizing with NoRinging (Dither_resize16nr)

Actually, as I'm writing this, I'm remembering that NoRinging resize is simply a script-based wrapper around the standard resizer so it probably can be used just the same (would have to try to confirm). Still that leaves dithering which requires custom coding.

Have I missed any other major update that either impact quality of performance since I last interacted here, or was it mostly new features?

[Motenai Yoda]

dithering is possible with convertto8bits or convertbits, but IIRC there is only dither or not dither (truncate, round?)

as you can see from the wrapper function nr resize it's just a repair between the chosen one and gauss
Function Dither_resize16nr (clip src, int width, int height,
\ float "src_left",
\ float "src_top",
\ float "src_width",
\ float "src_height",
\ string "kernel",
\ float "fh",
\ float "fv",
\ int "taps",
\ float "a1",
\ float "a2",
\ float "a3",
\ int "kovrspl",
\ bool "cnorm",
\ bool "center",
\ string "cplace",
\ int "y",
\ int "u",
\ int "v",
\ string "kernelh",
\ string "kernelv",
\ float "totalh",
\ float "totalv",
\ bool "invks",
\ bool "invksh",
\ bool "invksv",
\ int "invkstaps",
\ string "cplaces",
\ string "cplaced",
\ string "csp",
\ bool "noring")
{
noring = Default (noring, true)

Assert (width > 0 && height > 0, "Dither_resize16nr: width and height must be > 0.")

sr_h = Float (width ) / Float (src.width () )
sr_v = Float (height) / Float (src.height ())
sr_up = Dither_max (sr_h, sr_v)
sr_dw = 1.0 / Dither_min (sr_h, sr_v)
sr = Dither_max (sr_up, sr_dw)
Assert (sr >= 1.0)

# Depending on the scale ratio, we may blend or totally disable
# the ringing cancellation
thr = 2.5
nrb = (sr > thr)
nrf = (sr < thr + 1.0 && noring)
nrr = (nrb) ? Dither_min (sr - thr, 1.0) : 1.0
nrv = (nrb) ? Round ((1.0 - nrr) * 255) * $010101 : 0

main = src.Dither_resize16 (width, height,
\ src_left =src_left,
\ src_top =src_top,
\ src_width =src_width,
\ src_height=src_height,
\ kernel =kernel,
\ fh =fh,
\ fv =fv,
\ taps =taps,
\ a1 =a1,
\ a2 =a2,
\ a3 =a3,
\ kovrspl =kovrspl,
\ cnorm =cnorm,
\ center =center,
\ cplace =cplace,
\ y =y,
\ u =u,
\ v =v,
\ kernelh =kernelh,
\ kernelv =kernelv,
\ totalh =totalh,
\ totalv =totalv,
\ invks =invks,
\ invksh =invksh,
\ invksv =invksv,
\ invkstaps =invkstaps,
\ cplaces =cplaces,
\ cplaced =cplaced,
\ csp =csp
\ )

nrng = (nrf) ? src.Dither_resize16 (width, height,
\ src_left =src_left,
\ src_top =src_top,
\ src_width =src_width,
\ src_height=src_height,
\ kernel ="gauss",
\ a1 =100,
\ center =center,
\ cplace =cplace,
\ cplaces =cplaces,
\ cplaced =cplaced,
\ csp =csp,
\ y =y,
\ u =u,
\ v =v
\ ) : main

nrm = (nrb && nrf) ? main.BlankClip (color_yuv=nrv, height=main.Height()/2) : main

# To do: use a simple frame blending instead of Dither_merge16
rgm = 1
rgc = (nrb) ? -1 : 0
rgy = Defined (y) ? ((y == 3) ? rgm : rgc) : rgm
rgu = Defined (u) ? ((u == 3) ? rgm : rgc) : rgm
rgv = Defined (v) ? ((v == 3) ? rgm : rgc) : rgm
rguv = Dither_max (rgu, rgv)
(nrf ) ? main.Dither_repair16 (nrng, rgy, rguv) : main
(nrf && nrb) ? Dither_merge16_8 (main, last, nrm, y=y, u=u, v=v) : last
}Function Dither_resize16nr (clip src, int width, int height,
\ float "src_left",
\ float "src_top",
\ float "src_width",
\ float "src_height",
\ string "kernel",
\ float "fh",
\ float "fv",
\ int "taps",
\ float "a1",
\ float "a2",
\ float "a3",
\ int "kovrspl",
\ bool "cnorm",
\ bool "center",
\ string "cplace",
\ int "y",
\ int "u",
\ int "v",
\ string "kernelh",
\ string "kernelv",
\ float "totalh",
\ float "totalv",
\ bool "invks",
\ bool "invksh",
\ bool "invksv",
\ int "invkstaps",
\ string "cplaces",
\ string "cplaced",
\ string "csp",
\ bool "noring")
{
noring = Default (noring, true)

Assert (width > 0 && height > 0, "Dither_resize16nr: width and height must be > 0.")

sr_h = Float (width ) / Float (src.width () )
sr_v = Float (height) / Float (src.height ())
sr_up = Dither_max (sr_h, sr_v)
sr_dw = 1.0 / Dither_min (sr_h, sr_v)
sr = Dither_max (sr_up, sr_dw)
Assert (sr >= 1.0)

# Depending on the scale ratio, we may blend or totally disable
# the ringing cancellation
thr = 2.5
nrb = (sr > thr)
nrf = (sr < thr + 1.0 && noring)
nrr = (nrb) ? Dither_min (sr - thr, 1.0) : 1.0
nrv = (nrb) ? Round ((1.0 - nrr) * 255) * $010101 : 0

main = src.Dither_resize16 (width, height,
\ src_left =src_left,
\ src_top =src_top,
\ src_width =src_width,
\ src_height=src_height,
\ kernel =kernel,
\ fh =fh,
\ fv =fv,
\ taps =taps,
\ a1 =a1,
\ a2 =a2,
\ a3 =a3,
\ kovrspl =kovrspl,
\ cnorm =cnorm,
\ center =center,
\ cplace =cplace,
\ y =y,
\ u =u,
\ v =v,
\ kernelh =kernelh,
\ kernelv =kernelv,
\ totalh =totalh,
\ totalv =totalv,
\ invks =invks,
\ invksh =invksh,
\ invksv =invksv,
\ invkstaps =invkstaps,
\ cplaces =cplaces,
\ cplaced =cplaced,
\ csp =csp
\ )

nrng = (nrf) ? src.Dither_resize16 (width, height,
\ src_left =src_left,
\ src_top =src_top,
\ src_width =src_width,
\ src_height=src_height,
\ kernel ="gauss",
\ a1 =100,
\ center =center,
\ cplace =cplace,
\ cplaces =cplaces,
\ cplaced =cplaced,
\ csp =csp,
\ y =y,
\ u =u,
\ v =v
\ ) : main

nrm = (nrb && nrf) ? main.BlankClip (color_yuv=nrv, height=main.Height()/2) : main

# To do: use a simple frame blending instead of Dither_merge16
rgm = 1
rgc = (nrb) ? -1 : 0
rgy = Defined (y) ? ((y == 3) ? rgm : rgc) : rgm
rgu = Defined (u) ? ((u == 3) ? rgm : rgc) : rgm
rgv = Defined (v) ? ((v == 3) ? rgm : rgc) : rgm
rguv = Dither_max (rgu, rgv)
(nrf ) ? main.Dither_repair16 (nrng, rgy, rguv) : main
(nrf && nrb) ? Dither_merge16_8 (main, last, nrm, y=y, u=u, v=v) : last
}
as rgtools and merge(luma/chroma) now works in 16bit it can be adapted

[MysteryX]

as rgtools and merge(luma/chroma) now works in 16bit it can be adapted
If someone wants to do that adaptation, it would then work for both 8-bit and 16-bit with the same code.

[real.finder]

Hello,

since long time I am a silent reader in this discussion. I am using the plug-in RemoveDirt in the 8-bit version of avisynth for many years. I am very satisfied with this plug-in.
Now I am starting to use avisynth+ for my cleaning script, all plugins which i normaly use in the 8-bit version are already available exept "RemoveDirt".
RemoveDirt is for me a important plugin which I don't want to miss in my cleaning script for avisynth+.

Is there the plan to convert the plugin "RemoveDirt" to the new version avisynth+?


yes its important for many

and if someone add it to rgtools I wish that he/she add the others mode of RemoveGrain too (more than 24) as there are some scripts use them, and there are RemoveGrainHD and RemoveGrainT too

[gaak]

I suspect the RoboCrop function in the script, try to use it with align=true

@pinterf Thank you very much for the answer, that worked!

[ajp_anton]

I'd also like to be able to do linear-light resizing in 16-bit. Dither tools has "Dither_y_gamma_to_linear" and "Dither_y_linear_to_gamma". But for these to work you need to convert to and from stacked as well. And also use "dither_resize16" unless you really want to go to and from stacked a lot of times.

Is there another way to convert between linear and gamma light? mt_lut could do it if it worked in 16 bits.

[Wilbert]

Yes. Avisource and DirectShowSource.
Was asking about the output. Apperantly the code is in main.cpp (*), but i don't know that part well enough to tell what and how it should be updated.

(*) see CAVIStreamSynth::Info, CAVIFileSynth::ImageSize, CAVIStreamSynth::ReadFrame and CAVIStreamSynth::ReadFormat.

[StainlessS]

One of the filters used SubFrame or SubframePlanar and specified plane offsets and/or pitches that are incompatible with Avisynth.

Pinterf, you really should use the term Avisynth+ or similar when talking about such, RoboCrop is totally compatible with Avisynth, it's Avs+ where
the problem arises.

Also might be related:- I wrote a plugin a few weeks/months ago with optional clip which produced some kind of access Violation when NULL clip,
(with avs+ I think), I suspect that the code that causes/detects above SubFrame error in avs+ was accessing the NULL clip at some point and causing the
access violation, (I'm not sure about that being the cause, but if internal avs+ is gonna mess with clips it should make sure not to mess with optional
NULL ones, I think that problem only appeared in avs+ and not avs standard, but am not completely sure).

Also, can you tell me how to reliably detect Avs+ in most recent versions (at least), without basing it on Version or VersionString, I'll have a go at doing modified RoboCrop behaviour only for avs+ and the default avs+ cropping alignment of 32.

Thanx very much :)

[Groucho2004]

Also, can you tell me how to reliably detect Avs+ in most recent versions (at least), without basing it on Version or VersionString, I'll have a go at doing modified RoboCrop behaviour only for avs+ and the default avs+ cropping alignment of 32.
See here (https://forum.doom9.org/showthread.php?p=1776891#post1776891). As for newer builds, just test for newly introduced functions.

[StainlessS]

Thanx G2K4, think i'll use "AddAutoloadDir()".

Any body aware of bulletproof way to call GScript() code in both avs+ and avs standard ?
(GScript does not appear in list of builtin functions in avs+, nor does eg GImport, GEval, for, if, else, etc.)

EDIT: I guess that easiest way is to still use GScript plugin even in avs+.
GScript() really should have been incorporated into avs many moons ago, then we would not have current nonsense.

EDIT: Maybe have to force Eval/GEval into use with some kind of string replace to select plus or standard.

[dipje]

Isn't it possible and an idea to port fmtconv from vapoursynth to avs+? Would give you all the resizers, kernels, chroma conversion, matrix conversion, gamma space conversion and dithering tools you would I guess.

[real.finder]

Isn't it possible and an idea to port fmtconv from vapoursynth to avs+? Would give you all the resizers, kernels, chroma conversion, matrix conversion, gamma space conversion and dithering tools you would I guess.

or just update dither tools to read all avs+ features

[Reel.Deel]

Isn't it possible and an idea to port fmtconv from vapoursynth to avs+? Would give you all the resizers, kernels, chroma conversion, matrix conversion, gamma space conversion and dithering tools you would I guess.

There's already z.lib resizers: http://forum.doom9.org/showthread.php?t=173986

[pinterf]

Was asking about the output. Apperantly the code is in main.cpp (*), but i don't know that part well enough to tell what and how it should be updated.

(*) see CAVIStreamSynth::Info, CAVIFileSynth::ImageSize, CAVIStreamSynth::ReadFrame and CAVIStreamSynth::ReadFormat.
Thanks for the hints. Made some tests with vdubmod14.

ConvertToYV16().ConvertBits(16) # 1st frame OK, crash when play
ConvertToYV12().ConvertBits(16) # P016 unknown
ConvertToYV12().ConvertBits(10) # P010 unknown
ConvertToYV16().ConvertBits(10) # 1st frame OK, crash when play
ConvertToRGB32().ConvertBits(16) # BRA[64] OK, upside down
ConvertToRGB24().ConvertBits(16) # BGR0 unknown (could not locate decompressor)

For BRA[64] I had to reverse the output though (in avisynth internally it's upside down like RGB32)

[odyssey]

I have a minor issue with plugin loading in Avisynth+

Plugins loaded with absolute path works fine, but if they are just loaded with their name, it complains that it can't find the plugin in the current working dir. It never searches for it in the plugins directory.

E.g. LoadPlugin("DGMVCDecode.dll")

If I comment it out, it works, because it finds it in the plugins directory when calling the function.

Perhaps this should be fixed, so it behaves the same way as normal Avisynth?

[shekh]

Thanks for the hints. Made some tests with vdubmod14.

ConvertToYV16().ConvertBits(16) # 1st frame OK, crash when play
ConvertToYV12().ConvertBits(16) # P016 unknown
ConvertToYV12().ConvertBits(10) # P010 unknown
ConvertToYV16().ConvertBits(10) # 1st frame OK, crash when play
ConvertToRGB32().ConvertBits(16) # BRA[64] OK, upside down
ConvertToRGB24().ConvertBits(16) # BGR0 unknown (could not locate decompressor)

For BRA[64] I had to reverse the output though (in avisynth internally it's upside down like RGB32)

Crash in which module? With VapourSynth P210/P216 worked for me.

[Groucho2004]

I have a minor issue with plugin loading in Avisynth+

Plugins loaded with absolute path works fine, but if they are just loaded with their name, it complains that it can't find the plugin in the current working dir. It never searches for it in the plugins directory.

E.g. LoadPlugin("DGMVCDecode.dll")

If I comment it out, it works, because it finds it in the plugins directory when calling the function.

Perhaps this should be fixed, so it behaves the same way as normal Avisynth?
Works fine for me. What do you use to load the script? VDub, mpchc, x264?

[pinterf]

Crash in which module? With VapourSynth P210/P216 worked for me.
I don't know. Not in avisynth. Works for single step forward or backward.
I will build a 32 bit test soon.

[pinterf]

New test build: Avisynth+ r2367 (http://www.mediafire.com/file/gcts63bn7gb6v44/avsplus-r2367.7z)

20170109 r2367dev

VfW: BRA[64],b64a,BGR[48],P010,P016,P210,P216,Y3[10][10],Y3[10][16],v210
experimental, just to have feedback

Default format FourCCs:
RGB64: BRA[64]
RGB48: BGR[48]
YUV420P10: P010
YUV420P16: P016
YUV422P10: P210
YUV422P16: P216

Use these global variables to override default formats:
OPT_Enable_V210 = true --> v210 for YUV422P10
OPT_Enable_Y3_10_10 = true --> Y3[10][10] for YUV422P10
OPT_Enable_Y3_10_16 = true --> Y3[10][16] for YUV422P16
OPT_Enable_b64a = true --> b64a for RGB64
Overlay: blend for float format
Overlay: blend: SSE4 for 10-16 bit, SSE2 for float
AddAlphaPlane: also accepts clip with Y-only or alpha (YUVA/PRGBA/RGB32/64) for alpha source
(was: optional int/float mask value)

[tuanden0]

Can someone help me the filter fft3dGPU crashed if I use SetFilterMTMode("FFT3dGPU", 3)
Here is my script:

SetFilterMTMode("LWLibavVideoSource", 3)
SetFilterMTMode("gradfun2dbmod", 2)
LWLibavVideoSource("E:\Download\test.mp4")
AssumeFPS(24000, 1001)

#Denoise
SetFilterMTMode("FFT3dGPU", 3)
FFT3DGPU(sigma=4,bt=3).gradfun2dbmod()


Prefetch(6)

[shekh]

I don't know. Not in avisynth. Works for single step forward or backward.
I will build a 32 bit test soon.

I can produce a crash with input pane. Will take some time.

Fixed (build 38494).

[shekh]

New test build: Avisynth+ r2367 (http://www.mediafire.com/file/gcts63bn7gb6v44/avsplus-r2367.7z)

OPT_Enable_Y3_10_10 = true --> Y3[10][10] for YUV422P10
OPT_Enable_Y3_10_16 = true --> Y3[10][16] for YUV422P16


I see bigendian tags:
[10][10]3Y
[16][10]3Y

[jpsdr]

I think it would be great if (at least) the formats RGB64, YUV422P10 and YUV422P16 would be exposed through the VfW interface. Then we can open such scripts in Virtualdub and encode straight to MagicYUV (without any color conversion).
How do you "open" in VDub this kind of avs script ?
Configure video in "DirectStream Copy" ?
I think there will still be an issue with the "Output format to compressor/Display" in Video Color Depth. How do you configure this one ?
Because even if the Compressor can handle it, what about the display ? Disabling both Output and Input Video Pane ? Because the display will probably be possible only with color format VDub understand.
It could be interesting, i'm curious to see how you think you may work and configure VDub for this kind of files.

[Reel.Deel]

@jpsdr

Use shekh's VirtualDub mod: https://forum.doom9.org/showthread.php?t=172021

[pinterf]

I see bigendian tags:
[10][10]3Y
[16][10]3Y
Isn't is normal? It is encoded the same way as all the others.
012P = P210
008Y = Y800
[16][10]3Y = Y3[10][16]
etc...

[shekh]

Isn't is normal? It is encoded the same way as all the others.
012P = P210
008Y = Y800
[16][10]3Y = Y3[10][16]
etc...

This is strange but these literals are translated differently.

'610P' -> 'P','0','1','6'
'\012\0123Y' -> 10,10,'3','Y'

How about this:


#define MAKEFOURCC(byte1, byte2, byte3, byte4) (((uint8)byte1) + (((uint8)byte2) << 8) + (((uint8)byte3) << 16) + (((uint8)byte4) << 24))

MAKEFOURCC('Y', '3', 10, 16)

[pinterf]

Thanks, then I will do this way. Noticed that behaviour but could not find the real reason for it, maybe it is undefined or compiler specific to define dword such way...

[pinterf]

Is there any planar rgb for VfW? Or else I could convert them to classic packed rgb formats on the fly? And 12 and 14 bit 420/422 formats could be silently converted and reported as 16 bits as well.

[shekh]

MagicYUV implements these (planar rgb/rgba 10,12,14,16) G3[0][10], G4[0][10], G3[0][12], G4[0][12], G3[0][14], G4[0][14], G3[0][16], G4[0][16]
I don`t implement them (it is boring and benefit over b64a is not obvious)

[jpsdr]

MagicYUV implements these (planar rgb/rgba 10,12,14,16) G3[0][10], G4[0][10], G3[0][12], G4[0][12], G3[0][14], G4[0][14], G3[0][16], G4[0][16]
I don`t implement them (it is boring and benefit over b64a is not obvious)
Having planar data format over interlaced/packed can be a great benefit, the most is avoiding to have to transform (and transform back) the data into planar for doing the process/filter whatever.

@jpsdr
Use shekh's VirtualDub mod: https://forum.doom9.org/showthread.php?t=172021
No 64bits version ? :(
And it seems it's not using the last version for code base, as some menu/interfaces are different from the version i'm using.
Nevertheless, it still can be usefull to have this.

Otherwise, tested :
64bits RGB(A) : Working.
4:2:2 YCbCr 10bits : Working.
4:2:2 planar YCbCr 16-bit : Working.
4:2:0 planar YCbCr 16-bit : Complain can't find decoder for P016.
4:4:4 planar YCbCr 16-bit : Everything is grey.

Release 38494.

[sl1pkn07]

No 64bits version ? :(


https://sourceforge.net/projects/vdfiltermod/files/VirtualDub%20pack/version%2014/

@printf you can upload the avs+ binaries to github instead of cyberloker?

greetings

[shekh]

Having planar data format over interlaced/packed can be a great benefit, the most is avoiding to have to transform (and transform back) the data into planar for doing the process/filter whatever.


If you promise to port some useful filters for rgb planar mode, I can implement it.
Otherwise just having planar source "supported" but immediately converted to packed - is not useful.


No 64bits version ? :(
And it seems it's not using the last version for code base, as some menu/interfaces are different from the version i'm using.


Since original VirtualDub was never hosted publicly, I have no idea about last code base.
If you have it, please share.
Of course some menu/interfaces are different, I am making changes after all.


4:2:0 planar YCbCr 16-bit : Complain can't find decoder for P016.


Not implemented yet.


4:4:4 planar YCbCr 16-bit : Everything is grey.
Release 38494.

May accept Y416 but AviSynth+ does not implement it, I wonder what happens.

[jpsdr]

If you promise to port some useful filters for rgb planar mode, I can implement it.
Otherwise just having planar source "supported" but immediately converted to packed - is not useful.

No, so indeed, don't bother.


Since original VirtualDub was never hosted publicly, I have no idea about last code base.
If you have it, please share.

Can get it here (https://mega.nz/#!VJ9j1aQC!lD2fVyRJuVA3ncM1tOPIeZJ6uEWPdQS1WxEt51zI2Xk). That's the last version that has been made avaible a loong time ago already (you can get it only in the forum, now unfortunately closed).
Thanks for your work on this upgraded version.

I've tested only the modes avaibles on the Decode format menu, that's why i've tested 16 bits 4:2:0.

Thanks for the links with all VDubMod version.

[pinterf]

New test build
Avisynth plus r2372-dev (http://www.mediafire.com/file/rl3fuac03tk3kuz/avsplus-r2372.7z)

20170110 r2372dev (vdubmod14 VfW test)

New: SSE2/SSE4 for 10-16 bit <-> 10-16 bit Planar RGB (and Alpha plane) full scale conversions
(needed for automatic planar RGB -> packed RGB VfW conversions)
VfW:
Fixed: Y3[10][10],Y3[10][16] fourcc's byte order
New: Planar RGB(A) (MagicYUV)
10,12,14,16 bits: G3[0][10], G4[0][10], G3[0][12], G4[0][12], G3[0][14], G4[0][14], G3[0][16], G4[0][16]
New: YUV444P16 to fourcc Y416
New: Automatic conversion of 12, 14 and float YUV formats to 16 bit for 4:2:0 and 4:2:2
Note: OPT_Enable_Y3_10_16 is still valid as if format was originally 16 bits
New: Automatic conversion of 10, 12, 14 and float YUV formats to 16 bit for 4:4:4
New: Conversion of 10, 12, 14 and float planar RGB formats to RGB64
when global Avisynth variable Enable_PlanarToPackedRGB is true
New: Conversion of 8 bit planar RGB formats to RGB24
when global Avisynth variable Enable_PlanarToPackedRGB is true
New: Conversion of 8 bit planar RGBA formats to RGB32
when global Avisynth variable Enable_PlanarToPackedRGB is true

Note: OPT_VDubPlanarHack=true may still be needed for Virtualdub for YUV planar outputs other than YV12 or else U and V planes are exchanged
Edit: this must affect only 8 bit videos. Fixed in a following release


Supported formats:
BRA[64],b64a,BGR[48],P010,P016,P210,P216,Y3[10][10],Y3[10][16],v210,Y416
G3[0][10], G4[0][10], G3[0][12], G4[0][12], G3[0][14], G4[0][14], G3[0][16], G4[0][16]

Default format FourCCs:
RGB64: BRA[64]
RGB48: BGR[48]
YUV420P10: P010
YUV420P16: P016
YUV422P10: P210
YUV422P16: P216
YUV444P16: Y416
Planar RGB 10-16 bit: G3[0][10], G3[0][12], G3[0][14], G3[0][16]
Planar RGBA 10-16 bit: G4[0][10], G4[0][12], G4[0][14], G4[0][16]

Global variables to override default formats:
OPT_Enable_V210 = true --> v210 for YUV422P10
OPT_Enable_Y3_10_10 = true --> Y3[10][10] for YUV422P10
OPT_Enable_Y3_10_16 = true --> Y3[10][16] for YUV422P16
OPT_Enable_b64a = true --> b64a for RGB64
Enable_PlanarToPackedRGB = true --> RGBP8->RGB24, RGBAP8->RGB32, all other bit depths to RGB64

[shekh]

New test build
Avisynth plus r2372-dev (http://www.mediafire.com/file/rl3fuac03tk3kuz/avsplus-r2372.7z)


> New: YUV444P16 to fourcc Y416

video data is too short (w*h*6 bytes, should be w*h*8 bytes)

> Note: OPT_VDubPlanarHack=true may still be needed for Virtualdub for YUV planar outputs other than YV12 or else U and V planes are exchanged

I dont know, who is guilty? The Y3[10][10] output works with magic, but requires hack with avs+

[pinterf]

It's history.
Comment in avisynth.h:
// Hack YV16 and YV24 chroma plane order for old VDub's

[shekh]

It's history.
Comment in avisynth.h:
// Hack YV16 and YV24 chroma plane order for old VDub's

Does it mean there is old (bad) VD, and there is new one (which?), where the hack is not needed anymore?
But I have to apply it now, is this expected?

[pinterf]

1.) OK, Y416 is now really done but cannot test, vdub says: XYUV64 output is not implemented. Using vdubmod 38494.

2.) (plane hack)
It looks something like this in the avs source


// Old VDub wants YUV for YV24 and YV16 and YVU for YV12.
if (parent->VDubPlanarHack && !vi.IsYV12()) {
plane1 = PLANAR_U;
plane2 = PLANAR_V;
}
else {
// Set default VFW output plane order.
plane1 = PLANAR_V;
plane2 = PLANAR_U;
}

[shekh]

"XYUV64 output is not implemented" is message from output (dubbing) part, why you see it?
Has nothing to do with raw/avs input.

I think there is misunderstanding, Y3[10][16] is not 16-bit YV16, it has YUV plane order while YV16 has YVU plane order.


ConvertToYV16()

works (YV16)


OPT_Enable_Y3_10_16 = true
ConvertToYV16().ConvertBits(16)

swapped


OPT_VDubPlanarHack=true
OPT_Enable_Y3_10_16 = true
ConvertToYV16().ConvertBits(16)

correct

There is no reason for Y3[10][16] to be affected by VDubPlanarHack since it is brand new fourcc.

[pinterf]

"XYUV64 output is not implemented" is message from output (dubbing) part, why you see it?
Has nothing to do with raw/avs input.

I just had a look at the log window after clicking on play.

[shekh]

I just had a look at the log window after clicking on play.

Thanks, I too often forget about play button.

[pinterf]

I think there is misunderstanding, Y3[10][16] is not 16-bit YV16, it has YUV plane order while YV16 has YVU plane order.

There is no reason for Y3[10][16] to be affected by VDubPlanarHack since it is brand new fourcc.
O.K. I will then use (vi.IsYV16() || vi.IsYV24())
instead of !vi.IsYV12()
In the 8 bit world the latter was enough.
What about YV411? (Y41B)

[ajp_anton]

Question: why are there two versions of RGB, planar and packed? Does the user really have to know/care which one is used?

[jpsdr]

Something came to my mind, i've checked in avisynth.h and didn't see any information about it.
Standard/normal YUV mode is 16..235 for Y and 16..240 for UV. You can have a "full range" mode, but it's "unusual" or not the standard.
VDub has in its color mode a difference for the YUV mode between full range or limited range. I didn't see anything like this in avisynth. Have i missed it (in that case where is it), or is it just that there is not a such thing ?
If there is not something to chose between full or limited range, can we assume that the behavior in this case is the standard/common behavior, meaning the limited range ?
What are the specifications for the extended bit range ? Are they also limited, or are they just only full range by default ?
If limited, how is the range ? Is it proportional (16-240 becomes 4096-61440 in 16 bits) or fixed (16-240 becomes 16-65520 in 16 bits) ?

That make me realise that since the begining, at least the resample and nnedi3 filters are prone to produce incorrect results, as they clip only to 0-255, meaning they can produce out of range values in case of YUV data (but not in case of RGB data, of course).

So, what is exactly the situation about these points ?

[TheFluff]

Avisynth has functions to convert between full and limited range (just pointing that out, because it does seem like you might have somehow missed this) but does not have metadata flagging to keep track of which range a given clip has.

YUV limited range ("TV range") numerical limits for bitdepths above 8 are quite well-defined (see f.ex. the H.264 standard). For any bitdepth, the luma offset is
16 * (2^(bitdepth - 8))
while the range is
219 * (2^(bitdepth - 8))
For chroma, the offset is the same, but substitute 224 for 219 to get the range.

Full range YUV on the other hand isn't well defined at all. It's been discussed extensively in this thread before, see here (http://forum.doom9.org/showthread.php?p=1773277#post1773277) and a number of posts forward.

[jpsdr]

but does not have metadata flagging to keep track of which range a given clip has.

Argh.... That is very troublesome, it's a shame something like this have been missed when it should have been present since the begining...
Thanks for the others informations.

[pinterf]

Can someone help me the filter fft3dGPU crashed if I use SetFilterMTMode("FFT3dGPU", 3)
Here is my script:

Reproduced, but cannot help with it.

I tried with this simplified script:
Colorbars(pixel_type="YV12")
SetFilterMTMode("FFT3dGPU", 3)
FFT3DGPU(sigma=4,bt=3)
Prefetch(6)


Debug log shows, that sometimes this filter requests negative frames.
This was already mentioned, related link:
https://forum.doom9.org/showthread.php?p=1671525#post1671525

Debug log with Prefetch(6) until the sad finish, which occured in fft3dgpu.dll when frame number 7 was requested from it.

ColorBars::GetFrame 0
ColorBars::GetFrame 3
ColorBars::GetFrame 2
ColorBars::GetFrame 1
ColorBars::GetFrame 1
ColorBars::GetFrame -1
ColorBars::GetFrame 5
ColorBars::GetFrame 4
ColorBars::GetFrame 4
ColorBars::GetFrame 4
ColorBars::GetFrame 2
ColorBars::GetFrame 1
ColorBars::GetFrame 0
ColorBars::GetFrame 6
ColorBars::GetFrame 4
ColorBars::GetFrame 6
ColorBars::GetFrame 5
ColorBars::GetFrame 7
ColorBars::GetFrame 1
ColorBars::GetFrame 0
ColorBars::GetFrame 7
ColorBars::GetFrame 8
ColorBars::GetFrame 3
ColorBars::GetFrame 7
Cache::GetFrame LRU_LOOKUP_NO_CACHE: [FFT3DGPU] n= 2 child=007302F8 frame=0A4BF9E8 vfb=0900AEF8 videoCacheSize=0 SeekTime :0.068393
Cache::GetFrame LRU_LOOKUP_NO_CACHE: [FFT3DGPU] n= 1 child=007302F8 frame=0A4BF8B0 vfb=006B6D20 videoCacheSize=0 SeekTime :0.069542
ColorBars::GetFrame 2
ColorBars::GetFrame 6
ColorBars::GetFrame 13
ColorBars::GetFrame 1
Cache::GetFrame LRU_LOOKUP_NO_CACHE: [FFT3DGPU] n= 6 child=007302F8 frame=0A4BFAB8 vfb=0900AEB8 videoCacheSize=0 SeekTime :0.075657
ColorBars::GetFrame 8
Cache::GetFrame LRU_LOOKUP_NO_CACHE: [FFT3DGPU] n= 0 child=007302F8 frame=0A4BFA50 vfb=0900C178 videoCacheSize=0 SeekTime :0.077987
Cache::GetFrame LRU_LOOKUP_NO_CACHE: [FFT3DGPU] n= 4 child=007302F8 frame=0A4BF918 vfb=0900A4F8 videoCacheSize=0 SeekTime :0.078408
Cache::GetFrame LRU_LOOKUP_NO_CACHE: [FFT3DGPU] n= 3 child=007302F8 frame=0A4BF980 vfb=0900C1B8 videoCacheSize=0 SeekTime :0.078792
Cache::GetFrame LRU_LOOKUP_NO_CACHE: [FFT3DGPU] n= 5 child=007302F8 frame=0A4BFB20 vfb=0900ADF8 videoCacheSize=0 SeekTime :0.078573
ColorBars::GetFrame 8
Exception thrown at 0x02DF1FDA (FFT3dGPU.dll) in AVSMeter.exe: 0xC0000005: Access violation reading location 0x00000000.


Although this filter is set for serialized mode in MT, the frame requests are not sequential in a multithreaded environment. Requested frame numbers can jump randomly back and forward. Maybe this situation is not handled too well in the code, but seeing no source for it I cannot make any further assumption.

This post got a bit long, but interesting to see what happens in the background:

Without Prefetch (non-MT):
ColorBars::GetFrame -1
ColorBars::GetFrame 0
ColorBars::GetFrame 1
ColorBars::GetFrame 0
ColorBars::GetFrame 2
Cache::GetFrame LRU_LOOKUP_NO_CACHE: [FFT3DGPU] n= 0 child=090A34B0 frame=005CF580 vfb=08E3F838 videoCacheSize=0 SeekTime :0.025495
ScriptEnvironment::GetNewFrame NEW METHOD EXACT hit! VideoFrameListSize= 1 GotSize= 460831 FrReg.Size= 1 vfb=08E3F838 frame=005CF580 SeekTime:0.000010
frame 005CF580 RowSize=640 Height=480 Pitch=640 Offset=24
ScriptEnvironment::GetNewFrame returning frame. VideoFrameListSize was 1
ColorBars::GetFrame 1
ColorBars::GetFrame 3
Cache::GetFrame LRU_LOOKUP_NO_CACHE: [FFT3DGPU] n= 1 child=090A34B0 frame=005CF580 vfb=08E3F838 videoCacheSize=0 SeekTime :0.006794
ScriptEnvironment::GetNewFrame NEW METHOD EXACT hit! VideoFrameListSize= 1 GotSize= 460831 FrReg.Size= 1 vfb=08E3F838 frame=005CF580 SeekTime:0.000006
frame 005CF580 RowSize=640 Height=480 Pitch=640 Offset=24
ScriptEnvironment::GetNewFrame returning frame. VideoFrameListSize was 1
ColorBars::GetFrame 2
ColorBars::GetFrame 4
Cache::GetFrame LRU_LOOKUP_NO_CACHE: [FFT3DGPU] n= 2 child=090A34B0 frame=005CF580 vfb=08E3F838 videoCacheSize=0 SeekTime :0.006903
ScriptEnvironment::GetNewFrame NEW METHOD EXACT hit! VideoFrameListSize= 1 GotSize= 460831 FrReg.Size= 1 vfb=08E3F838 frame=005CF580 SeekTime:0.000016
frame 005CF580 RowSize=640 Height=480 Pitch=640 Offset=24
ScriptEnvironment::GetNewFrame returning frame. VideoFrameListSize was 1
ColorBars::GetFrame 3
ColorBars::GetFrame 5
Cache::GetFrame LRU_LOOKUP_NO_CACHE: [FFT3DGPU] n= 3 child=090A34B0 frame=005CF580 vfb=08E3F838 videoCacheSize=0 SeekTime :0.006695
ScriptEnvironment::GetNewFrame NEW METHOD EXACT hit! VideoFrameListSize= 1 GotSize= 460831 FrReg.Size= 1 vfb=08E3F838 frame=005CF580 SeekTime:0.000005
frame 005CF580 RowSize=640 Height=480 Pitch=640 Offset=24
ScriptEnvironment::GetNewFrame returning frame. VideoFrameListSize was 1
ColorBars::GetFrame 4
ColorBars::GetFrame 6
Cache::GetFrame LRU_LOOKUP_NO_CACHE: [FFT3DGPU] n= 4 child=090A34B0 frame=005CF580 vfb=08E3F838 videoCacheSize=0 SeekTime :0.005836
ScriptEnvironment::GetNewFrame NEW METHOD EXACT hit! VideoFrameListSize= 1 GotSize= 460831 FrReg.Size= 1 vfb=08E3F838 frame=005CF580 SeekTime:0.000005
frame 005CF580 RowSize=640 Height=480 Pitch=640 Offset=24
ScriptEnvironment::GetNewFrame returning frame. VideoFrameListSize was 1
ColorBars::GetFrame 5
ColorBars::GetFrame 7
Cache::GetFrame LRU_LOOKUP_NO_CACHE: [FFT3DGPU] n= 5 child=090A34B0 frame=005CF580 vfb=08E3F838 videoCacheSize=0 SeekTime :0.006020
ScriptEnvironment::GetNewFrame NEW METHOD EXACT hit! VideoFrameListSize= 1 GotSize= 460831 FrReg.Size= 1 vfb=08E3F838 frame=005CF580 SeekTime:0.000005
frame 005CF580 RowSize=640 Height=480 Pitch=640 Offset=24
ScriptEnvironment::GetNewFrame returning frame. VideoFrameListSize was 1
ColorBars::GetFrame 6
ColorBars::GetFrame 8

[pinterf]

New dev build
Avisynth Plus r2380-dev (http://www.mediafire.com/file/6pyic6yoto80vtq/avsplus-r2380.7z)

20170111 r2380

Overlay: Modes "Blend", "Luma" and "Chroma" now support all bit depths and 444 conversionless (use444=false) mode
Overlay: fix SSE2 Blend for mask+opacity for 10-16 bits
VfW: (vdubmod14 VfW test)
Fix: YUV444P16 or YUVA444P16 to fourcc Y416
if alpha channel is present, it will we copied, else filled with FFFF
Fix: VDubPlanarHack is checked only for 8 bit YUV planar sources


Now practically all color formats can be shown in vdubmod. If a specific bitdepth does not exist, it will be converted on-the-fly, and some alternative output formats can be hinted with OPT_xxx variables.
For details see readme.

(I'd like to separate github releases from these 'daily' builds. Albeit this version is quite usable, there were huge refactorizations and earthquake e.g. in Overlay, so I'd like to wait a bit more)

[LigH]

Question: why are there two versions of RGB, planar and packed? Does the user really have to know/care which one is used?

The "user" may not care. But a programmer has to. Planar formats have an important advantage to process video filters fast, but it is completely different to the way the video memory stores pixels displayed on screen.

Planar RGB (components can be kept in separate memory blocks, the same pixel will have the same offset in all components, needs to be calculated only once per pixel):
RRRR...RRRR

GGGG...GGGG

BBBB...BBBB

Packed RGB24 (please notice that memory addresses aligned to 32-bit structures = DWORD are addressed most efficiently in 32-bit systems):
(R,G,B)(R
G,B)(R,G
B)(R,G,B)
...

Packed RGB32 (to align pixels with 32-bit addresses, a fourth byte is inserted which may contain an alpha value – or be ignored, which wastes RAM):
(R,G,B,A)
(R,G,B,A)
(R,G,B,A)
...

[TheFluff]

VS only supports packed RGB for backwards compatibility with Avisynth and for output. Internally in a filtering framework there is no reason whatsoever to ever use packed. Just unpack on input and pack on output if you have to - my gut feeling says that for any but the most trivial filters that's going to be insignificantly slower than filtering packed (and you can drop a dumb extra code path too). There are most likely no particularly useful or interesting RGB only filters anyway, so breaking things shouldn't be a big deal.

[ajp_anton]

But what is the point then in using packed in Avisynth, which is about processing video, not displaying it? If the input serves packed, then immediately "unpack" it. And pack it again for the output if needed.
Is there any reason for the user to ever convert to packed RGB? And if there are rare cases, why not just have one type of planar "ConvertToRGB24" (/32/48/64) function, and require "packed=true" for packed? It's easier to remember from previous experience that RGB48 is 16-bit per component RGB without alpha, than remembering whatever the name of the planar versions are (tried to google them for this post, but didn't find them fast enough). Having everything the same type (planar?) makes things easier for the user.

[LigH]

Many VfW compatible tools don't support planar RGB. They can't handle it. It was not supported by Microsoft in a blank installation of most Windows versions (I am not even sure if there are any supporting VfW codecs as of today). I would even believe, if the semi-pro home users did not insist in it, hardly any professional software company would have cared about it... So, for ancient compatibility's sake, AviSynth still must be able to output packed RGB. The most compatible way of displaying images in Windows, DIB = "Device Independent Bitmaps", was invented with packed-pixel RGB and palette formats only, AFAIK. Planar RGB is a rather recent invention, I believe...

YUV based formats are useful for real-life content, whereas RGB based formats are common for computer generated content. Just imagine screen recordings of a game or an application's user interface. Recording that in a YUV based format, especially with the most common 4:2:0 chroma subsampling and TV range, would limit the color saturation and chrominance resolution, blurring and fading 1-pixel wide colored lines.

[wonkey_monkey]

If the input serves packed, then immediately "unpack" it. And pack it again for the output if needed.

That's needlessly wasteful.

Packed RGB(A) has its advantages. Want to copy a whole pixel? With packed RGB32, that's two instructions. With planar, it's several more.

[Myrsloik]

That's needlessly wasteful.

Packed RGB(A) has its advantages. Want to copy a whole pixel? With packed RGB32, that's two instructions. With planar, it's several more.

TRIGGER WARNING

I don't care about ancient cpus. Take that!

This thread is now painful to read. Truly painful. I wish I could quote all the stupid assumptions but the most recent example will have to do.

1. The unpack-process-pack method is effectively no more expensive than keeping pixels packed. This is because you generally have to copy memory into a frame in source filters and there's a memcpy at the VfW side too. Ha!

2. To whoever said something about DIB. It's irrelevant because they only go up to rgb32. Doesn't say what everything else should be. Also asking what the early 90s at best thought was a good idea IS NOT A GOOD IDEA.

3. About using the most common input format as the processing format: b64a is the most common rgb64 format. It's BIG STINKING ENDIAN AND YOU DON'T WANT TO GO THERE ON A LITTLE ENDIAN CPU.

4. Individual examples about the pros and cons of different pixel layouts. You know what? (you obviously don't since you post them) IT DEPENDS ON THE ALGORITHM THE INDIVIDUAL FILTERS USE.

5. Planar is still your friend even if there are no direct performance gains. This is because of code sharing between yuv and rgb paths in filters.

6. If you allow unchanged planes to be passed through (as VS does) you'll save a lot of memcpy.

7. Read and write sizes don't matter much as long as they're 16 bits or more. For simple 8 bit filters sse2 can speed things up a lot just by combining loads and stores. With multiple threads and a simple 16 bit filter you'll usually become ram bandwidth limited even without simd.

(EN)CODING TRUTH

[wonkey_monkey]

triggered warning

ftfy.

[LigH]

Regarding 2.: I don't say DIB compatibility is a "good" idea. I only say some people still use "legacy" software which doesn't know it better than that. And if packed RGB would be removed from AviSynth(+), then you could probably not use AviSynth(+) anymore in conjunction with such tools or plugins.

The questions were:

a) Why are there both worlds? – Legacy, compatibility, and different advantages for different kinds of use.

b) Should AviSynth(+) get rid of one? – Only if compatibility with legacy software doesn't matter.

[jpsdr]

@pinterf
In the process of avs+ upgrade/improvements, i suggest the following to fill the missing gaps.
It would work the way the new bitdepth functions works : "Do nothing" or return a default value if we are on standard avisynth.

It should be nice to add these missing metadata :
Range mode, result would be : NONE, FULL_RANGE, LIMITED_Y, LIMITED_C.
Two limited modes, because a grey plane can be either a true greyscale plane, or an extract of an RGB plane, or an extract of a YUV plane, in that case it can be a chroma plane.
For YUV mode, LIMITED_Y or LIMITED_C would be the same thing, but i propose the used of LIMITED_Y by default.
Color mode, result would be : NONE, REC601, etc...
MPEG mode, result would be : NONE, MPEG-1, MPEG-2.
Frame mode, result would be : NONE, PROGRESSIVE,INTERLACED.

Several way to handle them.
A function wich return the status, with NONE returned on not avs+.
A function which manualy set it, "doing nothing" on not avs+.
And the last, the "automatic" way.
The default value, when a clip is created, would be the default value used in functions specifying them.
For exemple, a ConvertYV16 has a default color matrix value, this is this default value which will be used when a clip is created.
Same for all the others tags.
When a function with one or more of these parameters exist is used, the behavior would be the following :
- If the meta data is not NONE, and the parameter is not specified, the value used is the one of the meta data.
- If the meta data is NONE, the meta data get the value of the default value of the parameter if it's not specified.
- If the parameter is specified, the metadata get the value of the parameter.
Some metadata are kept even if the format don't need it.
For exemple, an YUV clip converted to RGB, would it be directly converted, or would it be converted and result put in a different clip, the resulting RGB clip will keep the Color mode. Because this same color mode will be used if converted back to YUV without the color matrix specified in the called function.
Some metadata will be automaticaly changed according what is done, unless a parameter in the function specify it.
For exemple, an YUV clip converted to RGB will have the range parameter changed from LIMITED_x to FULL_RANGE. On the other way, an RGB clip converted to YUV will have the parameter changed from FULL_RANGE to LIMITED_Y (unless parameter specification, of course).
RGB will allways be FULL_RANGE, because it's RGB we're working with, not R'G'B'.
Extracted plane would have the parameter set accordingly.
En extracted plane from RGB or from YUV set to FULL_RANGE will be FULL_RANGE. Y or U/V plane extracted to LIMITED_x will be set accordingly.

Well, i think you see the picture.
What do you think ?
I personnaly think these metadata realy should be present, and adding them is within the actual avs+ improvement way.

[LigH]

slightly confused

Does pinterf also develop the legacy AviSynth? If not, he won't be able to implement any features there. Then your requested features will only exist in AviSynth+ at all.

MPEG mode: What does this mean? AviSynth(+) only handles uncompressed video frames. Do you refer to chroma subsampling locations?

[pinterf]

This is what I found.

VideoInfo struct, defined in Avisynth.h has an image_type property.
It is a bitmap, we have 32 bits for storing video related properties.
This is where BFF, TFF, and FIELDBASED info is stored.

Single bit properties can be checked with VideoInfo::Is(property) function.

Checking for the few existing properties are directly implemented
VideoInfo::IsFieldBased()
VideoInfo::IsBFF()
VideoInfo::IsTFF()

VideoInfo::SetFieldBased(bool fieldbased) is a shortcut for set/clear FIELDBASED flag, something like this:
void VideoInfo::SetFieldBased(bool isfieldbased) { if (isfieldbased) image_type|=IT_FIELDBASED; else image_type&=~IT_FIELDBASED; }

One can set and clear a bit property as:
VideoInfo::Set(property) and VideoInfo::Clear(property)

In avisynth.h these are defined:
// Imagetype properties

int image_type;

enum {
IT_BFF = 1<<0,
IT_TFF = 1<<1,
IT_FIELDBASED = 1<<2
};


Then there are some other defines, that are nowhere used. At least not inside avisynth plus.

Based on the CS_xxx naming, maybe these were originally intented to appear in the pixel_type. But as VideoInfo:: pixel_type is directly used for checking/setting the video format, using these chroma placement bits in pixel_type would break plugins and avisynth itself.


// Chroma placement bits 20 -> 23 ::FIXME:: Really want a Class to support this
enum {
CS_UNKNOWN_CHROMA_PLACEMENT = 0 << 20,
CS_MPEG1_CHROMA_PLACEMENT = 1 << 20,
CS_MPEG2_CHROMA_PLACEMENT = 2 << 20,
CS_YUY2_CHROMA_PLACEMENT = 3 << 20,
CS_TOPLEFT_CHROMA_PLACEMENT = 4 << 20
};

[pinterf]

slightly confused

Does pinterf also develop the legacy AviSynth? If not, he won't be able to implement any features there. Then your requested features will only exist in AviSynth+ at all.


In avisynth.h there are a couple of VideoInfo:: functions that smartly fallback to return a default value when the relevant function does not exist in avisynth linkage.

Thus using this avisynth.h in your plugin development you can use the new functions (VideoInfo::BitsPerComponent(), etc...) and it won't crash when your plugin is used with classic avisynth or pre-high bit depth avisynth plus. You needn't distinct whether your target audience uses newer avisynth plus or classic avisynth.

Possibly specialized image_type getter and setter functions could work in such a way, but one could use the all-compatible VideoInfo::Set and Clear

[Groucho2004]

Can someone help me the filter fft3dGPU crashed if I use SetFilterMTMode("FFT3dGPU", 3)
Apart from instability/crashing, running fft3dgpu multi-threaded is pointless. The speed does not increase and the GPU memory consumption goes through the roof.

I suggest you use FFT3DFilter from here (https://forum.doom9.org/showthread.php?t=173229). Multi-threaded, it will be faster than fft3dgpu.

[jpsdr]

Do you refer to chroma subsampling locations?
Yes, and it seems that some features allready exist, this one seems to be already included.

[ajp_anton]

So from the planar/packed discussion, it seems that:
Packed is only needed for output. Otherwise it's easier (shared code with planar YUV) and faster (non-ancient CPUs only?) to process. Therefore IMO planar should be the default RGB format with ConvertToRGB24 etc, and Avisynth should only convert to packed before outputting (can it detect if whatever's at the other end wants packed or if it supports planar?). There should also be a "packed"-named bool argument when converting to any RGB format, in case an old filter requires it. What do you think?

[StainlessS]

There should also be a "packed"-named bool argument when converting to any RGB format, in case an old filter requires it.

With default true, unless intent is to break nearly everything ever written.

[tuanden0]

@Groucho2004: :thanks:

That was great, no crashed with MT mode 3 and I can use the fft3dgpu setting for fft3dfilter. :D

[TheFluff]

Regarding 2.: I don't say DIB compatibility is a "good" idea. I only say some people still use "legacy" software which doesn't know it better than that. And if packed RGB would be removed from AviSynth(+), then you could probably not use AviSynth(+) anymore in conjunction with such tools or plugins.

The questions were:

a) Why are there both worlds? – Legacy, compatibility, and different advantages for different kinds of use.

b) Should AviSynth(+) get rid of one? – Only if compatibility with legacy software doesn't matter.

I think you're kinda missing the point here. Supporting everything under the sun plus the kitchen sink is of course "good" for the end user, but it's not free - it adds complexity, both to the user and to the programmer, and it adds maintenance costs (work on an enthusiast project may be free as in beer, but it has a non-monetary price nevertheless). If one standard way of doing things is agreed upon, the process of interacting with the filtering framework is streamlined and eased for everyone - people using it, people writing filters for it and people maintaining the framework itself. That is highly desirable.

Nobody has suggested that input or output of packed RGB should not be supported. Not even VS goes that far, despite a wholehearted desire to throw out everything old. As you say, there are still important legacy systems that you kinda have to deal with that only support packed.

What has been proposed is to only use planar RGB internally, and automatically pack/unpack on input and output. The reasons for this are as follows:

1. Packed 8-bit RGB is an oddity in 2017. Literally everything else is planar - higher bitdepth RGB, YUV, YCgCo, etc. If you switch to planar as a standard, there is a not insignificant number of filters that can be adapted to use the same code path for all colorspaces, which is pretty huge for maintenance.

2. It's essentially free. Packing or unpacking is barely more expensive than copying the frame, and as Myrsloik points out you almost always have to do that at each end of your filter chain anyway.

3. It has performance benefits, especially for filters that want to treat some components differently or pass them through unchanged. Some filters could in theory benefit from packed, but since those benefits are 8-bit RGB only that's almost completely irrelevant, and it is likewise theoretically possible to rewrite the algorithm to benefit from planar instead.


Now, to fully reap these benefits you must standardize on planar, or you're still left with the whole legacy codepath maintenance garbage. Hence, if you want to support legacy RGB filters you should pack/unpack automatically on input/output from those. That should hopefully give people an incentive to update their filters to avoid the (admittedly rather minor) performance hit.

[LigH]

OK, understood ... "internally", for the core filters, this would surely be a good idea, assuming that the benefits are as obvious as you explain them (which I would probably agree with). You may just need to repack not only for the final output to the calling application, but also for plugins supporting packed RGB and addressing frame content directly (if this is included in your statement "automatically pack/unpack on input and output", you already considered that). And new plugins working in RGB space will surely be written to support it in planar organization as well when compatibility specifically to AviSynth+ is desired.

[jpsdr]

Based on the CS_xxx naming, maybe these were originally intented to appear in the pixel_type. But as VideoInfo:: pixel_type is directly used for checking/setting the video format, using these chroma placement bits in pixel_type would break plugins and avisynth itself.


// Chroma placement bits 20 -> 23 ::FIXME:: Really want a Class to support this
enum {
CS_UNKNOWN_CHROMA_PLACEMENT = 0 << 20,
CS_MPEG1_CHROMA_PLACEMENT = 1 << 20,
CS_MPEG2_CHROMA_PLACEMENT = 2 << 20,
CS_YUY2_CHROMA_PLACEMENT = 3 << 20,
CS_TOPLEFT_CHROMA_PLACEMENT = 4 << 20
};

I didn't read properly.
Do you mean that these bits are already used for something else, so i can't use them for checking the chroma placement ?

[pinterf]

These chroma placement bits are defined but nowhere used.
At many places VideoInfo.pixel_type is checked and set directly. (like vi.pixel_type == VideoInfo:: CS_YUV420P16, or vi.pixel_type=VideoInfo:: CS_YV12)
If we put chroma placement bits in VideoInfo.pixel_type then all these comparison will fail because they modify the pixel_type constants. The bits could be masked out before comparison like VideoInfo::IsColorSpace does now, but I think for the placement (and any other) metadata we should use the image_type property in order not to break existing plugins.

[jpsdr]

Ok, thanks for the clarification.

[chummy]

Hello, so i have a script with MFlowBlur which works with SET Avisynth MT but cannot make avisynth+ MT work on it.

SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("ffvideosource", 3)
SetFilterMTMode("RGtools", 1)

[StainlessS]

Chummy, Pinterf will want some kind of script he can test, post the whole script including MFlowBlur().

[chummy]

RemoveGrain(2,5)
UUMblur3()
return Last
####
function UUMblur3(clip C, int "percentblur", int "speed")
{
Assert(C.IsYV12, "source must be YV12")

percentblur = Min(Max(0, Default(percentblur, 30)), 80)
speed = Default(speed, 0)

super = MSuper(C)

## slow : medium : fast
B = (speed<0)
\ ? MFlowBlur(C, super,
\ MAnalyse(super, search=3, searchparam=24, truemotion=true, isb=true),
\ MAnalyse(super, search=3, searchparam=24, truemotion=true, isb=false),
\ blur=Float(percentblur))
\ : (speed==0)
\ ? MFlowBlur(C, super,
\ MAnalyse(super, search=4, searchparam=16, truemotion=true, isb=true),
\ MAnalyse(super, search=4, searchparam=16, truemotion=true, isb=false),
\ blur=Float(percentblur))
\ : MFlowBlur(C, super,
\ MAnalyse(super, search=4, searchparam= 2, truemotion=true, isb=true),
\ MAnalyse(super, search=4, searchparam= 2, truemotion=true, isb=false),
\ blur=Float(percentblur))

return (percentblur==0) ? C : B
}

[Groucho2004]

Hello, so i have a script with MFlowBlur which works with SET Avisynth MT but cannot make avisynth+ MT work on it.

SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("ffvideosource", 3)
SetFilterMTMode("RGtools", 1)
Can you elaborate on "cannot make avisynth+ MT work on it"?

[chummy]

With Set MT it's capable to use all threads from my CPU and speed up the processing by almost 3.5x, while without multithreading in Avisynth+ it stuck to slow speed. 1.60fps with avisynth+ single-thread process and 15% CPU usage, while with SET multithreading it achieving almost 6fps and 90% CPU usage. Avisynth+ MT works for some other scripts which i tried but not for this one. I hope that explain what i trying to say.

[Groucho2004]

With Set MT it's capable to use all threads from my CPU and speed up the processing by almost 3.5x, while without multithreading in Avisynth+ it stuck to slow speed. 1.60fps with avisynth+ single-thread process and 15% CPU usage, while with SET multithreading it achieving almost 6fps and 90% CPU usage. Avisynth+ MT works for some other scripts which i tried but not for this one. I hope that explain what i trying to say.
Where did you put the "prefetch" statement?

[chummy]

Where did you put the "prefetch" statement?
At bottom like any other script.

[Groucho2004]

At bottom like any other script.
If you put it at the bottom of the script you posted above it will of course not work, the unnecessary "return last" prevents it from being executed.
Post the entire script.

[chummy]

If you put it at the bottom of the script you posted above it will of course not work, the unnecessary "return last" prevents it from being executed.
Post the entire script.

Thanks for the information, so i put prefetch before return last and multithreading is working fine.

[gaak]

Just started using 64 bit Avisynth+ for my project and it's working out fine. I was wondering if there is a formal way to request a 64 bit version to be made from a 32 bit source? I can't find a 64 bit version of RoboCrop. I asked the author and he is unable to do it because he only has a 32 bit system. I know AutoCrop is available and have been using it, but I find RoboCrop to be more reliable. Thanks.

[wonkey_monkey]

This may be a stupid question but I've just migrated to Avisynth+. I installed the FilterSDK, but where is, or what is the name of, the header file I should be including in my plugin development projects from now on? And is there an avisynth+.lib I should be linking too?

I usually get these things working by trial-and-error...

---

Also, should I have an avisynth+.dll somewhere? It's all installed and working, but I can't find a file called that, and any avisynth.dlls I can find (x86 and x64) are 2.6.0.5.

[JoeyMonco]

You either include avisynth.h or avisynth_c.h (depending on whether you want the C or C++ API) just like normal avisynth. The DLL and lib are still also just called avisynth, not avisynth+, as well. If the DLL were renamed it would no longer be a drop-in replacement for classic Avisynth...

[Groucho2004]

I installed the FilterSDK, but where is, or what is the name of, the header file I should be including in my plugin development projects from now on?Use the AVS+ headers from here (https://github.com/pinterf/AviSynthPlus/tree/MT/avs_core/include).
And is there an avisynth+.lib I should be linking too?If you need it (only when you're writing c-plugins), you have to build it yourself with the AVS+ sources.
Also, should I have an avisynth+.dll somewhere? It's all installed and working, but I can't find a file called that, and any avisynth.dlls I can find (x86 and x64) are 2.6.0.5.It's avisynth.dll, also for AVS+. If you have 2.6.0.5 versions you probably did something wrong, I recommend uninstalling all traces of previous versions and cleaning the registry and plugin directories before installing AVS+.
By the way, there is no 2.6.0.5 64 bit version as far as I know.
Edit: I stand corrected. There is a 2.6.0.5 64 bit version, I forgot about AVS+ r1576.

[wonkey_monkey]

It's avisynth.dll, also for AVS+. If you have 2.6.0.5 versions you probably did something wrong

Here's the properties of the DLL in System32:

http://i.imgur.com/Y3p9gyt.png

It says Avisynth+ 2.6...

If you need it (only when you're writing c-plugins)

I guess I'm doing something wrong, then, since I can't compile without linking to it, and also need to define AVS_LINKAGE_DLLIMPORT... these are unfortunately all the things I've never tried to understand, because I just did them and they made it so I could write filters to monkey around with pixels (which I do understand).

Otherwise I get this:

error LNK2001: unresolved external symbol "__declspec(dllimport) struct AVS_Linkage const * const AVS_linkage" (__imp_?AVS_linkage@@3QBUAVS_Linkage@@B)

[pinterf]

This version could be the old v1576?

[wonkey_monkey]

It's what you get when click the big "Installer" button at www.avs-plus.net.

[qyot27]

Here's the properties of the DLL in System32:

http://i.imgur.com/Y3p9gyt.png

It says Avisynth+ 2.6...
Then you definitely need to upgrade, because that version of AviSynth+ (I'm guessing you just installed 0.1/r1576 from the project page, or possibly one of the really early builds from the MT branch, given the 2014 modified date) has been outdated for a long time; it was released three years ago. On a partially separate tangent, a 'stable' 0.2 release has been right on the cusp of being released for over a year but stuff just keeps sidetracking it, which is why simply using the periodic builds from git is the normal thing here.

The latest build by ultim (I can't remember what the revision number was...r2173?) or the latest one by pinterf (r2380) is the one you should be using.

[wonkey_monkey]

Eh... well I get why things are the way they are, but it's this kind of situation that could easily put someone off ever trying to use Avisynth in the first place. The original 2.6 is outdated, or so advice I've seen hereabouts says, but the most prominent link to install the modernised fork is also out-of-date with no obvious instructions on how to get an up-to-date version, even if it is a beta...

So I got r2380, copied the x86 DLL to SYSWOW64 and the x64 DLL to System32, and copied the plugins+ and plugins64+ folders over their counterparts that were previously installed... and now I get "AVI Import Filter error: (Unknown) (80040154)" from just a "version" script.

Should I just go back to 2.6? My plugins seem to work okay with Avisynth+ anyway.

---

Edit: I finally figured out how to use AvisynthPluginInit3 instead of AvisynthPluginInit2 and now I don't need to link to avisynth.lib any more ¯\_(ツ)_/¯ I shall just stick to r1576 since it was good enough to have an installer at some point in history, and I've not had any problems with it so far.

[LigH]

It's what you get when click the big "Installer" button at www.avs-plus.net.

:rolleyes: It's such a pity that the official website is so outdated. You'll find recent MT versions by scanning this thread backwards carefully. :eek:

[real.finder]

:rolleyes: It's such a pity that the official website is so outdated. You'll find recent MT versions by scanning this thread backwards carefully. :eek:

or here http://avisynth.nl/index.php/AviSynth%2B#Downloads

[Bexley]

Just started using 64 bit Avisynth+ for my project and it's working out fine. I was wondering if there is a formal way to request a 64 bit version to be made from a 32 bit source? I can't find a 64 bit version of RoboCrop. I asked the author and he is unable to do it because he only has a 32 bit system. I know AutoCrop is available and have been using it, but I find RoboCrop to be more reliable. Thanks.

There is a 64-bit version here (http://avisynth.nl/index.php/AviSynth%2B#AviSynth.2B_x64_plugins) but I haven't tried it.

I also have just made the move over to AVS+ because I am finding x64 is able to do things that x32 can't, like TemporalDegrain MT on 1080p source. I'm still trying to work a lot of things out with plugins, and I'm having problems with RemoveDirtMC_SE. I have mvtools, masktools, rgtools, and fluxsmooth from the link above. I also have avsrecursion from Kassandro's RemoveDirt_x64 package. I can't find anything for NLmeansCL in x64, BUT I didn't have them on my x32 system either and it worked. :confused:

When I try to load RemoveDirtMC_SE, I get the following error.Script error: Clense does not have a named argument "cache"
If I edit the function script and remove the cache argument, I get the same error with RestoreMotionBlocks. I know this is an RGTools/RemoveGrain/RemoveDirt error somehow because I've seen it before a long time ago, but I can't remember or figure it out.

Anyone have suggestions?

[Reel.Deel]

@Bexley

RemoveDirtMC_SE uses a lot of older plugins that can probably be replaced by more modern ones. For example, modify the script to use KNLMeansCL instead of NLMeansCL. Regarding the cache parameter, RGTools does not have this parameter so remove all instances in the script. Onto 64-bit RemoveDirt, this version was claimed to be incompatible with the old AviSynth64 so it's a possibility that it also might not work in AviSynth+. See the note that I added at the bottom of the RemoveDirt wiki page:

Note: This version is incompatible with AviSynth, it's only here for reference! For more information on incompatibility read post 5 through 14 here (http://videoprocessing.fr.yuku.com/topic/127).

Edit:
:rolleyes: It's such a pity that the official website is so outdated. You'll find recent MT versions by scanning this thread backwards carefully. :eek:

As real.finder already stated, the AviSynth+ wiki page (http://avisynth.nl/index.php/AviSynth%2B) is the easiest way to keep up with all of the changes. I haven't been as active on the forums as of late but I still try to keep the wiki page up-to-date.

[real.finder]

Regarding the cache parameter, RGTools does not have this parameter so remove all instances in the script.


but it work for me with RGTools! maybe because I have AvsRecursion.dll

[Bexley]

RemoveGrainMC_SE uses a lot of older plugins that can probably be replaced by more modern ones. For example, modify the script to use KNLMeansCL instead of NLMeansCL. Regarding the cache parameter, RGTools does not have this parameter so remove all instances in the script. Onto 64-bit RemoveDirt, this version was claimed to be incompatible with the old AviSynth64 so it's a possibility that it also might not work in AviSynth+. See the note that I added at the bottom of the RemoveDirt wiki page:

Right, that clears up quite a bit. Thanks. That's where I got the package from, but I guess I didn't read far enough down. When I edit the function to remove the "cache" argument, it vomits all over my screen complaining that there is no function named RestoreMotionBlocks. If I'm reading kassandro's posts correctly, without an x64 version of RemoveGrainT, there is really no way to get it working. Right? If that's the case, can you recommend something comparable?

[Reel.Deel]

but it work for me with RGTools! maybe because I have AvsRecursion.dll

That's great! I've yet to try it, if it does indeed work, I'll add it to the x64 plugins list.

Hello, so i have a script with MFlowBlur which works with SET Avisynth MT but cannot make avisynth+ MT work on it.

SetFilterMTMode("DEFAULT_MT_MODE", 2)
SetFilterMTMode("ffvideosource", 3)
SetFilterMTMode("RGtools", 1)

Just a few observations:

Starting from AviSynth+ r2069 you don't really have to set an MT mode for source filters:
- Avs+ will now automatically recognize source filters. If it sees a source filter which has no MT-mode specified at all, it will automatically use mode 3 instead of the default MT mode. This is great for source filters as in their case it rarely hurts performance and they often need mode 3 anyway, and it will help yet unclassified source filters perform correctly without any user action. One step closer to the "it just works" target.


SetFilterMTMode("RGtools", 1) is incorrect. You have to use the filter name not the plugin name. For example, RgTools has RemoveGrain, Repair, Clense, etc. So to correctly set an MT mode you would write SetFilterMTMode("RemoveGrain", 1) or SetFilterMTMode("RgTools_RemoveGrain", 1). You'll have to do this for each filter included in the plugin.

[Bexley]

but it work for me with RGTools! maybe because I have AvsRecursion.dll

I also have that, but it's from kassandro's package that may or may not be incompatible. Where did you get it?

[real.finder]

That's great! I've yet to try it, if it does indeed work, I'll add it to the x64 plugins list.


in x86, in x64 it's not work, is the rgtools in x64 different or something?

[Reel.Deel]

Right, that clears up quite a bit. Thanks. That's where I got the package from, but I guess I didn't read far enough down. When I edit the function to remove the "cache" argument, it vomits all over my screen complaining that there is no function named RestoreMotionBlocks. If I'm reading kassandro's posts correctly, without an x64 version of RemoveGrainT, there is really no way to get it working. Right? If that's the case, can you recommend something comparable?

real.finder claims the 64-bit RemoveDirt plugins works. If that's true then you might be missing the runtime dependencies.

You don't need RemoveGrainT, the RemoveDirt script uses Clense, ForwardClense, and BackwardClense which is already included in RgTools.

[real.finder]

I also have that, but it's from kassandro's package that may or may not be incompatible. Where did you get it?

there are AvsRecursion_x64.dll by kassandro but it's seems broken or something else is

[Reel.Deel]

in x86, in x64 it's not work, is the rgtools in x64 different or something?

Ok you're confused. We're not talking about RgTools working or not, we're talking about the 64-bit RemoveDirt from here: http://avisynth.nl/index.php/RemoveDirt

See note at the bottom.

[real.finder]

real.finder claims the 64-bit RemoveDirt plugins works. If that's true then you might be missing the runtime dependencies.

You don't need RemoveGrainT, the RemoveDirt script uses Clense, ForwardClense, and BackwardClense which is already included in RgTools.

I didn't, see my post above :D

and RemoveDirtMC_SE need RemoveGrainT for it's prefilter

[real.finder]

Ok you're confused. We're not talking about RgTools working or not, we're talking about the 64-bit RemoveDirt from here: http://avisynth.nl/index.php/RemoveDirt

See note at the bottom.

away form RemoveDirt, I mean the RgTools and cache parameter

[Reel.Deel]

I didn't, see my post above :D

and RemoveGrainMC_SE need RemoveGrainT for it's prefilter

You claimed in post #2881 that RemoveDirt worked, but you were talking about 32-bit while we were discussing 64-bit.

So I guess it does need RemoveGrainT for TemporalRepair, I missed that. There's probably an alternative or a work around though. Anyways it's probably best it we take this discussion elsewhere. Starting to be a bit off topic for this thread.

Your post are sometimes very confusing :D

[real.finder]

You claimed in post #2881 that RemoveDirt worked, but you were talking about 32-bit while we were discussing 64-bit.

I was mean RgTools with cache parameter, anyway, yes, RemoveDirt not work in x64, just did test

[gaak]

There is a 64-bit version here (http://avisynth.nl/index.php/AviSynth%2B#AviSynth.2B_x64_plugins) but I haven't tried it.

@Bexley: Thanks, I'll try it now.

EDIT: @Groucho2004: Just looked at the file date. Wow, looks like you just did it today (well now it's yesterday). Thank you very much. Now that's quick!

EDIT2: @Bexley: Using it now, works great!

[pinterf]

New dev build.
Avisynth Plus r2397-dev (http://www.mediafire.com/file/bazu8v58ab318j6/avsplus-r2397.7z)

20170119 r2397

TemporalSoften: Planar RGB support
Speed: TemporalSoften: much faster average mode (thres=255)
radius=1 +70%, radius=2 +45%,
16bit: generally 7-8x speed (SSE2/4 instead of C)
SeparateColumns: 10-16bit,float,RGB48/64
WeaveColumns: 10-16bit,float,RGB48/64,PlanarRGB(A)
AddAlphaPlane: fix function parameter type list, clip type did not work
Internals: add SubframePlanarA to IScriptEnvirontment2 for frames with alpha plane
SwapUV: YUVA support
ConvertToRGB32/64: copy alpha from YUVA
SeparateRows,SeparateFields: PlanarRGB(A),YUVA support
WeaveRows: PlanarRGB(A), YUVA
Weave (fields,frames): YUVA,PlanarRGB(A)
Crop: Fast crop possible for frames with alpha plane (subframe)
AddBorders missing l/r/top/bottom vs. subsampling check for YUVA
Fix: YUVA->PlanarRGBA and YUVA42x->444 missing alpha plane copy
Speed: YUV444->RGB48/64: fast intermediate PlanarRGB(A) then RGB48/64 (instead of C)
Speed: RGB48/64->YUV4xx target: Planar RGB intermediate (instead of C, 10x faster)


I have one thing left in my list, to make Overlay work for Planar RGB (also as a new intermediate format for old packed RGB formats) and make it work in general without converting to 4:4:4 internal format.

[real.finder]

New dev build.
Avisynth Plus r2397-dev (http://www.mediafire.com/file/bazu8v58ab318j6/avsplus-r2397.7z)


big thanks :)

days ago I try use444=false in y8 then I get error that it's not supported, does that mean that y8 now don't convert to 444? (mean that it will be faster than normal avs in y8)

[pinterf]

Internally the processing still needs exactly three planes. Mask is also faked to 444 even if it is y8 only. I want to remove all these overheads. Integrating rgb to other modes than blend is harder a bit, but it is only a question of working effort.

[gaak]

I just tried to download your latest dev from mediafire. They launch other web pages when this is done. This last attempt launched a page that told me I had a virus and locked the computer. When I shut down and restarted my WiFi settings no longer show and I cannot bring them back. Of course, this is the 1st time my backup has failed. This is going to take a while.

[pinterf]

I have not experienced such behaviour from this site, sorry for that

[kypec]

I just tried to download your latest dev from mediafire. They launch other web pages when this is done.
I guess that uploading binary builds directly on github should be perfectly fine, isn't it? :thanks:

[gaak]

I have not experienced such behaviour from this site, sorry for that

First time for me too. I was able to get it back, I was just surprised/shocked.

[LigH]

Don't blame MediaFire in the first place. I would suspect a malicious advertizing network (ab)user spreading malware via Flash ads. But with ad blocker and script blocker add-ons in your browser, and regular updates if not even removal of Flash, chances to catch one should be quite low; passing on such security measures is grossly negligent, though (like visiting a brothel without a condom).

[StainlessS]

Also, use anything other than IE as browser. + nice to have eg FlashBlocker as FireFox AddOn, with everything that Ligh said too.
I rarely have any such problems when set up as above.

EDIT: As well as FlashBlock (linked 3 posts below by qyot27), I also have Flash Stopper (one of them dont always work, dont remember
which one):- https://addons.mozilla.org/en-US/firefox/addon/flashstopper/

[gaak]

Don't blame MediaFire in the first place. I would suspect a malicious advertizing network (ab)user spreading malware via Flash ads. But with ad blocker and script blocker add-ons in your browser, and regular updates if not even removal of Flash, chances to catch one should be quite low; passing on such security measures is grossly negligent, though (like visiting a brothel without a condom).

I use Firefox with Adblocker Plus. Script blocker? I'll look for one. But this only happens with mediafi

What happens is when I click on the download button other tabs open connecting to other web pages. I'm sorry if this is off-topic, but I need more specifics like what script blocker? Please PM me if it's more appropriate. I searched add_ons are you talking about a javascript blocker?

[Sparktank]

I use Firefox with Adblocker Plus. Script blocker? I'll look for one. But this only happens with mediafi

What happens is when I click on the download button other tabs open connecting to other web pages. I'm sorry if this is off-topic, but I need more specifics like what script blocker? Please PM me if it's more appropriate. I searched add_ons are you talking about a javascript blocker?

You could also try a download manager.

Something like JDownloader can load the link if you copy/paste the link without visiting the site and thus remove the risk of abused ads.
Most ad services have no real control over their own content. The users on MF have even less control over that.

uBlock Origin is a good alternative to AD+, it blocks more things where AD+ sold out to let some ads through for certain sites.
https://addons.mozilla.org/en-us/firefox/addon/ublock-origin/

NoScript is a good script blocker, but requires a lot of maintainence for every site you go to.
It can be tedious for new users. Everything is reversible, but has a huge learning curve.

[qyot27]

The aforementioned Flash blocker:
https://addons.mozilla.org/en-US/firefox/addon/flashblock/

[gaak]

Thank you all for your suggestions. It's all Installed.
Let's see what happens.

[sl1pkn07]

I guess that uploading binary builds directly on github should be perfectly fine, isn't it? :thanks:



@printf you can upload the avs+ binaries to github instead of cyberloker?

greetings

;_; (finally I stop feeling like dropout)

[StainlessS]

(finally I stop feeling like dropout)

Nah, you be still a dropout, but, there be other strange people too.

[MysteryX]

It's kind of a stupid question but... does the AVS+ new features work with INT16, FLOAT16 and/or FLOAT32?

[pinterf]

No float16. But avisynth plus can provide you this f16c cpu flag, I included it in the list.
One remark: if you support 16 bit integer, that means your plugin should supports 10, 12, 14 and 16 bit inputs also. "should" may be a strong word, but let's keep us to this rule in the future.

[MysteryX]

Oh... you support 10, 12, 14 and 16 bit? And 32-bit float (if overflow is needed)?

I'm finally starting to slowly take a look at how to add support in AviSynthShader. From 16-bit, it's easy, the data is already 16-bit. Perhaps the components need to be reversed, have to check. But for for 10, 12 and 14 bit, how do I convert? First convert to 16-bit, then convert to Shader format. Easy enough.

What's the function to convert a 10, 12 or 14 bit frame to 16 bit?

And I'm wondering, what's the point of 10-bit data except for input filter? AFAIK you can't calculate 10-bit data unless you convert it to 16-bit. The goal is to save memory space?

Edit: found my answers here (http://forum.doom9.org/showthread.php?p=1783714#post1783714)

[pinterf]

At 10 bits, you can use faster signed 16 bit integer aritmetic in simd, you don't neccessarily have to convert to 32 bits to avoid overflow.
For 10 bits you can still use lookup tables, as I did it in Tweak for example.
You are not saving memory space, 10 bit format still occupies two bytes, but the full range is 0..1023, 0..4095, 0..16383, etc...

[mcjordan]

6> conditional_functions.cpp
6>C:\AviSynthPlus\avs_core\filters\conditional\conditional_functions.cpp(44): fatal error C1083: Cannot open include file: 'filters/focus.h': No such file or directory

This break compiling of Avisynth.dll (VS2015 U3). Help?

[pinterf]

6> conditional_functions.cpp
6>C:\AviSynthPlus\avs_core\filters\conditional\conditional_functions.cpp(44): fatal error C1083: Cannot open include file: 'filters/focus.h': No such file or directory
What happens when you put
#include "../filters/focus.h"
instead of
#include "filters/focus.h"
at the beginning?

In Additional Include directories I have:
C:\Github\AviSynthPlusPf\avs_core\include;C:\Github\AviSynthPlusPf\avs_core;%(AdditionalIncludeDirectories)

and without ../ works for me.

[mcjordan]

Work like a charm! Thank you, pinterf!
Мy mistake - apologize for the oversight.

[cork_OS]

DirectShowSource from Avisynth+ bundle can't properly open MPEG-1 files. Tried both r2294 and last r2397. FFmpegSource2 works ok.
https://t8.pixhost.org/thumbs/1338/36950365_bloodhound-gang-the-bad-touch-avs_snapshot_00-05_-2017-01-23_21-30-32.png (https://pixhost.org/show/1338/36950365_bloodhound-gang-the-bad-touch-avs_snapshot_00-05_-2017-01-23_21-30-32.png)

[LigH]

That's possibly a general problem with DirectShowSource: It uses DirectShow filters installed in your Windows system, and when anything doesn't work as expected, you'll have to find the reason in your heap of installed DirectShow filters, but not in AviSynth. A tool like GraphStudio(Next) may help, displaying the filter graph which is most probably built. But that's just a first step towards a solution. Finding the optimum of promoted and demoted filters by changing their merits takes a while. Much longer (if successful at all, and not destroying DirectShow completely by accident) than switching to FFMS2 or L-SMASH Works.

All of the above except ... well, maybe DirectShowSource in AviSynth+ is different than the one in legacy AviSynth, and delivers a wrong decoded video format. But then I would expect more video source formats to fail in a similar way, and reliably in the same way.

[Dion]

DirectShowSource from Avisynth+ bundle can't properly open MPEG-1 files. Tried both r2294 and last r2397. FFmpegSource2 works ok.
https://t8.pixhost.org/thumbs/1338/36950365_bloodhound-gang-the-bad-touch-avs_snapshot_00-05_-2017-01-23_21-30-32.png (https://pixhost.org/show/1338/36950365_bloodhound-gang-the-bad-touch-avs_snapshot_00-05_-2017-01-23_21-30-32.png)

DirectShowSource uses whatever your OS codec is setup to use. Use DGIndex ( not free and requires Nvidia ) or FFMS2 ( Free ). They are much better.

[wonkey_monkey]

Use DGIndex ( not free and requires Nvidia )

That's DGIndexNV (actually one part of DGDecNV), as opposed to DGIndex (part of DGMPGDec, which is free).

[videoh]

DGIndex is free and can open MPEG1 files.

DGIndexNV requires nVidia, is not free, and does NOT open MPEG1 files.

[ajp_anton]

Bug in overlay?

background = blankclip(width=400,height=400,length=1,pixel_type="y8").mt_lut("255")

box = blankclip(width=100,height=100,length=1,pixel_type="y8").mt_lut("0")

mask = box.mt_lut("255")

#overlay(background, box, x=150, y=150, mask=mask) # black box value is 0
overlay(background, box, x=150, y=150) # black box value is 1

scriptclip("""
subtitle(string(yplanemax)+"\n"+string(yplanemin),lsp=0)
""")
Also when reversing the black and white, using a "maximum" mask (instead of no mask) results in a white box balue of 254 instead of 255.

[real.finder]

Bug in overlay?

background = blankclip(width=400,height=400,length=1,pixel_type="y8").mt_lut("255")

box = blankclip(width=100,height=100,length=1,pixel_type="y8").mt_lut("0")

mask = box.mt_lut("255")

#overlay(background, box, x=150, y=150, mask=mask) # black box value is 0
overlay(background, box, x=150, y=150) # black box value is 1

scriptclip("""
subtitle(string(yplanemax)+"\n"+string(yplanemin),lsp=0)
""")
Also when reversing the black and white, using a "maximum" mask (instead of no mask) results in a white box balue of 254 instead of 255.

I think this is known thing, even in masktools https://github.com/tp7/masktools/issues/12

edit: in original avisynth


#overlay(background, box, x=150, y=150, mask=mask) # black box value is 1
overlay(background, box, x=150, y=150) # black box value is 0


and there are another thing, if I overlay 2 rgb32 then I get all alpha in zero in normal avs, but in last avs+ it all 255

[pinterf]

The original blending formula is something like that, where an ideal mask is 0..1.0:
new_value = orig*(1-mask) + overlay*mask

This is equivalent to (only one multiplication, faster):
new_value = orig+(overlay-orig)*mask

As mask is coming from a clip, its value is 0..255

The approximation in overlay core:
new_value = ((orig * 256 + 128)+(overlay-orig)*mask) / 256

When orig=255, overlay=0, mask=255 (overlay is fully visible), we would expect 0 (=overlay)

Unfortunately the approximation above results in:

new_value = ((orig * 256 + 128)+(overlay-orig)*mask) / 256:
(255*256+128) + (0-255)*255) / 256 = 383/256 =
(65408 - 65025) / 256 =
383/256 = 1
which is obviously incorrect

For orig=0, overlay=255, mask=255 the result is 254 instead of 255.

[ajp_anton]

So can it be fixed? I guess it's a bit complicated if you need
0 -> 0%
128 -> 50%
255 -> 100%
Do you need two separate linear scales on both sides of 128, a non-linear scale, or a special case for 255? Or treat both 0 and 1 as 0%?

[real.finder]

So can it be fixed? I guess it's a bit complicated if you need
0 -> 0%
128 -> 50%
255 -> 100%
Do you need two separate linear scales on both sides of 128, a non-linear scale, or a special case for 255? Or treat both 0 and 1 as 0%?

in 16 bit you will get better result, and I think there is no problem at all in float point

but if you need it in 8 bit there are RMerge (https://forum.doom9.org/showthread.php?p=1537311#post1537311) with mode=256

@pinterf
but there are difference between normal avs and avs+ like I mention

[ajp_anton]

in 16 bit you will get better result, and I think there is no problem at all in float point

but if you need it in 8 bit there are RMerge (https://forum.doom9.org/showthread.php?p=1537311#post1537311) with mode=256

@pinterf
but there are difference between normal avs and avs+ like I mention
That's not a solution, it's a workaround. RMerge doesn't have arguments for x and y offsets, so that's not even a workaround. Float probably works while 16 bit still has this problem (though it's less noticeable).

[pinterf]

and there are another thing, if I overlay 2 rgb32 then I get all alpha in zero in normal avs, but in last avs+ it all 255
What is the use case when you rely on having the output alpha is filled by zeros?

On the other hand in classic avisynth the alpha channel of an RGB32 after an Overlay is undefined.
At least after having a quick look at the source, it is not filled up by any defaults. There is always an RGB->444->RGB conversion sequence, and the final conversion back from internal 444 to rgb32 fills only r, g and b channels.

Avisynth+ Overlay may use ConvertToRGB32 (which fills up alpha with 255; full transparency).
Or it just simply preserves source clip's alpha info if it works in conversionless mode (no RGB->444->RGB conversion, blend works in RGB natively)

[pinterf]

So can it be fixed? I guess it's a bit complicated if you need
0 -> 0%
128 -> 50%
255 -> 100%
Do you need two separate linear scales on both sides of 128, a non-linear scale, or a special case for 255? Or treat both 0 and 1 as 0%?
Mask value of 255 (and in general the maximum pixel value for a given bit depth) is definitely a special case that we have to handle.
It really should work as maximum transparency.
Much more special, I think than 128 / 50%

[real.finder]

What is the use case when you rely on having the output alpha is filled by zeros?

On the other hand in classic avisynth the alpha channel of an RGB32 after an Overlay is undefined.
At least after having a quick look at the source, it is not filled up by any defaults. There is always an RGB->444->RGB conversion sequence, and the final conversion back from internal 444 to rgb32 fills only r, g and b channels.

Avisynth+ Overlay may use ConvertToRGB32 (which fills up alpha with 255; full transparency).
Or it just simply preserves source clip's alpha info if it works in conversionless mode (no RGB->444->RGB conversion, blend works in RGB natively)


background = blankclip(width=400,height=400,length=1, color=$FFFFFF,pixel_type="rgb32")

box = blankclip(width=100,height=100,length=1,pixel_type="rgb32")

overlay(background, box, x=150, y=150)


you can test it with mask too, but anyway it's not important

but I say something else

here in avs+ as ajp_anton say

#overlay(background, box, x=150, y=150, mask=mask) # black box value is 0
overlay(background, box, x=150, y=150) # black box value is 1


and here what I get with normal avs

#overlay(background, box, x=150, y=150, mask=mask) # black box value is 1
overlay(background, box, x=150, y=150) # black box value is 0

edit and here another test without mask in normal avs


overlay(background.invert, box.invert, x=150, y=150) #white box value is 255, background is 0

[real.finder]

let's back to grun

SetFilterMTMode("GScriptClip", 3)
SetFilterMTMode("RequestLinear", 1) #or 3, mode 2 will make avs+ freeze and not respond (with real clip not ColorBars, ColorBars seems ok even with RequestLinear in mode 2 here)
ColorBars(width=640, height=480, pixel_type="yv12").AddGrainC(10000, 10000, seed=1)
#~ srestore() #seems ok
admfilter (http://pastebin.com/2AfwAngu)() #show error on screen
Prefetch(6)

[pinterf]

here in avs+ as ajp_anton say

#overlay(background, box, x=150, y=150, mask=mask) # black box value is 0
overlay(background, box, x=150, y=150) # black box value is 1

and here what I get with normal avs

#overlay(background, box, x=150, y=150, mask=mask) # black box value is 1
overlay(background, box, x=150, y=150) # black box value is 0

I think ajp_anton exchanged the comments of 0 and 1 values

My experience is:
background = blankclip(width=400,height=400,length=1,pixel_type="y8").mt_lut("255")
box = blankclip(width=100,height=100,length=1,pixel_type="y8").mt_lut("0")
mask = box.mt_lut("255")
#overlay(background, box, x=150, y=150, mask=mask) # black box value is 1
overlay(background, box, x=150, y=150) # black box value is 0

scriptclip("""
subtitle(string(yplanemax)+"\n"+string(yplanemin),lsp=0)
""")
return last

[ajp_anton]

Yes, sorry, looks like I got the 0 and 1 wrong there.

How is 8(or higher)bit to float handled? Shouldn't it also be
0 -> .0
128 -> .5
255 -> 1.0 ?
Using "averageluma", 128 is converted to 0.501961 (128/255).
Using "yplanemax"/"-min", 128 is converted to 32896 (is this a bug? should be a float number, not a 16bit int)

Also, y=128 in 8bit -> float is different from 8bit -> 16bit -> float.

[pinterf]

let's back to grun

SetFilterMTMode("GScriptClip", 3)
SetFilterMTMode("RequestLinear", 1) #or 3, mode 2 will make avs+ freeze and not respond (with real clip not ColorBars, ColorBars seems ok even with RequestLinear in mode 2 here)
ColorBars(width=640, height=480, pixel_type="yv12").AddGrainC(10000, 10000, seed=1)
#~ srestore() #seems ok
admfilter (http://pastebin.com/2AfwAngu)() #show error on screen
Prefetch(6)

I have not continued the investigation on grunt freeze, I have spent three day on it in December, and it is still beyond my knowledge, I am not an avisynth expert. All I have seen that it gets deadlocked on an internal mutex. Scriptclip invoke runs under a different thread id and sometimes that conflicts with the internal cache mechanism. The problem can occur when a runtime function e.g. YPlaneMin requests the child frame and that frame should retreived from the cache. So I put aside this problem a bit until I have more time/knowledge on the topic.

[jpsdr]

When i'm creating an ouput like this :

PVideoFrame dst = env->NewVideoFrame(vi);

Is there something i can do to force an alignment value ?
(If i want aligned on 32 or 64 bits for exemple)

[pinterf]

When i'm creating an ouput like this :

PVideoFrame dst = env->NewVideoFrame(vi);

Is there something i can do to force an alignment value ?
(If i want aligned on 32 or 64 bits for exemple)


PVideoFrame dst = env->NewVideoFrame(vi, 64);

[jpsdr]

Easy, lol ! Thanks.
Euh... Of course, i wanted to say 32 or 64 bytes... (YMM registers.... :rolleyes:)

[pinterf]

Avs+ default is 32

[real.finder]

Yes, sorry, looks like I got the 0 and 1 wrong there.

How is 8(or higher)bit to float handled? Shouldn't it also be
0 -> .0
128 -> .5
255 -> 1.0 ?
Using "averageluma", 128 is converted to 0.501961 (128/255).
Using "yplanemax"/"-min", 128 is converted to 32896 (is this a bug? should be a float number, not a 16bit int)

Also, y=128 in 8bit -> float is different from 8bit -> 16bit -> float.

yes, I think there are bugs in Runtime Functions, AverageChromaU and AverageChromaV in float too

[MysteryX]

For now, what plugins support the new 16-bit format? RgTools; anything else?

[Reel.Deel]

For now, what plugins support the new 16-bit format? RgTools; anything else?

RgTools, Average, NNEDI3, DCTFilter, YadifMod2, FFMS2, RawSourcePlus, VapourSource, AVSResize, FQPlus, ModPlus, and MovePlus all support 10-16 bit and 32 bit float.

Edit: also pinterf's MVTools, MDepan, and DepanEstimate support 10-16 bit.

There's also VirtualDubFilterMod, avs2pipemod, and Avs2Yuv which support some of the new HBD colorspaces.

[MysteryX]

Thanks. Is there an updated version of SMDegrain script that uses the new MVTools or not yet?

[Reel.Deel]

Thanks. Is there an updated version of SMDegrain script that uses the new MVTools or not yet?

Don't know, ask Dogway on VideoHelp. If you want the hacks-upon-hacks-mod-of-a-mod version check with real.finder :).

[MysteryX]

I have this line of code for which I want to add 16-bit support with Y16, YUV420P16, YUV444P16, RGB48 and RGB64.

sourceFormat = FormatOut != "" ? FormatOut : IsY8 ? "Y8" : IsYV12 ? "YV12" : IsYV24 ? "YV24" : IsRGB24 ? "RGB24" : IsRGB32 ? "RGB32" : ""


How can I know whether the clip is 8 bit or 16 bit from the script? Is there a way to write it in a way that will still work under AviSynth 2.6?

[real.finder]

Thanks. Is there an updated version of SMDegrain script that uses the new MVTools or not yet?

my mod work and use last mvtools, but all prefilter not yet work with > 8 bit, with tv_range=false and prefilter=-1 or prefilter=external clip it should work now

[real.finder]

Don't know, ask Dogway on VideoHelp. If you want the hacks-upon-hacks-mod-of-a-mod version check with real.finder :).

most hack done in YUY2 and that nothing to do with new color format :)

all filter that needed in SMDegrain work with yv16 now, so there is no need for YUY2 in avs 2.6 (Except for contrasharp > 0.0 cuz it use LSFmod), smart users will covert to yv16 if they have YUY2 source ;)

[MysteryX]

that uses the new MVTools or not yet?
Oups what I wanted to ask is "that uses native 16-bit in/out instead of Stack16"

[real.finder]

Oups what I wanted to ask is "that uses native 16-bit in/out instead of Stack16"

in most cases, script functions support depends on plugins supports, lsb is still there in new mvtools, you can use what you want whether old lsb hack or native (but not both), native > 8 support incompatible with lsb things, there are functions in new avs+ that convert native > 8 from/to lsb but I don't want to did this hack in SMDegrain, but anyone can use these functions like this

10 bit source
prefilter=ConvertBits(16).ConvertToStacked().SMDegrain_prefilters(prefilter=3,lsb_in=true).ConvertFromStacked(16).ConvertBits(10) #or prefilter=4
SMDegrain(tv_range=false, prefilter=prefilter) #don't use contrasharp cuz there is no native > 8 support

[MysteryX]

I'm not interested in 10-bit sources... just looking at whether I can drop LSB stuff and use native 16-bit instead. Question is: the filters used by SMDegrain that were using LSB, do they now support native 16-bit? MVTools does.

[real.finder]

I'm not interested in 10-bit sources... just looking at whether I can drop LSB stuff and use native 16-bit instead.

then

prefilter=ConvertToStacked().SMDegrain_prefilters(prefilter=3,lsb_in=true).ConvertFromStacked(16) #or prefilter=4


Question is: the filters used by SMDegrain that were using LSB, do they now support native 16-bit? MVTools does.


in this case, as I already said, you can't use prefilter or tv_range=true or contrasharp cuz there is no native 16 bit for all plugins that used in SMDegrain

[MysteryX]

in this case, as I already said, you can't use prefilter or tv_range=true or contrasharp cuz there is no native 16 bit for all plugins that used in SMDegrain
Native 16-bit will provide great performance improvement over LSB, especially for a heavy script like SMDegrain. However, it's kind of pointless until enough plugins support 16-bit to actually use it.

How about producing a list of filters supporting LSB that don't support the new native formats? Since they already work with high-bit-depth, I'm supposing it wouldn't be too hard to update those.

[pinterf]

Using "averageluma", 128 is converted to 0.501961 (128/255).
Using "yplanemax"/"-min", 128 is converted to 32896 (is this a bug? should be a float number, not a 16bit int)
.
Yes, it was fixed recently, perhaps after v2397. MinMax-like conditional functions (Min, Max, MinMaxDifference and Median) were done at the very beginning and could not decide that the return value should be the old integer or can be float (always the compatibility in mind). Then recently it was changed to float.

Conditional runtime functions have 10-16 bit/float support for YUV, PlanarRGB and 16 bit packed RGB formats.

Since RGB is also available as a planar colorspace, the plane statistics functions logically were expanded.

New functions
• AverageR, AverageG AverageB like AverageLuma
• RDifference, GDifference, BDifference like LumaDifference(clip1, clip2)
• RDifferenceFromPrevious, GDifferenceFromPrevious, BDifferenceFromPrevious
• RDifferenceToNext, GDifferenceToNext, BDifferenceToNext
• RPlaneMin, GPlaneMin BPlaneMin like YPlaneMin(clip [, float threshold = 0, int offset = 0])
• RPlaneMax, GPlaneMax BPlaneMax like YPlaneMax(clip [, float threshold = 0, int offset = 0])
• RPlaneMinMaxDifference, GPlaneMinMaxDifference BPlaneMinMaxDifference like YPlaneMinMaxDifference(clip [, float threshold = 0, int offset = 0])
• RPlaneMedian, GPlaneMedian, BPlaneMedian like YPlaneMedian(clip [, int offset = 0])

For float colorspaces the Min, Max, MinMaxDifference and Median functions populate pixel counts for the internal statistics at a 16 bit resolution internally.

[Khanattila]

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


I'm working on adding new formats to my program and I need a clarification.
Packed RGB64 is BGRA internally?

[pinterf]

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


I'm working on adding new formats to my program and I need a clarification.
Packed RGB64 is BGRA internally?
Yes, same as RGB32 and the same upside down order.

[Khanattila]

Yes, same as RGB32 and the same upside down order.

Perfect, I will not have problems.

[poodle]

The original blending formula is something like that, where an ideal mask is 0..1.0:
new_value = orig*(1-mask) + overlay*mask

This is equivalent to (only one multiplication, faster):
new_value = orig+(overlay-orig)*mask

As mask is coming from a clip, its value is 0..255

The approximation in overlay core:
new_value = ((orig * 256 + 128)+(overlay-orig)*mask) / 256

When orig=255, overlay=0, mask=255 (overlay is fully visible), we would expect 0 (=overlay)

Unfortunately the approximation above results in:

new_value = ((orig * 256 + 128)+(overlay-orig)*mask) / 256:
(255*256+128) + (0-255)*255) / 256 = 383/256 =
(65408 - 65025) / 256 =
383/256 = 1
which is obviously incorrect

For orig=0, overlay=255, mask=255 the result is 254 instead of 255.

Hi.
I encountered similar problem.
Chroma is offset signed value, then these asymmetric conversion brings to color shift.

In order to cope with this problem, I wrote the following codes.

u = _mm_sub_epi16(u, offsetUV);
sign = _mm_cmpgt_epi16(zero, u);
u = _mm_sub_epi16(_mm_xor_si128(u, sign), sign); // abs(u)

process U

u = _mm_sub_epi16(_mm_xor_si128(u, sign), sign); // if (sign) neg(u)
u = _mm_add_epi16(u, offsetUV);

It is complex than madd. :)

[pinterf]

I decided to make a release, I hope this version is much better than the previous one, it is quite a few months since v2294 was released. Sure, it has a wider feature set than the ROM routines of a ZX81, which I started programming on.

Avisynth Plus v2420 (https://github.com/pinterf/AviSynthPlus/releases/)

Report bugs, regressions, wish-list as always.

!!! There is a long readme.txt in the packet which contains detailed informations on the new and changed functions, fixes and hints. Formatting is not that nice, but at least there is some doc (sort of).

Changelog since last dev release (v2397):

- CombinePlanes:
When there is only one input clip, zero-cost BitBlt-less subframes are used, which is much faster.

e.g.: casting YUV to RGB, shuffle RGBA to ABGR, U to Y, etc..
Target planes that are not specified, preserve their content.

Examples:
CombinePlanes(clipRGBP, planes="RGB",source_planes="BGR") # swap R and B
CombinePlanes(clipYUV, planes="GBRA",source_planes="YUVA",pixel_type="RGBAP8") # cast YUVA to planar RGBA
CombinePlanes(clipYUV, planes="Y",source_planes="U",pixel_type="Y8") # extract U

- fix: SubframePlanarA (available in IScriptEnvironment2)
- faster: Difference-type conditional functions: Simd for 10-16 bits
- Fix: MinMax-type conditional functions (min, max, median): return float value for float clips
- ConvertToPlanarRGB(A):
PlanarRGB <-> PlanarRGBA is now allowed
- ConvertToPlanarRGB(A):
YUY2 source is now allowed (through automatic ConvertToRGB proxy)
- faster: RemoveAlphaPlane (subframe instead of BitBlt copy)
- Overlay: "Blend" native greyscale mode: process y plane only w/o conversion
- Overlay: automatic use444=false for "blend"/"luma"/"chroma"
for inputs: 420/422/444 and any RGB, lossless Planar RGB intermediate for PackedRGB
Overlay/mask auto-follows input clip format.
For compatibility: when greymask=true (default) and mask is RGB then mask source is the B channel
- faster: RGB48->RGB64 SSSE3 (1,6x), RGB64->RGB48 SSSE3 (1.5x speed)
- faster: RGB24,RGB48->PlanarRGB: uses RGB32/64 intermediate clip
- Histogram "levels": allow RGB24/32/48/64 input.
Display R, G and B channels instead of Y, U and V
Reminder 1: "levels" for Planar RGB was working already
Reminder 2: Histogram "levels" and "Classic" allows bits=xx parameter, xx=8..12
If "bits" is specified then Histogram is drawn with 9..12 bits precision. Get a wide monitor though :)

[ajp_anton]

Small feature request: In histogram, add some parameter to show the histogram itself in a higher bitdepth. Even a histogram of an 8-bit video can benefit from being able to display the data more accurately. Probably has to convert the whole clip into a higher bitdepth in the process, unless you add another bool parameter (default false) to only return the histogram part and make it faster. Only returning the histogram would also help with those ultra-wide histograms that you can crop and stretch more easily, without having to crop away the video part first.

[real.finder]

Native 16-bit will provide great performance improvement over LSB, especially for a heavy script like SMDegrain. However, it's kind of pointless until enough plugins support 16-bit to actually use it.

How about producing a list of filters supporting LSB that don't support the new native formats? Since they already work with high-bit-depth, I'm supposing it wouldn't be too hard to update those.

lsb in SMDegrain is not full 16 bit, it's done in MDegrain and some prefilters only, even MDegrain is not full cuz there are no lsb_in in MDegrain, dogway use some dither tools functions to do the lsb_in support in crooked ways

but anyway, since pinterf promise to work on masktools2 you can try port Dfttest, it's work in float internally too so I think it's not hard to you

[mp3dom]

Regarding histogram levels, I don't know if there are already plugins that do that, but it could be helpful to have the min and max value of each channel written down. Sometimes there are videos with some levels off that needs to be "shifted" (especially the old ones) and having the min/max value can be useful to shift with more precision.

[LigH]

One may use WriteFile (http://avisynth.nl/index.php/WriteFile) to log a CSV with strings concatenated from Color plane median, min, max, range (http://avisynth.nl/index.php/Internal_functions#Color_plane_median.2C_min.2C_max.2C_range) function results.

[mp3dom]

Nice, thanks!

[dandyclubs]

http://publishwith.me/ep/pad/view/ro.rDkwcdWn4k9/latest

#rgtools
SetFilterMTMode ( "RemoveGrain", MT_NICE_FILTER)
SetFilterMTMode ( «réparation», MT_N ICE_FILTER)
SetFilterMTMode ( «verticalcleaner», MT_NICE_FILTER)
SetFilterMTMode ( "clense", MT_NICE_FILTER)
#medianblur
SetFilterMTMode ( «medianblur», MT_MULTI_INSTANCE)
SetFilterMTMode ( «medianblurtemporal», MT_MULTI_INSTANCE)
#masktools
SetFilterMTMode ( «mt_invert», MT_MULTI_INSTANCE)
SetFilterMTMode ( «mt_binarize», MT_MULTI_INSTANCE)
SetFilterMTMode ( «mt_inflate», MT_MULTI_INSTANCE)
SetFilterMTMode ( «mt_deflate», MT_MULTI_INSTANCE)
SetFilterMTMode ( «mt_inpand», MT_MULTI_INSTANCE)
SetFilterMTMode ( «mt_expand», MT_MULTI_INSTANCE)
SetFilterMTMode ( «mt_lut», MT_MULTI_INSTANCE)
SetFilterMTMode ( «mt_lutxy», MT_MULTI_INSTANCE)
SetFilterMTMode ( «mt_lutxyz», MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_luts", MT_MULTI_INSTANCE)
SetFilterMTMode ( «mt_lutf», MT_MULTI_INSTANCE)
SetFilterMTMode ( «mt_lutsx», MT_MULTI_INSTANCE)
SetFilterMTMode ( «mt_lutspa», MT_MULTI_INSTANCE)
SetFilterMTMode ( «mt_merge», MT_MULTI_INSTANCE)
SetFilterMTMode ( «mt_logic», MT_MULTI_INSTANCE)
SetFilterMTMode ( «mt_convolution», MT_MULTI_INSTANCE)
SetFilterMTMode ( «mt_mappedblur», MT_MULTI_INSTANCE)
SetFilterMTMode ( «mt_makediff», MT_MULTI_INSTANCE)
SetFilterMTMode ( «mt_average», MT_MULTI_INSTANCE)
SetFilterMTMode ( «mt_adddiff», MT_MULTI_INSTANCE)
SetFilterMTMode ( «mt_clamp», MT_MULTI_INSTANCE)
SetFilterMTMode ( «mt_motion», MT_MULTI_INSTANCE)
SetFilterMTMode ( «mt_edge», MT_MULTI_INSTANCE)
SetFilterMTMode ( «mt_hysteresis», MT_MULTI_INSTANCE)
SetFilterMTMode ( "sangnom2", MT_SERIALIZED) #can exécuté avec 2 mais vous devez spécifier threads = 1 alors, sinon trop de threads se crée sans aucun bénéfice
SetFilterMTMode ( «moyenne», MT_NICE_FILTER)
SetFilterMTMode ( «TMaskCleaner», MT_MULTI_INSTANCE)
SetFilterMTMode ( "mater", MT_NICE_FILTER)
SetFilterMTMode ( "Deblock", MT_NICE_FILTER)
SetFilterMTMode ( «msharpen», MT_MULTI_INSTANCE)
SetFilterMTMode ( «TColorMask», MT_NICE_FILTER)
SetFilterMTMode ( «Vinverse», MT_MULTI_INSTANCE)
SetFilterMTMode ( «Vinverse2», MT_MULTI_INSTANCE)



wrong..

replace

#rgtools
SetFilterMTMode ( "RemoveGrain", MT_NICE_FILTER)
SetFilterMTMode ( "repair", MT_NICE_FILTER)
SetFilterMTMode ( "verticalcleaner", MT_NICE_FILTER)
SetFilterMTMode ( "clense", MT_NICE_FILTER)
#medianblur
SetFilterMTMode ( "medianblur", MT_MULTI_INSTANCE)
SetFilterMTMode ( "medianblurtemporal", MT_MULTI_INSTANCE)
#masktools
SetFilterMTMode ( "mt_invert", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_binarize", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_inflate", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_deflate", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_inpand", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_expand", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_lut", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_lutxy", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_lutxyz", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_luts", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_lutf", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_lutsx", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_lutspa", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_merge", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_logic", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_convolution", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_mappedblur", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_makediff", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_average", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_adddiff", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_clamp", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_motion", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_edge", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mt_hysteresis", MT_MULTI_INSTANCE)
SetFilterMTMode ( "sangnom2", MT_SERIALIZED) #can exécuté avec 2 mais vous devez spécifier threads = 1 alors, sinon trop de threads se crée sans aucun bénéfice
SetFilterMTMode ( "moyenne", MT_NICE_FILTER)
SetFilterMTMode ( "TMaskCleaner", MT_MULTI_INSTANCE)
SetFilterMTMode ( "mater", MT_NICE_FILTER)
SetFilterMTMode ( "Deblock", MT_NICE_FILTER)
SetFilterMTMode ( "msharpen", MT_MULTI_INSTANCE)
SetFilterMTMode ( "TColorMask", MT_NICE_FILTER)
SetFilterMTMode ( "Vinverse", MT_MULTI_INSTANCE)
SetFilterMTMode ( "Vinverse2", MT_MULTI_INSTANCE)


Listes #Another

La mise à jour de # tp7: sangnom2 enlevés et des lignes vinverse car ils ne peuvent pas fonctionner avec le mode 1 correctement (versions mises à jour peuvent mais ceux qui vont se faire enregistrer de toute façon), a également retiré les filtres de base

replace

#Listes #Another

#La mise à jour de # tp7: sangnom2 enlevés et des lignes vinverse car ils ne peuvent pas fonctionner avec le mode 1 correctement (versions mises à jour peuvent mais ceux qui vont se faire enregistrer de toute façon), a également retiré les filtres de base

[Groucho2004]

Some fucking moron messing around in that list with google translate again?

[LigH]

I don't believe angular quotes (&laquo; / &raquo;) are supported as string delimiters; better disable typographic autotext features or just never edit such documents with external advanced word processors.

Oh, does Google Translate also translate quote styles?

[Groucho2004]

Oh, does Google Translate also translate quote styles?https://s6.postimg.org/gxfxb98jl/Image1.png

This happened before, Tp7 (when he was still active with Avisynth+) got very upset at the time and used very colourful language to discourage the idiot(s) from using google translate on that page.

[real.finder]

this link ok http://publishwith.me/ep/pad/view/ro.rDkwcdWn4k9/rev.495

Public Pad Version 496 Saved Jan 28, 2017 is full with shit and French words

[Groucho2004]

Public Pad Version 496 Saved Jan 28, 2017 is full with shit and French words
Apparently these (purple) changes were done by someone with the moniker "A.SONY".

[LigH]

So let's hope that it is easy to revoke a change.

[real.finder]

Apparently these (purple) changes were done by someone with the moniker "A.SONY".

I am A.SONY :D

I don't even know something in French, my edit is http://publishwith.me/ep/pad/view/ro.rDkwcdWn4k9/rev.495 and did it in 2016

[Groucho2004]

I am A.SONY :D

I don't even know something in French, my edit is http://publishwith.me/ep/pad/view/ro.rDkwcdWn4k9/rev.495 and did it in 2016
Ok. Go to rev 496 and you can see that the stupid changes have a slightly different shade of purple than the ones made by you. Sorry, my mistake, I just saw "purple". :D

[real.finder]

Ok. Go to rev 496 and you can see that the stupid changes have a slightly different shade of purple than the ones made by you. Sorry, my mistake, I just saw "purple". :D

even me, I start think there someone used my name or I have Alzheimer's :p until I see my laptop monitor from another angle

[Reel.Deel]

Reverted the changes :)

[MysteryX]

I was using Dither_resize16nr to convert from YV12 to YV24 with either Spline36 or Bicubic.

ConvertToYUV444 and ConvertToYUV420, however, don't allow specifying the algorithm for upscaling or downscaling the chroma. Please consider adding this in the future :)

As for the 'no ringing' variant, it can be nice, but perhaps it won't change much at all in the case of chroma resampling.

[Reel.Deel]

I was using Dither_resize16nr to convert from YV12 to YV24 with either Spline36 or Bicubic.

ConvertToYUV444 and ConvertToYUV420, however, don't allow specifying the algorithm for upscaling or downscaling the chroma. Please consider adding this in the future :)

As for the 'no ringing' variant, it can be nice, but perhaps it won't change much at all in the case of chroma resampling.

Umm, both functions have the chromaresample parameter: https://github.com/pinterf/AviSynthPlus/blob/5e45d740b8d78f2c19d220c0247238bba26c1499/avs_core/convert/convert.cpp#L73

[MysteryX]

oh, sorry.

Question. What happens with ConvertToDoubleWidth on 32-bit clips?

[DJATOM]

Question. What happens with ConvertToDoubleWidth on 32-bit clips?

ConvertBits(32)
ConvertToDoubleWidth()
This will complain about "clip must be 16 bit" or something.

ConvertBits(32)
ConvertBits(16,false)
ConvertToDoubleWidth()
This will expose 32-bit clip as 8.

[pinterf]

ConvertBits(32)
ConvertToDoubleWidth()
This will complain about "clip must be 16 bit" or something.

ConvertBits(32)
ConvertBits(16,false)
ConvertToDoubleWidth()
This will expose 32-bit clip as 8.
That false is not necessary, it has meaning only when converting 10-16 bit video to 10-16 bit video, and we want to change only the video bitdepth (clip property) but not the data itself.
To tell the truth, a well behaving avisynth+ would warn you that that parameter is irrelevant :)

[pinterf]

Hi.
I encountered similar problem.
Chroma is offset signed value, then these asymmetric conversion brings to color shift.

Thanks, poodle, finally I did not want to touch that part, if it was good for a decade, it will stay as-is for another couple of weeks or months.

[DJATOM]

That false is not necessary, it has meaning only when converting 10-16 bit video to 10-16 bit video, and we want to change only the video bitdepth (clip property) but not the data itself.
To tell the truth, a well behaving avisynth+ would warn you that that parameter is irrelevant :)

So... ok. It seems I've got the wrong idea about this parameter. I thought if it's set to true, clip will be actually converted or just changed bit depth information (but not the actual data) if false.

[MysteryX]

oh... but on 32-bit, I could call ConvertToDoubleWidth twice; if it would convert 32-bit to 16-bit. Is there a simple script that would achieve that?


ConvertBits(32)
ConvertBits(16)
ConvertToDoubleWidth()

This would first discard 16-bit of the 32-bit, which is not what I'm looking for.

[DJATOM]

oh... but on 32-bit, I could call ConvertToDoubleWidth twice; if it would convert 32-bit to 16-bit. Is there a simple script that would achieve that?


ConvertBits(32)
ConvertBits(16)
ConvertToDoubleWidth()

This would first discard 16-bit of the 32-bit, which is not what I'm looking for.
Lol, I just realized that I misread what pinterf said, so I was right about truerange. Set it 'false' and ConvertToDoubleWidth will work for 32 bit input.

[pinterf]

32 bit is float. 16 bit is integer. ConvertToDoublewidth is a hack to fake both the format and frame dimension.

[MysteryX]

How about integrating these conversion functions into the core DLL? In that way, plugin developers could write 16-bit code using the native format, and still support Stack16 by calling these standard conversion functions. Otherwise, I might as well copy and integrate that code into my DLL to avoid dependencies.

Basically, I keep the standard v2.6 conversion code, and on Avisynth+, I'm branching into another code that does it using the new functions -- and supports extra formats. The Stack16 conversion functions would be useful for any developer doing that. I also want to keep using DoubleWidth to preserve compatibility with v2.6

[DJATOM]

32 bit is float. 16 bit is integer. ConvertToDoublewidth is a hack to fake both the format and frame dimension.

Indeed. But if we need to process our clip with filter which can process exposed 32-bit data, but does not support avs+ colorspaces, that will help.

[MysteryX]

I would need a "ConvertToQuadripleWidth" if I want to allow someone to use AviSynthShader while allowing overflow values; as all other formats are INT. Again, I keep the double-width hack to maintain compatibility with AVS 2.6, and since I'm doing a data transfer to the GPU, it doesn't matter how the metadata is set.

[real.finder]

How about integrating these conversion functions into the core DLL? In that way, plugin developers could write 16-bit code using the native format, and still support Stack16 by calling these standard conversion functions. Otherwise, I might as well copy and integrate that code into my DLL to avoid dependencies.

Basically, I keep the standard v2.6 conversion code, and on Avisynth+, I'm branching into another code that does it using the new functions -- and supports extra formats. The Stack16 conversion functions would be useful for any developer doing that. I also want to keep using DoubleWidth to preserve compatibility with v2.6

no more hack please, and you can keep the lsb (Stack16) supports just like what pinterf did in mvtools

[real.finder]

Reverted the changes :)

:thanks:


#rgtools # starting from v0.94, the plugin self registers the MT mode
SetFilterMTMode("removegrain", MT_NICE_FILTER)
SetFilterMTMode("repair", MT_NICE_FILTER)
SetFilterMTMode("verticalcleaner", MT_NICE_FILTER)
SetFilterMTMode("clense", MT_NICE_FILTER)


should


#rgtools # starting from v0.94, the plugin self registers the MT mode
SetFilterMTMode("removegrain", MT_NICE_FILTER)
SetFilterMTMode("repair", MT_NICE_FILTER)
SetFilterMTMode("verticalcleaner", MT_NICE_FILTER)
#SetFilterMTMode("clense", MT_NICE_FILTER)


it's better, cuz when reduceflicker is true, MULTI_INSTANCE MT mode is reported in RGtools

[MysteryX]

Is there a way to pass a format as a string and get the properties of that format? For example, a parameter "FormatOut" might be set to "YUVAP16", and in my code, I want to know a few things. Does that format have an alpha plane? What is BitsPerComponent?

Of course I can get it done with a bunch of IF, but the code then gets very clumsy especially with all the new formats.

[pinterf]

Is there a way to pass a format as a string and get the properties of that format? For example, a parameter "FormatOut" might be set to "YUVAP16", and in my code, I want to know a few things. Does that format have an alpha plane? What is BitsPerComponent?

Of course I can get it done with a bunch of IF, but the code then gets very clumsy especially with all the new formats.
Declare a temporary VideoInfo variable, fill its pixel_type, now you can request all its properties.

[edcrfv94]

I update r2420 from r1858, have a problem with MP_Pipeline.
Very high CPU usage and very slow.

r2420 1.6 fps 40-50% CPU usage
r1858 26 fps 16-20% CPU usage

MP_Pipeline("""

SetMemoryMax(500)

input = "K:\test.m2ts"
LWLibavVideoSource(input, threads=1)

src = last

### export clip:src
### prefetch: 92,88
### ###

SetMemoryMax(2000)

src
kf_awarpFCB_test(depth=8, thresh=96, blur=3, lsb_in=true, lsb_out=true, YV12_out=false, cplace="MPEG2")
dither_out()

function kf_awarpFCB_test(clip src, int "depth", int "thresh", int "blur", bool "lsb_in", bool "lsb_out", bool "isYV24", bool "YV12_out", string "cplace")
{

depth = Default(depth, 6)
thresh = Default(thresh, 96)
blur = Default(blur, 3)

lsb_in = Default(lsb_in, false)
lsb_out = Default(lsb_out, true)
isYV24 = Default(isYV24, false)
YV12_out = Default(YV12_out, false)

w = width(src)
h = (lsb_in == false) ? height(src) : height(src)/2

src16 = (lsb_in == false) ? src.Dither_convert_8_to_16() : src

Y416 = src16.Dither_resize16(w, h, csp="YV24", kernel="bicubic", a1=0.6, a2=0.4, cplace=cplace)
YV24 = (isYV24 == false) ? Y416.DitherPost(mode=7) : (lsb_in == false) ? src : src.DitherPost(mode=7)
emask = YV24.ConvertToY8().aSobel(thresh, 1).aBlur(blur, 1, 1)
uv_fcb = YToUV(YV24.UToY8().awarp(emask, depth, 1), YV24.VToY8().awarp(emask, depth, 1), YV24)
Dither_limit_dif16(Y416, uv_fcb.Dither_convert_8_to_16(), thr=1.0, elast=2, y=2, u=3, v=3)

YV12_out ? last.Dither_resize16(w, h, csp="YV12", kernel="bicubic", a1=0, a2=0.5) : last

lsb_out ? last : last.DitherPost(mode=7)

return last
}

""")

[pinterf]

I update r2420 from r1858, have a problem with MP_Pipeline.
Very high CPU usage and very slow.

r2420 1.6 fps 40-50% CPU usage
r1858 26 fps 16-20% CPU usage
I think I found the reason. r2043 is ok, r2068 is slow.

Beginning from r2068 Eval-like and runtime functions are detected internally in order to apply an appropriate cache and MT behaviour for them.

But MP_Pipeline is an external Eval-like filter and the core is not able to detect it. In my test, when I have set a hardcoded line to apply this rule on MP_Pipeline, the speed returned to the original. I don't know yet how to detect such external filters automatically, from the core point of view it is a filter that takes a string parameter and returns a clip. Like a source filter.
Perhaps we have to introduce a registration command for this case, e.g. RegisterScriptFunction(string filter_name) (?)

[real.finder]

since there are no more than 8 bit in 411, then should convertbits show error Message, but it's not

if I use convertbits(16) in yv411 source it will work but with unsupported colour format

[pinterf]

since there are no more than 8 bit in 411, then should convertbits show error Message, but it's not

if I use convertbits(16) in yv411 source it will work but with unsupported colour format
True. I expect to have increasing number of reports for 10+ bit stuff after reaching a critical mass in the number of non-8bit users and supporting scripts.

Currently under progress:
Integrate GScriptClip and co.
Better handling MP_Pipeline-like filters (speedwise)
Playing with masktools.

[tormento]

True. I expect to have increasing number of reports for 10+ bit stuff after reaching a critical mass in the number of non-8bit users and supporting scripts.
When every plugin we need will be 16 bit and we will work internally at 16 bit to output in 8 bit, I think you will be flooded :D

[MysteryX]

Pinterf, you're already flooded porting every plugin to 16-bit :) Now get to work

[Reel.Deel]

Pinterf, you're already flooded porting every plugin to 16-bit :) Now get to work

Since you're a programmer also, help him out :)

[MysteryX]

Since you're a programmer also, help him out :)
I got a lot of priorities to focus on already (but I guess that also applies to most of us). For now I must get 16-bit to work with AviSynthShader (somehow I'm having a hard time to get that simple task done), and release the next version of Natural Grounding Player as the YouTube downloader doesn't work anymore with the currently released version. And even more importantly... working on my business instead of putting too much time on Open Source projects, and publishing some more books.

There's the Floyd-Steinberg Dithering I could work on, but then, it would only be a CPU version. Someone else would have to write it in assembly. I can write a C# 432hz Music Player and playlist manager in a few hours, but C++ is much harder for me.

So yeah... first must empty the pipeline of work to do.

[MysteryX]

Declare a temporary VideoInfo variable, fill its pixel_type, now you can request all its properties.
Except that pixel_type is an int, not a string. In C# I could easily convert a string to its enumeration value but that won't work in C++. It seems the only way is to create a map with all the possible values and get the int matching the string from the map. A standard function to accomplish that would be nice. Is it possible to include such a function in the header file so that it also works with older versions of Avisynth? Actually I'll need to call such a function from the script so I'll need to create a custom filter for it anyway, unless I'm missing something.

So there are 2 tasks:
1. Get current format as a string so the script can use it.
2. Get VideoInfo from string to know the properties of specified format.

Formats were quite easy to handle in Avisynth 2.6 because there were only a few pixel formats. With the new version, however, the amount of formats increased exponentially.

The best might be to create a map and use it for both tasks.

[MysteryX]

I believe code like this should do the job to convert back and forth between INT and STRING format types. It might be useful to have something similar in the header.


#pragma once
#include <map>
#include <string>
#include "avisynth.h"

class PixelFormatParser {
typedef std::map<std::string, int> my_map;
my_map enumMap;
public:
PixelFormatParser();

int GetPixelFormatAsInt(std::string format) {
my_map::const_iterator iValue = enumMap.find(format);
if (iValue == enumMap.end())
return 0;
return iValue->second;
}

std::string GetPixelFormatAsString(int pixel_type) {
int key = 0;
std::string Result = std::string("");
for (auto &i : enumMap) {
if (i.second == pixel_type) {
Result = i.first;
// If format ends with P8, continue searching to return the other name variant.
if (i.first.length() < 3 || i.first.substr(i.first.length() - 2, 2) != std::string("P8"))
break;
}
}
return Result;
}

VideoInfo GetVideoInfo(int pixel_type) {
VideoInfo Result;
Result.pixel_type = pixel_type;
return Result;
}

VideoInfo GetVideoInfo(std::string format) {
VideoInfo Result;
Result.pixel_type = GetPixelFormatAsInt(format);
return Result;
}
};

PixelFormatParser::PixelFormatParser() {
enumMap["RGB24"] = VideoInfo::CS_BGR24;
enumMap["RGB32"] = VideoInfo::CS_BGR32;
enumMap["YUY2"] = VideoInfo::CS_YUY2;
enumMap["RAW32"] = VideoInfo::CS_RAW32;
enumMap["YV24"] = VideoInfo::CS_YV24;
enumMap["YV16"] = VideoInfo::CS_YV16;
enumMap["YV12"] = VideoInfo::CS_YV12;
enumMap["I420"] = VideoInfo::CS_I420;
enumMap["IYUV"] = VideoInfo::CS_IYUV;
enumMap["YUV9"] = VideoInfo::CS_YUV9;
enumMap["YV411"] = VideoInfo::CS_YV411;
enumMap["Y8"] = VideoInfo::CS_Y8;
enumMap["YUV444P8"] = VideoInfo::CS_YV24;
enumMap["YUV422P8"] = VideoInfo::CS_YV16;
enumMap["YUV420P8"] = VideoInfo::CS_YV12;
enumMap["YUV444P10"] = VideoInfo::CS_YUV444P10;
enumMap["YUV422P10"] = VideoInfo::CS_YUV422P10;
enumMap["YUV420P10"] = VideoInfo::CS_YUV420P10;
enumMap["Y10"] = VideoInfo::CS_Y10;
enumMap["YUV444P12"] = VideoInfo::CS_YUV444P12;
enumMap["YUV422P12"] = VideoInfo::CS_YUV422P12;
enumMap["YUV420P12"] = VideoInfo::CS_YUV420P12;
enumMap["Y12"] = VideoInfo::CS_Y12;
enumMap["YUV444P14"] = VideoInfo::CS_YUV444P14;
enumMap["YUV422P14"] = VideoInfo::CS_YUV422P14;
enumMap["YUV420P14"] = VideoInfo::CS_YUV420P14;
enumMap["Y14"] = VideoInfo::CS_Y14;
enumMap["YUV444P16"] = VideoInfo::CS_YUV444P16;
enumMap["YUV422P16"] = VideoInfo::CS_YUV422P16;
enumMap["YUV420P16"] = VideoInfo::CS_YUV420P16;
enumMap["Y16"] = VideoInfo::CS_Y16;
enumMap["YUV444PS"] = VideoInfo::CS_YUV444PS;
enumMap["YUV422PS"] = VideoInfo::CS_YUV422PS;
enumMap["YUV420PS"] = VideoInfo::CS_YUV420PS;
enumMap["Y32"] = VideoInfo::CS_Y32;
enumMap["RGB48"] = VideoInfo::CS_BGR48;
enumMap["RGB64"] = VideoInfo::CS_BGR64;
enumMap["RGBP"] = VideoInfo::CS_RGBP;
enumMap["RGBP8"] = VideoInfo::CS_RGBP;
enumMap["RGBP10"] = VideoInfo::CS_RGBP10;
enumMap["RGBP12"] = VideoInfo::CS_RGBP12;
enumMap["RGBP14"] = VideoInfo::CS_RGBP14;
enumMap["RGBP16"] = VideoInfo::CS_RGBP16;
enumMap["RGBPS"] = VideoInfo::CS_RGBPS;
enumMap["RGBAP"] = VideoInfo::CS_RGBAP;
enumMap["RGBAP8"] = VideoInfo::CS_RGBAP;
enumMap["RGBAP10"] = VideoInfo::CS_RGBAP10;
enumMap["RGBAP12"] = VideoInfo::CS_RGBAP12;
enumMap["RGBAP14"] = VideoInfo::CS_RGBAP14;
enumMap["RGBAP16"] = VideoInfo::CS_RGBAP16;
enumMap["RGBAPS"] = VideoInfo::CS_RGBAPS;
enumMap["YUVA444"] = VideoInfo::CS_YUVA444;
enumMap["YUVA422"] = VideoInfo::CS_YUVA422;
enumMap["YUVA420"] = VideoInfo::CS_YUVA420;
enumMap["YUVA444P8"] = VideoInfo::CS_YUVA444;
enumMap["YUVA422P8"] = VideoInfo::CS_YUVA422;
enumMap["YUVA420P8"] = VideoInfo::CS_YUVA420;
enumMap["YUVA444P10"] = VideoInfo::CS_YUVA444P10;
enumMap["YUVA422P10"] = VideoInfo::CS_YUVA422P10;
enumMap["YUVA420P10"] = VideoInfo::CS_YUVA420P10;
enumMap["YUVA444P12"] = VideoInfo::CS_YUVA444P12;
enumMap["YUVA422P12"] = VideoInfo::CS_YUVA422P12;
enumMap["YUVA420P12"] = VideoInfo::CS_YUVA420P12;
enumMap["YUVA444P14"] = VideoInfo::CS_YUVA444P14;
enumMap["YUVA422P14"] = VideoInfo::CS_YUVA422P14;
enumMap["YUVA420P14"] = VideoInfo::CS_YUVA420P14;
enumMap["YUVA444P16"] = VideoInfo::CS_YUVA444P16;
enumMap["YUVA422P16"] = VideoInfo::CS_YUVA422P16;
enumMap["YUVA420P16"] = VideoInfo::CS_YUVA420P16;
enumMap["YUVA444PS"] = VideoInfo::CS_YUVA444PS;
enumMap["YUVA422PS"] = VideoInfo::CS_YUVA422PS;
enumMap["YUVA420PS"] = VideoInfo::CS_YUVA420PS;
}


Then I could write a GetFormat function like this.


AVSValue __cdecl Create_GetFormat(AVSValue args, void* user_data, IScriptEnvironment* env) {
VideoInfo vi = args[0].AsClip()->GetVideoInfo();
static PixelFormatParser pfp;
std::string Result = pfp.GetPixelFormatAsString(vi.pixel_type);
return AVSValue(env->SaveString(Result.c_str(), Result.length() + 1));
}

[JoeyMonco]

Why do you need a whole class simply to write a utility function? Just write a simple function that just uses a switch statement to return the value based on the integer.