Vapoursynth

[jackoneill]

Has anybody been able to cross-compile VapourSynth using Linux?

I'm trying to use MXE (M Cross Environment; mingw32-w64 toolchain builder) and it compiles mpv without any problems, but VapourSynth requires Python 3.4 and I'm stumped on how to properly compile the VapourSynth DLL...

It has been done. There are some hoops to jump through.

Note that cross-compiling a 32 bit libvapoursynth produces a broken DLL. I didn't investigate, but I think it has to do with function decorations somehow.

You could try to cross-compile Python, but I found it easier to use the official win64 installer in Wine (even if it took a few hours to find the magic switch that made msiexec work).

So, assuming you will use the official Python installer, the configure command will look something like this:

./configure --host=x86_64-w64-mingw32 --disable-python-module --disable-plugins PYTHON3_CFLAGS='/path/to/Python3.h' PYTHON3_LIBS='-L/path/to/libpython3.dll -lpython3'


--disable-python-module because Python modules have to be compiled with the same compiler as libpython, so you'll have to use the Python module provided in the official VapourSynth installer.

--disable-plugins because I assume you won't need those.

PYTHON3_CFLAGS needs to be passed to please the configure script. Point it to the Python installation's "include" folder.

PYTHON3_LIBS is also needed to please the configure script. Point it to the Python installation's "DLLs" folder. Inside, you will need to rename Python3.dll to libpython3.dll because otherwise libtool refuses to acknowledge its existence. This means you'll also need to rename Python3.dll on the Windows machine where this thing will run.

Most unfortunately, you will receive a libvapoursynth-script-0.dll instead of vsscript.dll.

Don't use GCC 5.3.0 for this because its libstdc++ has a bug that makes wstring_convert unusable. This is a problem for VapourSynth. GCC 5.1.0 is okay.

If it's for mpv, I think you'll find it much easier to convince mpv's build system to use the vsscript.dll provided in the official VapourSynth installer, or the portable archive.

[sofakng]

Thanks a lot for the help. I ended up using dlltool to generate the lib files (for vapoursynth.dll and vsscript.dll) and I was able to get mpv compiled with vapoursynth supported. I still need to try it on my actual win32 machine so who knows if it will work but at least it compiled :)

[sofakng]

Sorry, but one more question.

Is there an installer for the 64-bit version of VapourSynth? It looks like VapourSynth-R32.exe only installs the 32-bit version.

[speedyrazor]

Hi, I am getting "VSPipe.exe has stopped working" when trying to process Quicktime Prores 4444 files. Here is the script:

import vapoursynth as vs
core = vs.get_core(threads=4)
ret = core.lsmas.LibavSMASHSource(source=r"Prores_4444_HD_Test.mov")
ret = core.fmtc.resample (clip=ret, w=480, h=384, 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()

I am on the latest version of Vapoursynth (R32) and the latest version of LSMASHSource (r877). Here is the crash report:


Problem signature:
Problem Event Name: APPCRASH
Application Name: VSPipe.exe
Application Version: 0.0.0.0
Application Timestamp: 5707beaa
Fault Module Name: vslsmashsource.dll
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 00000000
Exception Code: c0000005
Exception Offset: 0000000000001c80
OS Version: 6.2.9200.2.0.0.272.7
Locale ID: 2057
Additional Information 1: a279
Additional Information 2: a279be6c627875dc7e1b7d38560dd807
Additional Information 3: 750b
Additional Information 4: 750b3a6db190a3b8cb8b4f7bce54513d

Am I doing something wrong, or is this a bug?

Kind regards.

[stax76]

I've downloaded a YUV444P10 sample and got an VS error telling YUV444P10 is not supported by VFW module, could it be supported? I get this error not only with StaxRip and VirtualDub but also with MPC-BE which I thought does not use VFW.

Sample is from here:

https://www.arri.com/camera/amira/learn/amira_sample_footage/


Count : 334
Count of stream of this kind: 1
Kind of stream : Video
Kind of stream : Video
Stream identifier : 0
StreamOrder : 0
ID : 1
ID : 1
Format : ProRes
Commercial name : ProRes
Format version : Version 1
Format profile : 4444
Codec ID : ap4h
Codec ID/Url : http://www.apple.com/quicktime/download/standalone.html
Codec : ap4h
Codec : ap4h
Codec/CC : ap4h
Duration : 10240
Duration : 10s 240ms
Duration : 10s 240ms
Duration : 10s 240ms
Duration : 00:00:10.240
Duration : 00:00:10:06
Duration : 00:00:10.240 (00:00:10:06)
Bit rate mode : VBR
Bit rate mode : Variable
Bit rate : 286246400
Bit rate : 286 Mbps
Width : 1920
Width : 1 920 pixels
Clean aperture width : 1920
Clean aperture width : 1 920 pixels
Height : 1080
Height : 1 080 pixels
Clean aperture height : 1080
Clean aperture height : 1 080 pixels
Pixel aspect ratio : 1.000
Clean aperture pixel aspect ratio: 1.000
Display aspect ratio : 1.778
Display aspect ratio : 16:9
Clean aperture display aspect ratio: 1.778
Clean aperture display aspect ratio: 16:9
Rotation : 0.000
Frame rate mode : CFR
Frame rate mode : Constant
Frame rate : 25.000
Frame rate : 25.000 fps
Frame count : 256
Chroma subsampling : 4:4:4
Chroma subsampling : 4:4:4
Scan type : Progressive
Scan type : Progressive
Bits/(Pixel*Frame) : 5.522
Delay : 10280
Delay : 10s 280ms
Delay : 10s 280ms
Delay : 10s 280ms
Delay : 00:00:10.280
Delay_Settings : DropFrame=No / 24HourMax=Yes / IsVisual=No
Delay_DropFrame : No
Delay, origin : Container
Delay, origin : Container
Stream size : 366395392
Stream size : 349 MiB (97%)
Stream size : 349 MiB
Stream size : 349 MiB
Stream size : 349 MiB
Stream size : 349.4 MiB
Stream size : 349 MiB (97%)
Proportion of this stream : 0.96949
Writing library : Arnold & Richter Cine Technik
Writing library : Arnold & Richter Cine Technik
Language : en
Language : English
Language : English
Language : en
Language : eng
Language : en
Encoded date : UTC 2014-07-02 09:44:35
Tagged date : UTC 2014-07-02 09:44:45
colour_description_present: Yes
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709
colour_description_present_Original: Yes
matrix_coefficients_Original: RGB

[Myrsloik]

The problem is that there is no fourcc to represent it that I know of. The closest are ms p010 or whatever it was called and v210 which are both 10bit but subsampled. Find me a fourcc that's actually supported in applications and I'll consider adding it.

[stax76]

Who might help here, maybe the author of MediaInfo or VirtualDub?

[stax76]

found something:

http://wiki.multimedia.cx/index.php?title=Apple_ProRes

[Myrsloik]

found something:

http://wiki.multimedia.cx/index.php?title=Apple_ProRes

No, must be uncompressed formats obviously.

[poisondeathray]

YUV 444 10bit packed is known as "Y410", but it's not supported in ffmpeg as a pixel format .


https://msdn.microsoft.com/en-us/library/windows/desktop/bb970578%28v=vs.85%29.aspx#_444formats
https://en.wikipedia.org/wiki/FFmpeg#Pixel_formats

It's also known as "v410" (analgous to "v210" for 10bit422) but 10bit444
https://www.mplayerhq.hu/DOCS/codecs-status.html

[stax76]

yuv fourcc on apple dev page:

https://developer.apple.com/library/mac/technotes/tn2273/_index.html#//apple_ref/doc/uid/DTS40009994-CH1-SECTION3


d:\Temp>ffmpeg -codecs -hide_banner | findstr 4:4:4
DEVI.. ayuv Uncompressed packed MS 4:4:4:4
DEVI.. v308 Uncompressed packed 4:4:4
DEVI.. v408 Uncompressed packed QT 4:4:4:4
DEVI.S v410 Uncompressed 4:4:4 10-bit

[Khanattila]

I don't think it's helpful.

x264/x265 accept i420, yv12, nv12, i422, yv16, nv16, i444, yv24:
- yv12, yv16 and yv24 are planar, good;
- i420, i422, i444 are identical except that the U and V plane order is reversed, good;
- nv12, nv16 are semi-planar.

Why add a packed format?

[Myrsloik]

My personal opinion is that you should just let vfw die. I know it's convenient and simple sometimes but it simply doesn't define enough things. Simply convert to RGB24 or yv24 at the end of all scripts you're only going to preview and be done with it.

If anything I thinkbthe future belongs to specialized editors/preview apps that have proper 10bit and up handling. There are monitors that truly support a higher depth but I don't think any open source solution is capable of properly doing that yet. Let vfw die, it's old and tired.

And you can easily pipe y4m at higher depths into x264 so that makes even less sense. I got that stuff added to y4m several years ago to work around this.

[stax76]

I don't give it up yet, I'm getting closer though.

[Myrsloik]

I don't give it up yet, I'm getting closer though.

Why does staxrip need it at all when doing VS stuff?

[stax76]

It does not really need it, it just was always good enough.

[speedyrazor]

Does this all relate to this issue?
http://forum.doom9.org/showthread.php?p=1766005&highlight=Hi%2C+VSPipe.exe+has+stopped+working#post1766005

[stax76]

Does this all relate to this issue?
http://forum.doom9.org/showthread.php?p=1766005&highlight=Hi%2C+VSPipe.exe+has+stopped+working#post1766005

no, vspipe don't use VFW

[speedyrazor]

The fault comes from the source filter you use. You'd better open an issue on https://github.com/VFR-maniac/L-SMASH-Works and provide a small sample file so the author can reproduce the problem.
Done, thanks for the suggestion.

[feisty2]

anyone ever thought about making a GUI based editor, something like Nuke for vs?
I mean vseditor is cool but it's based on script writing still... you're gonna have to write scripts even for some pretty simple tasks and that is not very user friendly..
would be nice if such GUI thing exists and you manipulate the filters and modules as "nodes" and it generates python scripts automatically for you..

[LigH]

You are probably thinking of something similar to "AVE AviSynth Visual Editor" (which was probably abandoned, IIRC).

[feisty2]

You are probably thinking of something similar to "AVE AviSynth Visual Editor" (which was probably abandoned, IIRC).

shame, I always think it's good to "GUI whatever if possible and script manually only where it must"

[LigH]

That's the POV of the user.

The developer looks from the opposite angle and needs to have basic routines working first. A pretty GUI on a brittle core is like a penthouse floating above a basement still being built.

AviSynth was developed as (scriptable) frameserver; it was meant to be invisible. VapourSynth is a video filtering framework, not the same as a frameserver, but still meant to be the invisible engine covered by any kind of casing. Because the VapourSynth engine itself is partially made of a common programming language (Python), it is even more probable than for AviSynth that a user interface could be made which may change the video processing script as a part of itself. But this is just a very elaborate challenge...

[Are_]

anyone ever thought about making a GUI based editor, something like Nuke for vs?
I mean vseditor is cool but it's based on script writing still... you're gonna have to write scripts even for some pretty simple tasks and that is not very user friendly..
would be nice if such GUI thing exists and you manipulate the filters and modules as "nodes" and it generates python scripts automatically for you..

Not sure if it is exactly what you meant, but somebody did think about it and wrote pyhenkan (https://github.com/alucryd/pyhenkan).

I don't know if it works out of the box in Windows, it's not mentioned anywhere, and has some bugs here and there, looks a little unfinished yet.

I don't really know what's Nuke, but is not Staxrip (https://github.com/stax76/StaxRip) similar to what you are asking for (I have not used it, so I don't really know what it is)?

[feisty2]

The developer looks from the opposite angle and needs to have basic routines working first. A pretty GUI on a brittle core is like a penthouse floating above a basement still being built.


been years since the first vs release, I actually think the vs core should be pretty stable by now, trivial changes and improvements and bug fixes will always be going but nothing drastic, the basement is done imho

[feisty2]

I don't really know what's Nuke

Nuke is a node based commercial NLE software, it's a pretty popular thing in movie industry, see https://www.thefoundry.co.uk/products/nuke/

and it's different from transcoding toolkits like Staxrip or MeGUI, it's designed specifically for video manipulating not transcoding

[Mystery Keeper]

anyone ever thought about making a GUI based editor, something like Nuke for vs?
I mean vseditor is cool but it's based on script writing still... you're gonna have to write scripts even for some pretty simple tasks and that is not very user friendly..
would be nice if such GUI thing exists and you manipulate the filters and modules as "nodes" and it generates python scripts automatically for you..

Like Cycles in Blender? Doable. But how usable it would be? Writing scripts is simply faster. It lets you copy/paste and comment out lines. A complex script might use tens of nodes.

[feisty2]

Like Cycles in Blender? Doable. But how usable it would be? Writing scripts is simply faster. It lets you copy/paste and comment out lines. A complex script might use tens of nodes.

It's extremely useful on complex restoration projects like VideoFred's stuff, you got a clearer view of the entire process chain instead of figuring it out by hours of script reading and organizing, and it helps the function calling also, some fat plugins, mvtools kind of thing, might contain 20+ parameters or so, and you got them all on a gui panel, no more staring at the extra long function calling and tryna locate the parameter you set before and wanna modify now...

[feisty2]

And scripts tend to be messy and confusing and likely to go wrong when things get big and complex, cuz we humans make mistakes...GUI nodes help with that too

[dipje]

Utvideo codec has now RGB 10-bit and RGB-with-alpha 10-bit versions, with quicktime support and working (import/export) in Adobe After Effects for Windows at least.

Virtualdub FilterMod has added b64a support and tested the codecs and they seem to work.
But there is no way yet to go from Vapoursynth (with RGB30 / RGB48) into Virtualdub FilterMod since Vapoursynth doesn't support those colorspaces in the VfW module. May I request this? There is a legit use now for it :).

(Vpy RGB30 into Utvideo 'UQRG' seems to be close to 50% of the same RGB30 as a DPX sequence in disksize so it helps a lot with disk i/o in After Effects)


An alternative would be an updated ffmpeg with the 10-bit utvideo versions in _encoding_ mode, but since there doesn't seem to be support for the (now a fear years old) YUV422-10bit mode (UQR2) I have little hope for that happening.

[Myrsloik]

I'll add b64a then. The reason I don't add all formats is that b64a (until now) didn't have an easy way to test it.

[dipje]

Now comes to noobish question.

What is 'b64a'. 16-bit-per-pixel RGB with A? Planer or packed?

What output format should my Vapoursynth be if it would have to go to b64a? Regular vs.RGB48 or do I somehow need to fake an alpha channel?

(Or do you don't know yet till you worked on it :P)

[shekh]

Yes, 16-bit-per-pixel RGB with A, packed.

I could also support b48r (no alpha) if it gives any benefit. Currently both UQRG and UQRA accept b64a so I did not bother with b48r.
I check whether alpha is valid by the codec id, not by bitmap format, so if you expect alpha from Vapoursynth I need to do something else.

[dipje]

Well I couldn't care about alpha, but some other people I guess do.

But just 'support whatever is needed to get UQRG working' is enough for me to be honest :).

[kolak]

I'll add b64a then. The reason I don't add all formats is that b64a (until now) didn't have an easy way to test it.

b64a is quite universal, so good to have it.

[Myrsloik]

b64a is quite universal, so good to have it.

I'm having trouble finding something to test b64a in. Is there any free program I can use? (madvr doesn't count since it+mpc-hc doesn't play nice with debuggers)

[kolak]

Utvideo codec has now RGB 10-bit and RGB-with-alpha 10-bit versions, with quicktime support and working (import/export) in Adobe After Effects for Windows at least.

Virtualdub FilterMod has added b64a support and tested the codecs and they seem to work.
But there is no way yet to go from Vapoursynth (with RGB30 / RGB48) into Virtualdub FilterMod since Vapoursynth doesn't support those colorspaces in the VfW module. May I request this? There is a legit use now for it :).

(Vpy RGB30 into Utvideo 'UQRG' seems to be close to 50% of the same RGB30 as a DPX sequence in disksize so it helps a lot with disk i/o in After Effects)


An alternative would be an updated ffmpeg with the 10-bit utvideo versions in _encoding_ mode, but since there doesn't seem to be support for the (now a fear years old) YUV422-10bit mode (UQR2) I have little hope for that happening.

Both UQY2 and UQRG has been added to ffmpeg in recent days.

[kolak]

I'm having trouble finding something to test b64a in. Is there any free program I can use? (madvr doesn't count since it+mpc-hc doesn't play nice with debuggers)

Hmmm...modded Vdub which has been mentioned here?
ffplay?

[Myrsloik]

Hmmm...modded Vdub which has been mentioned here?

Nope, it says it doesn't know b64a. That makes me sad. Maybe there's some obscure codec that also provides b64a "decoding".

[kolak]

What about graphstudio + MadVR or ffplay?

[shekh]

Nope, it says it doesn't know b64a. That makes me sad. Maybe there's some obscure codec that also provides b64a "decoding".

Can I help with this?
Maybe vpy is handled by some other code path in vdub.
I tested UQRG with "avi (compat)" open option and it works.

For reference, this is how BitmapInfoHeader is filled:


biWidth = w
biHeight = h
biPlanes = 1
biCompression = VDMAKEFOURCC('b', '6', '4', 'a')
biBitCount = 64
biSizeImage = w*8 * h


Or I can try your intermediate version and see what happens.

[Myrsloik]

R33 test 1 (https://dl.dropboxusercontent.com/u/73468194/VapourSynth-R33-test1.exe)

RGB24 will now be automatically packed to BGRA so VFW likes it more.
RGB48 will be packed to b64a.
YUV444P14 will be packed to Y416.

The b64a I haven't managed to test so report your success with that.

Not much else changed, really.

[shekh]

I made some fixes and in general it "works" (will make fixed update soon).
However it looks like VS output has different component order and byte order (UQRG matches this description http://www.bitjazz.com/en/products/sheervideo/faq/formats/pixel_formats.php#b64a)

[Myrsloik]

I made some fixes and in general it "works" (will make fixed update soon).
However it looks like VS output has different component order and byte order (UQRG matches this description http://www.bitjazz.com/en/products/sheervideo/faq/formats/pixel_formats.php#b64a)

I double checked it and I'm fairly certain I match it. The evils of endianness and so on. Even the simple description says that the order of the components is ARGB which the big endian example confirms.

[shekh]

I confirm that your output is correct. My mistake.
Uploaded new version, now everything works fine.

[dipje]

I installed Vapoursynth r33 test 1 (x64, python 35) together with virtualDub64_pack_37197 (that was the latest one you were talking about, right shekh?)

If I open a .vpy file with RGB48 I get VirtualDub FilterMod showing it as b64a and it displays fine, and I can scrub around and it seems to work.

Setting the VDubFilterMod to 'direct stream copy' in video mode I can save a raw b64a AVI file no problem.

But whatever I try to save a Utvideo 10bit version VDub seems to crash.
Is it working with UQRA / UQRG? I know Myrsloik said it's basically untested but if I see the video OK in VDubFilterMod I'm guessing Vapoursynth has done it's job.

Shekh, you said you tested your b64a with Utvideo right? Did it break doing the latest changes?

[kolak]

Same here. Looks like UTVideo problem or something in between.

[dipje]

Both UQY2 and UQRG has been added to ffmpeg in recent days.

Decoding only from the looks of it

[shekh]

I installed Vapoursynth r33 test 1 (x64, python 35) together with virtualDub64_pack_37197 (that was the latest one you were talking about, right shekh?)

If I open a .vpy file with RGB48 I get VirtualDub FilterMod showing it as b64a and it displays fine, and I can scrub around and it seems to work.

Setting the VDubFilterMod to 'direct stream copy' in video mode I can save a raw b64a AVI file no problem.

But whatever I try to save a Utvideo 10bit version VDub seems to crash.
Is it working with UQRA / UQRG? I know Myrsloik said it's basically untested but if I see the video OK in VDubFilterMod I'm guessing Vapoursynth has done it's job.

Shekh, you said you tested your b64a with Utvideo right? Did it break doing the latest changes?

It works for me. Tested UQRA, UQRG, x86, amd64 - all work.
Can you narrow down the test which will crash and share source & script so I try it? Also crash report from vdub may be useful.

update:
Looks like it crashed when preferences->video compression threads is set to 0.
Fixed now, build 37201

[Selur]

http://www.vapoursynth.com/doc/functions/levels.html doesn't mention the 'gamma' option of levels.