Avisynth+

[qyot27]

I really hope I don't start a quarrel here, and 1st I must admit I'm new to using Git/Github and I'm afraid the discussion tends to get off topic.
I realized that pinterf is doing many, many valuable things these days, but I feel documentation/installer things become left behind.
So i forked pinterf's Github AviSynthPlus fork and stupid as I am I thought I might work myself into the docs and update here and there.
Now I have the new question on my mind if someone who forks a Guthub project can commit his changes back to the original project without being authorized by the original project's owner? Should I regard AviSynth/AviSynthPlus or pinterf/AviSynthPlus as the most up to date and legitimate current version of AviSynth+?
I could not spot any commits after about Aug 17,2016 to avisynth/AviSynthPlus, but the pinterf repository is much more recent.
If you fork a project on Github, it spawns a copy under your user account. You clone from your user account's copy repository with commit privileges so that you have it locally. You commit the changes locally in a separate topic branch (preferably; it keeps things cleaner), push your commits back to your Github repository, and then issue a pull request to the main repository to allow them to review the commits and propose changes, or if they have no objections or critiques, they can just go ahead and merge the changes into the upstream repo.

AviSynth/AviSynthPlus is the official upstream repository, but it probably shouldn't matter that you told Github to fork it from pinterf's. You can also open pull requests against other users' repositories, if need be.

[pinterf]

The arrays syntax support for script arrays was temporarily removed because I was nit able to not solve compatibility with 2.5 style plugin interfaces. This is the "baked code" problem, in plugins/apps using 2.5 headers the AVSValue constructor and destructor is hardcoded in the header. In avs interface 6 the allocation/deallocation/copy routines are using interface calles and are running finally in the current avisynth core.
I will put it back, at least I intend to provide a build that has arrays but that build won't support 2.5 plugins. I have worked weeks on arrays, so they will come back mne nice day.

[tormento]

I will put it back, at least I intend to provide a build that has arrays but that build won't support 2.5 plugins. I have worked weeks on arrays, so they will come back mne nice day.
I think that 2.5 signed DNR (http://en.wikipedia.org/wiki/Do_not_resuscitate). Please do not sort therapeutic persecution. It's time 2.5 dies of honorable death.

[pinterf]

And another incompatible application if AvsPmod, I cannot tell users to stop using this application, because there is no replacement for it.

[tormento]

And another incompatible application if AvsPmod, I cannot tell users to stop using this application, because there is no replacement for it.

Latest version was released on 16th February 2015, two years ago.



It's the same problem as with Windows XP or Flash.



Until nobody stopped supporting them (hint: Google), they wouldn't die.

I mean... nobody tells people to stop using Avspmod.. they can stay there with older AVS+ version or AviSynth 2.5.

But why should we?

[martin53]

And another incompatible application is AvsPmod, I cannot tell users to stop using this application, because there is no replacement for it.
Latest version was released on 16th February 2015, two years ago.
Umm, more precisely Aug 9, 2015 (https://forum.doom9.org/showpost.php?p=1733655&postcount=1148), but one one hand it's obvious it needs someone who cares or a successor app, and on the other hand: can you name any alternative? Maybe I don't get what you are suggesting with 'Google'.

[pinterf]

Just to inform you what is happening behind the scenes:

On git commits:

Fixed Merge for float formats
ColorBars allows any 4:2:0, 4:4:4 formats, plus RGB64 and all planar RGB.
ColorBarsHD accepts any 4:4:4 formats
ConvertBits dither=1: Floyd-Steinberg (was: dither=0 for ordered dither)
Use of parameter "dither_bits": ConvertBits(x, dither=n [, dither_bits=y])
- ordered dither: dither_bits 2, 4, 6, ... but maximum difference between target bitdepth and dither_bits is 8
- Floyd-Steinberg: dither_bits 1, 2, 4, 6, ... up to target bitdepth - 2
(Avisynth+ low bitdepth, Windows 3.1 16 bit feeling :) I was astonished that dither_bits=6 still resulted in a quite usable image)
dithering is allowed from 10-16 -> 10-16 bits (was: only 8 bit targets)
dithering is allowed while keeping original bit-depth. clip10 = clip10.ConvertBits(10, dither=0, dither_bits=8)
Ordered dither to 8bit: SSE2 (10x speed)
(you still cannot dither from 8 or 32 bit source)
ConditionalFilter syntax extension like Gavino's GConditional: no "=" "true" needed


Experimenting/planned (not on git):
- gain back the speed of MP_Pipeline like filters - I did it but I have to find a nicer way.
- perhaps GScriptClip-like parameter passing

[real.finder]

what about add IsVideoFloat() (as there are already IsAudioFloat())? :)

