Why is AviSynth still more popular than VapourSynth?

[Reclusive Eagle]

Just a question, not like it matters since VapourSynth can natively load Avisynth Plugins and there are ways to load Avsi's.

My question is, if Vapoursynth is like 10 years old at this point and is the new evolution of Avisynth with backward compatibility, why is Avisynth still the most used?
Even the forums are more active and when it comes to a lot of plugins, You need to look at the Avisynth documentation as well.

Is it because Avisynth has simpler commands that are easier to read?
Is it because native Python VapourSynth is more complicated than what its worth?

Lack of native plugin support?
Lack of documentation?

Or is Avisynth actually more powerful than VapourSynth and I am missing something?

I know QTGMC is better on AviSynth and tbilateral removes more artifacts with the same settings.
But from what I've experienced VapourSynth is so, so much faster since many of the plugins are getting Cuda support.

So even though there aren't as many plugins. There are really really high end plugins based on Cuda that cut render times by like 10x and there is backwards compatibility.

So what am I missing?
I'm not saying one is better or not it doesn't matter I'm just genuinely curious why AviSynth + virtual dub is still the preferred method

[VoodooFX]

AvS is simpler to use, more scripts, more plugins, better documentation and more examples of stuff.
AvSPMod is more comfortable than VS Editor.
Latest VS doesn't support Win7 and lower.
And I used AvS for a decade... before I heard that VS exist. I heard that MT is better there, but I get 100% CPU usage with AvS on quad, so...


Dunno where VS is much faster as I didn't see such comparisons.

PS
I know Python, and I don't know much about "AviSynth code"... I just type something and it usually works from the first try in AvS... :)

[Dogway]

Personally because Python is noisier on the eyes, harder to read, and I have worked with Python for a Blender addon before and still don't like it, I'm not sure why all the fuss about it.
The syntax is also too verbose and strange:

"x if true else y", are we talking Japanese (cause reverse syntax)?

