Log in

View Full Version : Vapoursynth


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 [29] 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100

Emulgator
24th November 2014, 16:19
Objection !
XP is still needed everywhere around and tools should be kept compatible, if possible.
(See the hassle with newer compilers (HCEnc), come codecs dropping XP support (UT),
unnecessary dependencies (NLE's only working in Vista or Win 7 like Vegas)
If this affects the here developed software as well,
all those would be mutually exclusive with certain valuable pieces of hardware and/or software,
which are often, although no longer maintained, very well functional.

Myrsloik
24th November 2014, 16:28
Objection !
XP is still needed everywhere around and tools should be kept compatible, if possible.
(See the hassle with newer compilers (HCEnc), come codecs dropping XP support (UT),
unnecessary dependencies (NLE's only working in Vista or Win 7 like Vegas)
If this affects the here developed software as well,
all those would be mutually exclusive with certain valuable pieces of hardware and/or software,
which are often, although no longer maintained, very well functional.

Where is XP actually needed? Name one relevant thing that isn't an internal enterprise system or a proprietary multimedia program with useless developers and yearly expensive updates.

And what does HCEnc's questionable code quality have to do with this?

Other things that dropped XP support: MICROSOFT

LoRd_MuldeR
24th November 2014, 17:10
Where is XP actually needed?

Actually you'll meet a lot of people who vigorously refuse to update from Windows XP to a somewhat up-to-date operating system (not necessarily Windows) for whatever reasons :p

I have pretty much given up on explaining that you cannot build a "secure" software stack on top of an operating system that is known to be flawed and that is certain to no longer receive any updates/fixes from the manufacturer...

(Note that, apparently, there are certain "embedded" editions of Windows XP that still receive updates. And some people claim you can get these updates into your "normal" Windows XP by means of dubious registry hacks)

See discussion here:
https://forum.doom9.org/showthread.php?t=171393

Myrsloik
24th November 2014, 17:11
Actually you'll meet a lot of people who refuse to update from Windows XP to a somewhat up-to-date operating system :p

See discussion here:
https://forum.doom9.org/showthread.php?t=171393

The same people also refuse to leave avisynth so that's not a real issue...

TheFluff
24th November 2014, 20:37
https://forum.doom9.org/showthread.php?t=171393

that thread has some exceptionally low quality argumentation, even by doom9's already low standards

just drop XP support already, it will never disappear if people don't stop supporting it and there's absolutely no reason to keep using it on an encoding box other than pure obstinacy

Wilbert
24th November 2014, 22:36
just drop XP support already, it will never disappear if people don't stop supporting it and there's absolutely no reason to keep using it on an encoding box other than pure obstinacy
Sure if you want more people to use VapourSynth, it would be logical to drop XP support.

Myrsloik
24th November 2014, 22:36
I've released R25 in all its glory. The usual blog post with the highlights. (http://www.vapoursynth.com/2014/11/r25-death-to-windows-xp/) Full changelog in the first post as usual and downloads on github (https://github.com/vapoursynth/vapoursynth) as usual.

Enjoy your dots. I'll release improved imwri builds in a day or two. After that I'll slowly add alpha support to FFMS2.

Myrsloik
24th November 2014, 22:41
Sure if you want more people to use VapourSynth, it would be logical to drop XP support.

Definitly does make sense. Since XP gets zero testing less people will get scared off by XP specific bugs. Not even the forum monkeys test things on XP enough these days.

Myrsloik
26th November 2014, 22:40
Here's something interesting for you all to try. R25 compiled with tcmalloc (https://www.dropbox.com/s/vbfcfp1y6a37lwb/vapoursynth-r25-tcmalloc.exe?dl=1). It should be faster than R25. Possibly quite a bit faster with lots of threads and high resolutions.

Benchmark your favorite script with both versions and report the results.

buchanan
27th November 2014, 00:33
Hello,

My quick & dodgy comparison :

VS x64, threads = 10

.avs source file (dss2mod 1920*1080i 25fps + a couple of very quick avisyntyh filters)
QTGMC (medium)
fmtconv resize to 1440*810
finesharp

Speed comparison (output to NUL)
VS25 : ~11 fps
VS25 tcmalloc : ~16 fps

CPU (other tasks running in background, but identical and almost constant at ~12% during each test)
VS25 : ~95%
VS25 tcmalloc : ~99%

Tests repeated twice : the results seem consistent down to 0.1 fps


Well, certainly not a proper benchmark in good conditions, but still, what a great boost !

buchanan
1st December 2014, 00:54
Hi Myrsloik,

I just realized that with R25tcmalloc (maybe R25 too ? didn't try), I can't load avisynth plugins anymore :

core.avs.LoadPlugin(path=r'c:\Program Files (x86)\VapourSynth\filtersx64\avs\FFT3DFilter.dll')

gives me an error : "No attribute with the name avs exists"
Is there something special related to avisynth compatibility in this version ?

Myrsloik
1st December 2014, 00:58
Can't load avisynth plugins on x64. It's never worked and never will because avisynth.h wasn't properly adjusted for 64bits.

buchanan
1st December 2014, 08:06
Oh, my bad, I forgot that

manolito
3rd December 2014, 11:04
that thread has some exceptionally low quality argumentation, even by doom9's already low standards

just drop XP support already, it will never disappear if people don't stop supporting it and there's absolutely no reason to keep using it on an encoding box other than pure obstinacy

You Guys are so arrogant, shame on you... I wonder why you even bother to use Windows at all, you belong into the Apple camp.

There is a growing number of people who despise the direction Microsoft is pushing its Windows operating system to. Have you ever heard of the ReactOS project? Would anyone of you be willing to make your software compatible with it once it is stable?

I guess not... :mad:

For the time being I am not giving up XP as well as AviSynth for a very simple reason. It works.

And a special remark to LoRd_MuldeR:
You always point out that you cannot build a "secure" software stack on top of an operating system that is known to be flawed.

This is none of your business. I can take responsibility for the security of my operating system quite well, thank you. I will certainly not blame you (or any software developer) for any security related problems of my operating system. Stop trying to educate and lecture your users, this is a very German attitude (I know because I am German, too).


Cheers
manolito

TurboPascal7
3rd December 2014, 13:25
Have you ever heard of the ReactOS project? Would anyone of you be willing to make your software compatible with it once it is stable?
I've heard a lot about ReactOS (being a Russian and all) and there's absolutely no reason for anyone to be compatible with it. It's already ancient and if it ever gets stable (which I doubt) it'll be outdated by decades right at the beginning. It's a fun research project but not a real OS anyone should be using.

So yeah, I totally support dropping XP.

Myrsloik
3rd December 2014, 15:34
You Guys are so arrogant, shame on you... I wonder why you even bother to use Windows at all, you belong into the Apple camp.

There is a growing number of people who despise the direction Microsoft is pushing its Windows operating system to. Have you ever heard of the ReactOS project? Would anyone of you be willing to make your software compatible with it once it is stable?

...

Cheers
manolito

I'll happily support reactos the day it's stable.

Bloax
3rd December 2014, 17:48
I can understand not wanting to use Windows >=8 but there's nothing peculiar about Windows 7 (although not being able to run 16-bit executables on x64 systems is a bit sad ;~;) and if you absolutely need to use something so ancient and unsupported that it only works on XP then you can always just dual-boot.

LoRd_MuldeR
4th December 2014, 01:07
and if you absolutely need to use something so ancient and unsupported that it only works on XP then you can always just dual-boot.

...or Windows XP Mode ;)

adrianmak
9th December 2014, 02:31
only work for python 3.x ?

My Windows 8.1 x64 installed 2.x only, which is used by other devel tools

and also, beside video encoder cmd line , which encoding tools accept vapoursynth script currently ?

does megui support ?

Are_
9th December 2014, 12:18
Yes, only python 3.4
You can install it alongside with 2.7

Virtualdub accepts the vpy scripts too, and you may like to use http://forum.doom9.org/showthread.php?t=170965 for editing.
Not sure if there is any automated suit out there that supports vapoursynth.

blindbox
11th December 2014, 07:48
The same people also refuse to leave avisynth so that's not a real issue...

If audio support is available in vapoursynth, I'd be willing to give vapoursynth a try. For now, avisynth stays.

My avisynth script involves a lot of trimming and concatenating. The lack of audio support makes this impossible/really hard with vapoursynth.

Disclaimer: I don't care for XP support, but there are reasons we are still staying with avisynth.

TheFluff
11th December 2014, 17:56
I wouldn't call cutting and splicing uncompressed audio a "really hard" problem.

foxyshadis
12th December 2014, 00:44
I wouldn't call cutting and splicing uncompressed audio a "really hard" problem.

It is when you get perfectly edited audio for free via AviSynth. Duplicating the work of a script in another set of tools is a lot of work, if it's at all complex.

kolak
26th December 2014, 14:09
Anyone capable of making vapoursynth Mac installer with image sequence and latest audio filters?

kaefert
28th December 2014, 11:22
Is there any linux desktop (ubuntu or linux mint) user that could point me to (or write me) a quick start guide for vapoursynth?

I've managed to get past the 'tesseract' not found problem during building (incomplete ubuntu package) with help of responses I got in the bugtracker @ https://github.com/vapoursynth/vapoursynth/issues/142

Now I was trying to get a first simple script to run which I mostly took from http://www.vapoursynth.com/doc/gettingstarted.html but I always end up with this error:
"Failed to initialize VapourSynth environment"

kaefert@mint ~/Videos $ vspipe --version
Failed to initialize VapourSynth environment

jackoneill
28th December 2014, 12:12
Is there any linux desktop (ubuntu or linux mint) user that could point me to (or write me) a quick start guide for vapoursynth?

I've managed to get past the 'tesseract' not found problem during building (incomplete ubuntu package) with help of responses I got in the bugtracker @ https://github.com/vapoursynth/vapoursynth/issues/142

Now I was trying to get a first simple script to run which I mostly took from http://www.vapoursynth.com/doc/gettingstarted.html but I always end up with this error:
"Failed to initialize VapourSynth environment"

You probably installed VapourSynth in the default prefix (/usr/local), which means the Python module (vapoursynth.so) is installed in a location that Python doesn't search by default. This should work:

PYTHONPATH=/usr/local/lib/python3.4/site-packages vspipe --version

I'll add a note about this in the INSTALL file.

kaefert
28th December 2014, 12:16
thanks jackoneill ! that worked :)
$ PYTHONPATH=/usr/local/lib/python3.4/site-packages vspipe --version
VapourSynth Video Processing Library
Copyright (c) 2012-2014 Fredrik Mellbin
Core R26
API R((3 << 16) | (1))

Next problem, how do I tell vapoursynth where to find ffms2?
$ PYTHONPATH=/usr/local/lib/python3.4/site-packages vspipe vapoursynth-sample.py -
Script evaluation failed:
Python exception: No attribute with the name ffms2 exists. Did you mistype a plugin namespace?
Traceback (most recent call last):
File "vapoursynth.pyx", line 1486, in vapoursynth.vpy_evaluateScript (src/cython/vapoursynth.c:25110)
File "vapoursynth-sample.py", line 11, in <module>
ret = core.ffms2.Source(source='Super Size Me.avi')
File "vapoursynth.pyx", line 1107, in vapoursynth.Core.__getattr__ (src/cython/vapoursynth.c:19224)
AttributeError: No attribute with the name ffms2 exists. Did you mistype a plugin namespace?

UPDATE1: this seems to work:
core.std.LoadPlugin(path='/usr/local/lib/libffms2.so')

UPDATE2: new problem:
$ PYTHONPATH=/usr/local/lib/python3.4/site-packages vspipe vapoursynth-sample.py -
Script evaluation failed:
Python exception: No attribute with the name avs exists. Did you mistype a plugin namespace?
Traceback (most recent call last):
File "vapoursynth.pyx", line 1486, in vapoursynth.vpy_evaluateScript (src/cython/vapoursynth.c:25110)
File "vapoursynth-sample.py", line 14, in <module>
ret = core.avs.UnDot(ret)
File "vapoursynth.pyx", line 1107, in vapoursynth.Core.__getattr__ (src/cython/vapoursynth.c:19224)
AttributeError: No attribute with the name avs exists. Did you mistype a plugin namespace?

so I guess I need a linux equivalent for this:
core.avs.LoadPlugin(path=r'c:\avisynth\UnDot.dll')

feisty2
28th December 2014, 12:39
I got a moron question, which will be faster working on single 16bit clip
"Lut" or "Expr" ?

Myrsloik
28th December 2014, 12:41
I got a moron question, which will be faster working on single 16bit clip
"Lut" or "Expr" ?

Lut is (probably) always faster when it's possible to use. The advantage of Expr is that it can work with more and higher bitdepth clips when Lut(2) would use too much memory.

Note that in some cases Expr may be faster when used cleverly. For example if you fold several luts together into one Expr use.

feisty2
28th December 2014, 12:46
thx :)
guess I'll change the sigmoid and gamma linear methods to "Lut" since they only take one input clip

kaefert
28th December 2014, 12:48
okey so after removing the UnDot part from the sample script, I can use this line
$ PYTHONPATH=/usr/local/lib/python3.4/site-packages vspipe --y4m vapoursynth-t3.py - | ~/src/mpv/build/mpv -

to get mpv to play a video through VapourSynth - how can I get audio too?

jackoneill
28th December 2014, 13:35
okey so after removing the UnDot part from the sample script, I can use this line


to get mpv to play a video through VapourSynth - how can I get audio too?

With mpv's --audio-file option.

Are_
28th December 2014, 14:17
Also if you intend to use vapoursynth to filter your videos on playback it better if you activate vapoursynth support on mpv.

I recall it was a little a pain in the ass for me, so if you want help you can always ask here.

About plugin autoloading you can follow this manual: https://github.com/vapoursynth/vapoursynth/blob/master/doc/autoloading.rst and symlink them to any of that locations if them are installed by any external package.

EDIT: Also, rgvs.RemoveGrain(clip, mode=1) is the equivalent for UnDot()

kaefert
28th December 2014, 15:09
how do I enable vapoursynth support when building mpv? whats the config switch called?

with this audio-file parameter, it seems it expects a path, or when giving '-' for reading from standard in I get
PYTHONPATH=/usr/local/lib/python3.4/site-packages vspipe --y4m vapoursynth-t3.py - | ~/src/mpv/build/mpv - --audio-file -
Playing: -
[file] Reading from stdin...
[ffmpeg/demuxer] yuv4mpegpipe: Stream #0: not enough frames to estimate rate; consider increasing probesize
[file] Reading from stdin...
Can not open external file -.
[stream] Video (+) --vid=1 (rawvideo)
[lavf] error reading packet.
VO: [opengl] 1920x1080 yuv420p
[lavf] error reading packet.
V: 00:00:00 Cache: 0s+15855KB
[lavf] error reading packet.
V: 00:00:00 Dropped: 1 Cache: 0s+15855KB
[lavf] error reading packet.
[lavf] error reading packet.

Are_
28th December 2014, 16:28
--enable-vapoursynth
Vapoursynth does not output audio to pipe (only to a file with the appropriate plugin), so your command line should look like:
$ vspipe -y _script.vpy - | mpv --audio-file file.mkv -
And file.mkv is the file from you are getting the video, it can be also an standalone audio file ofc.

kaefert
28th December 2014, 17:19
okey, so I've built mpv with
$ ./waf configure --enable-vapoursynth
which prints:
Checking for VapourSynth filter bridge (core) : yes
Checking for VapourSynth filter bridge (Python) : yes
Checking for VapourSynth filter bridge (Lazy Lua) : lua not found

but trying to open an VapourSynth python script with it gives me
kaefert@mint ~/src/mpv $ ./build/mpv ~/Videos/vapoursynth-t3.py
Playing: /home/kaefert/Videos/vapoursynth-t3.py
Failed to recognize file format.

Are_
28th December 2014, 17:35
You don't use it like that:

https://gist.github.com/ChrisK2/10606922
https://github.com/mpv-player/mpv/wiki/Fixing-Simulcasts

When building mpv you can pass this too "--disable-vapoursynth-lazy", you don't want your vapoursynth to become lazy...

kaefert
28th December 2014, 17:42
I have no interest in using it like described in https://gist.github.com/ChrisK2/10606922

I want to write a script that opens a number of files do something with them and return one result which finally should get encoded with ffmpeg or something like it - but before the final encoding I'd like a way to preview what I've scripted.

./build/mpv --vf=vapoursynth=~/Videos/vapoursynth-t3.py
doesn't work

my background: I'm an avisynth / avxsynth user currently checking out vapoursynth as a possible replacement. I am using avxsynth as "non-linear video editor" without the annoying and always imprecise GUI that every other video editor is built around. My daytime job is softwaredevelopment so I have no problem writing scripts.
my problems with avisynth: it needs windows or wine, wine64 and avisynth64 bit editons don't work well together, avisynth 32bit doesn't like to open and process more than a few dozen input files before crashing.
my problems with avxsynth: subtitles function is ignoring a few essential parameters like 'allign' and the function overlay is missing completely.

Are_
28th December 2014, 17:57
Ok, then normal mpv is enough, you misslead me when you said you wanted to have audio. Audio for what?

If you want to preview just use the vspipe/mpv method or vsedit (http://forum.doom9.org/showthread.php?t=170965).

If you are going to manipulate audio too, use damb (http://forum.doom9.org/showthread.php?t=171555), and if you need to check the audio is Ok too, use the mpv audio-file method with the final wav as source.

kaefert
28th December 2014, 18:03
hmm, well I don't want to really manipulate audio on its own, I just want the audio being read from my input videos and for them to get output at the appropriate time in the output.

for example in avisynth I use the function Dissolve(..) a lot and it does automatically Dissolve both Video and Audio at the same time. (slowly reducing the volume of the first stream and slowly increasing the volume of the second one)
Is there an equivalent for vapoursynth?

Are_
28th December 2014, 18:13
I'm afraid vapoursynth has no equivalents for that.

kaefert
28th December 2014, 18:38
I'm afraid vapoursynth has no equivalents for that.

hmpf. well. I already feared that it would be like that after reading the original developers response to a question about audio processing here (http://www.vapoursynth.com/2012/11/vapoursynth-tasks/)
Fredrik Mellbin on November 15, 2012 at 15:05 said:
Pick one thing. Do it well. This way I at least have a working half instead of a big, convoluted mess. And no, audio isn’t that important in my opinion, just look at the poor treatment and how few filters were written for it in Avisynth. Besides, you can always mux it in later in the next step.

If you need audio support very soon I’m of course willing to discuss the cost of implementing it. I estimate it’s one month of full time work to design the API, implement basic filters and spend a few minutes testing it.

So for my purpose of cutting together videos that do contain audio with maybe a few pictures and in some cases for silent passages (like a lot of pictures) a seperate audio track - and getting both video and audio output - I guess I'll need to stick with Avisynth / Avxsynth for now..

this damb looks nice, but to first extract the audio of every video file and save it as *.wav files seems like too much effort necessary - especially compared to the good audio support in Avisynth / Avxsynth (also I want Dissolve for both Audio and Video).

@Myrsloik and other capable & willing developers: Of course I can't offer you to pay you a months salary, but I'd be willing to offer you a 100€ donation if you could implement the discussed features:

-) reading audio together with video clips
-) a function to dissolve both video and audio in a sensible way
-) getting both audio and video to preview playback in mpv or something like it
-) getting both audio and video to an encoder like ffmpeg
(and all that without me having to reencode, remux, or manually handle some temp files)

Myrsloik
28th December 2014, 20:26
I have been thinking a bit about audio recently since the video part is finally getting close to what it should be.

Unfortunately basic audio support is a yawn fest to actually implement. I'm yawning right now just thinking about it. From a programming perspective it's like implementing a bad "audiosynth" as well and strapping it on badly.

Expect it to happen but not soon...

kaefert
29th December 2014, 01:35
thanks for taking the time to reply :)

