Vapoursynth

[Myrsloik]

R14 is out. It's mostly some much needed bugfixing and installer improvements. If you use VSFS it has to be registered again because it's now installed into a slightly different path.

And remember to check out the SDK and try to port your favorite filter from avisynth to help make the project a success.

The bloggy post (http://www.vapoursynth.com/2012/10/r14-improved-packaging/) as usual.

[Mug Funky]

how would one go about opening up temporalsoften to allow arbitrary colourspaces? i gitted the code but remembered as i looked through it that i don't know how to program in C.

[jackoneill]

how would one go about opening up temporalsoften to allow arbitrary colourspaces? i gitted the code but remembered as i looked through it that i don't know how to program in C.
Which ones do you need? Maybe I'll add support. Or maybe not. Who knows...

[Mug Funky]

i was thinking at least on principle it could be adapted to any colourspace, as the native avs one works in rgb and yuv.

specifically, it would be awesome to have 16 bits so i can apply it to linear light and emulate a true motion-blur with it :)

[edit] btw, it goes without saying, but saying is always nicer: thanks for your work on porting from avisynth :) it's an exciting time with vapoursynth at the moment, as it looks like it could really reinvigorate the video-script concept. alas, i need to spend a bit of time learning C, and i don't really have much of that :( i'll share any functions i apply other people's plugins to, of course.

[Myrsloik]

i was thinking at least on principle it could be adapted to any colourspace, as the native avs one works in rgb and yuv.

specifically, it would be awesome to have 16 bits so i can apply it to linear light and emulate a true motion-blur with it :)

[edit] btw, it goes without saying, but saying is always nicer: thanks for your work on porting from avisynth :) it's an exciting time with vapoursynth at the moment, as it looks like it could really reinvigorate the video-script concept. alas, i need to spend a bit of time learning C, and i don't really have much of that :( i'll share any functions i apply other people's plugins to, of course.

Do try to learn c. There are quite a few simple tasks that need to be done too. Such as ports of some of the popular internal avisynth filters or adding override file support to vivtc.
I have quite a few tasks in mind at different difficulty levels for those who want to try their luck or learn something.
Just send me a message here or find me on irc (usually in #avisynth on freenode).

At the moment I'm porting avisource which I'll probably post a first test version of tomorrow.
If there's any interest I'll make the source available for an intermediate step in the porting too. An avisynth avisource with the latest vdub parser. It could be useful to merge back into the avisynth tree... maybe.

[Mug Funky]

if human beings could execute in parallel, and i got myself an upgrade, i'd be on it in a flash.

as it happens, tasks exist in parallel but capability is single-threaded. gotta balance day job, housekeeping, side business, plus baby with one more coming in april :)

though if there's some good learning resources out there that assume no programming knowledge (i fear the visual basic and actionscript i learnt back in the day might have been equivalent to negative learning as far as programming practice goes), i'll jump on them and take my first steps. i figure if programmers can do it, it can't be that hard, but i need to learn in between tasks, which reduces the utility of most noob guides out there.

[JEEB]

though if there's some good learning resources out there that assume no programming knowledge (i fear the visual basic and actionscript i learnt back in the day might have been equivalent to negative learning as far as programming practice goes), i'll jump on them and take my first steps. i figure if programmers can do it, it can't be that hard, but i need to learn in between tasks, which reduces the utility of most noob guides out there.
For C I now dearly recommend Zed A. Shaw's freely available Learn C The Hard Way (http://c.learncodethehardway.org/book/). It gets you right into the usual development cycle with Makefiles, a compiler and valgrind. Unfortunately Valgrind is only for *nix for now, so Windows users won't be able to get its wonderful output.

For editor I kind of recommend Qt's Qt Creator. It does have many advanced features as an IDE, but it lets you "just open files" in it (and edit things rather straightforwardly, which is not something that all high-level development environments can boast with *cough*MSVS*cough*), and has nice header parsing capabilities :) Now if I only could find a way to set it not use CRLF endlines on Windows... ^^;

[mandarinka]

as it happens, tasks exist in parallel but capability is single-threaded. gotta balance day job, housekeeping, side business, plus baby with one more coming in april :)

Ah, just forget programming/open source contributing. Other people can do that /especially since you would have to learn C too = the ones already knowing it can do the job much more efficiently = you will be wasting your time/. Also, in 5-10 years, your code is going to be obsolete and long replaced anyway. Little point in spending precious time on that.

