Vapoursynth

[Guest]

However, DGMPEGDec can't be used because it requires avs internal crop function.
I can make a version without internal cropping if you like.

[Reel.Deel]

I can make a version without internal cropping if you like.

Please do. That would be very nice. Thanks neuron2!

[wOxxOm]

Regarding updating of avisynth plugins: as far as I can see, it's possible to make them native vapoursynth plugins by providing _VapourSynthPluginInit in addition to _AvisynthPluginInit2, so what are the benefits in general?

[Keiyakusha]

Also, I'm happy to see DGIndexNV work on Vapoursynth. :)
I don't understand why you need DGIndexNV if you have FFMS2 (which is free and awesome). if you have not very ancient CPU, nvidia decoding is not faster at all and not safe with more than one instance (or if you use some memory eating gpu filters). What are other possible benefits?

However, DGMPEGDec can't be used because it requires avs internal crop function.
I used TS2AVI/MPEG2Dec3k after a long time...

When and what for if uses crop? You mean DgdecNV when decoding 1080p blu-ray? It should be possible to disable crop so it will output 1920x1088.
On the other hand DGMPEGDec Is what I'd like to see too. Not that it is irreplaceable, I'm just so used to it...

[TheFluff]

Regarding updating of avisynth plugins: as far as I can see, it's possible to make them native vapoursynth plugins by providing _VapourSynthPluginInit in addition to _AvisynthPluginInit2, so what are the benefits in general?

Native VS plugins can:
- interact directly with the VS thread pool (= potentially better multithreading performance, may require some work on the plugin though)
- support high bitdepth colorspaces (and some other exotics such as planar RGB) natively
- store arbitrary per-frame metadata (such as VFR timestamps) without having to resort to hiding it in obscure ways (the decomb/tfm hinting information is one example of plugins doing that)

[mandarinka]

Isn't FFMS2 (because of limitations in libavcodec) unable to properly decode interlaced h.264 streams? (At least when muxed in TS.) IIRC it also had problems with VC-1 streams.

[Myrsloik]

Regarding updating of avisynth plugins: as far as I can see, it's possible to make them native vapoursynth plugins by providing _VapourSynthPluginInit in addition to _AvisynthPluginInit2, so what are the benefits in general?

Unless you're willing to do a bit of extra coding, or at least code auditing, none. Here are some of my observations from looking at filter code about what different things you could expect:
1. Several filters use planar YUV422 internally and have to pack and unpack. These could quite easily be changed to directly accept planar YUV for a small speedup for YUY2.
2. Many of the same filters in category one are quite general and probably could be extended to full resolution planar YUV support at least with a bit more effort.
3. Native filters can select their best threading model. For example a filter like ColorMatrix probably never updates its conversion tables after initialization so they're safe to share. This means that the filter can be run on several frames in parallel.
4. If you lay off the inline assembler (you can still use yasm+that magic x264 asm.inc file) your plugins will work and compile on every civilized desktop OS from a single codebase.
5. No more hacks.

[Reel.Deel]

I don't understand why you need DGIndexNV if you have FFMS2. if you have not very ancient CPU, nvidia decoding is not faster at all and not safe with more than one instance. What are other possible benefits?

I was just trying it out to see if it worked. Also IIRC FFMS2 was not frame accurate with VC-1 and and did not like interlaced H.264 (don't know if that's still the case).
Futhermore, I have a handfull of blu-rays that the movie is cut up into a 100+ segments and it's very easy just to drag the mpls onto DGIndexNV and index the entire movie. BTW I do have an ancient CPU (not for long) :).

[Keiyakusha]

it's very easy just to drag the mpls onto DGIndexNV and index the entire movie.
Hmm, didn't know that. I had impression that it only can work with single segment at one time or something like that. Maybe will try it someday.(I, as many others I guess, just remux the movie first, to make it one) Interlaced streams maybe true. I never saw any interlaced bluray though (or tv broadcasts that is not mpeg2)

[hajj_3]

uk tv show blurays are 1080i for uk created tv shows.

[Guest]

