Vapoursynth

[Myrsloik]

Can 2 python versions 3.x coexist ? 3.7.x and 3.8.x ? I ask because I need 3.7 for some other projects but would like to test new version of vapoursynth, and I'm assuming 3.8 is a requirement for r49-rc2 ?

Yes, they can generally do that without any problems. However the python installer doesn't approve so you'll need to rename/delete the registry entries for the version you install first.

There's also always the portable version. Maybe that's easier.

[feisty2]

@Myrsloik

auto y1 = vsapi->getReadPtr(x, 0);

auto x2 = vsapi->cloneFrameRef(x);
auto y2 = vsapi->getReadPtr(x2, 0);

say "x" is a frame ref, do "y1" and "y2" evaluate to the same value?

[Myrsloik]

@Myrsloik

auto y1 = vsapi->getReadPtr(x, 0);

auto x2 = vsapi->cloneFrameRef(x);
auto y2 = vsapi->getReadPtr(x2, 0);

say "x" is a frame ref, do "y1" and "y2" evaluate to the same value?

Yes, they point to the same underlying frame.

[feisty2]

what is the lifetime of "in" and "out" in the "Create" function? If I create an std::string_view from propGetData(in, ...), does it have a global lifetime?

[Myrsloik]

what is the lifetime of "in" and "out" in the "Create" function? If I create an std::string_view from propGetData(in, ...), does it have a global lifetime?

They're only valid inside the create function and usually destroyed very quickly after.

[feisty2]

I see, so I should copy the string with an owning std::string.

[Myrsloik]

I see, so I should copy the string with an owning std::string.

Yes, always.

[Boulder]

If I have a VFR video clip, say like part A deinterlaced to 25fps and part B bobbed to 50fps in the script and the two parts combined with A+B - what is the proper way to get the correct timecodes out with vspipe? Should I use AssumeFPS to set the framerate to 25fps (which I will use when I feed it to x265) or leave it as it is?

[Myrsloik]

R49 released!

[Myrsloik]

If I have a VFR video clip, say like part A deinterlaced to 25fps and part B bobbed to 50fps in the script and the two parts combined with A+B - what is the proper way to get the correct timecodes out with vspipe? Should I use AssumeFPS to set the framerate to 25fps (which I will use when I feed it to x265) or leave it as it is?

It's been a long time since I did this so it could be wrong but generally you simply splice the two different fps clips (mismatch=1 in splice) and then use it as input to x265. Make sure to use the vspipe timecode option and after the encode is done mux in the proper timecodes.

Or that's how I think it should work.

[Boulder]

It's been a long time since I did this so it could be wrong but generally you simply splice the two different fps clips (mismatch=1 in splice) and then use it as input to x265. Make sure to use the vspipe timecode option and after the encode is done mux in the proper timecodes.

Or that's how I think it should work.

Doesn't seem to be working properly :( I fed the VFR clip into x265 and told it to expect 25fps input (otherwise it would simply crash). The clip was produced by splicing with the + operator in Vapoursynth.

The timecodes have two steps, 20ms and 40ms in the 50fps parts. The 25fps parts have 40ms and 80ms steps.

# timecode format v2
0.000000
20.000000
60.000000
80.000000
120.000000
.
.
.
46600.000000
46680.000000
46720.000000
46800.000000
46840.000000
46920.000000
46960.000000

I have some similar old Matroska files in which I have encoded the video track at 50fps (at least according to MediaInfo) and created the timestamp v1 file manually. I now extracted the timestamps and they look like this, first the 50fps part and the latter one is from a 25fps part:

# timestamp format v2
0
20
40
60
.
.
.
408000
408040
408080
408120
408160

[DJATOM]