At the same time, nobody is going to substitute you for your kids. IMHO, just leave the unimportant matters to the internets and focus on family :)

[Chirico]

Other people can do that /especially since you would have to learn C too = the ones already knowing it can do the job much more efficiently = you will be wasting your time/.

What a terrible attitude. You could have said that about anyone wanting to learn C for the last 3 decades. Heck, you could say that about learning any skill. There will always be people who are better at some skill than you. Doesn't mean it's a "waste of time" to learn something just because you aren't going to be a guru.

Also, in 5-10 years, your code is going to be obsolete and long replaced anyway. Little point in spending precious time on that.

Yeah, right. Code lives around for decades good or bad. In most cases, people don't want to put in the effort to rewrite or replace things as long as it works. This is true whether it's an open source project or not. One only has to look at the cruft built up in projects like Avisynth, ffdshow, or some the more bizarre and byzantine code sections in ffmpeg/libav that almost no one wants to touch despite people repeatedly talking about how it needs to be rewritten.

[mandarinka]

Look at your examples - Vapoursynth is going to replace Avisynth. FFDshow is likely going to be replaced by LAV Video/Audio. Code in ffmpeg/libav gets rewritten all the time, just not the real arcane parts they are scared of (it's almost as if they focused on polishing the chrome so as to not have free time for the hard parts, haha </troll>).

But that's not important - in the end he has a family. Better if people with free time that is less precious volunteer. (Anyway, we should probably drop this not exactly on-topic discussion).

Edit - (@Chirico)
So basically your point is that he should neglect his children and instead learn programming languages so that he can invest his time into serving your interest in a random video editing software? (Funny how you are requesting that with a moralising tone, though.)

[Chirico]

Look at your examples - Vapoursynth is going to replace Avisynth. FFDshow is likely going to be replaced by LAV Video/Audio.

It's quite unlikely that Avisynth or ffdshow will be fully replaced any time soon. Tons of people will still use them and will continue to do so. And so what if the code, if Mug Funky chooses to write some, gets replaced or rewritten? If he got enjoyment/use out of it along with others why attempt to discourage the endeavor?

Code in ffmpeg/libav gets rewritten all the time, just not the real arcane parts they are scared of (it's almost as if they focused on polishing the chrome so as to not have free time for the hard parts, haha </troll>).

Many parts are constantly being cleaned up and optimized. Hardly any pieces are routinely being rewritten from scratch.

But that's not important - in the end he has a family.

Yeah, and? I have a family, too, and so do plenty of open source volunteers. I'm failing to grasp what your point can possibly be unless you think Mug Funky is not a mature adult who can manage their life properly.

Better if people with free time that is less precious volunteer.

What a bizarre attitude. Volunteering your time to work on hobby projects does not mean your free time is somehow not precious. If the person wants to learn C to do hobbyist development let them do so without being piled on about how it's a waste of their time.

Edit to add: Yes, this is OT and I'll drop it, but it's disheartening to see someone told they shouldn't do something because some random person on the Internet thinks its a waste of that person's time.

[Myrsloik]

Here's a test version of my "port" of avisource. There's really not much left of the original code anymore. It should work ok and be able to open avi, vpy and avs files. There are some issues with v210 and b48r input which will be fixed.

download (https://dl.dropbox.com/u/73468194/avisource.dll)

Usage: core.avisource.AVISource('blah.avi')
Has about the same options as in avisynth

[Mug Funky]

@ JEEB: thanks for the links. i'll check them out when i can. i might make a functional equivalent of temporalsoften as a first project, but written from scratch so i don't have to worry about figuring out which parts are bit-depth specific or are achieved using bitwise trickery. even experienced programmers find other people's code to be gobbledygook...

@ everyone else: lolfest. sorry about the OT derailment - hopefully my next posts will be more useful to the discussion. perhaps i'll teach my son to program in C and learn it while doing so :) chances are he'll be more interested in breaking stuff though.

[edit]

@ Myrsloik: avisource seems to work nicely. cool.

[Robert Martens]

Please excuse me if I'm just looking in the wrong place, but what does everyone recommend for testing a filter's proper function with the various colorspaces offered by Vapoursynth? I've got an Avisynth plugin of mine working in VS with most of the 8 and 16 bit YUV formats, and I can set up the Visual Studio debugger to launch either VirtualDub or MPC-HC (with madVR) to display the output of a test script, but things like Grey16, YUV444P16, and all of the RGB formats are presenting a problem.

Take this script, for example:

import vapoursynth as vs
import sys

core = vs.Core()

core.avs.LoadPlugin(path=r'C:\Program Files (x86)\AviSynth 2.5\plugins\ffms2.dll')

ret = core.avs.FFVideoSource(source=r'DVfulliNTSC.avi', colorspace="YV12")

ret = core.resize.Bicubic(ret, format=vs.RGB24)

last = ret

VirtualDub returns the error "Avisynth open failure: VFW module doesn't support RGB24 output", MPC-HC shows the Vapoursynth error screen (ten seconds of red, green, and blue bars in RGB32), and if I swap the last line of the script with

ret.output(sys.stdout, y4m=False)

and attempt to pipe the script to x264, I get an error from swscaler, "gbrp is not supported as output pixel format". I take it I can't use the resizers' colorspace conversion option to turn my YV12 clip into Planar RGB, but even if I manage to find or generate a test clip that's natively stored in that format, how might I get it into Vapoursynth, through my plugin, and out to a program that can display it?

I've read through the thread, the VS documentation, and some of the source code, but I haven't found anything to tip me off to the right approach here.

[Reel.Deel]

I don't know if this is correct but try using this for RGB output. It works. :)

src = core.resize.Bicubic(src, format=vs.COMPATBGR32)
src = core.std.FlipVertical(src) # When I tried I needed this, not sure if you will too
edit:
I only tried this with VFW.

[Robert Martens]

Ah, damn it, I had it all so clear in my mind I forgot no one else will know what I was trying to do; I'm planning to implement planar RGB processing in my plugin, so I need to get a planar clip from somewhere (in this case by trying to convert a YV12 video), pass it into my plugin, then send it out to some application so I can see if I'm doing everything correctly. The script I posted is pared down from what I had been using, in an attempt to remove my own code from the equation for troubleshooting purposes. I figured I should start by confirming whether or not I can even view planar RGB output in the first place, before worrying about my own processing.

I have tried your suggestion, though, converting to the BGR32 compatibility format before the final output, but I get an access violation from VDub when doing so, the call stack in the report being:

736c2b75: MSVCR100!strncpy [736c0000+2ad0+a5]
6a41600f: vapoursynth!0000600f
6a41d3f5: vapoursynth!_getVapourSynthAPI@4 [6a410000+74d1+5f24]
66a2678c: QtCore4!?start@QThread@@QAEXW4Priority@1@@Z [66a00000+25fc0+7cc]
66aedef9: QtCore4!??0QAbstractEventDispatcher@@IAE@AAVQAbstractEventDispatcherPrivate@@PAVQObject@@@Z [66a00000+edec0+39]
66a237b5: QtCore4!?currentThread@QThread@@SAPAV1@XZ [66a00000+237b0+5]
66a25b49: QtCore4!?setTerminationEnabled@QThread@@KAX_N@Z [66a00000+25b20+29]
66a25f93: QtCore4!?setPriority@QThread@@QAEXW4Priority@1@@Z [66a00000+25c60+333]
7371c556: MSVCR100!_endthreadex [736c0000+5c51c+3a]
7371c600: MSVCR100!_endthreadex [736c0000+5c51c+e4]
751633aa: kernel32!BaseThreadInitThunk [75150000+13398+12]
77039ef2: ntdll!RtlInitializeExceptionChain [77000000+39e8f+63]
77039ec5: ntdll!RtlInitializeExceptionChain [77000000+39e8f+36]

If I remove the initial conversion to planar RGB24, your suggestion works to display the clip as RGB, so I take it that's where the issue lies; I suppose the only answer is to get my hands on a clip that's actually stored as planar RGB, run it through my plugin, and convert to another format on output for preview purposes.

Why I didn't actually try doing that before posting here, I honestly can't say. I guess I'm dumb.

[jackoneill]

i was thinking at least on principle it could be adapted to any colourspace, as the native avs one works in rgb and yuv.

specifically, it would be awesome to have 16 bits so i can apply it to linear light and emulate a true motion-blur with it :)
TemporalSoften now takes up to 16 bits per sample YUV, RGB and Gray. Testing welcome.
Like in the avisynth version, scenechange is not available with RGB input. I'll have to think about that one.

[TheProfileth]

So, I think someone has probably thought this somewhere along the line. When does Vapoursynth get its own sub forum on doom9? Also just wanted to say great job everyone for picking up vapoursynth and running with it, I am sure that by one year's time Vapoursynth will be the predominate non-linear access video filtering suite.

[qyot27]

Since some more options for source filters have arrived, I can now verify that the crash I saw occurring after 99 frames are piped from VapourSynth on Windows is definitely not in my build of FFMS2 (nor was it fixed in the release of R14). I just tested both the MSVC and MinGW builds of the D2VSource filter (http://forum.doom9.org/showthread.php?t=166399), the AVISource port, and even DGDecode.dll itself: the crash still occurs, and at the same 99 frames point.

Would CPU instructions be a possible cause of this? It's been the one I've wondered about for a while, since my processor doesn't have SSE2 and that seems to be the most common issue that arises when it's instruction set related. Dunno why it would suddenly kick up a fuss at ~100 frames in, though. If the build system optimizes for this during the compilation process, that could explain why my Linux builds of VapourSynth don't exhibit it (unless it's actually some kind of Windows-specific problem that just happens to get exposed because of my ancient hardware).

[Reel.Deel]

@ Myrsloik
I was testing out AVIsource with a 4:2:0 UTVideo compressed source and I noticed it was decompressing to YV16. I added the pixel_type="YV12" and VDub gives me the following error:
Avisynth open failure:
Python exception: "AVISource: the video decompressor couldn't produce YV21 output"
Also if I change pixel_type to YV16, the error is ...."couldn't produce YV61 output"

This is the script (vpy) I used:
import vapoursynth as vs
core = vs.Core()
core.std.LoadPlugin(path=r'C:\Vapoursynth\avisource.dll')
src = core.avisource.AVISource(path=r'D:\TS.avi', pixel_type="YV12", fourcc="ULY0")
last = src

[Myrsloik]

I typoed the fourccs for yv12 and yv16. Get an updated dll here (https://dl.dropbox.com/u/73468194/avisource.dll). (completely untested but at least the code is less wrong now)

[hajj_3]

there is a new build of x264 out (v2230), there is a change in there for vapoursynth:

commit 28ddb0dd533154b58f9147932fb1dec4c74127c8 r2226
Author: Jan Ekström <jeebjp@gmail.com>
Date: Sun Oct 7 21:12:05 2012 +0300

Add support for the ffmpeg/vapoursynth high bit depth y4m extensions

[Mug Funky]

i'm having an issue with building luts for use with... Lut.

anything over 8 bits is taking a phenomenally long time to build. is it a python limitation or a bug somewhere?

check:

ret = core.resize.Lanczos(clip=ret,format=vs.YUV422P16)

luty = []
for x in range(2**ret.format.bits_per_sample):
x = float(x / 2**ret.format.bits_per_sample)
x = 10 ** x
x = x - 1
x = x * (.112 * 2**ret.format.bits_per_sample)
x = int(x + .5)
x = max(min(x,2**ret.format.bits_per_sample - 1),0)
luty.append(x)

ret = core.std.Lut(clip=ret,lut=luty,planes=0)

there's source stuff there of course - this is the relevant snippet. when the resize line is set to YUV422P8 all is fine, but P10 or P16 seem to never give an output (i've had vdub open for 10 minutes on a 16 bit one). 65536 values doesn't seem too big to me.

btw, this is an attempt to undo a lin-to-log, eventually apply a temporalsoften, then apply a lin-to-log to allow me to output 10 bit motion-blurred log files from an 8-bit log source (a canon 550D set to 720p60). if i can make it work, then i can almost shoot with the dynamic range of film on my cheapie DSLR...

[StainlessS]

I dont understand Python but it might be a bit quicker if you precalculated eg "2**ret.format.bits_per_sample" rather than doing it time and time
again.
Also, "luty.append(x)" looks like it is doing a lot of reallocating memory, copying existing contents and then adding another. (unless is linked list).

EDIT: Perhaps something like:


SZ=2**ret.format.bits_per_sample
Q=.112 * SZ
Z=SZ-1
luty = [SZ]
for i in range(SZ): # Maybe SZ should be Z here
x = float(i / SZ) # Maybe SZ should be Z here
x = 10 ** x
x = x - 1
x = x * Q
x = int(x + .5)
x = max(min(x,Z),0)
luty[i]=x

ret = core.std.Lut(clip=ret,lut=luty,planes=0)


You've used x as both for loop index and as a temp variable, hence the main problem, where would loop 4E4 (forever).

[Chikuzen]

I tried as follows

>>> import vapoursynth as vs
>>> core = vs.Core()
>>> core.std.LoadPlugin('G:/vsplugins/vsrawsource.dll')
>>> clip = core.raws.Source('D:/source/sample.y4m')
>>> clip = core.resize.Point(clip, format=vs.YUV420P16)
>>> luty = [x for x in range(2 ** 16)]
>>> clip = core.std.Lut(clip, luty, 0)

and Python shell was freezed.
so, this may be a bug.


Also, "luty.append(x)" looks like it is doing a lot of reallocating memory, copying existing contents and then adding another. (unless is linked list).
This is nonsence.
this processing does not take 1 second in total.

[Myrsloik]

i'm having an issue with building luts for use with... Lut.

anything over 8 bits is taking a phenomenally long time to build. is it a python limitation or a bug somewhere?

check:

ret = core.resize.Lanczos(clip=ret,format=vs.YUV422P16)

luty = []
for x in range(2**ret.format.bits_per_sample):
x = float(x / 2**ret.format.bits_per_sample)
x = 10 ** x
x = x - 1
x = x * (.112 * 2**ret.format.bits_per_sample)
x = int(x + .5)
x = max(min(x,2**ret.format.bits_per_sample - 1),0)
luty.append(x)

ret = core.std.Lut(clip=ret,lut=luty,planes=0)

there's source stuff there of course - this is the relevant snippet. when the resize line is set to YUV422P8 all is fine, but P10 or P16 seem to never give an output (i've had vdub open for 10 minutes on a 16 bit one). 65536 values doesn't seem too big to me.

btw, this is an attempt to undo a lin-to-log, eventually apply a temporalsoften, then apply a lin-to-log to allow me to output 10 bit motion-blurred log files from an 8-bit log source (a canon 550D set to 720p60). if i can make it work, then i can almost shoot with the dynamic range of film on my cheapie DSLR...

I found the typo in the 9-16 bit code. It entered an infinite loop. Now it takes under a second for a 16bit lut on my computer.

[StainlessS]

EDIT: Perhaps something like:


SZ=2**ret.format.bits_per_sample
Q=.112 * SZ
Z=SZ-1
luty = [SZ]
for i in range(SZ): # Maybe SZ should be Z here
x = float(i / SZ) # Maybe SZ should be Z here
x = 10 ** x
x = x - 1
x = x * Q
x = int(x + .5)
x = max(min(x,Z),0)
luty[i]=x

ret = core.std.Lut(clip=ret,lut=luty,planes=0)


You've used x as both for loop index and as a temp variable, hence the main problem, where would loop 4E4 (forever).

Probably as already pointed out.

[TheFluff]

Also, "luty.append(x)" looks like it is doing a lot of reallocating memory, copying existing contents and then adding another. (unless is linked list).
wrong

You've used x as both for loop index and as a temp variable, hence the main problem, where would loop 4E4 (forever).
That's not how Python works. "for x in range()" iteratively sets x to each of the values in the list returned by range(), it's not a c-style for. It's completely safe to manipulate the loop variable inside the loop. Changing the loop variable does not change the list, either.

Example:
>>> for x in range(0,4):
... x = x+2
... print x
...
2
3
4
5

As Myrsloik said, it was a bug in vapoursynth.

[StainlessS]

Thanks for your explanation Fluffy, did look like an infinite loop to me.
As it happens Iv'e just downloaded VapourSynth & Python 3.3 a couple of moments ago so Ill have something new to play with.

[Mug Funky]

ah, excellent. being a python novice, i just copied the example lut in the vapoursynth docs and hacked at it.

seeing it work in 8 bit suggested to me it was not something i was doing.

i will precalculate the bit depth thing though - save a couple of instructions here and there.

[Myrsloik]

With the official binary of R13 I'm consistently getting a crash after frame #99. It affects all the files I've tested it with (tested with .avi, .mp4, .mov, .mkv, and .flv files...still results in x264 only getting 99 frames to encode before crashing). The Windows error reporting dialog says the crash is in vapoursynth.dll, so is it safe to say that's where it really is? Namely because the script only uses FFMS2, so if it was actually in the source filter I'd think it would report that ffms2.dll crashed. I tried culling what little information gdb can generate without debug symbols, but that was completely fruitless (tried hooking both python itself and x264...neither one gave me anything to go on).

None of this happens on Linux, so it seems like it might just be a problem with compilation settings or something (I'll have to try satisfying the dependencies first to attempt building under Windows, though). Unless this is part of a fix that occurred between the release of R13 and HEAD.

Is there any kind of internal error reporting type of thing that could be used to help diagnose this?


Some output from the Command Prompt:
>python vpytestscript.vpy | x264 --stdin y4m --preset ultrafast --crf 18 -o testvs.mkv -
y4m [info]: 1920x800p 0:0 @ 24000/1001 fps (cfr)
y4m [info]: color matrix: undef
x264 [info]: using cpu capabilities: MMX2 Cache32
x264 [info]: profile Constrained Baseline, level 4.0
x264 [info]: started at Sat Oct 27 18:04:29 2012

x264 [info]: frame I:1 Avg QP:15.00 size: 92219
x264 [info]: frame P:98 Avg QP: 7.36 size: 891
x264 [info]: mb I I16..4: 100.0% 0.0% 0.0%
x264 [info]: mb P I16..4: 0.0% 0.0% 0.0% P16..4: 1.9% 0.0% 0.0% 0.0% 0.0% skip:98.1%
x264 [info]: coded y,uvDC,uvAC intra: 11.2% 10.7% 10.7% inter: 0.6% 0.4% 0.4%
x264 [info]: i16 v,h,dc,p: 92% 6% 2% 0%
x264 [info]: i8c dc,h,v,p: 89% 7% 3% 0%
x264 [info]: kb/s:347.87

encoded 99 frames, 2.540 fps, 349.09 kb/s, 175.96 KB
x264 [info]: ended at Sat Oct 27 18:05:08 2012
x264 [info]: encoding duration 0:00:39

And one with the normal AviSynth side of the .dll to prove there's nothing wrong there. I killed it at 151 frames so I wouldn't have to wait around too long.
>x264 --preset ultrafast --crf 18 -o testvs-avs.mkv testvs.avs
avs [info]: 1920x800p 0:0 @ 24000/1001 fps (cfr)
avs [info]: color matrix: undef
x264 [info]: using cpu capabilities: MMX2 Cache32
x264 [info]: profile Constrained Baseline, level 4.0
x264 [info]: started at Sat Oct 27 18:05:54 2012
[5.0%] 151/3008 frames, 5.969 fps, 249.76 kb/s, 192.02 KB, eta 0:07:58, est.size

x264 [info]: frame I:1 Avg QP:15.00 size: 92219
x264 [info]: frame P:150 Avg QP: 7.27 size: 692
x264 [info]: mb I I16..4: 100.0% 0.0% 0.0%
x264 [info]: mb P I16..4: 0.7% 0.0% 0.0% P16..4: 1.5% 0.0% 0.0% 0.0% 0.0% skip:97.9%
x264 [info]: coded y,uvDC,uvAC intra: 5.7% 5.4% 5.3% inter: 0.5% 0.3% 0.2%
x264 [info]: i16 v,h,dc,p: 95% 3% 2% 0%
x264 [info]: i8c dc,h,v,p: 95% 4% 2% 0%
x264 [info]: kb/s:248.96

aborted at input frame 151, output frame 151
encoded 151 frames, 5.969 fps, 249.76 kb/s, 192.02 KB
x264 [info]: ended at Sat Oct 27 18:06:20 2012
x264 [info]: encoding duration 0:00:26

>

I figured out why. Sse2 math is enabled in my compiles. There's an event every 100 frames or so when internal statistics are updated using floating point.
So what can I say, vapoursynth requires a cpu with sse2. This is to make things easier for plugin writers too. Nowadays sse2 support is about as widespread as pure mmx support was 10 years ago or so.

[Keiyakusha]

Hi, I have few questions.

import vapoursynth as vs
core = vs.Core()
ret=core.std.BlankClip(format=vs.YUV420P8,color=[255,255,255]) #Is this supposed to be purple color? And color=[0,0,0] is green, I kind of expected black...
ret=core.std.CropRel(ret,right=638)
ret=core.resize.Point(ret,format=vs.YUV444P8) # this gives crashes/hangs - access violation in msvcr100
last=ret

I'm using VS r14, vfw module. Am I doing something wrong?

[Myrsloik]

Hi, I have few questions.

import vapoursynth as vs
core = vs.Core()
ret=core.std.BlankClip(format=vs.YUV420P8,color=[255,255,255]) #Is this supposed to be purple color? And color=[0,0,0] is green, I kind of expected black...
ret=core.std.CropRel(ret,right=638)
ret=core.resize.Point(ret,format=vs.YUV444P8) # this gives crashes/hangs - access violation in msvcr100
last=ret

I'm using VS r14, vfw module. Am I doing something wrong?

For color you're setting the raw pixel values so for yuv 255, 128, 128 should give you white which probably is what you expected. The resize thing I'll have to test and see what happens...

[Chikuzen]

>>> import vapoursynth as vs
>>> core = vs.Core()
>>> clip = core.std.BlankClip(format=vs.YUV420P8, color=[255, 128, 128])
>>> clip = core.std.CropRel(clip, right=638)
>>> clip = core.resize.Point(clip, format=vs.YUV444P8)
>>> print(clip)
VideoNode
Format: YUV444P8
Width: 2
Height: 480
Num Frames: 240
FPS Num: 24
FPS Den: 1
Flags: No Cache

>>> out = open('yuv444p8_width2.raw', 'wb')
>>> clip.output(out)
[swscaler @ 02979cc0] 2x480 -> 2x480 is invalid scaling dimension
[swscaler @ 02979cc0] 2x480 -> 2x480 is invalid scaling dimension
[swscaler @ 02979cc0] 2x480 -> 2x480 is invalid scaling dimension
[swscaler @ 02979cc0] 2x480 -> 2x480 is invalid scaling dimension
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "vapoursynthpp.pyx", line 671, in vapoursynth.VideoNode.output (src\cython\vapoursynthpp.c:10473)
vapoursynth.Error: 'Failed to retrieve frame 1 with error: Resize: context creation failed'

seems it's swscale's limitation (or bug).
however, VS has some problem on error handling too.

[Myrsloik]

seems it's swscale's limitation (or bug).

Yes, swscale usually fails below 32x32 sized output and probably input too. It's simply useless and broken. Other bugs are green tint, some really broken resizer modes that mess up chroma completely. The inability to both convert to and from planar rgb, respecting the color matrix and most other things. I hope to replace it soon because it sucks.

Prodding the developers has given exactly 0 improvements over a period of 6 months. Or 6 years depending on how you count...

[Chikuzen]

Other bugs are green tint, some really broken resizer modes that mess up chroma completely.
I heard that issue was already fixed, isn't it?
https://bugzilla.libav.org/show_bug.cgi?id=33

[kolak]

Green tint is there for sure, but it happens in specific cases- eg yuv42210bit to 8 bit is fine, but yuv44410bit to 8bit is not. In the same time yuv44410bit to 422 10bit is fine also- mess :)

[Mug Funky]

resampleHQ might be a good place to look for a better resizer core. works in linear light, too, which i reckon could be broken out as a separate special colour space.

[Myrsloik]

resampleHQ might be a good place to look for a better resizer core. works in linear light, too, which i reckon could be broken out as a separate special colour space.

There is already a much better one in the works by cretindesalpes.

[Adub]

Myrsloik,

I'm interested in using Vapoursynth as a basis for some academic research I'm conducting. TheFluff encouraged me to check out this project over Avxsynth, as he said Avisynth's caching mechanism "is an incredible mess." source (http://forum.doom9.org/showpost.php?p=1599555&postcount=141)

The short version is that I would like to port a few C versions of filters over to CUDA and evaluate the performance difference. The greatest performance gains can be established if we can ship a large number of frames across the PCI-Express bus in one fell swoop, perform the necessary computations (ideally, chaining several filters together, as that will let us keep the frames on the card) and then ship the frames back.

Now, do you think that there is a path to this in the current implementation of Vapoursynth? For instance, when a filter requests a frame using requestFrameFilter(), this could trigger a transfer of frames across the bus? Or is there another implementation that you have in mind?

I plan to do most of my development in Linux (for now), as I will be gaining access to several workstations running new Kepler cards, and my thesis advisor wants to run these workstations on Arch Linux for now. I have an Ubuntu rig at home for testing with lower end cards as well.

I look forward to your input on this, as I'd like to have as little data transfer overhead as possible.

[Myrsloik]

This is territory I didn't plan to seriously explore for quite a few more months. If you want to try to hack the stuff in I'd suggest something like this.

Modify the VSFrame class so it represents either a local or a gpu stored frame. Keep the total memory usage counters separated of course.

Then simply write a filter that moves frames to the gpu. I don't know what the mapping looks like here in cuda. Add a filter that does the gpu to local memory transfer too.

After that just write your gpu filters and see if it works. So sure, you can probably hack something in fairly easily if you really want to.


And now something completely unrelated. .. I've posted a last with all the tasks I could think of that would be good for VapourSynth at my blog. Tasks (http://www.vapoursynth.com/2012/11/vapoursynth-tasks/)

[Myrsloik]

Hi Myrsloik,

Just want to know do you have any clue to this problem (http://forum.doom9.org/showthread.php?p=1599044#post1599044)? Thanks.

It's a bug in mvtools. For some reason it doesn't use the emms instruction to restore the fpu state before returning when pel=1. Contact the mvtools author to get it fixed. I will never add a workaround for this in vs because it really is a fatal error.

[Myrsloik]

R15 has come. It adds some filters and some fixes but mostly it's internal changes to have more efficient memory handling. See the first post for the changelog. I also recommend looking at the python documentation as it now documents the most important classes and all their methods and attributes.

The usual blog post contains details on how to got from API R2 to R3:
R15 - API Improvements (http://www.vapoursynth.com/2012/11/r15-api-improvements/)

[Mr VacBob]

There is already a much better one in the works by cretindesalpes.

What's much better about it?

[TheFluff]

What's much better about it?

this post makes me wonder if you're trolling or if you're actually a genuine swscale apologist

the latter possibility is quite unsettling

[Mr VacBob]

Oh, I can think of lots of things wrong with it. It's unreadable, single-threaded, could use GPGPU (or anything newer than MMX), missing 10-bit+ and linear light processing, and could use an EEDI scaler. And the Gaussian filter didn't work last time I tried.

I have a new (NIH) resizer project in progress myself, but it's just for thumbnailing and not really worth trying to do much else with it.

Which ones did you want to address?

[Myrsloik]

Oh, I can think of lots of things wrong with it. It's unreadable, single-threaded, could use GPGPU (or anything newer than MMX), missing 10-bit+ and linear light processing, and could use an EEDI scaler. And the Gaussian filter didn't work last time I tried.

I have a new (NIH) resizer project in progress myself, but it's just for thumbnailing and not really worth trying to do much else with it.

Which ones did you want to address?

All of them would be nice. I could live without the gpu stuff though.

[Chikuzen]

@Myrsloik
How about this patch (http://forum.doom9.org/showpost.php?p=1600823&postcount=6) ?

[Adub]

This is territory I didn't plan to seriously explore for quite a few more months. If you want to try to hack the stuff in I'd suggest something like this.

Modify the VSFrame class so it represents either a local or a gpu stored frame. Keep the total memory usage counters separated of course.

Then simply write a filter that moves frames to the gpu. I don't know what the mapping looks like here in cuda. Add a filter that does the gpu to local memory transfer too.

After that just write your gpu filters and see if it works. So sure, you can probably hack something in fairly easily if you really want to.
Tasks (http://www.vapoursynth.com/2012/11/vapoursynth-tasks/)

Okay, I'll see what I can do with this. I am worried a bit about blocking, but I'll see what we can do with this method. I won't be able to work on it for a few weeks, as I have other projects for classes to get done, but I should be able to make something work over break.

[Chikuzen]

How can I read AVI file containing alpha with avisource?
I tried

>>> import vapoursynth as vs
>>> core = vs.Core()
>>> print(core.version())
VapourSynth Video Processing Library
Copyright (c) 2012 Fredrik Mellbin
Core r15
API r3

>>> core.std.LoadPlugin('G:/vsplugins/avisource.dll')
>>> clip = core.avisource.AVISource('320x240_uly0.avi')
>>> print(clip)
VideoNode
Format: YUV420P8
Width: 320
Height: 240
Num Frames: 600
FPS Num: 60
FPS Den: 1
Flags: No Cache

>>> clip = core.avisource.AVISource('alpha_test.avi')

and got crash.

sample (http://www.mediafire.com/download.php?9c4d6x05d908dxp) and information (http://pastebin.com/0kBM2PY7)