Vapoursynth

[Myrsloik]

Behold the glory of R30! Now with new features and stuff!

The usual blog post with a summary of the interesting changes. (http://www.vapoursynth.com/2016/01/r30-recommended-by-9-out-of-10-installer-haters/)

Full changelog in the first post as usual.

[RiCON]

As a note, autobuild suite (https://github.com/jb-alvarado/media-autobuild_suite) has been updated to also work with portable installations.

[jmartinr]

Tried to compile R30. I'm quite new to Linux. So I'm asking here.

Compiled ZIMG allright, but Vapoursynth is giving troubles. Configure gives me:
checking for ZIMG... yes
configure: error: failed to link zimg. See config.log for details.
I'm on Ubuntu (Mint). Fiddled a bit, but am really stuck here.

[an3k]

Tried to compile R30. I'm quite new to Linux. So I'm asking here.

Compiled ZIMG allright, but Vapoursynth is giving troubles. Configure gives me:
checking for ZIMG... yes
configure: error: failed to link zimg. See config.log for details.
I'm on Ubuntu (Mint). Fiddled a bit, but am really stuck here.

How have you compiled ZIMG? Can you post the full command lines you used for ./configure, make and make install? Also please post the whole content of config.log (same directory in which you run ./configure) to pastebin.com and link it here.

[jmartinr]

How have you compiled ZIMG? Can you post the full command lines you used for ./configure, make and make install? Also please post the whole content of config.log (same directory in which you run ./configure) to pastebin.com and link it here.
I redid the steps and discovered that I had used the wrong version of ZIMG. I feel stupid. The good news is that I now understand the error and that it's gone. Thanks for pointing me in the right direction.

However... the bad news is that make now gives an error:
make: *** No rule to make target `src/core/vsresize.c', needed by `src/core/libvapoursynth_la-vsresize.lo'. Stop.

[an3k]

I redid the steps and discovered that I had used the wrong version of ZIMG. I feel stupid. The good news is that I now understand the error and that it's gone. Thanks for pointing me in the right direction.

However... the bad news is that make now gives an error:

I know that feeling. Don't worry ;) You're welcome.

I just ran my build_script which uses the most recent version from git itself and I had no errors. That means that everything is fine with VapourSynth R30 but not with your build environment.

I just checked by logs and environment and actually there is no vsresize.c but vsresize.cpp. Looks like your source directory for VapourSynth is not clean.
I would suggest to run make distclean inside the vapoursynth directory and if that doesn't help to delete the current directory and to download vapoursynth r30 again.

[jmartinr]

I know that feeling. Don't worry ;) I would suggest to run make distclean inside the vapoursynth directory and if that doesn't help to delete the current directory and to download vapoursynth r30 again.
Thanks. Deleted the directory, retried and succeeded.

After that at the first try to use the freshly installed Vapoursynth I got :
Failed to initialize VapourSynth environment
But that was fixed by using:
LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/usr/local/lib"
export LD_LIBRARY_PATH
PYTHONPATH="${PYTHONPATH}:/usr/local/lib/python3.4/site-packages"
export PYTHONPATH
It's all fine and dandy now. Thanks again!

[qyot27]

But that was fixed by using:
LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:/usr/local/lib"
export LD_LIBRARY_PATH
This is what running ldconfig is for. Manually adding a path that should already be on the search path is clearly not correct. Manually overriding LD_LIBRARY_PATH is only for situations where the libs aren't installed in an area the system is set to detect them from - a user's $HOME, for instance. But /usr/local is a standard system-detected area (on Linux, anyway), hence forcing LD_LIBRARY_PATH is wrong here.

PYTHONPATH="${PYTHONPATH}:/usr/local/lib/python3.4/site-packages"
export PYTHONPATH
And this is why Ubuntu (well, likely any Debian derivative) requires using ./setup.py install after make install. That allows the system to assess where it's going and put it in the correct place.

[jmartinr]

This is what running ldconfig is for. Manually adding a path that should already be on the search path is clearly not correct. Manually overriding LD_LIBRARY_PATH is only for situations where the libs aren't installed in an area the system is set to detect them from - a user's $HOME, for instance. But /usr/local is a standard system-detected area (on Linux, anyway), hence forcing LD_LIBRARY_PATH is wrong here.
You're right. This is not needed at all. Bad Googling. I was just happy it worked.

And this is why Ubuntu (well, likely any Debian derivative) requires using ./setup.py install after make install. That allows the system to assess where it's going and put it in the correct place.
Thanks for the direction.
At first this command picked up my Python 2.7 installation, but running "python3.4 setup.py install" made it all work perfectly. :thanks:

[ryrynz]

Behold the glory of R30! Now with new features and stuff!


Back in 2012 you said you'd expect Vapoursynth to have possibly resolve any threading issues unlike Avisynth MT. How's things in this area ATM performance and stability wise vs Avisynth MT?

[Myrsloik]

Avisynth mt is still just a bad joke and it's just as prone to crashing as it's always been because of its horrible memory management.

VapourSynth on the other hand just works. Speed comparisons between the two have never interested in me for that reason.

And threading of course works very well when done right. Which it is in VapourSynth.

[salty1]

where should i put the .py scripts in for the portable version?:confused::confused:

[tObber166]

Hi


When using for instance QTGMC I know you set "Tff=true" or false to indicate field parity.

Is there a way to indicate (like in AviSynth, AssumeTFF/BFF) to a whole script in vapoursynth?


In the documentation it says the "frame property _FieldBased" can be set to indicate TFF or BFF. How do I use it?


clip = _FieldBased=TFF ???



sorry, I am new to using vapoursynth and I'm trying to learn


//Thanks!

[jackoneill]

Hi


When using for instance QTGMC I know you set "Tff=true" or false to indicate field parity.

Is there a way to indicate (like in AviSynth, AssumeTFF/BFF) to a whole script in vapoursynth?


In the documentation it says the "frame property _FieldBased" can be set to indicate TFF or BFF. How do I use it?


clip = _FieldBased=TFF ???



sorry, I am new to using vapoursynth and I'm trying to learn


//Thanks!

You can use SetFrameProp (http://www.vapoursynth.com/doc/functions/setframeprop.html) right after the source filter.

[tObber166]

:thanks:

[speedyrazor]

Hi, I am opening a Quicktime Uncompressed RGB, which I am piping to ffmpeg to convert to Quicktime Prores. My first attempt yielded an error:

Error: Can only apply y4m headers to YUV and Gray format clips

So I added core.fmtc.matrix(ret, col_fam=vs.YUV).
Just wanted to check I am doing things correctly and in the right order.
Here's my script:

import vapoursynth as vs
core = vs.get_core()
ret = core.lsmas.LibavSMASHSource(source=r"RGB.mov")
ret = core.fmtc.resample (clip=ret, w=720, h=576, css="444", kernel="spline36")
ret = core.fmtc.matrix (clip=ret, mats="709", matd="601")
ret = core.std.AssumeFPS(ret, fpsnum=25, fpsden=1)
ret = core.fmtc.matrix(ret, col_fam=vs.YUV)
ret = core.fmtc.bitdepth (clip=ret, bits=10)
ret.set_output()

[jackoneill]

Does it make any sense to convert from 709 to 601 when both your input and output are RGB?

You can pipe raw RGB if you don't use the --y4m parameter. You'll have to tell ffmpeg the dimensions and format, though.

[speedyrazor]

Does it make any sense to convert from 709 to 601 when both your input and output are RGB?

You can pipe raw RGB if you don't use the --y4m parameter. You'll have to tell ffmpeg the dimensions and format, though.

Sorry, somewhat new to this.
So in RGB there is no 709 / 601?
would piping raw RGB into ffmpeg be better that converting to YUV?

[sneaker_ger]

You should output the format your encoder needs as input.

[speedyrazor]

You should output the format your encoder needs as input.
Cool, so this makes sense with a Quicktime RGB input piping to ffmpeg?

import vapoursynth as vs
core = vs.get_core()
ret = core.lsmas.LibavSMASHSource(source=r"RGBInput.mov")
ret = core.fmtc.resample (clip=ret, w=720, h=576, css="444", kernel="spline36")
ret = core.fmtc.matrix (clip=ret, col_fam=vs.YUV, mats="709", matd="601")
ret = core.fmtc.bitdepth (clip=ret, bits=10)
ret = core.std.AssumeFPS(ret, fpsnum=25, fpsden=1)
retFinal = ret
retFinal.set_output()

UPDATE:
Actaully this produces a very purple output :(

[sneaker_ger]

That does not tell me anything about what the format you want to encode to.

[speedyrazor]

That does not tell me anything about what the format you want to encode to.

Sorry, I am piping to ffmpeg, going to Quicktime Prores HQ.

[sneaker_ger]

So you want your output to have the following properties:
- YUV
- 4:2:2
- 10 bits per sample

I can already see you are not outputting 4:2:2.

If you are unsure do:
vspipe --info "script.vpy" -
It should show "Format Name: YUV422P10"

[speedyrazor]

So you want your output to have the following properties:
- YUV
- 4:2:2
- 10 bits per sample
How would I lay that out with my script please?

[sneaker_ger]

import vapoursynth as vs
core = vs.get_core()
ret = core.lsmas.LibavSMASHSource(source=r"RGBInput.mov")
ret = core.std.AssumeFPS(ret, fpsnum=25, fpsden=1)

ret = core.fmtc.matrix (clip=ret, mat="601", col_fam=vs.YUV, bits=16)
ret = core.fmtc.resample (clip=ret, w=720, h=576, css="422", kernel="spline36")
ret = core.fmtc.bitdepth (clip=ret, bits=10)

ret.set_output()

[speedyrazor]

ret = core.fmtc.matrix (clip=ret, mat="601", col_fam=vs.YUV, bits=16
Forgot to mention that my Quicktime RGB source is HD, and I'm down-converting to PAL, so will mat="601" correctly convert from 709 to 601?

[foxyshadis]

Forot to mention that my Quicktime RGB source is HD, and I'm downconverting to PAL, so will mat="601" correctly convert from 709 to 601?

601, 709, and 2020 only apply to converting to and from YUV; RGB is RGB, it's already correct and you only have to convert once to the correct form of YUV. (You can think of converting from 709->601 as actually being 709->RGB->601, it's equivalent.) However, beyond 601/709, there's the issue of color-calibration; before converting to YUV you MUST convert to sRGB first. They're only defined against sRGB, and fmtconv doesn't have any way to use other calibrated profiles. If it's already in sRGB or close enough, that's fine.

[speedyrazor]

601, 709, and 2020 only apply to converting to and from YUV; RGB is RGB, it's already correct and you only have to convert once to the correct form of YUV. (You can think of converting from 709->601 as actually being 709->RGB->601, it's equivalent.) However, beyond 601/709, there's the issue of color-calibration; before converting to YUV you MUST convert to sRGB first. They're only defined against sRGB, and fmtconv doesn't have any way to use other calibrated profiles. If it's already in sRGB or close enough, that's fine.
A good explanation, thanks.

[speedyrazor]

I am running multiple instances of VapourSynth / VSPipe.exe piping to ffmpeg using --y4m, which will be running up to 4 instances all with different files / profiles, within a python application.
I am currently using the latest R30 64bit portable, piping to 32bit ffmpeg (as I am having to use Avisynth for audio).
I just wanted to check if there is anything I should look out for, anything specific I should, or shouldn't, be doing when running multiple instances of VapourSynth / VSPipe.exe piping to ffmpeg?

Kind regards.

[littlepox]

Here is the cry for 64bit avisynth 2.5 plugin support. I cannot live without tivtc.

I have tried the vivtc, but the only conclusion I can say is it should never be used for (even slightly) irregular teleclined sources.

Meanwhile, I would like to keep other stuffs in 64bit as much as possible. My current solution is to use avfs to get a virtual avi file. It works, just not as convenient as desired.

[jackoneill]

Here is the cry for 64bit avisynth 2.5 plugin support. I cannot live without tivtc.

I have tried the vivtc, but the only conclusion I can say is it should never be used for (even slightly) irregular teleclined sources.

Meanwhile, I would like to keep other stuffs in 64bit as much as possible. My current solution is to use avfs to get a virtual avi file. It works, just not as convenient as desired.

How do you call TFM and TDecimate? What about VFM and VDecimate? What goes wrong with VIVTC? Can you post a small sample where VIVTC doesn't work? Maybe VIVTC can be fixed.

If I remember correctly, 64 bit Avisynth 2.5 plugins are incompatible with VapourSynth due to a mistake made when Avisynth 2.5 was modified to work in 64 bits (distances from one image plane to the next stored in a 32 bit type).

[feisty2]

Or easier, compile tivtc with an avs2.6 header

[littlepox]

How do you call TFM and TDecimate? What about VFM and VDecimate? What goes wrong with VIVTC? Can you post a small sample where VIVTC doesn't work? Maybe VIVTC can be fixed.

If I remember correctly, 64 bit Avisynth 2.5 plugins are incompatible with VapourSynth due to a mistake made when Avisynth 2.5 was modified to work in 64 bits (distances from one image plane to the next stored in a 32 bit type).

generally the problem is no matter how you try to do the field matching in VFM, there are always (many) failed cases, and tfm solves them with default settings(with pp off; no automated deint).

I have made sure that field order is properly addressed and tried all 5 modes. Based on the observations of _Combed, VFM does detect combed scenes vs non-combed scenes; it's just the field matching result is so annoying. You see a lot of unmatched scenes where tfm gets everything perfectly with plain settings.

[feisty2]

generally the problem is no matter how you try to do the field matching in VFM, there are always (many) failed cases, and tfm solves them with default settings.

I have made sure that field order is properly addressed and tried all 5 modes. Based on the observations of _Combed, VFM does detect combed scenes vs non-combed scenes; it's just the field matching result is so annoying. You see a lot of unmatched scenes where tfm gets everything perfectly with plain settings.

I ain't seen anything vivtc doing different from tivtc (pp=0) so far, sure ya got that pp=0 part right? Cuz vivtc got no post processing unlike tivtc.

Edit: okay, too slow

[littlepox]

https://onedrive.live.com/redir?resid=58344014938A89DC!116&authkey=!AEYTo_0RLVTTomM&ithint=file%2cmkv

for anyone interested in debugging, just try this file for field-matching.(we are not yet to discuss the vdecimate)
For avisynth, simply call tfm(pp=0) and you shall see it (should) does everything fine.
For vapoursynth, I have no idea how to get it done through vfm.

[jackoneill]

https://onedrive.live.com/redir?resid=58344014938A89DC!116&authkey=!AEYTo_0RLVTTomM&ithint=file%2cmkv

for anyone interested in debugging, just try this file for field-matching.(we are not yet to discuss the vdecimate)
For avisynth, simply call tfm(pp=0) and you shall see it (should) does everything fine.
For vapoursynth, I have no idea how to get it done through vfm.

Is there a particular frame I should be looking at? Because based on frames 417-473 from the simple script below, it appears to be working. I get only progressive frames, with the expected duplicates.

import vapoursynth as vs
core = vs.get_core()

clip = core.ffms2.Source("/tmp/00005.mkv")
clip = core.vivtc.VFM(clip, order=1)

clip.set_output()

What source filter did you use? Any other filters between the source filter and VFM?

[Myrsloik]

Is there a particular frame I should be looking at? Because based on frames 417-473 from the simple script below, it appears to be working. I get only progressive frames, with the expected duplicates.

import vapoursynth as vs
core = vs.get_core()

clip = core.ffms2.Source("/tmp/00005.mkv")
clip = core.vivtc.VFM(clip, order=1)

clip.set_output()

What source filter did you use? Any other filters between the source filter and VFM?

You have to add mode=2 to make a single frame at a bad cut turn out ok. But with
clip = core.vivtc.VFM(clip, order=1, mode=2)
every single frame is correct. I checked it manually. There's only one that slips through when the interlaced text shows up. But then no match is "correct" so it doesn't count. I don't see the bug either.

[littlepox]

WOW, that is surprising. I have been using lsmas.LWLibavSource(fileName, threads=1, repeat=True), and the result is just severely broken. No other filters are in between; so does anyone wish to try:

import vapoursynth as vs
core = vs.get_core(threads=4)

src = core.lsmas.LWLibavSource("00005.mkv", threads=1, repeat=True,fpsnum=30000,fpsden=1001)
res = core.vivtc.VFM(src, order=1)

res.set_output()


I'm looking forward to your replies. It would be best if I only need to update my plugins. But currently I'm using vs R30 with lsmas updated only weeks ago. When I go back home I'd figure out what happens if I switch to ffms2 and update this post.

[littlepox]

OK, updating:

ffms2 works pretty fine here. Only a few scenes with interlaced text not matched, but it is desired and _combed properly reported;

lsmashsource(L-SMASH-Works-r859-20160109-64bit.7z) will not work. you see a lot of unmatched scenes.

It looks like I can happily switch to ffms2 for interlaced input right now, but any volunteers to figure out what is wrong with its counterpart?

[jackoneill]

WOW, that is surprising. I have been using lsmas.LWLibavSource(fileName, threads=1, repeat=True), and the result is just severely broken. No other filters are in between; so does anyone wish to try:

import vapoursynth as vs
core = vs.get_core(threads=4)

src = core.lsmas.LWLibavSource("00005.mkv", threads=1, repeat=True,fpsnum=30000,fpsden=1001)
res = core.vivtc.VFM(src, order=1)

res.set_output()


I'm looking forward to your replies. It would be best if I only need to update my plugins. But currently I'm using vs R30 with lsmas updated only weeks ago. When I go back home I'd figure out what happens if I switch to ffms2 and update this post.

Using fpsnum and fpsden is what causes your problem. Why are you passing them?

+ fpsnum (default : 0)
Output frame rate numerator for VFR->CFR (Variable Frame Rate to Constant Frame Rate) conversion.

There is no VFR on blurays. You don't need this. If you want vspipe to report 30000/1001, use AssumeFPS (http://www.vapoursynth.com/doc/functions/assumefps.html), which doesn't touch the frames.

[littlepox]

Using fpsnum and fpsden is what causes your problem. Why are you passing them?


Indeed, removing them solves the problem. I used to pass them for some broken ts files which may give you wired fps like 29.968 or 29.972. never realized it shall change the frame, and I thought it to be an alias for assumefps()

[speedyrazor]

Hi, I am getting random "VSPipe.exe has stopped working" errors whilst piping to ffmpeg on a Windows Server 2012 machine. Below is what I am doing:

VapourSynth script:
import vapoursynth as vs
core = vs.get_core()
ret = core.lsmas.LibavSMASHSource(source=r"MovieFile.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=8)
ret.set_output()

And my command line:
VSPipe.exe --y4m "VapourSynthScipt.vpy" - | ffmpeg.exe -f yuv4mpegpipe -i - "OutputFile.mov"

This all works nicely, but sometimes on certain files I am getting "VSPipe.exe has stopped working" error.

And heres the details of the crash:

Problem signature:
Problem Event Name: BEX64
Application Name: VSPipe.exe
Application Version: 0.0.0.0
Application Timestamp: 569e558f
Fault Module Name: ucrtbase.DLL
Fault Module Version: 10.0.10240.16390
Fault Module Timestamp: 55a5b718
Exception Offset: 0000000000065a4e
Exception Code: c0000409
Exception Data: 0000000000000007
OS Version: 6.2.9200.2.0.0.272.7
Locale ID: 2057
Additional Information 1: 75fb
Additional Information 2: 75fb052fde80787a73a20c1e44b677a1
Additional Information 3: b53e
Additional Information 4: b53e9f85d450d6306cf57d374707b4b1

The same issue seems to have been reported earlier in this thread: http://forum.doom9.org/showthread.php?p=1753452&highlight=LWLibavSource+simply+doesn%27t+test.avi#post1753452

Kind regards.

[Izuchi]

Is there VS support in VirtualDub yet?

[sneaker_ger]

VapourSynth has had a VfW module to enable support for software like VirtualDub for years.

[LigH]

VirtualDub can handle .vpy as video source (I believe it even has a matching filename extension entry in the "Open File" types selector); but there is no support as filter only scripts to substitute .vdf filters – that could be interesting.

[Myrsloik]

Here's R31 RC1 (https://dl.dropboxusercontent.com/u/73468194/vapoursynth-r31-RC1.exe)

It's mostly just to fix resizing issues caused by switching to zimg. You should also go and test the latest version of imwri that's finally gotten a saner and up to date windows build.

Changes:
the imwri namespace will now be imwrif when compiled against a hdri imagemagick, this is to properly distinguish it from the integer version which has distincly different input and output support
the installer now also writes the path to vapoursynth.dll and vsscript.dll to the registry to make them easier to locate, vsscript.dll will probably stop being installed in the system dir in r33
changed registry entry structure to make more sense (no more 32/64 suffix, instead writes to HKLM32 or 64 as appropriate), the old entries will be kept for a few versions
portable version now includes vsfs and vsvfw to be more complete
the resize matrix check will no longer reject several valid combinations
more zimg bug fixes, to/from float conversions will no longer sometimes get stuck

[speedyrazor]

Actually it seems like LWLibavSource simply doesn't like your test.avi. It crashes here too and it's because it returns a null frame without setting an error. Definitely a bug in the plugin.
New version of L-SMASH Source:

L-SMASH-Works-r875-20160202-64bit.7z

Hope it fixes some of the issues?

[speedyrazor]

I have just done some tests with the new version, and I can confirm that VSPipe.exe no longer crashes on the files L-SMASH Source doesn't like, BUT..... instead it freezes the last 'good' frame and continues to pipe. :(
I would like to know why L-SMASH Source is not liking certain Quicktime Prores files as everything else is accepting these files fine, it seems random as to wether L-SMASH Source likes a file or not?
I can take two files, which seemingly are exactly the same, one file L-SMASH Source likes, the other it does not :(
Let me know if there is anything I can provide to help.

UPDATE:
Just discovered that at the exact frame L-SMASH Source decides it doesn't like the file, I found digital corruption (picture breaks up with colored blocks), so on a good note, it a digital glitch finder!
I'll do some more tests to see if std out from VSPipe reports something weird and maybe I could catch it that way, would be nice if VapourSynth would Pipe something I could catch at the std out from ffmpeg though.

Kind regards.

[speedyrazor]

I am having trouble getting the stderr out of VSPipe. Below is what I am using, but nothing is being printed out.
What is the correct method please?

import subprocess
from subprocess import Popen, PIPE, STDOUT
import time

command = 'VSPipe.exe --progress --y4m vpyScript.vpy - | ffmpeg.exe -f yuv4mpegpipe -i - -c:v prores -an -y outputMovie.mov'
process1 = Popen(command, stderr=PIPE, shell=True)
while True:
line = process1.stderr.readline().decode('utf-8')
print line
time.sleep(0.1)

UPDATE:
Forgive me, this is working well, both VSPipe and ffmpeg stderr are being printed.

Kind regards.

[splinter98]

UPDATE:
Forgive me, this is working well, both VSPipe and ffmpeg stderr are being printed.

To separate out vspipe and ffmpeg's output you need to create separate subprocess objects and pipe them together. Something like (Untested):


#!python3
import threading
from subprocess import Popen, PIPE, STDOUT

vspipe_cmd = ['VSPipe', '--progress', '--y4m', 'vpyScript.vpy', '-']
ffmpeg_cmd = ['ffmpeg', '-f', 'yuv4mpegpipe', '-i', '-', '-c:v', 'prores', '-an', '-y', 'outputMovie.mov']
vspipe_process = Popen(vspipe_cmd, stdout=PIPE, stderr=PIPE)
ffmpeg_process = Popen(ffmpeg_cmd, stdin=vspipe.stdout, stderr=PIPE)
vspipe_process.stdout.close() #Allow vspipe to receive a SIGPIPE if ffmpeg exists

def output_stderr(process, name):
for line in process.stderr:
print(name, ":", line)

vspipe_output = threading.Thread(target=output_stderr, args=(vspipe_process, "VSPIPE"))
ffmpeg_output = threading.Thread(target=output_stderr, args=(ffmpeg_process, "FFMPEG"))

vspipe_output.start()
ffmpeg_output.start()