[pinterf]

Or IsDuckFloat?

[real.finder]

Or IsDuckFloat?

LOL, or even IsGooseFloat :P

anyway, I waiting for these changes (the other one here (https://forum.doom9.org/showpost.php?p=1799108&postcount=49)) to seriously start port some scripts (the one I did in MaskTools2 - pfmod thread was for test only)

[mp3dom]

Uhmm, there's surely an error on my side that I can't resolve, but with r2420, the output from UtoY is the same image as VtoY, while UtoY8 and VtoY8 outputs proper different result.
Am I doing something wrong?

[blaze077]

Those functions work well on my side in both the 32 and 64 bit versions of Avisynth+ r2420. UToY() and VToY() output YV12 video if that has anything to do with it. Do you have anything else in your script?

EDIT: UToY() and VToY() output the source colorspace and not YV12 - I was mistaken.

[mp3dom]

I mean, UtoY=VtoY, while UtoY8 != VtoY8 (as expected, since different chroma channels).
So if I separate each channel and then recombine it back, I get wrong colors


y=ConvertToYV12()
u=UtoY().ConvertToYV12()
v=VtoY().ConvertToYV12()
YtoUV(u,v,y)

[pinterf]

I mean, UtoY=VtoY, while UtoY8 != VtoY8 (as expected, since different chroma channels).
So if I separate each channel and then recombine it back, I get wrong colors


y=ConvertToYV12()
u=UtoY().ConvertToYV12()
v=VtoY().ConvertToYV12()
YtoUV(u,v,y)

I was not able to reproduce it. Please test is with Colorbars, and if it works but with your real video still fails, then please upload a short (couple of frames is enough) sample somewhere, thanks.

[tormento]

Umm, more precisely Aug 9, 2015 (https://forum.doom9.org/showpost.php?p=1733655&postcount=1148), but one one hand it's obvious it needs someone who cares or a successor app, and on the other hand: can you name any alternative? Maybe I don't get what you are suggesting with 'Google'.
Chrome stopped supporting Flash and Google told Windows XP browser limitation will make it stop supporting on Gmail and other suite apps.

More: there is hardware out there that has no driver support for platform more recent than XP.

Things have to change, it's law of thermodynamics.

Even more: nobody asks people to stop using AVSPmod. They simply won't have any upgrade to environment.

Just my 2 cents.

[mp3dom]

I was not able to reproduce it. Please test is with Colorbars, and if it works but with your real video still fails, then please upload a short (couple of frames is enough) sample somewhere, thanks.

Yeah, it fails on ColorBars too, on both x86 and x64.

colorbars(width=720,height=480,pixel_type="yuy2")
y=last
u=UtoY()
v=VtoY()

YtoUV(u,v,y)


U channel is a "copy" of the V channel, so I get the same result of:
YtoUV(v,v,y)

However, it seems to fail on YUY2 only, because on YV12, YV16 and YV24 seems to work fine.

[pinterf]

Ah, thanks, that helps. I'll check it.
EDIT:
Thanks for the report. Fixed on git.
YUY2 UToY did not work since August, 2016 (r2150)

[tcope]

For those interested...

A new stable version is avail. Along
with supporting web page.

I highly recommend giving this a spin,
and very much look forward to feedback.

Original post with link
...HERE... (https://forum.doom9.org/showthread.php?p=1798200#post1798200)

Cheers :)

[videoFred]

Hello everybody,

I'm using Avisynth+ with great succes: for example a pretty complex (removedirt(), Mdegrain2() etc...) script that normally runs at 4fps runs now easily at 15fps in MTmode, using all my processor power.

But everytime I start up a script in AvsPmod v2.5.1 (it can be any script, even the most simple AviSource() ), I get this error message:
Error parsing plugin string at position 0:

And when closing AvsPmod, I get this error message:
Traceback (most recent call last):
File "avsp.pyo", line 5404, in OnActivate
File "wx\_core.pyo", line 14619, in __getattr__
wx._core.PyDeadObjectError: The C++ part of the AvsStyledTextCtrl object has been deleted, attribute access no longer allowed.


I'm using Groucho's installer so my plugins are in a specified folder.

Those error messages are not hurting me:p but I wonder why I get them?

PS: I have tried the modified AvsPmod v2.5.1 r452 no more error messages , but this version does not like this:
[Multi Tasking=0]
Prefetch(4)
[/Multi Tasking]

It throws this error message:
Only a single prefetcher is allowed per script

But the only prefetch in the script is this one, at the end as it should be and it works fine with AvsPmod v2.5.1.
I realy need the option to switch MT on/off so I can not use AvsPmod r452.

many greetings,
Fred.

[pinterf]

New release with important bug fixes and interesting enhancements.

Avisynth+ r2440-MT (https://github.com/pinterf/AviSynthPlus/releases/tag/r2440-MT)

20170310 r2440
- Fix Merge for float formats
- Fix error text formatting under wine (_vsnprintf_l issue)
- Fix Regression: YUY2 UToY copied V instead of U, since August, 2016 (v2150)
- faster Merge: float to sse2 (both weighted and average)
- faster ordered dither to 8bit: SSE2 (10x speed)
- ColorBars allows any 4:2:0, 4:4:4 formats, RGB64 and all planar RGB formats
- ColorBarsHD accepts any 4:4:4 formats
- Dithering: Floyd-Steinberg
Use ConvertBits with parameter dither=1: Floyd-Steinberg (was: dither=0 for ordered dither)
- Dithering: parameter "dither_bits"
For dithering to lower bit depths than the target clip format
Usage: ConvertBits(x, dither=n [, dither_bits=y])
- ordered dither: dither_bits 2, 4, 6, ... but maximum difference between target bitdepth and dither_bits is 8
- Floyd-Steinberg: dither_bits 1, 2, 4, 6, ... up to target bitdepth - 2
(Avisynth+ low bitdepth, Windows 3.1 16 bit feeling I was astonished that dither_bits=6 still resulted in a quite usable image)
- Dithering is allowed from 10-16 -> 10-16 bits (was: only 8 bit targets)
- Dithering is allowed while keeping original bit-depth. clip10 = clip10.ConvertBits(10, dither=0, dither_bits=8)
(you still cannot dither from 8 or 32 bit source)
- ConditionalFilter syntax extension like Gavino's GConditional: no "=" "true" needed
- Revert: don't give error for interlaced=true for non 4:2:0 sources (compatibility, YATTA)
- CombinePlanes: silently autoconvert packed RGB/YUY2 inputs to planar
- ConvertBits: show error message on YV411 conversion attempt: 8 bit only
- ConvertBits: Don't give error message if dither=-1 (no dithering) is given for currently non-ditherable target formats
- Script function: IsVideoFloat. returns True if clip format is 32 bit float. For convenience, same as BitsPerComponent()==32
- ConvertToDoubleWidth and ConvertFromDoubleWidth: RGB24<->RGB48, RGB32<->RGB64
- New MT mode: MT_SPECIAL_MT. Specify it for MP_Pipeline like filters, even if no Prefetch is used (MP_Pipeline issue, 2 fps instead of 20)

[Groucho2004]

@pinterf
I noticed that in cpuid.cpp the reported CPU features (AVX, FMA) depend on CPU and OS support. So, if I run "Info()" on XP for example, these new extensions will be hidden even though the CPU has them.
In "Info()", it says "CPU detected:" so is it not a bit misleading? With the OS conditional, should it not rather read something like "CPU features supported by OS"?

[tuanden0]

@pinterf

- New MT mode: MT_SPECIAL_MT. Specify it for MP_Pipeline like filters, even if no Prefetch is used (MP_Pipeline issue, 2 fps instead of 20)

Can you give me an example or document for this?
:thanks:

[pinterf]

@pinterf
Can you give me an example or document for this?
:thanks:
SetFilterMtMode("MP_Pipeline",MT_SPECIAL_MT)

[ryrynz]

Can you list a few MP_Pipeline like filters please?

[pinterf]

@pinterf
I noticed that in cpuid.cpp the reported CPU features (AVX, FMA) depend on CPU and OS support. So, if I run "Info()" on XP for example, these new extensions will be hidden even though the CPU has them.
In "Info()", it says "CPU detected:" so is it not a bit misleading? With the OS conditional, should it not rather read something like "CPU features supported by OS"?
The text now is simply "CPU:", I have made it shorter, there is only a little place, I wanted to fit the feature list in 300-400 pixels wide, which is hard when the capabilities include FMA3, AVX2, etc.

Possible AVX512 extensions are listed in a second line however, there is quite a few of them.

XP users in 2017, well, they know what they do :) I don't want to warn them in Info() that AVX or better requires a decent OS

[pinterf]

Can you list a few MP_Pipeline like filters please?
No, I don't know yet similar filters like MP_Pipeline, but I did not know it either, before the issue had been reported.
Similar filters:
Behaving as source filters because they have no input clip parameter.
Unlike regular source filters, they are internally starting processes in multiple script environments (?)

Unfortunately this mt thing is the most difficult area in avs core, I was not able to understand it 100% (not even near of that) or else I could fix it by rewriting the relevant module.

Basically this option prevents Avisynth core from trying to figure out the effective mt mode of this filter.
I'm not sure that it will work in all situations, but in this specific MP_Pipeline case it works fine.

(When a filter is invoked it may invoke other filters, the core follows the nested invoke list and the effective mt mode is determined by the weakest mt mode, e.g. if there are invokes for filter with an MT_NICE_FILTER and MT_SERIALIZED, the latter will be chosen as the safest mt method. During the process internal MT guard object(s) is(are) created.)

[burfadel]

XP users in 2017, well, they know what they do :) I don't want to warn them in Info() that AVX or better requires a decent OS

Encoding on XP would be a significant slowdown on AVX and AVX2 machines when compared to running Windows 10, not to mention security and other issues. Also unless they're running 64-bit XP you are limited in RAM, which in turn could impinge on encode rate.

Any reason for using XP on a 'modern' AVX CPU?

[Groucho2004]

XP users in 2017, well, they know what they do :) I don't want to warn them in Info() that AVX or better requires a decent OSI know it's mostly semantics and I see your point. However, my opinion is that if you report CPU features, report them all, regardless of OS support
- or -
if you're including OS dependency, phrase it differently like x264 does:
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2

[Groucho2004]

Encoding on XP would be a significant slowdown on AVX and AVX2 machines when compared to running Windows 10, not to mention security and other issues. Also unless they're running 64-bit XP you are limited in RAM, which in turn could impinge on encode rate.

Any reason for using XP on a 'modern' AVX CPU?
I was hoping that this wouldn't turn into another OS argument.

[jmac698]

I just wanted to clear up something. Using avx requires OS support. It seems strange at first, but it's because the os has to save the extra registers so they don't get changed between processes. You could try to use it, but the program would mess up the results.

avx requires win7+ I believe.

[jmac698]

I have a question, did you derive the exact values for the high bit depth colour bars? I was the one who got them into avisynth in the first place. Especially the -I value requires some sin() calculations.

ConvertToDoubleWidth
was confusing to me, perhaps ConvertToDoubleDepth ?

[pinterf]

I just wanted to clear up something. Using avx requires OS support. It seems strange at first, but it's because the os has to save the extra registers so they don't get changed between processes. You could try to use it, but the program would mess up the results.

avx requires win7+ I believe.
AVX safe context switching is available from Windows 7 SP1

[pinterf]

I have a question, did you derive the exact values for the high bit depth colour bars? I was the one who got them into avisynth in the first place. Especially the -I value requires some sin() calculations.

ConvertToDoubleWidth
was confusing to me, perhaps ConvertToDoubleDepth ?
The values are scaled from the 8 bit constants. Can you help me with that if it is not correct?

DoubleWidth is a compatibility format ("hack"), sometimes called as interleaved. Format is an Avs2.6 compatible 8 bits one, but internally stores 16bit pixels, thats why the reported width is double than the original. Unlike stacked format its internal layout is the same as Avs+'s high bit depth formats.

[pinterf]

ConvertBits supports ordered and Floyd-Steinberg dithering.
Latter is new, available from r2440. You can dither down to 1-2-4-6-8..14 bits with parameter dither_bits. For restriction see the readme or the release announcement some posts back. Ordered dither is simd optimized.

[ChaosKing]

I started to use the x64 version now and noticed one thing. It's seems it is impossible to autoload avsi script for both 32 and 64 bit.

Would it be a good idea to implement a seperate "script-autoload-folder" in avs+?
This would also make the plugins plugins folder less cluttered.

[Groucho2004]

I started to use the x64 version now and noticed one thing. It's seems it is impossible to autoload avsi script for both 32 and 64 bit.

Would it be a good idea to implement a seperate "script-autoload-folder" in avs+?
This would also make the plugins plugins folder less cluttered.
Judging by your earlier post today I assume that you're using my Avisynth Version Selector which supports separate plugin directories for 64 and 32 bit by default.

[ChaosKing]

Yes. But I would like to have a shared avs script autoload folder, so I don't need to copy my avsi script in both (32 & 64 bit) folders.

The goal is:
Plugins32
Plugins64
Avs-Scripts (witch can be used by 32 & 64 avisynth) <-- missing yet



Edit:
I just found that there is a AddAutoloadDir() function. Will test it...

Edit2:
ok this is working, but it needs to be placed in the scripts header everytime. I guess I can live with that. But a global extra folder like the plugins folder would still be convenient.

AddAutoloadDir("D:\AvisynthRepository\SCRIPTS")

Sadly it does not work when I put a "scriptlaoder.avsi" with the line above in my plugins folder.

[real.finder]

speaking of that

the autoload folder list order now is

PluginDir+ in Software/Avisynth in HKEY_CURRENT_USER
PluginDir+ in Software/Avisynth in HKEY_LOCAL_MACHINE
PluginDir2_5 in Software/Avisynth in HKEY_CURRENT_USER
PluginDir2_5 in Software/Avisynth in HKEY_LOCAL_MACHINE

why not like this?

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

see here to know why https://forum.doom9.org/showthread.php?p=1789735#post1789735

[pinterf]

Hello everybody,

PS: I have tried the modified AvsPmod v2.5.1 r452 no more error messages , but this version does not like this:
[Multi Tasking=0]
Prefetch(4)
[/Multi Tasking]

It throws this error message:
"Only one prefetcher...."

But the only prefetch in the script is this one, at the end as it should be and it works fine with AvsPmod v2.5.1.
I realy need the option to switch MT on/off so I can not use AvsPmod r452.

Hi Fred, welcome to Avisynth+! I hope we'll solve your problems.

I have downloaded AvsPMod r452, and toggleing the option is working for me.
However when another Prefetch line is present, the "Only one prefetcher is allower per script" error occurs (as expected)
[Multi Tasking=1]
Prefetch(4)
[/Multi Tasking]
Prefetch(4)


Can you check that you don't have another Prefetch somewhere else (for example in an imported avsi)?

[Motenai Yoda]

Looks like someone has to add Is400()/IsYXX or mod IsY() to return true with 8+ Y-only clips too.
edit: I mean >8

[real.finder]

Looks like someone has to add Is400()/IsYXX or mod IsY() to return true with 8+ Y-only clips too.

there are already isy()

[Motenai Yoda]

there are already isy()

converttoy()
converttofloat()
subtitle(PixelType().string()+" "+isY().string())
convertbits(32)
subtitle(PixelType().string()+" "+isY().string(),y=16)
convertbits(16)
subtitle(PixelType().string()+" "+isY().string(),y=32)
convertbits(14)
subtitle(PixelType().string()+" "+isY().string(),y=48)
convertbits(12)
subtitle(PixelType().string()+" "+isY().string(),y=64)
convertbits(10)
subtitle(PixelType().string()+" "+isY().string(),y=80)
convertbits(8)
subtitle(PixelType().string()+" "+isY().string(),y=96)
what did it return to you?

I'll give you an hint...
https://3-t.imgbox.com/6wJJOEc6.jpg (http://imgbox.com/6wJJOEc6)

[real.finder]

converttoy()
converttofloat()
subtitle(PixelType().string()+" "+isY().string())
convertbits(32)
subtitle(PixelType().string()+" "+isY().string(),y=16)
convertbits(16)
subtitle(PixelType().string()+" "+isY().string(),y=32)
convertbits(14)
subtitle(PixelType().string()+" "+isY().string(),y=48)
convertbits(12)
subtitle(PixelType().string()+" "+isY().string(),y=64)
convertbits(10)
subtitle(PixelType().string()+" "+isY().string(),y=80)
convertbits(8)
subtitle(PixelType().string()+" "+isY().string(),y=96)
what did it return to you?

I'll give you an hint...
https://3-t.imgbox.com/6wJJOEc6.jpg (http://imgbox.com/6wJJOEc6)

there are bug then

[pinterf]

Thanks for the report. Fix will come soon. Only the script function was affected, VideoInfo::IsY was O.K.

[tormento]

- Dithering: Floyd-Steinberg
Use ConvertBits with parameter dither=1: Floyd-Steinberg (was: dither=0 for ordered dither)
- Dithering: parameter "dither_bits"
For dithering to lower bit depths than the target clip format
Usage: ConvertBits(x, dither=n [, dither_bits=y])
- ordered dither: dither_bits 2, 4, 6, ... but maximum difference between target bitdepth and dither_bits is 8
- Floyd-Steinberg: dither_bits 1, 2, 4, 6, ... up to target bitdepth - 2
(Avisynth+ low bitdepth, Windows 3.1 16 bit feeling I was astonished that dither_bits=6 still resulted in a quite usable image)
- Dithering is allowed from 10-16 -> 10-16 bits (was: only 8 bit targets)
- Dithering is allowed while keeping original bit-depth. clip10 = clip10.ConvertBits(10, dither=0, dither_bits=8)
(you still cannot dither from 8 or 32 bit source)
@real.finder is it of any use in SMDegrain instead of Dither dll?

[pinterf]

New Avisynth build.

Avisynth+ r2455-MT (https://github.com/pinterf/AviSynthPlus/releases/tag/r2455-MT)

v2455 (20170316), changes since v2440
-------------------------------------
# Fixes
IsY() script function returned IsY8() (VideoInfo::IsY was not affected)

# other modification, additions
ConvertBits, dither=1 (Floyd-Steinberg): allow any dither_bits value between 0 and 8 (0=b/w)


Thanks to Motenai Yoda for the IsY bug report.

[Motenai Yoda]

err... I don't know if it's a bug but
dither=1 to ie 2 bits give 0-64-128-192-255 -> 5 shades

[pinterf]

Sorry, quickly replaced 2454 to 2455, dither=1, dither_bits=any_less_than_8 did not work for 10 bits->10 bits conversion.

[pinterf]

err... I don't know if it's a bug but
dither=1 to ie 2 bits give 0-64-128-192-255 -> 5 shades
Yes, I was also expecting exactly 2^N levels for Floyd, and don't know the reason yet. I extended dither_bits for any <8 bit values to experiment what it looks like after seeing that dither_bits=1 gave me three histogram spikes.
dither_bits=0 -> 2 levels
dither_bits=1 -> 3 levels
dither_bits=2 -> 5 levels
dither_bits=3 -> 9 levels

[real.finder]

@real.finder is it of any use in SMDegrain instead of Dither dll?

no, no convert will done, input = output, but you can do it by your self, there are no need for dither dll without lsb in first place