ffmpeg using .vpy scripts directly one day, like avisynth ?

[Wolfberry]

Originally Posted by jackoneill

By the way, did you need to patch VapourSynth to accomplish this?

I use gendef and dlltool to generate delay-import libraries from official VapourSynth and Python dlls, so no patch is needed.

What I mean by static is that ffmpeg will not require extra dlls at startup.

Originally Posted by ChaosKing

I think VS needs to be installed. ffmpeg & ffplay are working fine.
Tested with: ffplay.exe -f vapoursynth -i 'D:\test.vpy'

Portable VapourSynth should also works since this is the only one I tested.

I just extracted VapourSynth64-Portable-R45, python-3.7.3-embed-amd64 and ffmpeg to the same directory and use that as a testing environment.

[unix]

Thank you Wolfberry.

By the way using direct vapoursynth method is it faster than vspipe to ffmpeg, or it depends on the filters that using?

[Wolfberry]

Originally Posted by unix

By the way using direct vapoursynth method is it faster than vspipe to ffmpeg, or it depends on the filters that using?

Usually the native vapoursynth demuxer is faster than piping, but different implementation of the demuxer can have a impact on speed, see post #47 and #48 for details.

[qyot27]

Since I've now hammered out the kinks (hopefully), I'm able to answer this based on actually cross-compiling VapourSynth instead of using gendef on Windows dlls.

Originally Posted by jackoneill

By the way, did you need to patch VapourSynth to accomplish this?

Not really. Most of the weirdness is in how to handle Python (it still needs to be gendeffed, et al.). VapourSynth itself has only three issues at play here:

• src/vsscript/vsscript.cpp has an include of Windows.h that trips up cross-compiles due to case sensitivity.
• No matter what I tried, I couldn't force NASM to recognize the multilib MinGW-w64 environment and actually compile 32-bit objects, so I have to force-override the Makefile to compile the correct object format.
• The Requires.private invocation of python in vapoursynth-script.pc screws up FFmpeg's configure tests; Libs.private does work as expected.
• A possible fourth issue is whether there's a case for including -lstdc++ in the .pc file's Libs(.private) stuff (it's not a problem when a bunch of other external libraries are enabled, since one/several of them pull in -lstdc++, but a 'simple' build of FFmpeg with VapourSynth and AviSynth as the only enabled external libraries fails unless --extra-libs is used to provide libstdc++ as detailed way earlier in this thread). Or whether a Cflags.private entry should be added for pkgconf users so -DVS_CORE_EXPORTS can be used only in the case of static linking. Essentially, this 'point' basically is just bikeshedding.

The entire process is documented here (link goes directly to the VapourSynth section of the guide):
https://github.com/qyot27/mpv/blob/e...ious.txt#L4396


One distinction is that when I'd tested with using gendef to handle VapourSynth too, I could get FFmpeg to link to it, but mpv refused to link to libavformat. gendeffing only Python and then cross-compiling VapourSynth like any other library results in both FFmpeg and mpv being able to link to it (importantly, mpv being able to directly play back scripts this way).

32-bit and 64-bit FFmpeg and mpv with static VapourSynth

Said binaries include *both* VS demuxers. The upstream demuxer is still 'vapoursynth', and the other one is 'vapoursynth_alt'. It's easy to tell them apart because they return different data types as input: '-f vapoursynth' returns wrapped_avframe, '-f vapoursynth_alt' returns rawvideo. The upstream demuxer also doesn't honor relative file paths across directories (in just FFMS2? maybe in general?), while the alt demuxer does.

[Natty]

Originally Posted by Wolfberry

ffmpeg-20190729-43891ea-win64-static

404. That’s an error.

The requested URL was not found on this server. That’s all we know.

[ChaosKing]

Originally Posted by Natty

404. That’s an error.

The requested URL was not found on this server. That’s all we know.

Click on his signature link, you can find a newer version there.

[Natty]

Originally Posted by ChaosKing

Click on his signature link, you can find a newer version there.

got it.

[kolak]

Originally Posted by qyot27

Since I've now hammered out the kinks (hopefully), I'm able to answer this based on actually cross-compiling VapourSynth instead of using gendef on Windows dlls.

Not really. Most of the weirdness is in how to handle Python (it still needs to be gendeffed, et al.). VapourSynth itself has only three issues at play here:

• src/vsscript/vsscript.cpp has an include of Windows.h that trips up cross-compiles due to case sensitivity.
• No matter what I tried, I couldn't force NASM to recognize the multilib MinGW-w64 environment and actually compile 32-bit objects, so I have to force-override the Makefile to compile the correct object format.
• The Requires.private invocation of python in vapoursynth-script.pc screws up FFmpeg's configure tests; Libs.private does work as expected.
• A possible fourth issue is whether there's a case for including -lstdc++ in the .pc file's Libs(.private) stuff (it's not a problem when a bunch of other external libraries are enabled, since one/several of them pull in -lstdc++, but a 'simple' build of FFmpeg with VapourSynth and AviSynth as the only enabled external libraries fails unless --extra-libs is used to provide libstdc++ as detailed way earlier in this thread). Or whether a Cflags.private entry should be added for pkgconf users so -DVS_CORE_EXPORTS can be used only in the case of static linking. Essentially, this 'point' basically is just bikeshedding.

The entire process is documented here (link goes directly to the VapourSynth section of the guide):
https://github.com/qyot27/mpv/blob/e...ious.txt#L4396


One distinction is that when I'd tested with using gendef to handle VapourSynth too, I could get FFmpeg to link to it, but mpv refused to link to libavformat. gendeffing only Python and then cross-compiling VapourSynth like any other library results in both FFmpeg and mpv being able to link to it (importantly, mpv being able to directly play back scripts this way).

32-bit and 64-bit FFmpeg and mpv with static VapourSynth

Said binaries include *both* VS demuxers. The upstream demuxer is still 'vapoursynth', and the other one is 'vapoursynth_alt'. It's easy to tell them apart because they return different data types as input: '-f vapoursynth' returns wrapped_avframe, '-f vapoursynth_alt' returns rawvideo. The upstream demuxer also doesn't honor relative file paths across directories (in just FFMS2? maybe in general?), while the alt demuxer does.

Both versions crash very quickly with my deinterlacing script. ffmpeg simply hangs and does nothing.
Wolfberry version does absolutely nothing- just ends without any print or error.

[poisondeathray]

Originally Posted by kolak

Both versions crash very quickly with my deinterlacing script. ffmpeg simply hangs and does nothing.
Wolfberry version does absolutely nothing- just ends without any print or error.

Is it valid script ? Does it work in other programs?

what does info say ?

vspipe --info script.vpy -

Post the script.

[qyot27]

Roll back VapourSynth (git) and Python (release) to versions that were current at the end of May. Trying to mix and match versions will fail spectacularly.

Or don't use a build from nearly 5 months ago; use a current one built against the now-current versions of those environments.

[kolak]

Where can I find current build?
(script is absolutely fine)

[unix]

Originally Posted by kolak

Where can I find current build?
(script is absolutely fine)

https://drive.google.com/drive/folde...mHKYLzO3elemlC

[kolak]

I've used this one already:
ffmpeg-20190926-87ddf9f-win64-static.7z

and it does nothing. Maybe my PY is too new as it's the latest one (3.7.4).

[qyot27]

FFmpeg and mpv built with static VapourSynth/Python, 2019-10-10

VapourSynth: git-bae5d1a
Python: 3.7.4

The incompatibility is most likely tied to the version of Python, but VS itself probably incurs *some* of the restriction too (it matters which version of Python the VS .dlls were built against, just as much as it matters which one is linked into FFmpeg). I still have Python 3.7.3 and the official release build of R47 installed system-wide, but built FFmpeg with Python 3.7.4 and VapourSynth's current git HEAD. It worked just fine. It seems to be okay as long as the Python and VapourSynth linked into FFmpeg are newer than the ones on the system, but the inverse situation will almost certainly fail.

As before, both VapourSynth demuxers are present. The upstream demuxer is vapoursynth, the rawvideo demuxer patch provides vapoursynth_alt.

[kolak]

THX.
Any difference in demuxers stability wise?

[kolak]

Seems to be working. Just getting this:
"Script exceeded memory limit" which I assume is about some cache in vs. How do I increase it ?
With vapoursynth_alt speed is 3x better.

[Pat357]

The FFmpeg binaries work fine to play/process .VPY files directly ; the vapoursynth_alt demuxer seems faster than the build-in.

How to feed a.vpy directly to MPV ?
Is there a way to specify which demuxer/format to use when playing a .vpy file using MPV ?

[qyot27]

--demuxer-lavf-format=vapoursynth (or vapoursynth_alt). The 64-bit mpv from the package I posted on the 10th also supports using VapourSynth as a video filter (for say, 24->60fps motion interpolation).

.vpy can associated with the above command in the config file, so you don't have to remember to use it:

[extension.vpy]
demuxer-lavf-format=vapoursynth