Also remember that DGDecNV can use the GPU for deinterlacing/resizing and that can bring a substantial speedup. Sure it's not QTGMC but the quality is pretty good and so offers a useful performance point. DGDecNV can load multiple files (including automatically from an MPLS playlist file); it's the old DGAVCDec that could open only one file.

Regarding DGMPGDec, it contains an internal Invoke call, which I assume is the source of the problem with Vapoursynth. I'd like to understand the problem better though. Is it only an issue for 1088 streams that get cropped automatically to 1080? Obviously we can't enable cropping in the GUI as that will trigger an Invoke("crop") in DGDecode, but if we have a non-1088 stream with no cropping enabled in the GUI does everything work?

[Reel.Deel]

I tried DGMPGDec with a true 1080 stream (cropping disabled) and it gave me the following error:
Invoke not fully implemented, tried to call: crop but I will pretend it doesn'texist
Avisynth Error: escaped IScriptEnvironment::NotFound exceptions are non-recoverable, crashing...

BTW the file I used was 1080 not 1088.

*edit*

Just to be sure I tried DGMPGDec (same settings as before) with both a NTSC DVD stream and a 720p60 stream and they both worked. :)

[Guest]

Yes, I know about the automatic 1088->1080 issue!

I'm asking if it fails when we don't have that case. Try an SD stream for example, with no cropping enabled in the GUI.

[tebasuna51]

Just yesterday I make some test with r3.

With r5 (I never can download r4):

Python 3.2.3 (default, Apr 11 2012, 07:15:24) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import vapoursynth as vs
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: DLL load failed: No se puede encontrar el módulo especificado.

XP SP3 without changes from yesterday.
Reload r3 and work fine.

[Reel.Deel]

Had the same problem yesterday. Try re-downloading r5 again and re-replace the binaries. It worked for me.

[Myrsloik]

Just yesterday I make some test with r3.

With r5 (I never can download r4):



XP SP3 without changes from yesterday.
Reload r3 and work fine.

Did you download it within one hour of release? I forgot to select static linking and silently updated it.
If not I have no idea why you're getting that error since no dependencies have changed.

[Guest]

BTW the file I used was 1080 not 1088. No, it's coded as 1088. DGIndex hides that from you. It it were not coded as 1088, then the Invoke() call would not be made. If you are still adamant that it is 1080, then please post a sample.

Just to be sure I tried DGMPGDec (same settings as before) with both a NTSC DVD stream and a 720p60 stream and they both worked. :) OK, sweet, thank you.

[tebasuna51]

Did you download it within one hour of release? I forgot to select static linking and silently updated it.

Thanks, now work r5.

[06_taro]

Did some tests, and *.avs.MPEG2Source(d2v=r"d2vpath") works for SD sources.

BTW, I encountered "QWaitCondition: Destroyed while threads are still waiting" when finishing a session if I use Core() instead of Core(threads=1). Only occurs in r5.

[Myrsloik]

Did some tests, and *.avs.MPEG2Source(d2v=r"d2vpath") works for SD sources.

BTW, I encountered "QWaitCondition: Destroyed while threads are still waiting" when finishing a session if I use Core() instead of Core(threads=1). Only occurs in r5.

That warning is harmless. It's just that I haven't made the destruction of the threadpool completely correct.

[wOxxOm]

