Avisynth+

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