I would rather see a Julia adapted framework, yes it's newer but it's very well thought and syntax (https://juliadatascience.io/syntax)aligns well with Avisynth

[Reclusive Eagle]

Personally because Python is noisier on the eyes, harder to read, and I have worked with Python for a Blender addon before and still don't like it, I'm not sure why all the fuzz about it.
The syntax is also too verbose and strange:

"x if true else y", are we talking Japanese (cause reverse syntax)?

I would rather see a Julia adapted framework, yes it's newer but it's very well thought and syntax (https://juliadatascience.io/syntax)aligns well with Avisynth

Depends on how it is formatted I guess.
If VS had options to color code besides Pythons native # or """text"""
That would be really really helpful honetsly

[real.finder]

Personally because Python is noisier on the eyes, harder to read, and I have worked with Python for a Blender addon before and still don't like it, I'm not sure why all the fuzz about it.
The syntax is also too verbose and strange:

"x if true else y", are we talking Japanese (cause reverse syntax)?

I would rather see a Julia adapted framework, yes it's newer but it's very well thought and syntax (https://juliadatascience.io/syntax)aligns well with Avisynth

I totally agree with you, but most Anime encoders in discord like vs and say that avs is not a language and it is difficult to read through their work in porting avsi to vs

anyway I personally see avs language is suitable for use in video purposes, also we got many new improvements and additions in avs+ syntax like arrays and loops, although at least for me reading old avs (not plus) functions isn't that hard, or at least isn't as they said

also I don't like how vs dependence on Python at least in windows, maybe I will care more about vs if the vs adopted Python as embedded python that is become one dll (as avisynth.dll in avs/avs+) that don't need download python to work so it will independent from Python in the system (kinda like avspmod or maybe Blender), maybe avs/avs+ can do this with Python or another language in the future as optional alternative of .avsi with also https://forum.doom9.org/showthread.php?p=1822289&highlight=Myrsloik#post1822289

[Reclusive Eagle]

AvS is simpler to use, more scripts, more plugins, better documentation and more examples of stuff.
AvSPMod is more comfortable than VS Editor.
Latest VS doesn't support Win7 and lower.
And I used AvS for a decade... before I heard that VS exist. I heard that MT is better there, but I get 100% CPU usage with AvS on quad, so...


Dunno where VS is much faster as I didn't see such comparisons.

PS
I know Python, and I don't know much about "AviSynth code"... I just type something and it usually works from the first try in AvS... :)

I feel like the lack of documentation is 99% Plugin creator's fault.
Most of the avisynth mods are converted to .py files and then all they do is link back to the original avisynth wiki.

Which is 100% not an issue... if it worked exactly the same way as the avisynth plugins. However most of the time they don't. Definitions are changed, removed or added.
They aren't updated with the current avisynth plugins so the VapourSynth version can be 4 years old vs Avisynth that is updated every 2 months etc.


Nvm the fact that for the dll files. Sometimes VapourSynth creators refuse to even compile their stuff. Or the release version is 4 years old but the new code
is uncompiled source code thats 2 weeks old and you need to attempt to sniff the air for information on how to build the solution in visual studios.
If you even have or know how to use Visual Studios. And even then its a massive pain


Nvm the fact that the Vapoursynth wiki (that was once available to the public)
http://www.vapoursynth.com/doc/plugins.html

Has been temporarily removed for the past 2 years for the new site leaving only basic documentation for native VapourSynth commands.


If we had the Wiki and if plugin creators would actually do like a fraction of a percentage of effort in documenting their changes for users
I'm sure Avisynth wouldn't be the default

[ChaosKing]

I think if pinterf hadn't made so many improvements and maintenance to avs+, more people would have switched to VS already.

@Dogway there was an attempt to bring Julia to VS here https://github.com/mantielero/VapourSynth.jl

[real.finder]

If the bottom question of the op is how do we make vs more popular than avs/avs+ (which vs already may popular nowadays in Anime fansub encoders at least in Discord) then I think the place to ask is not here but https://forum.doom9.org/forumdisplay.php?f=82

[Reel.Deel]

I was an early user of VapourSynth when it was in its infancy. I am no programmer at all but I found my way thru and learned how to use it, at least the basics. It was really limited back then in terms of plugins and scripts. Then not long after came AviSynth+. I went back to AviSynth, and while it still had no proper high bit depth support I felt that I was just much more productive using it. For one, I think the documentation in VapourSynth and some of the external plugins/scripts assume that anyone using it is familiar with programming and sometimes the examples are a little to vague to help the users that are not well versed in Python. In the end it felt I spent more time in trying to make something work rather than doing any actual tasks. I still have VS installed and use it from time to time, but for the time being AVS+ does just about everything that VS does, as far as my needs go, and its easy enough for me to use and figure things out.

I think if pinterf hadn't made so many improvements and maintenance to avs+, more people would have switched to VS already.
Indeed.

[FranceBB]

I haven't really used VapourSynth, I've been an Avisynth user my entire life.
I started back in 2006 when almost everything was limited to yv12 and YUY2 and what a journey has been.
Nowadays we have several sampling supported, native high bit depth (after a brief 16bit stacked/interleaved period) up to 32bit float, we have multithreading, intrinsics, support for OS as legacy as Windows XP up to Windows 11, a work-in-progress cross-platform support for Linux and Mac OSX, a still developed CUDA hardware acceleration support, I mean, Avisynth has come a long way, indeed.
To me, starting with a brand new frameserver would be unthinkable 'cause I would have to learn how to code in Python and how to use its functions etc and I don't really want to start over given how familiar I am with Avisynth.
I mean, sure, sometimes I still have my doubts and I still ask the community (and bother StainlessS between a beer and another, in particular when I'm stuck writing my own functions ehehehehe), but if it comes down to my daily job in which I receive files from different companies and I have to encode them, I go on auto-pilot 90% of the time (TL;DR I'm writing a script and I know almost all the functions to call and their parameters as they're "hardcoded" in my mind).

About the IDE, AVSPmod mod has been a great success and I'm really thankful to Gispos for keeping it updated and still developing it.

By the way, sometimes people say that Python is more human readable and intuitive and easier to understand than C++ (or pseudo-C++ as the one used in Avisynth), but honestly, how is this:


import vapoursynth as vs
core = vs.get_core(threads=4)
ret = core.lsmas.LibavSMASHSource(source="Sample.mov")
ret = core.fmtc.resample (clip=ret, w=720, h=576, css="444", kernel="spline36")
ret = core.fmtc.matrix (clip=ret, mats="709", matd="601")
ret = core.fmtc.resample (clip=ret, css="420")
ret = core.fmtc.bitdepth (clip=ret, bits=10)
retFinal = ret
retFinal.set_output()


easier than this:


LWLibavVideoSource("Sample.mov")

Spline36Resize(720, 576)

Matrix(from=709, to=601, bitdepth=8)

ConverttoYUV420()

ConvertBits(10)

[Reel.Deel]

easier than this:

Can be even easier :p

LWLibavVideoSource("Sample.mov")

z_ConvertFormat(720, 576, pixel_type="YUV420P10", colorspace_op="709:709:709:full=>470bg:601:170m:full")

[takla]

But from what I've experienced VapourSynth is so, so much faster since many of the plugins are getting Cuda support.
Well there is your answer. Last time I checked, nvidia only had ~60% market share. Plus, the way you write a script of commands in vapoursynth isn't exactly identical to avisynth, which is another hurdle for people that would like to switch.

[VoodooFX]

By the way, sometimes people say that Python is more human readable and intuitive and easier to understand than C++ (or pseudo-C++ as the one used in Avisynth)
Python is easier to learn in comparison to C++, readability probably is similar when you actually know C++/Python.
To write/read Avisynth's pseudo code you don't need to learn any language, it's pretty intuitive.

Look at the latest VS issue posted [how to get Y from video], beginner needs to read documentation for every step:
clip = core.std.ShufflePlanes(clip, planes=[0], colorfamily=vs.GRAY)
When usually in AvS you intuitively can do without reading documentation:
ExtractY

PS
I see only one reason to choose VS over AvS - if you are some 'exotic' OS user.

[FranceBB]

To write/read Avisynth's pseudo code you don't need to learn any language, it's pretty intuitive.

That's why we love it. :)

[kedautinh12]

If avs can port some Improving Video Super-Resolution like basicvsr++ from Vapoursynth. It's sweet :D

[WolframRhodium]

By the way, sometimes people say that Python is more human readable and intuitive and easier to understand than C++ (or pseudo-C++ as the one used in Avisynth), but honestly, how is this:


import vapoursynth as vs
core = vs.get_core(threads=4)
ret = core.lsmas.LibavSMASHSource(source="Sample.mov")
ret = core.fmtc.resample (clip=ret, w=720, h=576, css="444", kernel="spline36")
ret = core.fmtc.matrix (clip=ret, mats="709", matd="601")
ret = core.fmtc.resample (clip=ret, css="420")
ret = core.fmtc.bitdepth (clip=ret, bits=10)
retFinal = ret
retFinal.set_output()


easier than this:


LWLibavVideoSource("Sample.mov")

Spline36Resize(720, 576)

Matrix(from=709, to=601, bitdepth=8)

ConverttoYUV420()

ConvertBits(10)

reference VapourSynth re-implementation:

import avs_syntax
globals().update(avs_syntax.env)

LWLibavSource("Sample.mov")

resample(w=720, h=576, css="444", kernel="spline36")

matrix(mats="709", matd="601")

resample(css="420")

bitdepth(bits=10)

last().set_output()


helper script (avs_syntax.py)

from vapoursynth import core

last = None

def wrapper(f):
def inner(*args, **kwargs):
global last
if len(args):
last = f(*args, **kwargs)
else:
last = f(last, **kwargs)
return last
return inner

env = {f.name:wrapper(f) for p in core.plugins() for f in p.functions()}
env["last"] = lambda: last

[VoodooFX]

If avs can port some Improving Video Super-Resolution like basicvsr++ from Vapoursynth. It's sweet :D

How this kind of destruction is sweet? :D

https://i.ibb.co/nnRhFXs/qtgmc-bsvcr-model5.png (https://ibb.co/F0nGFQb)

very little noticeable impact on the quality, that is really impressive!

[StainlessS]

I did not take a lot of notice of vs in the past due to its non support for audio,
I believe this is no longer the case [to some degree].

[Boulder]

Multithreading-wise Vapoursynth is better since that was designed there from the start. I think cache management and memory utilization is also better, especially with the latest API.

The syntax is hard to grasp for anyone who has not done any programming. Then again, the language is very powerful since you can do anything that Python can.

[Zarxrax]

In addition to other reasons people have already stated like the syntax in vapoursynth being more complex, I really dislike python in general because stuff tends to simply break on me.
Every python app you use has tons of other dependencies that you need to install.
I had vapoursynth running about half a year ago. Then a few weeks ago I tried to run it again and it simply didn't work anymore. I eventually got it working again by updating it or something, but the point is that it just stopped working, likely because something else on my system changed. With Avisynth, I simply install it and that's it. I don't have to worry about some weird dependency breaking it. For a general user who doesn't do python programming day in and day out, stuff like this just makes things difficult.

[real.finder]

but honestly, how is this:


import vapoursynth as vs
core = vs.get_core(threads=4)
ret = core.lsmas.LibavSMASHSource(source="Sample.mov")
ret = core.fmtc.resample (clip=ret, w=720, h=576, css="444", kernel="spline36")
ret = core.fmtc.matrix (clip=ret, mats="709", matd="601")
ret = core.fmtc.resample (clip=ret, css="420")
ret = core.fmtc.bitdepth (clip=ret, bits=10)
retFinal = ret
retFinal.set_output()


easier than this:


LWLibavVideoSource("Sample.mov")

Spline36Resize(720, 576)

Matrix(from=709, to=601, bitdepth=8)

ConverttoYUV420()

ConvertBits(10)

even the most fanatics vs users don't deny this, but they said that the difficulty of reading problems in avs happen in the complex use (like in avsi script complex functions)

[ChaosKing]

even the most fanatics vs users don't deny this, but they said that the difficulty of reading problems in avs happen in the complex use (like in avsi script complex functions)

+1
Yes, for simple scripts avs is more compact (less noise).
But let's open a complex script. You will find like 10 nested conditional if statements and some other weird stuff.

Vapoursynth needs a better editor with better assistance to beginners (non programmers). A combination of avspmod, vsedit(2) and Yuuno would be good + nice UI.

[Reclusive Eagle]

I haven't really used VapourSynth, I've been an Avisynth user my entire life.
I started back in 2006 when almost everything was limited to yv12 and YUY2 and what a journey has been.
Nowadays we have several sampling supported, native high bit depth (after a brief 16bit stacked/interleaved period) up to 32bit float, we have multithreading, intrinsics, support for OS as legacy as Windows XP up to Windows 11, a work-in-progress cross-platform support for Linux and Mac OSX, a still developed CUDA hardware acceleration support, I mean, Avisynth has come a long way, indeed.
To me, starting with a brand new frameserver would be unthinkable 'cause I would have to learn how to code in Python and how to use its functions etc and I don't really want to start over given how familiar I am with Avisynth.
I mean, sure, sometimes I still have my doubts and I still ask the community (and bother StainlessS between a beer and another, in particular when I'm stuck writing my own functions ehehehehe), but if it comes down to my daily job in which I receive files from different companies and I have to encode them, I go on auto-pilot 90% of the time (TL;DR I'm writing a script and I know almost all the functions to call and their parameters as they're "hardcoded" in my mind).

About the IDE, AVSPmod mod has been a great success and I'm really thankful to Gispos for keeping it updated and still developing it.

By the way, sometimes people say that Python is more human readable and intuitive and easier to understand than C++ (or pseudo-C++ as the one used in Avisynth), but honestly, how is this:


import vapoursynth as vs
core = vs.get_core(threads=4)
ret = core.lsmas.LibavSMASHSource(source="Sample.mov")
ret = core.fmtc.resample (clip=ret, w=720, h=576, css="444", kernel="spline36")
ret = core.fmtc.matrix (clip=ret, mats="709", matd="601")
ret = core.fmtc.resample (clip=ret, css="420")
ret = core.fmtc.bitdepth (clip=ret, bits=10)
retFinal = ret
retFinal.set_output()


easier than this:


LWLibavVideoSource("Sample.mov")

Spline36Resize(720, 576)

Matrix(from=709, to=601, bitdepth=8)

ConverttoYUV420()

ConvertBits(10)


To be fair when I went from Avisynth to Vapoursynth it took me like 2 weeks to learn to read and write python. Its not a monumental task.

In fact its almost the same as Avisynth just more in-depth. So from the coding side at least there isn't a difficulty curve. Just a research and time you put in to accelerate your learning

[Reclusive Eagle]

In addition to other reasons people have already stated like the syntax in vapoursynth being more complex, I really dislike python in general because stuff tends to simply break on me.
Every python app you use has tons of other dependencies that you need to install.
I had vapoursynth running about half a year ago. Then a few weeks ago I tried to run it again and it simply didn't work anymore. I eventually got it working again by updating it or something, but the point is that it just stopped working, likely because something else on my system changed. With Avisynth, I simply install it and that's it. I don't have to worry about some weird dependency breaking it. For a general user who doesn't do python programming day in and day out, stuff like this just makes things difficult.

I mean if Python Auto updates yes.
I use embedded Python with portable VapourSynth.

I can literally copy past the folder on a new pc and start using Vapoursynth since nothing is installed. And this way nothing ever auto updates

[Reclusive Eagle]

+1
Yes, for simple scripts avs is more compact (less noise).
But let's open a complex script. You will find like 10 nested conditional if statements and some other weird stuff.

Vapoursynth needs a better editor with better assistance to beginners (non programmers). A combination of avspmod, vsedit(2) and Yuuno would be good + nice UI.

What would be really nice if there was a GUI that auto detected definitions and made buttons for it automatically.

Imagine Hybrid's button layout but for every Plugin. Then you can just add and instead of writing scripts you can click buttons and change the load order of scripts instead of trying to find documentation for definitions ect.

Then you can just focus on if things work.
It would basically work like Fallout New Vegas / Fallout 4 / Skyrim.
"Does this order work? No ok change mods around"

That would be so much easier if there was a universal GUI to replace manual code

[real.finder]

+1
Yes, for simple scripts avs is more compact (less noise).
But let's open a complex script. You will find like 10 nested conditional if statements and some other weird stuff.

Vapoursynth needs a better editor with better assistance to beginners (non programmers). A combination of avspmod, vsedit(2) and Yuuno would be good + nice UI.

I don't mind even old avs, but I got another suggestion (since we are in Avisynth section of the forum not Vapoursynth) and it is adding embedded python or another language support to avs+ as optional alternative of .avsi and add support for vs api in avs+ to load vs plugins (dll) in avs+ (https://forum.doom9.org/showthread.php?p=1822289&highlight=Myrsloik#post1822289) (also https://forum.doom9.org/showthread.php?p=1644145#post1644145)


edit: IRC log from 2016


00[02:51] <AmjadSONY> ultim, vapoursynth can load avs plugins, so is there possibility to make avs+ load vapoursynth plugins? if that possibile then avs+ should output all Color format officially
02[02:56] * Disconnected
Session Close: Wed Jun 22 02:56:55 2016
Session Start: Thu Jun 23 22:04:12 2016
Session Ident: #avs-plus
03[22:04] * Now talking in #avs-plus
03[22:04] * Topic is 'Avisynth+ official development channel | Latest build at http://avs-plus.net/builds | Help filling MT modes: http://publishwith.me/ooiV92hupl'
03[22:04] * Set by tp7!~tp7@addicted.to.sweets on Wed May 06 12:54:23 2015
02[22:07] * ChocolateArmpits (kvirc@3F433B6B.89E38110.FC20E28A.IP) Quit (Ping timeout: 240 seconds)
[23:04] <@ultim> AmjadSONY: probably. I haven't spent any brain-time on such a conversion layer, but it should be possible. Ofc you wouldn't be able to use the vapoursynth-specific features that have no support in the avs-core, even if the plugin supported them.
[23:06] <@ultim> as for color formats, support is probably more work than just adding constants for VS-plugins, becuase if a VS script or plugin depends on internal functions, those also need to have the new color format support
[23:07] <@ultim> so at least internal filters (or some of them) in the avs core would need to be extended for the new color formats
[23:08] <@ultim> depending on the number that is required, this can be anything from fairly trivial to a considerable amount of work
00[23:12] <AmjadSONY> http://forum.doom9.org/showpost.php?p=1644145&postcount=18
00[23:14] <AmjadSONY> VapourSynth is just an API as TheFluff said
[23:14] <tp7> implementing another language support for vsynth is a terrible idea, don't do that
[23:32] <Myrsloik> Fun fact, there's a lua doodle for vs nobody cares about
[23:32] <Myrsloik> ultim: very few filters use internal functions though
[23:32] <Myrsloik> And they never use eval() stuff
[23:57] <@ultim> AmjadSONY: yes somebody could create a new project with avs-syntax but vs-api. but that means reinventing the wheel for all internal logic (memory management, error handling, pllugin loading, internal filters and a lto more) that both avs and vs has already done.
[23:58] <@ultim> so ideally, it'd be great if an avs frotend could be created for vs
[23:59] <@ultim> Myrsloik: since you're here, i think a long ago you stated that due to idunnowhat, VS is really not layed out for different (or avs-like?) language frontends
[23:59] <@ultim> is this so or is my memory cheating me?
[23:59] <Myrsloik> It's mostly that avs script is missing arrays
Session Time: Fri Jun 24 00:00:00 2016
[00:00] <Myrsloik> And function objects to pass around
[00:00] <@ultim> but wouldn't that mean that you simply wouldn't be able to use arrays and function objkects in avs scripts?
[00:01] <@ultim> but still make a fully functional avs forntend- fully functional in the sanse of support for avs scriptsd
[00:01] <@ultim> *sense
[00:02] <Myrsloik> Still makes some plugins impossible to use
[00:02] <Myrsloik> Unless you wrap them
[00:02] <@ultim> vs plugins
[00:02] <Myrsloik> Yes
[00:03] <Myrsloik> Obviously avs stuff would always work
[00:03] <@ultim> ofc just like avs syntax was extended with groucho's constructs, the avs language could be supplemented with these features
[00:04] <@ultim> than even vs stuff would work
[00:04] <@ultim> *then
[00:04] <Myrsloik> Yes
[00:04] <@ultim> well, that might just be the future
[00:04] <@ultim> imho
[00:05] <Myrsloik> Just wait until I add audio support
[00:05] <Myrsloik> Then you'll never catch up
[00:06] <@ultim> this sounds like it is on your not too far away todo list
00[00:06] * @ultim grins
[00:06] <Myrsloik> Just need to be inspired
[00:06] <Myrsloik> And I really don't want to go the avs route because that's a mess too
[00:08] <@ultim> <tp7> [22:14:28] implementing another language support for vsynth is a terrible idea, don't do that
[00:08] <@ultim> why?
[00:10] <Myrsloik> The only reason I can think of is that it'd fragment things even more
[00:12] <Myrsloik> Btw, do you care about avfs at all?
[00:12] <@ultim> fragment? in my oppinion it would finally unite the vs and avs people.
[00:13] <@ultim> avfs?
[00:13] <Myrsloik> The avs script to virtual avi file thing
[00:14] <@ultim> oh yeah, there was something like that :D no, not really.
[00:14] <@ultim> if somebody wants that, there are multiple frameservers out there for the same purpose but not avs-sepcific
[00:16] <tp7> <@ultim> fragment? in my oppinion it would finally unite the vs and avs people. --- except python scripts cannot use avs scripts and so on
[00:16] <tp7> which is yes, fragmentation
[00:16] <tp7> and the fun part will begin when somebody start porting scripts from one language to another
[00:17] <tp7> porting badly
[00:17] <tp7> or not updating after the original script got updated
[00:17] <@ultim> but both groups would be able to use the same core, contribute to the same core, and still use the scripts and plugins they like
[00:17] <tp7> and you'll have two identically named scripts with identical parameters doing the same thing slightly and subtly differently
[00:17] <tp7> what could be better?
00[00:17] <AmjadSONY> we don't need python scripts, we need the plugins
[00:18] <tp7> imo if you want to use vsynth code then just unfuck the vsynth api and don't bring avs language there at all
[00:18] <@ultim> lol you have the same problems with avs plugins today too
[00:18] <@ultim> so i i don't see the difference
[00:18] <Myrsloik> tp7: what is there to unfuck?
[00:18] <@ultim> if you don1T want two scripts or plugint hat collide, don't install them both
[00:18] <tp7> Myrsloik, your python api is crap
[00:18] <@ultim> btw, in vs you have namespacing
00[00:18] <AmjadSONY> and avs already can load another's plugins like vd
[00:18] <Myrsloik> All I see is a bag pf whiners on d9 wishing they'd made my decisions
[00:19] <tp7> >btw, in vs you have namespacing
[00:19] <tp7> yeah it'd have to go
[00:19] <tp7> terrible idea
[00:19] <@ultim> not go
[00:19] <@ultim> but mbe made optional
[00:20] <@ultim> *be made
[00:20] <Myrsloik> tp7: hahaha
[00:20] <tp7> optional namespaces are even worse than no namespaces
[00:20] <Myrsloik> Avisynth added it too
[00:20] <Myrsloik> Now remove the dllname_function aliases
[00:20] <tp7> anyway, remove namespaces, provide proper function registration so that function usage doesn't look different from plugin usage and they can be easily autoloaded
[00:20] <@ultim> you mean the underscrore thingy?
[00:20] <@ultim> lol, that migth work as a syntax, but the semantics are really bad
[00:21] <@ultim> i do hope vs has done it better
[00:21] <@ultim> or else you1re losing all my respect :D
[00:23] <Myrsloik> How would I do it worse?
[00:24] <@ultim> i'm not too familiar with vs
[00:24] <@ultim> so don't ask me questions about it. all i was saying is that avs is doing it bad, and i hope you did it better
[00:25] <tp7> https://github.com/IFeelBloated/Oyster/blob/master/Oyster.py#L102 all you've got to know about vsynth namespaces imo
[00:26] <@ultim> what i mean is, in avs there is no namespcing in the real sense
[00:26] <@ultim> this fake-namespacing is just adding a second function for every function you register with the dllname_ prepended
[00:27] <@ultim> in the core, there is no real connection or grouping between functions
[00:27] <tp7> oh that thingy
[00:28] <tp7> it kinda makes sense for debugging purposes I guess?
[00:29] <@ultim> imho that is of the places where it shoots you in the foot
[00:29] <@ultim> it is kinda usefull if you have multiple dlls which implement the same functions, but breaks immediately when those dlls have the same name
[00:29] <@ultim> just to name an example
[00:30] <@ultim> *two examples
[00:30] <@ultim> nvm
[00:30] <tp7> yeah w/e, nobody is really using it (because nobody has to use it) so who cares
[00:31] <@ultim> its not like either of us unfamiliar with the defects of avs
00[00:32] * Myrsloik will be out of battery in a few min
[00:32] <@ultim> but when avs+ was started, vs was really not a contender
[00:32] <@ultim> today it is a lot closer
[00:32] <tp7> is it
[00:32] <Myrsloik> tp7: fuck off
[00:32] <tp7> did something actually change in vs
[00:33] <Myrsloik> You're just jealous that I consider changing mistakea
[00:33] <tp7> what
[00:33] <Myrsloik> Instead of being tied to the Avisynth brick
[00:33] <tp7> uuuuh what
[00:33] <@ultim> i thoguht i made it clear a few times: we did consider correctiong mistakes. in fact the whole point of avs+ is about correcting as many mistakes as possible, so we do it all the time
[00:34] <@ultim> it is just we simply also value compatibilty as really important
[00:34] <Myrsloik> If you've missed it tp7 never considers vs stable
[00:34] <Myrsloik> Because I changed something
[00:34] <Myrsloik> That doesn't really break anything
[00:34] <@ultim> i cannot comment on that becuase i haven't really tried it.
[00:35] <@ultim> i did read up on its api and saw that lately many plugins and scripts have been either ported or developed
[00:35] <Myrsloik> Yes, quite a bit now
[00:35] <@ultim> so assuming it is stable, and i do assume it, i think it is aonly missing audio support, and a friendlier language for non-prgorammers
[00:36] <Myrsloik> I'll add php scripting next week!
[00:36] <@ultim> because video editrs and encoder are not programmers
00[00:36] * @ultim facepalms
00[00:36] <AmjadSONY> friendlier language for non-prgorammers < that is the point
[00:37] <tp7> Myrsloik, fwiw I have pretty much nothing against vsynth core at this point, now that twc wrote that C++ api thingy it's probably even convenient for plugin developers to use
[00:37] <tp7> (assuming you stop breaking compatibility, duhuhu)
00[00:38] <AmjadSONY> vs is c api as I know
[00:38] <tp7> question "is it" was asked because as far as I'm concerned nothing changed significantly in the vsynth core during the past year or two
[00:38] <tp7> what I do have problems with is the python api
[00:39] <tp7> which is not just "unfamiliar", it's simply inconvenient to use even for me, and I write python for a bloody living
[00:39] <@ultim> <-- that
[00:39] <tp7> and that fiesty guy is actually a very good indicator of that
[00:39] <@ultim> python is not the problem for any of us
[00:39] <@ultim> it is a problem for users
[00:39] <tp7> you've got an average dumb user without programming experience who just wants to solve his problems
[00:40] <@ultim> for us it is only inconvenient
[00:40] <tp7> and the solutions he comes up with are hideous
[00:40] <@ultim> but for users it is a problem
[00:40] <tp7> definitely not because vsynth helps him write good code
[00:40] <tp7> <AmjadSONY> vs is c api as I know -- twc wrote a C++ wrapper for it some time ago
[00:41] <tp7> which should've been made years ago tbh
[00:41] <tp7> http://forum.doom9.org/showthread.php?t=173558 this thing
[00:41] <tp7> (I never actually tried it so idk how good it actually is, but looks pretty reasonable?)

[zorr]

My experience on Avisynth vs VapourSynth is that VS simply performs better when doing complex things. I have made scripts that slice and dice the frame into multiple parts, detects things in them, doing corrections per slice, choosing among multiple versions, blending them back together. Several thousand lines of code. It seems Avisynth memory handling does not handle these kind of complex manipulations very well so VS is the only realistic option.

Also it's hard to do more complex logic without basic data structures like sets and maps. Avisynth is now getting arrays which is a huge improvement but I think a map implementation would also be very useful.

Other than that, Avisynth syntax is easier to eyes. I agree that a better editor would be needed to attract more users and that applies to both languages. I may or may not have something related in the works... *wink*

[qyot27]

PS
I see only one reason to choose VS over AvS - if you are some 'exotic' OS user.
AviSynth+ actually can be used on more OS/CPU configurations, but the selection of plugins outside of Windows hasn't caught up yet (most of the plugins available for non-Windows are actually more 'we just haven't tested it under every combo' not necessarily a 'it doesn't work at all under this OS/arch'). Somewhat expected, considering VapourSynth had an 8 year head start.

Technically, we could remove the OS and arch limiter in config.h, and if it builds it should work, but I wanted to be cautious about that so I could verify at least basic functionality on a given combo (either on real hardware or in a qemu-system-* VM with an appropriate OS).

That said, the single most exotic configuration that AviSynth+ theoretically supports right now is actually held back by the OS itself not yet fully booting on that architecture (it's Haiku on SPARC), although at some point it may be possible.

[Quadratic]

AvS is simpler to use
This is only true if you're writing very simple .avs files, the second you try and introduce any kind of complexity Vapoursynth (or rather python) is much simpler.

Personally because Python is noisier on the eyes, harder to read

With all due respect, I find reading the functions in your repo is akin to deciphering hieroglyphics.

[ErazorTT]

This is only true if you're writing very simple .avs files, the second you try and introduce any kind of complexity Vapoursynth (or rather python) is much simpler.

And that first point is, I think, really the reason why it’s so hard for VS to getting a hold. For real newbies, all they want is to get a clip loaded in things like VirtualDub. The minute they manage that and have the feeling of quick success is when their future environment is decided.
The second point is basically a non-issue for 95% of the users and only relevant for script creators. Further up the feed chain above script creators are those who can create dll libraries. There the Limitation of the scripting language is again irrelevant.
So you see, the only drawback of AS is for that intermediate part of the user base that is above an usual user but doesn’t create a library of their own. The probability to move after you have been a newbie and had that feeling of quick success is quite small.
You’ll be more willing to invest into something at a later point compared to investing when you’re starting out. While you’re less willing to move to another environment at any later point since than you’d be starting from scratch with being a newbie.

Personal story from literally yesterday, my first touch with VS: I wanted to load a clip in VS and have a py script loaded on it. I didn’t even mange to load that clip, didn’t even get to the script. ffms2 was apparently crashing or something, I don’t know. I gave up, because it didn’t work right out of the box and my interest of seeing the result of that script was not strong enough to overcome the missing documentation.

[Quadratic]

The second point is basically a non-issue for 95% of the users and only relevant for script creators.

But don't you see? Because it is easier in Vapoursynth, almost all users ARE script creators. Just about every Vapoursynth user is making custom functions to deal with issues because it is so easy! That's the magic.

In Avisynth, there's an enormous wall between calling some basic functions linearly to writing a your own functions.

[ErazorTT]

almost all users ARE script creators.

That’s called selection bias in statistics! Yes, the users of VS are script creators: because the must. You cannot not be a script creator. So VS is just losing all those that aren’t willing to become a script creator.

And really, what I wrote in my previous post was the objective side of it only. Personally I really think it’s worse: VS is too generic and not descriptive enough. Without documentation I’m having trouble even with single core commands. Example:
ShufflePlanes

I really think no user targeted function on earth should ever have shuffle in the name. I guess I see where its coming from (SSE and AVX) but really, when I’m writing SIMD (SSE, AVX and such) I have the full thousands of pages of top notch documentation right next to me. (Yes it’s literally multiple thousands of pages)

[Quadratic]

My background: I used Avisynth for about a year before swapping to Vapoursynth and I have never looked back.

That’s called selection bias in statistics! Yes, the users of VS are script creators: because the must. You cannot not be a script creator. So VS is just losing all those that aren’t willing to become a script creator.

I do not know how to argue against this, Vapoursynth is easier to use and learn therefore there are more people writing functions as a consequence. Outside of Doom9, I can count on a single hand the ones who know how to write functions let alone plugins. They (the 95% as you put it) all have to rely on other people or existing functions which usually are not sufficient. This has caused a massive lack of talent in general - but this is anecdotal of course.

Without documentation I’m having trouble even with single core commands. Example:
ShufflePlanes

No documentation? What do you mean? https://www.vapoursynth.com/doc/functions/video/shuffleplanes.html

I really think no user targeted function on earth should ever have shuffle in the name. I guess I see where its coming from (SSE and AVX) but really, when I’m writing SIMD (SSE, AVX and such) I have the full thousands of pages of top notch documentation right next to me.

I do not write plugins, I have no idea how this is relevant to the conversation.

[ErazorTT]

No documentation? What do you mean? https://www.vapoursynth.com/doc/functions/video/shuffleplanes.html


That’s not what I meant. I didn’t mean to say there is no documentation, I meant: given I’m not looking into the existing documentation, then I’m having trouble of just reading the code. That means that it’s not descriptive.


I do not write plugins, I have no idea how this is relevant to the conversation.
What I wanted to compare here was the fact while there are situations where it’s necessary to having documentation while writing code, I don’t think that that’s true for a scripting language. It should be more descriptive so that that much documentation is not even necessary.

[VoodooFX]

This is only true if you're writing very simple .avs files, the second you try and introduce any kind of complexity Vapoursynth (or rather python) is much simpler.
Generally, the scripts developing in VS should be easier, but in AvS there are huge amount of plugins to reuse, so less stuff you need to implement yourself.

In Avisynth, there's an enormous wall between calling some basic functions linearly to writing a your own functions.

You would be surprised how much I didn't/don't read AvS documentation, and just guess AvS syntax and functions...
Maybe solution for that wall was just one thread away but you never asked for help?
Maybe you knew Python beforehand, then VS looks much simpler for you?

[Reclusive Eagle]

And that first point is, I think, really the reason why it’s so hard for VS to getting a hold. For real newbies, all they want is to get a clip loaded in things like VirtualDub. The minute they manage that and have the feeling of quick success is when their future environment is decided.
The second point is basically a non-issue for 95% of the users and only relevant for script creators. Further up the feed chain above script creators are those who can create dll libraries. There the Limitation of the scripting language is again irrelevant.
So you see, the only drawback of AS is for that intermediate part of the user base that is above an usual user but doesn’t create a library of their own. The probability to move after you have been a newbie and had that feeling of quick success is quite small.
You’ll be more willing to invest into something at a later point compared to investing when you’re starting out. While you’re less willing to move to another environment at any later point since than you’d be starting from scratch with being a newbie.

Personal story from literally yesterday, my first touch with VS: I wanted to load a clip in VS and have a py script loaded on it. I didn’t even mange to load that clip, didn’t even get to the script. ffms2 was apparently crashing or something, I don’t know. I gave up, because it didn’t work right out of the box and my interest of seeing the result of that script was not strong enough to overcome the missing documentation.

You need to do clip = core.ffms2.Source(source=r'ClipLocation.mkv')
Or .mov or what ever the extension is. But yes the lack of documentation and basic tutorials is sooooooo fragmented and disgusting.

No joke, i've been using VS for 5 months now.
I can do complex things like edge masking etc.

You know what I couldn't do and couldn't find documentation on?
How to convert a YUV clip to just the Luma layer.

Turns out it was really simple but without the 2 people active on the VS forums I wouldn't have been able to get it. Its a joke.

[_Al_]

import vapoursynth as vs
core = vs.get_core(threads=4)
ret = core.lsmas.LibavSMASHSource(source="Sample.mov")
ret = core.fmtc.resample (clip=ret, w=720, h=576, css="444", kernel="spline36")
ret = core.fmtc.matrix (clip=ret, mats="709", matd="601")
ret = core.fmtc.resample (clip=ret, css="420")
ret = core.fmtc.bitdepth (clip=ret, bits=10)
retFinal = ret
retFinal.set_output()


easier than this:


LWLibavVideoSource("Sample.mov")

Spline36Resize(720, 576)

Matrix(from=709, to=601, bitdepth=8)

ConverttoYUV420()

ConvertBits(10)
Yes vs codes tend to have more characters while comparing, but it is structured, modules, its attributes, it just brings advantages only, when things get heavier. When avisynth becomes more elaborate, scripts become a torture.

Also that vapoursynth script example could be much easier just using built in zimg resizer, [edit] sorry, both are identicle:
import vapoursynth as vs
from vapoursynth import core
source = core.lsmas.LibavSMASHSource(source='test.mov')
vnode = source.resize.Spline36(width=720, height=576, format=vs.YUV420P10, matrix_in_s='709', matrix_s='170m')
vnode.set_output()

[Reclusive Eagle]

That’s not what I meant. I didn’t mean to say there is no documentation, I meant: given I’m not looking into the existing documentation, then I’m having trouble of just reading the code. That means that it’s not descriptive.


What I wanted to compare here was the fact while there are situations where it’s necessary to having documentation while writing code, I don’t think that that’s true for a scripting language. It should be more descriptive so that that much documentation is not even necessary.

To be fair you are right.
There is no wiki because the wiki was taken down for the "Future home of VS"

Problem is its been down for what? 2-3 years now??
And again, all the documentation in VS Github repos just refers to the Avisynth wiki. Either that or there is LITERALLY nothing at all.

And you need to manually open the .py file. Locate definitions decipher functions. Which is not a problem for me. I see the .py as the wiki.

But for most people this is not acceptable or usable at all.
Even then there are no example use cases. Just default values and descriptions of whether its an integer, float. Boolean etc

[Selur]

In my eyes, main points for:

Avisynth: It has tons of documentation and you can find more stuff about it by searching. And it has a ton of users that avused it for years and are willing to help folks out.
Vapoursynth: More growth potential and potentially easier to extend since Python is a rather aproachable language. That stuff folks write for universities often is in Python makes it easier for others to port that stuff to Vapoursynth. The whole pytorch bases stuff really is nice. (lots of thanks to HolyWu for porting stuff)


For me, it looks like in the long run Vapoursynth will be more wide spread than Avisynth, simply because more folks nowadays learn Python.

Cu Selur

[Reclusive Eagle]

Yes vs codes tend to have more characters while comparing, but it is structured, modules, its attributes, it just brings advantages only, when things get heavier. When avisynth becomes more elaborate, scripts become a torture.

I mean people complain about Python "readability" when its their own fault. All they have to do is organize their code and separate them into sections that are most legible to them.



#py imports
import vapoursynth as vs
import havsfunc as haf
import vsutil
import kagefunc as kg
import adjust
import muvsfunc as mv
import edi_rpow2 as edi
import numpy as np
import functools
core = vs.core

#----------------------------------------------------------------------------------------------------------------
#Source Video
clip = core.ffms2.Source(source=r'C:\Users\me\MyVideo.mkv')

#----------------------------------------------------------------------------------------------------------------

"""IVTC"""


#IVTC
clip= core.tivtc.TFM(clip, order=1, field=-1, mode=5, PP=6,micmatching=3)

#Doubles Height of IVTC
clip=core.nnedi3.nnedi3(clip, field=0, dh=True, nsize=4, nns=4, qual=2, etype=0, pscrn=2,exp=2)

#Restore NTSC Framerate
clip= haf.srestore(clip,frate=23.97)

#----------------------------------------------------------------------------------------------------------------

"""3 Pass Denoise"""

#Resize
clip = core.resize.Lanczos(clip, 1440,1080)
clip=core.fmtc.bitdepth (clip,bits=32)

#Reference Denoise
ref = core.dfttest.DFTTest(clip, ftype=1, tbsize=3, nlocation=[35,0,0,10, 28,0,83,87, 95,0,0,100],sigma=10.0,sst=[0.0,2.0, 1.0,20.0], ssystem=1,opt=3)
ref2= core.bm3dcuda.BM3D(clip, ref=ref, sigma=[25,25,25], block_step=3)

#Final Denoise
clip= core.bm3dcuda.BM3D(clip, ref=ref2, sigma=[13,13,13], block_step=3)
clip=core.fmtc.bitdepth (clip,bits=8)

#----------------------------------------------------------------------------------------------------------------

clip.set_output()


Look how easy this is to read now that I have created sections.
Nobody has any questions about what any part of the code does.

You can clearly see what was imported, which section deals with the IVTC, which section deals with denoising etc.
Especially in VS editor the # are gray. The """ """ are red ect.

Anyone who complains about "code looking messy" is because they expect the code to be auto formatted for them like? Tidy your own work

[_Al_]

You can clearly see what was imported
But avisynth users do not want to see what was imported :-), that is an overload for them. Not seeing what part is a part of what does not concern them. They do not want to import too many helper modules (avsi equivalents like in avisynth). If you are a dedicated guy to clean or prepare video, why would you want to be distracted by that. With python , that is a step to a coding, which could be a distraction. Avisynth creators made that nice and simple.

No one can blame anyone, with python you can start to come up with functions, modules, for example, you look for a patterns you can seamlessly use opencv and get a data, but again, that is what avisynth user does not want to hear, it is not a concern. The purpose is to fix video and do it simply.

If I may, I wish avisynth script users start to write arguments with their keys, not just positional arguments, lines like: some_filter(234,3,5,-1, 10) are just a too much a simplification. :-)

[Zarxrax]

Rather than this just being a negative thread about people's problems with vapoursynth, I will offer a few suggestions (to no one in particular)

For Vapoursynth to be as widely used as Avisynth, I think it needs two things:
1. Be easy to learn
2. Be easy to use
These are not necessarily issues with Vapoursynth itself, so much as the ecosystem around it.

Number one is very simple. There needs to be better tutorials. Give me some high quality youtube tutorials, along with an html tutorial. It should be something that I can follow along with. If you search for Vapoursynth on youtube right now, it's mostly a bunch of stuff about making Kpop gifs. It needs to cover everything from installing vapoursynth and plugins, getting vapoursynth into other applications and encoders, as well as covering all the common scripting functions and plugins that people want to use. After that, where do I go when I need help other than the forum here? Is there a vapoursynth discord server?

Number two is more complicated and relates to the experience around writing scripts and using vapoursynth. Vsedit is fine, but doesn't stand up to some Avisynth editors like AvsP. Can't someone port AvsP for Vapoursynth? An editor should also make it easy to do things like encode a sample video, or help with the syntax of the overall script. I would especially like to see more types of editors. A node-based script editor would be amazing!

If people can be onboarded easily and then enjoy the experience of using Vapoursynth, then I think people will use it. Simple as that.

[_Al_]

One important thing, as Reclusive Eagle mentioned,
if seeing those scripts in editors with color code introduced, it is whole different league.

Avisynth users or anyone else can see vapoursynth scripts on this forum and they might freak out. For example Selur posts vapoursynth script nicely properly and whole lot of explanations, including keys for arguments. If seeing it without colors it could be too much, but as soon as it is copy /pasted in color coding editor, that's first thing I do, it is something else.

[_Al_]

testing some color coding:

import vapoursynth as vs
from vapoursynth import core

#importing filepath source
source = core.lsmas.LibavSMASHSource(source='test.mov')

#reizing to 10bit, matrix BT601
vnode = source.resize.Spline36(width=720, height=576, format=vs.YUV420P10, matrix_in_s='709', matrix_s='470bg')

#setting output
vnode.set_output()

hey, it works :-) using [P H P] ... script.... [/P H P] (without spaces) can be used to make it more readable for vaporsynth scripts, it is not ideal, like python editors, but something ..., Selur, wink,wink,nudge,nudge ... :-)

It would be nice to introduce something like ... or ..... to python color code. Is it some plugin for web sites to color code python code instead of using php color coding?

[poisondeathray]

Vsedit is fine, but doesn't stand up to some Avisynth editors like AvsP. Can't someone port AvsP for Vapoursynth? An editor should also make it easy to do things like encode a sample video, or help with the syntax of the overall script. I would especially like to see more types of editors. A node-based script editor would be amazing!

Did you know AvsPMod can open and preview .vpy scripts ?

VSEdit can be setup to encode video

[ChaosKing]

Did you know AvsPMod can open and preview .vpy scripts ?

VSEdit can be setup to encode video
I think it uses VSImport, a vs import plugin. So you still would need avisynth to be installed.

[poisondeathray]

I think it uses VSImport, a vs import plugin. So you still would need avisynth to be installed.

avisynth installed maybe; but if I move VapourSource_x64.dll out of the avs plugins directory , avspmod still works to preview vpy scripts , so it doesn't look like VSImport

[ChaosKing]

I just tried it and it wants VSImport.

EDIT
Ok actually the message is "VSImport failed to initialize VapourSynth". So I guess the problem is something different.

[poisondeathray]

I just tried it and it wants VSImport.

When I use portable vapoursynth, with avspmod excecutable outside of portable environment it requests VSImport

Installed vapoursynth version, seems to work with avspmod without VSImport

[Selur]

While cleaning up a bit I stumbled over some notes about what filters Hybrid users miss in Vapoursynth that prevent them from switchting to Vapoursynth.
Since I had to think about this thread I thought I should post them here.
There are mainly color adjusment related filters:

RGBAdjust
SmoothTweak
AutoAdjust
ChannelMixer
SmoothCurve
ColorBalance
HDR AGC
Checkmate

and a few others:

DeScratch
RemoveDirt (that one actually exists, but I haven't found the time to support it in Hybrid or properly compare it against the AviSynth version)
DeSpot (got on in Hybrid, but it's really limited)
SpotRemover
FRIM


Cu Selur