ok, I've ported (http://www.privatepaste.com/db2acec810) avisynth's YAHR (http://avisynth.org/mediawiki/YAHR) to vapoursynth, apparently p lame as it uses only 30% cpu (20% in yahrmask), so what are the guidelines to paralellize spatial processing with these widely used avisynth plugins in vapoursynth/python? Or probably the more actual question is how to parallelize it when there are temporal filters like tdecimate?

[Myrsloik]

ok, I've ported (http://pastebin.com/vuHjKtaK) avisynth's YAHR (http://avisynth.org/mediawiki/YAHR) to vapoursynth, apparently p lame as it uses only 30% cpu (20% in yahrmask), so what are the guidelines to paralellize spatial processing with these widely used avisynth plugins in vapoursynth/python? Or probably the more actual question is how to parallelize it when there are temporal filters like tdecimate?

Do you get any warnings about frames not being prefetched? And can you share your converted script and the exact plugisn you used an I will take a look at it.

[Guest]

Invoke not fully implemented, tried to call: crop but I will pretend it doesn'texist
Avisynth Error: escaped IScriptEnvironment::NotFound exceptions are non-recoverable, crashing... Does this mean that Vapoursynth took an exception or DGDecode took an exception? Does Vapoursynth return an error for my Invoke call? It would be nice if it could simply be ignored. I'm not sure though who should do the ignoring. Thank you.

[Myrsloik]

Does this mean that Vapoursynth took an exception or DGDecode took an exception? Does Vapoursynth return an error for my Invoke call? It would be nice if it could simply be ignored. I'm not sure though who should do the ignoring. Thank you.

All crop calls will simply be ignored and the clip passed through in the next version. So far the strategy is to either just pass through a clip (Cache, InternalCache, and Crop in the next version) or simply throw the IScriptEnvironment::NotFound exception (just like avisynth does when a function doesn't exist), which no plugin is prepared to handle for such a basic function so it escapes out out the plugin.

[wOxxOm]

Do you get any warnings about frames not being prefetched?Yeah, every frame outputs 'Avisynth Compat: requested frame #### not prefetched, using slow method that may deadlock'

And can you share your converted script and the exact plugisn you used an I will take a look at it.I've added it in that message above under 'ported', and oh well here: the script (http://www.privatepaste.com/db2acec810) and plugins (http://puu.sh/13T0Q). Any SD DVD content will do, I suppose.

[Myrsloik]

Yeah, every frame outputs 'Avisynth Compat: requested frame #### not prefetched, using slow method that may deadlock'

I've added it in that message above under 'ported', and oh well here: the script (http://pastebin.com/vuHjKtaK) and plugins (http://puu.sh/13T0Q). Any SD DVD content will do, I suppose.

It's caused by TDecimate. When an avisynth plugin doesn't have a proper list of frames to prefetch it can become very slow. It's a known issue and I'll poke it some more. Did you try yahr by itself?

[wOxxOm]

Did you try yahr by itself?
yes, 32% cpu for mpeg2source+yahr. That is 2% more...
I'd try on a synthetic BlankClip but unlike avisynth's it cannot _create_ new clips, though probably it won't influence the result since freezing one frame doesn't change much except there is no 'frame not prefetched' message: v = yahr (core.std.loop (clip=core.std.trim (clip=v, first=1000, length=1), times=500))

Also lack of chaining makes stuff look obscure (not using 'code' tag as a line this long breaks layout of whole page):

core.avs.mt_makediff (c1=clip, c2=core.avs.removegrain (c1=core.avs.removegrain (c1=core.avs.removegrain (c1=clip, mode=11, modeU=rg11), mode=20, modeU=rg20), mode=20, modeU=rg20), U=uv2, V=uv2)

vs

mt_makediff (clp,clp.removegrain(11,rg11).removegrain(20,rg20).removegrain(20,rg20),U=uv2,V=uv2)

Currently to keep it obvious one needs to serialize calls like this:

v = core.avs.removegrain(c1=clip,mode=11,modeU=rg11)
v = core.avs.removegrain(c1=v,mode=20,modeU=rg20)
v = core.avs.removegrain(c1=v,mode=20,modeU=rg20)
v = core.avs.mt_makediff(c1=clip,c2=v,U=uv2,V=uv2)

[Myrsloik]

yes, 32% cpu for mpeg2source+yahr. That is 2% more...
I'd try on a synthetic BlankClip but unlike avisynth's it cannot _create_ new clips, though probably it won't influence the result since freezing one frame doesn't change much except there is no 'frame not prefetched' message: v = yahr (core.std.loop (clip=core.std.trim (clip=v, first=1000, length=1), times=500))


Uh, exactly how did you measure it? on my computer it at least reaches 90% on all 4 cores when simply having a quick look at the task manager.

[wOxxOm]

Uh, exactly how did you measure it? on my computer it at least reaches 90% on all 4 cores when simply having a quick look at the task manager.Task manager too, i7, 8 cores (4 with HT). Changing threads= parameter in Core() has no effect.

[Myrsloik]

Task manager too, i7, 8 cores (4 with HT). Changing threads= parameter in Core() has no effect.
How do you run the script? I always output to stdout and then do
Python test.py > NUL

[wOxxOm]

yeah, either that or simply v.output(open(os.devnull,'w'))
it works ~10% faster than exactly the same script in avisynth though, where it consumes only 12.5% cpu (1/8 of 100% btw) which is about 2 times less.

[Myrsloik]

Then I have no idea what makes our results so different.
Anyway, expect an update tomorrow with various minor fixes and maybe some new functionality. Dither mvtools and dgmpgdec have been fixed already.

[Keiyakusha]

Anyway, have some performance comparisons from r3 while you wait:
Avisynth 2.5.8
$ time avs2yuv.exe test.avs - > NUL
test.avs: 640x368, 24000/1001 fps, 5000 frames

real 1m23.680s
user 0m0.000s
sys 0m0.015s

VapourSynth r3:
$ time /c/Python32/python.exe test.py > NUL

real 0m23.753s
user 0m0.015s
sys 0m0.000s


Always wanted to ask but keep forgetting every time. This was measured with exactly what mvtools version? and avisynth 2.5.8 was multithreaded or not?

For example for me using single-threaded avisynth with normal mvtools I get speed X. Using Dither-mvtools it can be up to 2X.
But using multithreaded avisynth with 4 threads, SVP-mvtools (just their mvtools, not the actual SVP with GPU vector search) performs even faster than Dither-mvtools at same 4 threads, twice as fast.

[Myrsloik]

Always wanted to ask but keep forgetting every time. This was measured with exactly what mvtools version? and avisynth 2.5.8 was multithreaded or not?

For example for me using single-threaded avisynth with normal mvtools I get speed X. Using Dither-mvtools it can be up to 2X.
But using multithreaded avisynth with 4 threads, SVP-mvtools (just their mvtools, not the actual SVP with GPU vector search) performs even faster than Dither-mvtools at same 4 threads, twice as fast.

It was measured with the single threaded avisynth 2.5.8. The only version I think is good enough for general use. I used the official build of mvtools from fizicks website. Feel free to compare anything you want and post here. I still think it's interesting to see how vapoursynth compares to avisynth Messy Threads.

[Myrsloik]

R6 is here. It fixes several avisynth compatibility issues, most notably dither mvtools and dg decoding stuff.

[sneaker_ger]

Will VapourSynth be video-only?

[Myrsloik]

Will VapourSynth be video-only?

Yes, unless someone is willing to pay me to implement a similar companion module for audio.

[Chikuzen]

on vapoursynth-r6

>>> import vapoursynth as vs
>>> c = vs.Core()
>>> c.avs.LoadPlugin(path='rawsource.dll')
>>> clip = c.avs.RawSource(file='soccer.y4m')
>>> print(clip.width, clip.height)
704 576
>>> cropped = c.std.CropAbs(clip=clip, x = 0, y = 0, width=320. height=240)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "vapoursynth.pyx", line 507, in vapoursynth.Function.__call__ (cython\vapoursynth.c:8864)
vapoursynth.Error: 'CropAbs: negative cropping dimensions not allowed'
>>> cropped = c.std.CropAbs(clip=clip, x = 0, y = 0, width=-320. height=-240)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "vapoursynth.pyx", line 507, in vapoursynth.Function.__call__ (cython\vapoursynth.c:8864)
vapoursynth.Error: 'CropAbs: negative cropping dimensions not allowed'
>>> cropped = core.std.CropAbs(clip=clip, x=0, y=0, width=320, height=-240)
>>> print(cropped.width, cropped.height)
320 -240


:confused::confused::confused::confused::confused::confused::confused::confused::confused::confused::confused:

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

[06_taro]

nnedi3_rpow2 internally invokes AviSynth's resize filter, which cannot be used in VapourSynth.

[Myrsloik]

on vapoursynth-r6
:confused::confused::confused::confused::confused::confused::confused::confused::confused::confused::confused:

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

[Myrsloik]

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]

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 (http://www.vapoursynth.com/2012/09/r7-the-source-is-slowly-coming/) 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]

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]

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