Boulder
You probably doing it wrong.
Yesterday I had hybrid video file encoded as MBAFF (no actual combed frames, but it's 30000/1001i), and some sections are upscaled from 24000/1001p. So I need to decimate only certain sections and produce VFR video.
I'll describe my solution bellow and how to actually get valid timecodes (Myrs answer seems not so clear for you). The whole process is described to understand my workflow and most likely irrelevant for you, but you can adapt that to your case and use only what you need from it.

First, I have to check with VDecimate(dryrun=True) if scene actually telecined. The result for my video was
scenes = [0, 80, 173, 269, 366, 462, 561, 609, 657, 705, 1255, 1306]

Video starts from 24p scene, so I have to decimate every odd section.
vfr_pool = list()
for pos, start in enumerate(scenes, 1): # start from 1 for simplicity of the algo
if pos >= len(scenes): # last frame in list is the end of last section, so I want to terminate loop on it
break
end = scenes[pos]
if pos&1: # decimate only 1, 3, 5, 7, etc. sections
vfr_pool.append(core.vivtc.VDecimate(source[start:end]))
else:
vfr_pool.append(source[start:end])

And finally splice those scenes into one VFR video
vfr_clip = core.std.Splice(vfr_pool)
vfr_clip.set_output()
Now it's ready to encode,
vspipe -t mytimecodes.txt -y script.vpy - | x265 ... --y4m --fps 24000/1001 -
and after encoding use mytimecodes.txt to mux into mkv video. Result should be VFR and properly sync with audio.
I really want tdecimate's mode 4/5 solution in vapoursynth, but it seems like no one want to port that.

[Boulder]

Thank you, I will take a look at your method :)

I used this kind of approach for creating the test clip, the first and third parts are bobbed.

clp = core.dgdecodenv.DGSource(r"F:\Temp\Captures\monty\monty_s01e01.dgi", cl=244, cr=244)

result = haf.QTGMC(core.std.Trim(clp, 0,719), Preset='very fast', Search=5, SearchParam=8, PelSearch=8, ChromaMotion=True, ChromaNoise=False, SourceMatch=2, Lossless=2, EZKeepGrain=0.4, Sharpness=0.1, TR2=0, TFF=True)
result = result + haf.QTGMC(core.std.Trim(clp, 720,2890), Preset='very fast', Search=5, SearchParam=8, PelSearch=8, ChromaMotion=True, ChromaNoise=False, SourceMatch=2, Lossless=2, EZKeepGrain=0.4, Sharpness=0.1, TR2=0, TFF=True, InputType=2)
result = result + haf.QTGMC(core.std.Trim(clp, 2891,3935), Preset='very fast', Search=5, SearchParam=8, PelSearch=8, ChromaMotion=True, ChromaNoise=False, SourceMatch=2, Lossless=2, EZKeepGrain=0.4, Sharpness=0.1, TR2=0, TFF=True)
result = result + haf.QTGMC(core.std.Trim(clp, 3936,4428), Preset='very fast', Search=5, SearchParam=8, PelSearch=8, ChromaMotion=True, ChromaNoise=False, SourceMatch=2, Lossless=2, EZKeepGrain=0.4, Sharpness=0.1, TR2=0, TFF=True, InputType=2)

result.set_output()

Thinking a bit further, I think I could use some Python scripting to autofill the Trims as I've collected all the parts like this.
#0, 719 i
#720, 2890 p
#2891, 3935 i
#3936, 4428 p
#4429, 6676 i
#6677, 6834 p
#6835, 10567 i
#10568, 12260 p
#12261, 23093 i
#23094, 23991 p
#23992, 24154 i
#24155, 25876 p
#25877, 26664 i
#26665, 30805 p
#30806, 31140 i
#31141, 40655 p
#40656, 43509 i
#43510, 43599 p
#43600, 44268 i
#44269, 44403 p
#44404, 44831 i
#44832, 45795 p
#45796, 47686 i

[DJATOM]

Apparently timecodes produced with vspipe are weird. Working solution is

import easyvfr # https://gist.github.com/chikuzen/5005590 (usage: http://csbarn.blogspot.com/2013/02/easyvfr-for-vapoursynth.html)
<...>
clp = core.dgdecodenv.DGSource(r"F:\Temp\Captures\monty\monty_s01e01.dgi", cl=244, cr=244)
qtgmc_common_opts = {'Preset': 'very fast', 'Search': 5, 'SearchParam': 8, 'PelSearch': 8, 'ChromaMotion': True, 'ChromaNoise': False, 'SourceMatch': 2, 'Lossless': 2, 'EZKeepGrain': 0.4, 'Sharpness': 0.1, 'TR2': 0, 'TFF': True}
clips = []
clips.append(haf.QTGMC(core.std.Trim(clp, 0,719), **qtgmc_common_opts))
clips.append(haf.QTGMC(core.std.Trim(clp, 720,2890), **qtgmc_common_opts, InputType=2))
clips.append(haf.QTGMC(core.std.Trim(clp, 2891,3935), **qtgmc_common_opts))
clips.append(haf.QTGMC(core.std.Trim(clp, 3936,4428), **qtgmc_common_opts, InputType=2))
vfr = easyvfr.EasyVFR(clips, base_num=25, base_den=1)
vfr.write_timecode(r'test.tc.txt')
vfr.splice_clips().set_output()

