Vapoursynth

[Myrsloik]

Originally Posted by Chikuzen

on vapoursynth-r6

I found the typo. Instead of height < 0 it checked height < x.

[Myrsloik]

Originally Posted by Reel.Deel

I tried nnedi3 and the deinterlacing part works just fine but nnedi3_rpow2 has a problem.

core.avs.nnedi3_rpow2(c1=src,rfactor=2)

Invoke not fully implemented, tried to call: TurnRight but I will pretend it doesn't exist
Avisynth Error: escaped IScriptEnvironment::NotFound exceptions are non-recoverable, crashing...

I'm assuming other parameters like cshift, fwidth, and fheight will be problematic also.

I'd rather make a proper port of it than make an effort at fully implementing avisynth's invoke functionality including exact copies of the internal functions it calls.

[cretindesalpes]

Anyway the "_rpow2" part is just an avs script written in C++, wrapping nnedi() and other built-in functions, nothing more. So there would be no gain trying to port the dll part over porting the equivalent call sequence in scripted language. Same for eedi3_rpow2.

[Chikuzen]

It seems that the Y4M file header which VapourSynth outputs is not attached 'C'(color) tag.
Since it is inconvenient to output YUV422/444 stuff, please attach it.

[Myrsloik]

Originally Posted by Chikuzen

It seems that the Y4M file header which VapourSynth outputs is not attached 'C'(color) tag.
Since it is inconvenient to output YUV422/444 stuff, please attach it.

Added for all 8bit yuv formats. I guess there's no way to specify 10/16 bit ones.

[Myrsloik]

I've released R7. Changelog in the first post. Download from the website. I've also written a post about what will happen in the immediate future. Discuss it here or in the comment field there.

[mastrboy]