could you maybe give an approximate date when I should check back if the audio situation might have improved, or could you maybe send me a message when you have had time to code it together?

Myrsloik
29th December 2014, 02:09
thanks for taking the time to reply :)

could you maybe give an approximate date when I should check back if the audio situation might have improved, or could you maybe send me a message when you have had time to code it together?

No and no.

qyot27
29th December 2014, 03:02
You probably installed VapourSynth in the default prefix (/usr/local), which means the Python module (vapoursynth.so) is installed in a location that Python doesn't search by default. This should work:

PYTHONPATH=/usr/local/lib/python3.4/site-packages vspipe --version

I'll add a note about this in the INSTALL file.
I'd think the easier recommendation on such systems is just to follow up the make install step with one invoking setup.py install.

jackoneill
29th December 2014, 05:13
I'd think the easier recommendation on such systems is just to follow up the make install step with one invoking setup.py install.

What for? setup.py is not needed.

qyot27
29th December 2014, 08:06
It's mostly because Debian's Python packaging guidelines make a distinction between dist-packages (which is on sys.path) and site-packages, and it'd more than likely be Debian and its derivatives where most users will encounter the problem. While setting PYTHONPATH to site-packages at runtime or in the user's profile works, it's not what those distros technically want as far as packages go.

Myrsloik
15th January 2015, 22:43
It's RC TIME! This time with insane performance gains in some scenarios. My zimg speed test script goes from 80 to 330 fps. The performance boost will probably be a lot smaller for most scripts though. Benchmark and report your findings.

Changes in R26:
r26:
installer creation has been streamlined
fixed assumefps when using a clip as the fps source (nodame)
improved the performance of vsmap operations
the c version of the expr filter now clamps 16bit output properly (nobody noticed this bug because everyone used the x86 asm version of the code)
expr filter now always uses . as the decimal separator in expressions, previously it would wrongly use the current locale's separator
there is now a minor api version as well that will be bumped when features are added
expr filter can now run fully in parallel
now returns an error if nodes are passed between different cores
modifyframe is now properly set to parallelrequests which should speed it up slightly
added half precision float support to blankclip
improved documentation a lot, every single python and c api function is now documented properly (nodame)
now uses tcmalloc instead of the normal malloc implementation to increase performance on windows

Download link (https://www.dropbox.com/s/2wc2w8891p17qre/vapoursynth-r26-rc1.exe?dl=1)

It's only a RC because I didn't completely test the new stuff yet. It should be completely stable for normal use.

buchanan
16th January 2015, 00:18
"No attribute with the name rgvs exists" when trying to run QTGMC from latest havsfunc