That way we have valid timecodes, after converting to v1 (tcConv) the result is
# timecode format v1
Assume 25.000000
0,1439,50.000000
3612,5701,50.000000

[Boulder]

Thanks a lot, that probably saves me a huge amount of manual work :)

[feisty2]

I updated to r49 and weird things happened.
I ran the same std.Convolution script for speed test and the script ran for 497.17fps, but it was 2400+fps before the update!
my custom GaussBlur filter also ran a lot slower, from 1800+fps before update to now 483.92fps (gcc -O3)

[Are_]

std.Convolution with same parameters as you runs at 2384 fps here (Linux), maybe Windows build is compiled without optimizations?
I also did try to run it with core.std.SetMaxCPU('none') but it made no difference? Maybe I'm too sleepy and I'm doing something wrong.
import vapoursynth as vs
core = vs.get_core()
core.std.SetMaxCPU('none')
clip = core.std.BlankClip(format=vs.GRAYS, length=100000, fpsnum=24000, fpsden=1001, keep=True)
clip = core.std.Convolution(clip, matrix=[1,2,1,2,4,2,1,2,1])
clip.set_output()

[feisty2]

std.Convolution with same parameters as you runs at 2384 fps here (Linux), maybe Windows build is compiled without optimizations?
I also did try to run it with core.std.SetMaxCPU('none') but it made no difference? Maybe I'm too sleepy and I'm doing something wrong.
import vapoursynth as vs
core = vs.get_core()
core.std.SetMaxCPU('none')
clip = core.std.BlankClip(format=vs.GRAYS, length=100000, fpsnum=24000, fpsden=1001, keep=True)
clip = core.std.Convolution(clip, matrix=[1,2,1,2,4,2,1,2,1])
clip.set_output()