I was just about to ask how many more R# releases we would see before the source became public.
About the licensing, "free for non-commercial use" might scare off some potential developers who use avisynth at work.
I would put my vote for a "free for all usage, source code changes to core (vapoursynth) has to be shared, but plugins can be closed source" kind of license.
(Or something that fits the debian guidelines for open source: http://en.wikipedia.org/wiki/Debian_Free_Software_Guidelines )

[sneaker_ger]

Originally Posted by mastrboy

I would put my vote for a "free for all usage, source code changes to core (vapoursynth) has to be shared, but plugins can be closed source" kind of license.

Yes, I was about to say the same.

[Keiyakusha]

If some company will decide to use vapoursynth to make money, why Myrsloik can't make money on them?

[Myrsloik]

Originally Posted by mastrboy

I was just about to ask how many more R# releases we would see before the source became public.
About the licensing, "free for non-commercial use" might scare off some potential developers who use avisynth at work.
I would put my vote for a "free for all usage, source code changes to core (vapoursynth) has to be shared, but plugins can be closed source" kind of license.
(Or something that fits the debian guidelines for open source: http://en.wikipedia.org/wiki/Debian_Free_Software_Guidelines )

Yes, closed source plugins will of course be allowed. Anything else would just be crazy.
Free is all good and well, but to take this project all the way to where I want it is a bit more complicated.

Let's look at a relevant example: FFMS2
I released it under the MIT license in 2007. It has been about 2 years since I actively did any coding for it myself. Fortunately other people continued to maintain it (see the changelog for a full listing of these nice people), fixing all the api changes in ffmpeg and then the api changes in BOTH ffmpeg and libav. At once. Some bugs got fixed.

But where did the project go? Did it go anywhere? Did any new functionality really get added? Not really as I see it. Most of what end users celebrate are just improvements to libav/ffmpeg.

This brings me to my point. An open source project without a driving force will just sit there. You'll get some bugfixes and not much else. Organic growth and development is good at overcoming small obstacles but in the end directed development is needed to get bigger features. I want this to go further, I want vapoursynth to one day have good GPU support as well. Because without a GPU aware framework avoiding slow up/downloading to the GPU between filters will never be a possibility. In my world a stable CPU only version of vapoursynth is simply the first step. To make my point even more clear, just think about where Avisynth would be without sh0dan or IanB.

So how does this relate to my proposed license? Implementing this will take quite a bit of time. Time is money. Hence my choice to make it free for personal use but ask for a reasonable licensing fee for commercial use.

Note: I know that there is no such legal term as commercial use but there are other ways to state the same idea

[TurboPascal7]

c = vs.Core(accept_lowercase=True)
c.std.loadplugin(path=r'C:\Buf\vapoursynth\ffms2.dll')
ret = c.ffms2.source(source=r"C:\Buf\vapoursynth\sample.mkv")
print(ret.format)

Output with r7:

Traceback (most recent call last):
  File "C:/Buf/vapoursynth/test.py", line 7, in <module>
    print(ret.format)
  File "vapoursynth.pyx", line 202, in vapoursynth.Format.__str__ (cython\vapoursynth.c:3291)
AttributeError: 'str' object has no attribute 'decode'

Works right with r6.

Also, vapoursynth r7 prints the name of every positional argument used to stdout. Looks like someone forgot to remove debug code or something. >__>

[Caroliano]

The most restrictive free software license you can chose is likely is the GNU Affero GPL, and may be a good choice because there is lots of transcoding going on in the ~cloud~. x264 devs apparently managed to get corporate sponsors with GPL, and LuaJIT with the liberal MIT license.

Anyway, the only thing you should not do (besides not releasing the source code ) is create your own open source license. Repositories like Sourceforge and Google Code refuse to host software that are not under a OSI accepted license, exactly to tack on the license proliferation problem.

[Myrsloik]

Originally Posted by TurboPascal7

Also, vapoursynth r7 prints the name of every positional argument used to stdout. Looks like someone forgot to remove debug code or something. >__>

I'v reuploaded R7 with the debug print and .decode stuff fixed.

[Reel.Deel]

Hi Myrsloik, I was wondering if core.list_functions() is the only way to display internal functions.
The reason I ask is because I see people using print(clip.format,clip.width,clip.height) and that does not show up in the core.list_functions().

[JEEB]

Originally Posted by Reel.Deel

Hi Myrsloik, I was wondering if core.list_functions() is the only way to display internal functions.
The reason I ask is because I see people using print(clip.format,clip.width,clip.height) and that does not show up in the core.list_functions().

Print is a standard Python function. Now we have the power of a whole scripting language as well at our hands

[Reel.Deel]

Ahhh, I see. I guess after work I will be doing some reading. Thanks JEEB.

[gyth]

(unfortunately python itself has one huge mutex called the GIL so if it’s used too much it could lead to serious slowdowns)

The GIL is part of the threading module.
There is also a multiprocess module.

I haven't used either so it might be a non solution as well.

[Chikuzen]

If I type 'print(clip.format)' to Python shell, it will be displayed as follows.

Id: 3000024
Name: YUV444P16
Color Family: YUV

But, 'print(help(vs))' says as follows.

Yuv = 3000000
Yuv410P8 = 3000013
Yuv411P8 = 3000014
Yuv420P10 = 3000019
Yuv420P16 = 3000022
Yuv420P8 = 3000010
Yuv420P9 = 3000016
...

This is troublesome.
According to PEP8, you should unify all the constant names with the capital letter.

[Myrsloik]

Originally Posted by Chikuzen

If I type 'print(clip.format)' to Python shell, it will be displayed as follows.


But, 'print(help(vs))' says as follows.

This is troublesome.
According to PEP8, you should unify all the constant names with the capital letter.

Will change it in the next version.

[TheProfileth]

Originally Posted by gyth

The GIL is part of the threading module.
There is also a multiprocess module.

I haven't used either so it might be a non solution as well.

Hmm after a cursory glance over some of the stuff in there it is pretty interesting. I wonder if Myrsloik had already considered that method?
In an only semi-related question, it has been established that some form of multithreading will be used, but is the multithreading going to be only in the vapoursynth core or independently implemented into individual filters or both or what?
Sorry if this has been covered already just have been under the assumption that vapoursynth itself is multithreaded but individual filters will need to be programmed to support multithreading and I wanted to be clear if this has already been discussed.