could you compile this (https://github.com/IFeelBloated/vsFilterScript/blob/master/GaussBlur.hxx) with GCC10 -Ofast and run a speed test? :thanks:

[Are_]

I will give it a try in about one hour or so, I don't have GCC-10 installed and it will take a while here on Gentoo.

[ChaosKing]

std.Convolution with same parameters as you runs at 2384 fps here (Linux), maybe Windows build is compiled without optimizations?
I also did try to run it with core.std.SetMaxCPU('none') but it made no difference? Maybe I'm too sleepy and I'm doing something wrong.
import vapoursynth as vs
core = vs.get_core()
core.std.SetMaxCPU('none')
clip = core.std.BlankClip(format=vs.GRAYS, length=100000, fpsnum=24000, fpsden=1001, keep=True)
clip = core.std.Convolution(clip, matrix=[1,2,1,2,4,2,1,2,1])
clip.set_output()


R49 quick test on ryzen 2600, seems ok
vspipe.exe .\bla.vpy .
Output 100000 frames in 6.20 seconds (16138.35 fps) # without core.std.SetMaxCPU('none')
Output 100000 frames in 12.73 seconds (7856.92 fps) #with core.std.SetMaxCPU('none')

[sl1pkn07]

with/without dual xeon (:/) (linux, -02)


└───╼ vspipe test.vpy /dev/null
Output 100000 frames in 15.89 seconds (6293.29 fps)
└───╼ vspipe test.vpy /dev/null
Output 100000 frames in 9.40 seconds (10642.37 fps)


seems Konsole (KDE terminal) do strange things

lanuched the same in yakuake (based on konsole, not use as bakend)


┌─┤[$]|[sl1pkn07]|[sL1pKn07]|[~/aplicaciones/vapoursynth-git]|
└───╼ cat test.vpy
import vapoursynth as vs
core = vs.get_core()
core.std.SetMaxCPU('none')
clip = core.std.BlankClip(format=vs.GRAYS, length=100000, fpsnum=24000, fpsden=1001, keep=True)
clip = core.std.Convolution(clip, matrix=[1,2,1,2,4,2,1,2,1])
clip.set_output()
┌─┤[$]|[sl1pkn07]|[sL1pKn07]|[~/aplicaciones/vapoursynth-git]|
└───╼ vspipe test.vpy /dev/null
Output 100000 frames in 8.39 seconds (11923.86 fps)
┌─┤[$]|[sl1pkn07]|[sL1pKn07]|[~/aplicaciones/vapoursynth-git]|
└───╼ cat test.vpy
import vapoursynth as vs
core = vs.get_core()
#core.std.SetMaxCPU('none')
clip = core.std.BlankClip(format=vs.GRAYS, length=100000, fpsnum=24000, fpsden=1001, keep=True)
clip = core.std.Convolution(clip, matrix=[1,2,1,2,4,2,1,2,1])
clip.set_output()
┌─┤[$]|[sl1pkn07]|[sL1pKn07]|[~/aplicaciones/vapoursynth-git]|
└───╼ vspipe test.vpy /dev/null
Output 100000 frames in 7.32 seconds (13656.67 fps)
┌─┤[$]|[sl1pkn07]|[sL1pKn07]|[~/aplicaciones/vapoursynth-git]|
└───╼


htop with vspipe in konsole shot (https://i.ibb.co/YdYLj0z/Screenshot-20200329-192231.png)
htop with vspipe in yakuake shot (https://i.ibb.co/SXJ75C3/Screenshot-20200329-193114.png)

[leon]

Why does R49 installer force the download of vc++ 2019?

[Myrsloik]

Why does R49 installer force the download of vc++ 2019?

Because your runtimes are old and you didn't unchecked the option.

[leon]

You mean it checks for the installed runtimes? Because I'd already installed both x86 and x64 versions of it. You're right there's an option for it which I somehow missed.
Thank you.

BTW, I installed Python 3.8 in Program Files and moved its path to the end of PATH variable so that I'd be able to use the already installed 3.7.4 version, things appear to work so far, but I thought I'd ask here whether that's OK or not.

P.S. I updated from R45 so I thought I'd see some speed improvements considering AVX2 has been added since that version, but I got almost the same speeds, so was wondering if there's a way to check whether I was doing something wrong and that AVX2 was actually being used.

[Myrsloik]

You mean it checks for the installed runtimes? Because I'd already installed both x86 and x64 versions of it. You're right there's an option for it which I somehow missed.
Thank you.

BTW, I installed Python 3.8 in Program Files and moved its path to the end of PATH variable so that I'd be able to use the already installed 3.7.4 version, things appear to work so far, but I thought I'd ask here whether that's OK or not.

P.S. I updated from R45 so I thought I'd see some speed improvements considering AVX2 has been added since that version, but I got almost the same speeds, so was wondering if there's a way to check whether I was doing something wrong and that AVX2 was actually being used.

Yes, it checks for the exact version of installed runtimes. Note that the 2019 ones get updated every few months and I install the most recent minor update too. That's why it appears to you like I'm "pointlessly" installing it.

Don't do that python mess. You've most likely ended up using the R48 python module and things just work by accident.

[leon]

...Note that the 2019 ones get updated every few months and I install the most recent minor update too...

Well, I wasn't aware of that.

So what would you suggest? How can I keep 3.7 alongside 3.8 and make VS use it?
Does that also explain the speed problem?

[amayra]

i try run new VS R49 with latest version of mpv shinchiro build but mpv close after i open file and my script work fine in MPC
here my log file :
[ 5.731][v][cplayer] Opening failed or was aborted: C:\my file\mpv\test\test4.vpy
[ 5.731][v][cplayer] Running hook: ytdl_hook/on_load_fail
[ 5.731][v][ytdl_hook] full hook
[ 5.731][v][cplayer] finished playback, unrecognized file format (reason 4)
[ 5.731][e][cplayer] Failed to recognize file format.
[ 5.731][i][cplayer]
[ 5.731][i][cplayer] Exiting... (Errors when loading file)
[ 5.731][d][ytdl_hook] Exiting...
[ 5.731][d][stats] Exiting...
[ 5.731][d][cplayer] Run command: change-list, flags=64, args=[name="shared-script-properties", operation="remove", value="osc-margins"]
[ 5.731][v][cplayer] Set property: shared-script-properties -> 1
[ 5.731][d][osc] Exiting...
[ 5.732][d][console] Exiting...
[ 5.734][d][vo/gpu] flushing shader cache
[ 5.736][v][vo/gpu/win32] uninit

all vpy file after update stop working even with new clean mpv setup

[stax76]

@amayra

shinchiros builds don't have vs enabled in ffmpeg, see here:

https://forum.doom9.org/showthread.php?t=180433

[amayra]

@amayra

shinchiros builds don't have vs enabled in ffmpeg, see here:

https://forum.doom9.org/showthread.php?t=180433

he/she write in sourceforge :
Is vapoursynth supported?
Starting build 20171229, it was compiled with vapoursynth. If you want to use vapoursynth's filters, make sure to install vapourysnth and python3 on your own. Portable version should also works. You can read how-to setup here:
so this is lie :mad:

[stax76]

It supports vs and ffmpeg filters but not vs source support with ffmpeg libavformat, these are two independent things.

[amichaelt]

he/she write in sourceforge :

so this is lie :mad:

No, you just misread what they wrote in that post.

Just read the output of what you posted:

[ 5.731][v][cplayer] finished playback, unrecognized file format (reason 4)
[ 5.731][e][cplayer] Failed to recognize file format.

[amayra]

No, you just misread what they wrote in that post.

Just read the output of what you posted:

i thought this mean mpv can't unrecognized vpy after new VS version
so what this mean than ?

[amichaelt]

i thought this mean mpv can't unrecognized vpy after new VS version
so what this mean than ?

It means there's something wrong with mpv or with your build. You need to open a ticket with the person who makes the build scripts.

There github page also says:

vapoursynth (R48)

So they need to fix something.

[stax76]

It means there's something wrong with mpv or with your build. You need to open a ticket with the person who makes the build scripts.

You understand mpv and what I wrote before?

[amayra]

to be honest i couldn't build mpv by myself, maybe i'm too stupid or compilation process it's just a too complicated without reason

anyway used shinchiro build with R48 and python 37 and this give me this error:

[lavf] avformat_open_input() failed

my conclusion is as follows MPV doesn't support Vapoursynth file by default :'(

[sl1pkn07]

to be honest i couldn't build mpv by myself, maybe i'm too stupid or compilation process it's just a too complicated without reason

anyway used shinchiro build with R48 and python 37 and this give me this error:



my conclusion is as follows MPV doesn't support Vapoursynth file by default :'(

try with https://github.com/mpv-player/mpv/blob/master/DOCS/man/vf.rst (the vapoursynth part)

[stax76]

try with https://github.com/mpv-player/mpv/blob/master/DOCS/man/vf.rst (the vapoursynth part)

It's not exactly what he wants, that is opening a vpy file:

mpv test.vpy

That is not supported by shinchiros builds because ffmpeg is configured without vapoursynth support. One way I'm aware to check this is:


launching mpv from the console
open osd console
enter input command: print-text ${demuxer-lavf-list}


This will print the supported demuxer list to the attached console, this can also be done with mpv.net as it has advanced console support but since it uses also shinchiros builds it can't open vpy either, but it's on my to-do list to enable it for mpv.net by making my own builds.

[sl1pkn07]

play directly vpy files with mpv is a secury flaw, because vpy is in essential a python script. you can craft a python script as vpy wich delete or formated enterely the hardisk and ejecute it with mpv

https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/7074a7ccd9a4d4e445252780fd182aa0b3778b79

[LigH]

Need ffmpeg / mpv with VapourSynth support? Compile it yourself with the media-autobuild suite.

[stax76]

play directly vpy files with mpv is a secury flaw, because vpy is in essential a python script. you can craft a python script as vpy wich delete or formated enterely the hardisk and ejecute it with mpv

https://git.ffmpeg.org/gitweb/ffmpeg...182aa0b3778b79

If possible I consider disabling it by default with a setting, mpc-be has it enabled by default btw.


Need ffmpeg / mpv with VapourSynth support? Compile it yourself with the media-autobuild suite.

I might take a look, primary resource will be a guide written by quot27. It's just one of many things I might do at one time.

[sl1pkn07]

ffmpeg needs set ' --enable-vapoursynth' (needs the headers for compile) , mpv is autoconfigurable if detect vapursynth, only have a option for disable it


--disable-vapoursynth
disable VapourSynth filter bridge [autodetect]

[stax76]

Sorry but I cannot follow.

[qyot27]

shinchiro's builds have had vapoursynth enabled in ffmpeg since December when this came up before. It's up to the user to pass --demuxer-lavf-format=vapoursynth to mpv or put it in their config file.

[stax76]

You mean it's supposed to work now? I tried print-text ${demuxer-lavf-list} in the osd console and it shows vapoursynth, in mpv.conf I have:

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

But it's still not playing vpy, process just dies, both mpv and mpv.net, shinchiro builds from last month.

[qyot27]

https://github.com/shinchiro/mpv-winbuild-cmake/commit/70ecb49318950f6e4518d91b28770e06eea2d74c

All the builds after that should have had their ffmpeg updated if the build script is run in total every time. But I did check the most recent build, mpv-x86_64-20200405-git-c5f8ec7.7z, and all it needed was demuxer-lavf-format.

And with https://github.com/shinchiro/mpv-winbuild-cmake/commit/0810de172dd335a4168fdd7cbe07b59919c53849, it'll use R49 and Python 3.8 (but there's currently no builds including that, just the script).

[stax76]

OK, waiting for the next build then, thanks.

[feisty2]

@Myrsloik
is thread_local (https://en.cppreference.com/w/cpp/language/storage_duration) compatible with the multi-threading mechanism of vaporsynth? I have to use a global variable to extend the lifetime of temporary objects in some corner cases. (https://github.com/IFeelBloated/vsFilterScript/blob/master/Map.hxx#L84) the thread_local variable is exclusive to each thread like regular local variables, but has a lifetime similar to static variables, it should work with any form of multi-threading, but I just wanna make sure here.

[Myrsloik]

@Myrsloik
is thread_local (https://en.cppreference.com/w/cpp/language/storage_duration) compatible with the multi-threading mechanism of vaporsynth? I have to use a global variable to extend the lifetime of temporary objects in some corner cases. (https://github.com/IFeelBloated/vsFilterScript/blob/master/Map.hxx#L84) the thread_local variable is exclusive to each thread like regular local variables, but has a lifetime similar to static variables, it should work with any form of multi-threading, but I just wanna make sure here.

Anything goes. Thread local has no magic properties.

[amayra]

Need ffmpeg / mpv with VapourSynth support? Compile it yourself with the media-autobuild suite.

do you even realize this is not something average joe can do simply ?

[_Al_]

Is BestAudioSource.dll working with portable setup? For latest downloads it gives me error that it is older API 3.6 and BestAudioSource needs 3.7.
from vapoursynth import core
print(vs)
print(core.version())
core.std.LoadPlugin(r'F:\portable_vs\vapoursynth64\plugins\BestAudioSource.dll')
#
audio = vs.core.bas.Source('video.mp4', track=-1)
audio.set_output(1)

F:\portable_vs>python --version
Python 3.8.2

F:\portable_vs>python audio.py
<module 'vapoursynth' from 'F:\\portable_vs\\vapoursynth.cp38-win_amd64.pyd'>
VapourSynth Video Processing Library
Copyright (c) 2012-2020 Fredrik Mellbin
Core R49
API R3.6
Options: -

Traceback (most recent call last):
File "audio.py", line 6, in <module>
core.std.LoadPlugin(r'F:\portable_vs\vapoursynth64\plugins\BestAudioSource.dll')
File "src\cython\vapoursynth.pyx", line 1852, in vapoursynth.Function.__call__
vapoursynth.Error: Core only supports API R3.6 but the loaded plugin requires API R3.7; Filename: F:\portable_vs\vapoursynth64\plugins\BestAudioSource
.dll; Name: Best Audio Source