View Full Version : Vapoursynth
Mystery Keeper
27th October 2013, 13:59
Thank you. Installed R21 RC, and it has become fast.
This plugin interpolates between frames within (radius) using linear approximation/regression.
update: Compared unfiltered and filtered single planes. Filtered look like they have something like valid output, but much brighter (twice as bright?). That shouldn't be happening though, since all I'm doing is finding the linear approximation between the same pixels of several frames. Then, of course, I'm doing the bit depth conversion. But it shouldn't be different between planes, right?
update2: Checked the Y plane, and it is actually getting brighter too. So, there's a general mistake somewhere in my calculations.
update3: Silly silly me. I forgot to calculate xsum. Fixed. Now need to test with different bit depths and maybe optimize a little.
Myrsloik
27th October 2013, 15:25
Here's R21 RC2 (https://dl.dropboxusercontent.com/u/73468194/vapoursynth-r21-RC2.exe).
It will probably be released with no further changes. This final RC is just to see so I didn't break anything when moving some code around. It also has a fix for an issue no one ever noticed.
Mystery Keeper
27th October 2013, 15:26
Ok. Now something unrelated seems to have popped up.
ret = core.fmtc.bitdepth(ret, bits=16)
ret = core.tla.TempLinearApproximate(ret, radius=10, outBits=8)
Gives me an error in AvsPmod: AVISource: couldn't locate a decompressor for fourcc P016.
Both RC1 and RC2.
Myrsloik
27th October 2013, 15:49
Thank you. Installed R21 RC, and it has become fast.
This plugin interpolates between frames within (radius) using linear approximation/regression.
update: Compared unfiltered and filtered single planes. Filtered look like they have something like valid output, but much brighter (twice as bright?). That shouldn't be happening though, since all I'm doing is finding the linear approximation between the same pixels of several frames. Then, of course, I'm doing the bit depth conversion. But it shouldn't be different between planes, right?
update2: Checked the Y plane, and it is actually getting brighter too. So, there's a general mistake somewhere in my calculations.
update3: Silly silly me. I forgot to calculate xsum. Fixed. Now need to test with different bit depths and maybe optimize a little.
I noticed some things in your code:
1. VS doesn't allow less than 8 bits per sample to keep things simple so if((outBitsPerSample < 1) || (outBitsPerSample > 16))
;
is wrong.
2. You are NEVER supposed to created your own VSFormat struct copies.
WRONG!
internalData.format = *internalData.videoInfo.format;
internalData.videoInfo.format = &internalData.format;
You have to keep the pointer around. If you need to get a VSFormat describing a certain format either use getFormatPreset or registerFormat.
Your format error is because the output is 16 bit and you have nothing that can play it. Convert it to 8 bit to preview.
Mystery Keeper
27th October 2013, 15:54
ret = core.tla.TempLinearApproximate(ret, radius=10, outBits=8)
It does convert to 8bit.
Well, I'll try to register format properly. Haven't found an example of how to do that properly so far.
Myrsloik
27th October 2013, 15:56
http://i.imgur.com/V05gviR.png
Python get crashed when using the argument prop_src?
I found the typo. Will put up RC3 soon.
Myrsloik
27th October 2013, 15:59
ret = core.tla.TempLinearApproximate(ret, radius=10, outBits=8)
It does convert to 8bit.
Well, I'll try to register format properly. Haven't found an example of how to do that properly so far.
The relevant lines from ShufflePlanes (https://github.com/vapoursynth/vapoursynth/blob/master/src/core/simplefilters.c#L527). It's very simple. You enter all the parameters for the format you want and then you get a VSFormat * back you can use in VSVideoInfo (or anywhere else, really).
Mystery Keeper
27th October 2013, 16:56
Fixed the format. Works well so far. Still there are things to do, but hopefully shall release soon.
http://paste.org.ru/?vaevta
Myrsloik
27th October 2013, 17:23
Another problem, I am unable to get result from both assvapour.AssRender and assvapour.Subtitle. In the shell, it just stays there. No any error message. No crash.
It's not stuck. AssVapour uses fontconfig which needs to create a font index the first run. It's very slow. Give it up to 5 minutes. (or possibly more)
Myrsloik
27th October 2013, 17:42
Here's R21 RC3 (https://dl.dropboxusercontent.com/u/73468194/vapoursynth-r21-RC3.exe). Fixes the prop_src crash and checks so a proper VSFormat is passed to setVideoInfo().
Fixed the format. Works well so far. Still there are things to do, but hopefully shall release soon.
http://paste.org.ru/?vaevta
1. I've decided that all argument names should be lowercase and with underscores. So outBits => out_bits.
2. I also specify the planes to process as an int array in all internal filters. See Lut (http://www.vapoursynth.com/doc/functions/lut.html) which is called like this: Lut(clip, planes=[1,2], long_lut_array).
3. You probably don't want to have this condition uint32_t outValue;
if(inBytesPS == 2)
outValue = ((uint16_t *)srcp)[w];
else
outValue = srcp[w]; in the inner loop. Accept that you may need to write the outer loop several times instead. Again see how MaskedMerge works.
There's also the obivious question of why this filter is doing bitdepth conversion at all. Especially downconversion by truncation probably isn't what most people really want. Maybe you should leave that to fmtconv?
Upconversion from 8 to 16 bit is also extremely cheap to do in a separate filter placed in front of TLA so maybe drop that complexity?
Mystery Keeper
27th October 2013, 19:06
Yup, you're right. I did normalization of the source values, and I shouldn't. Double precision should be enough for 16-bit calculations on any reasonable radius. If it isn't - normalization wouldn't help anyway. So I'll drop normalization, bit depth conversion and format change altogether.
Mystery Keeper
27th October 2013, 20:33
Here you go. As fast as it gets. Still a draft, but usable.
http://paste.org.ru/?h6sf34
Myrsloik
27th October 2013, 21:12
Here you go. As fast as it gets. Still a draft, but usable.
http://paste.org.ru/?h6sf34
1. You can drop the (internalData.videoInfo->numFrames != 0) check. Requesting frames beyond the end is allowed (you'll get the last actual frame back)
2. You're calling vsapi->getReadPtr() in the inner loop, you probably want to store the pointers in a local array before the loop
3. You can automatically copy planes using newVideoFrame2() (which is free since it uses some reference counting behind the scenes). See ShufflePlanes as an example of how it's used. Basically you pass an array of 3 frame and another of the planes that should be copied from them. If you pass 0 as the frame pointer you get a normal blank plane.
Mystery Keeper
28th October 2013, 19:02
1. You can drop the (internalData.videoInfo->numFrames != 0) check. Requesting frames beyond the end is allowed (you'll get the last actual frame back)
I'm afraid I can't. This plugin needs to know the exact number of frames so it would take the proper range near the end.
IanB
28th October 2013, 21:51
I assume zero length clips are valid in VapourSynth as they are in Avisynth.
Zero length clips need to be handled gracefully.
Tima
28th October 2013, 21:56
I assume zero length clips are valid in VapourSynth as they are in Avisynth.
Zero length clips need to be handled gracefully.
Another corner case could be nonzero-length clips with both (or just one!) dimensions being zero :)
Myrsloik
28th October 2013, 22:00
I assume zero length clips are valid in VapourSynth as they are in Avisynth.
Zero length clips need to be handled gracefully.
If the length is zero it means that it is unknown. The actual number has to be determined some other way. Call it an esoteric feature. It can be useful for streaming and such. If you request a frame beyond the end all filters should return the last valid frame.
Clips that actually have 0 frames aren't allowed and can't be created for obvious reasons.
As for clips either both or no dimensions are known. You will trigger a fatal error if you try to set only one of width and height to zero.
I have plenty of extra argument checks going on to stop some common mistakes from happening. If VapourSynth ever "just quits" run it from the commandline to see the stderr output. It usually prints the reason and offending filter (if any).
Myrsloik
29th October 2013, 22:15
I finally released R21. Changelog in the first post. Download link on the website.
Blog post here (http://www.vapoursynth.com/2013/10/r21-big-improvements-again/).
Same procedure as every time... Now for some plugin writing.
Download link now fixed.
Mystery Keeper
30th October 2013, 04:14
Great work, Myrsloik! Is there MVTools among the priority plugins?
Myrsloik
30th October 2013, 09:35
Great work, Myrsloik! Is there MVTools among the priority plugins?
Of course it is. I actually do write these things down on the bug tracker and blog...
I don't know if there is any other really popular plugin left to port. I think I got all the extremely useful ones but correct me if I'm wrong.
sl1pkn07
30th October 2013, 10:34
Sangnom for example?
Greetings
Myrsloik
30th October 2013, 10:38
Sangnom for example?
Greetings
I suppose I could have a go at it now that tp7 has rewritten it. Should be fairly easy. The other thing is adding the remaining missing modes to removegrain which tp7 also reverse engineered.
Or someone could help by contributing a port. There's no shortage of small things to do.
aegisofrime
30th October 2013, 12:00
Of course it is. I actually do write these things down on the bug tracker and blog...
I don't know if there is any other really popular plugin left to port. I think I got all the extremely useful ones but correct me if I'm wrong.
Maybe it's just me using QTGMC a lot, but I recall you mentioned that you would like having all of QTGMC's plugins on native code?
Reel.Deel
30th October 2013, 14:42
While I doubt that all of these will come into fruition, I think these plugins make a nice addition to VapourSynth:
AddGrain (http://forum.doom9.org/showthread.php?t=111849) - Used by QTGMC and other scripts like GrainFactory3 (http://forum.doom9.org/showpost.php?p=1191292&postcount=30).
aWarpSharp2 (http://forum.doom9.org/showthread.php?t=147285) - A rewrite of aWarpSharp.
dfttest (http://forum.doom9.org/showpost.php?p=1386559&postcount=3) - Excellent spatial/temporal denoiser. Included in the Dither package.
ExpLabo (http://expsat.sourceforge.net/) - Creates neat looking color effects.
MedianBlur (http://forum.doom9.org/showthread.php?t=84636) - Kinda popular plugin that I've seen used in denoising, sharpening, and film restoration scripts.
RemoveGrainHD (http://chaosking.de/wp-content/uploads/avsfilters/Denoisers/Spatial_Denoisers/RemoveGrainHD___(0.5_-_2011-08-11).7z) - While not nearly as popular as RemoveGrain, it's still used in scripts here and there.
RemoveDirt (http://home.arcor.de/kassandro/prerelease/RemoveDirt.rar) - Very useful for film restoration.
VerticalCleaner (http://videoprocessing.fr.yuku.com/sreply/651/Can-use-quantile-like-vertical-median-filter#.UnED91PpdvY) - Also used by QTGMC and do other neat things like this (http://forum.doom9.org/showthread.php?p=1514235).
Closed source plugins that hopefully get ported or get a VS equivalent.
AutoGain (http://forum.doom9.org/showthread.php?t=167573) - High quality auto-leveling plugin.
FrFun7 (http://forum.doom9.org/showthread.php?t=110200) - Seems to be effective against dot crawl (http://forum.doom9.org/showpost.php?p=1584186&postcount=62). I know I'm probably wasting my time here. :)
SmoothAdjust (http://forum.doom9.org/showthread.php?t=154971) - High quality color correction plugin.
I can probably think of a few more but this is all I have time for at the moment. If I don't get completely shot down I can add some more potential plugins later. ;)
I finally released R21.
Hey there Myrsloik, thank you for the updates!
Myrsloik
30th October 2013, 16:11
While I doubt that all of these will come into fruition, I think these plugins make a nice addition to VapourSynth:
AddGrain (http://forum.doom9.org/showthread.php?t=111849) - Used by QTGMC and other scripts like GrainFactory3 (http://forum.doom9.org/showpost.php?p=1191292&postcount=30).
aWarpSharp2 (http://forum.doom9.org/showthread.php?t=147285) - A rewrite of aWarpSharp.
dfttest (http://forum.doom9.org/showpost.php?p=1386559&postcount=3) - Excellent spatial/temporal denoiser. Included in the Dither package.
ExpLabo (http://expsat.sourceforge.net/) - Creates neat looking color effects.
MedianBlur (http://forum.doom9.org/showthread.php?t=84636) - Kinda popular plugin that I've seen used in denoising, sharpening, and film restoration scripts.
RemoveGrainHD (http://chaosking.de/wp-content/uploads/avsfilters/Denoisers/Spatial_Denoisers/RemoveGrainHD___(0.5_-_2011-08-11).7z) - While not nearly as popular as RemoveGrain, it's still used in scripts here and there.
RemoveDirt (http://home.arcor.de/kassandro/prerelease/RemoveDirt.rar) - Very useful for film restoration.
VerticalCleaner (http://videoprocessing.fr.yuku.com/sreply/651/Can-use-quantile-like-vertical-median-filter#.UnED91PpdvY) - Also used by QTGMC and do other neat things like this (http://forum.doom9.org/showthread.php?p=1514235).
Closed source plugins that hopefully get ported or get a VS equivalent.
AutoGain (http://forum.doom9.org/showthread.php?t=167573) - High quality auto-leveling plugin.
FrFun7 (http://forum.doom9.org/showthread.php?t=110200) - Seems to be effective against dot crawl (http://forum.doom9.org/showpost.php?p=1584186&postcount=62). I know I'm probably wasting my time here. :)
SmoothAdjust (http://forum.doom9.org/showthread.php?t=154971) - High quality color correction plugin.
I can probably think of a few more but this is all I have time for at the moment. If I don't get completely shot down I can add some more potential plugins later. ;)
Hey there Myrsloik, thank you for the updates!
I did a quick survey of the source code for the filters you listed.
The only ones that can be salvaged for a somewhat easy port are:
AddGrainC - not too horrible once you delete the asm
dfttest - also has a C version so it's doable
ExpLab - seemed very straightforward, the biggest challenge would be to structure the pile of arguments in a nicer way
The rest are INLINE ASM MACRO PREPROCESSOR HELL. It's easier to start over and my duty as a mediocre coder to do so. Most of them don't have C versions of most functions.
It's simply faster to read the filter description and then guess what should be done. Avisynth filter writers love to implement different kinds of median filters badly... in asm. With macros.
Anyway, AddGrainC is a decent first porting project for anyone who's interested.
Mystery Keeper
30th October 2013, 20:25
By the way, VapourSynth keeps track of scene changes, right? Or does something need to be done for that? Is it possible to process a frame with different filter if it has scene change on both sides (flicker) within the script? Example please?
jackoneill
30th October 2013, 23:46
By the way, VapourSynth keeps track of scene changes, right? Or does something need to be done for that? Is it possible to process a frame with different filter if it has scene change on both sides (flicker) within the script? Example please?
There are two reserved properties (http://www.vapoursynth.com/doc/apireference.html#reserved-frame-properties). I'm not sure exactly how they're supposed to be used. I guess "_SceneChangePrev" should be set on the first frame of a scene, and "_SceneChangeNext" should be set on the last frame. Wouldn't "_SceneStart" and "_SceneEnd" make more sense?
Obviously VapourSynth doesn't magically add these properties to the right frames for you. Some filter needs to find the scene changes and set the properties accordingly.
sl1pkn07
31st October 2013, 17:15
hi, is possible port this script (the famous insertsign.avsi)
function insertsign(clip mainclip, clip overlayclip, int startframe, int "endframe") {
endframe = default(endframe,startframe+overlayclip.framecount()-1)
endframe = (endframe == 0) ? startframe+overlayclip.framecount()-1 : endframe
endframe = (endframe >= mainclip.framecount()-1) ? mainclip.framecount()-1 : endframe
begin= (startframe == 1) ? mainclip.trim(0,-1) : mainclip.trim(0,startframe-1)
middle= mainclip.trim(startframe,endframe)
end= (endframe == mainclip.framecount()-1) ? blankclip(mainclip,length=0) : mainclip.trim(endframe+1,0)
middleoverlay = Overlay(middle, overlayclip, mask=overlayclip.showalpha())
final = (startframe == 0) ? middleoverlay ++ end : begin ++ middleoverlay ++ end
return final
}
to vapoursynth?
greetings
Mystery Keeper
3rd November 2013, 19:22
I request a function which loads all plugins in specified (not predefined) folder.
sneaker_ger
3rd November 2013, 19:43
Can't you do that in Python?
Myrsloik
4th November 2013, 09:50
By the way, VapourSynth keeps track of scene changes, right? Or does something need to be done for that? Is it possible to process a frame with different filter if it has scene change on both sides (flicker) within the script? Example please?
My head has finally recovered. Here's a simple example that uses Chikuzen's scenechange plugin:
import vapoursynth as vs
import functools
def select_processing(n, f, original_clip, extra_processed_clip, core):
if f.props._SceneChangeNext and f.props._SceneChangePrev:
return extra_processed_clip
else:
return original_clip
core = vs.get_core()
source = core.ffms2.Source(source='D:/dl/Super Size Me/Super Size Me.avi')
source = core.scd.Detect(source)
source = core.text.FrameProps(source)
extra_processed_clip = core.std.BlankClip(source, color=[255,0,255]) # set the special frames to a distinct color
final_clip = core.std.FrameEval(source, functools.partial(select_processing, original_clip=source, extra_processed_clip=extra_processed_clip, core=core), prop_src=source)
final_clip.set_output()
Mystery Keeper
4th November 2013, 14:11
Thank you very much.
Reel.Deel
5th November 2013, 01:16
I did a quick survey of the source code for the filters you listed.
The only ones that can be salvaged for a somewhat easy port are:
AddGrainC - not too horrible once you delete the asm
dfttest - also has a C version so it's doable
ExpLab - seemed very straightforward, the biggest challenge would be to structure the pile of arguments in a nicer way.
Glad to hear that at least some are portable. Thanks for taking a look.
Another one I was going to mention was Vinverse, but I see that lachs0r already ported it (https://github.com/vapoursynth/vapoursynth/tree/master/src/filters/vinverse). :)
The rest are INLINE ASM MACRO PREPROCESSOR HELL. It's easier to start over and my duty as a mediocre coder to do so. Most of them don't have C versions of most functions.
It's simply faster to read the filter description and then guess what should be done. Avisynth filter writers love to implement different kinds of median filters badly... in asm. With macros
Maybe I'm missing something here but RemoveGrainHD's documentation says that it's written in "ordinary C/C++".
While RemoveGrain uses a very high level of parallelism - the SSE2/SSE3 version processes 16 pixels simultaneously - this is unfortunately no more possible for RemoveGrainHD. It is a rather ordinary C/C++ program without any inline assembler code.
If that documentation is wrong, please excuse my ignorance.
And finally, someone started (https://github.com/handaimaoh/vsremovedirt) to port RemoveDirt to VS. :)
------
Wouldn't "_SceneStart" and "_SceneEnd" make more sense?
I agree, _SceneStart/End is definitely more straightforward.
sl1pkn07
5th November 2013, 16:35
I found other plugin for vapoursynth
https://github.com/gnaggnoyil/VAutoDeint
greetings
Myrsloik
5th November 2013, 16:42
I found other plugin for vapoursynth
https://github.com/gnaggnoyil/VAutoDeint
greetings
Another secret plugin. Interesting.
Anyway, about the scenechange naming. I probably won't change it now since it's being used. I also think it makes more sense since in my world a scenechange happens between two frames. Not on a frame.
I'm busy converting the whole project to C++11 now and I've made quite a bit of progress. Qt has already been 80% removed from the codebase since C++11 finally gets a somewhat complete standard library.
Are_
5th November 2013, 17:13
I found other plugin for vapoursynth
https://github.com/gnaggnoyil/VAutoDeint
greetings
Unfortunately it's so Windows centric. It also performs plugin loading within the python module using filesystem paths (too bad, because the plugin itself compiles under Linux).
sl1pkn07
5th November 2013, 19:56
others (?)
https://github.com/gnaggnoyil/tc2cfr
https://github.com/4re/vapoursynth-modules
lansing
8th November 2013, 02:27
I just brought an i7 4470k and ran some speed test comparison between avisynth mt on the d2v source filter and tivtc/vivtc.
source was a 720x480 anime, all benchmark were measured by avsmeter.
avisynth-mt(fps)/cpu% vapoursynth(fps)/cpu%
d2v (mode 5)308/12% 912/12%
tfm (mode 2)215/17% 330/12%
tfm+tdecimate (mode 5)157/12% 255/12%
vfm 253/12%
vfm+vdecimate 31/13%
With vapoursynth, cpu was never fully utilized, not even 30%. And there's definitely something wrong with vdecimate, as running it alone also gives me 60fps.
Myrsloik
8th November 2013, 15:31
I just brought an i7 4470k and ran some speed test comparison between avisynth mt on the d2v source filter and tivtc/vivtc.
source was a 720x480 anime, all benchmark were measured by avsmeter.
avisynth-mt(fps)/cpu% vapoursynth(fps)/cpu%
d2v (mode 5)308/12% 912/12%
tfm (mode 2)215/17% 330/12%
tfm+tdecimate (mode 5)157/12% 255/12%
vfm 253/12%
vfm+vdecimate 31/13%
With vapoursynth, cpu was never fully utilized, not even 30%. And there's definitely something wrong with vdecimate, as running it alone also gives me 60fps.
That's quite odd indeed. I'll try to figure out why vdecimate makes it so slow.
Myrsloik
8th November 2013, 16:24
Here are two alternative vivtc dlls you can test:
Test1 (https://dl.dropboxusercontent.com/u/73468194/vivtc_test1.dll)
Test2 (https://dl.dropboxusercontent.com/u/73468194/vivtc_test2.dll)
Both are completely untested but should perform slightly better.
lansing
8th November 2013, 18:01
I did the test with the vpy script through using the VSimport wrapper (http://forum.doom9.org/showthread.php?t=168339), seems that it slows down the speed quite a lot, compared to simply threw the vpy script into virtualdub and ran analysis pass.
with wrapper:
R21 --> 30
test1 --> 35
test2 --> crash
without wrapper:
R21 --> 40
test1 --> 65
test2 --> crash
Myrsloik
8th November 2013, 19:16
I did the test with the vpy script through using the VSimport wrapper (http://forum.doom9.org/showthread.php?t=168339), seems that it slows down the speed quite a lot, compared to simply threw the vpy script into virtualdub and ran analysis pass.
with wrapper:
R21 --> 30
test1 --> 35
test2 --> crash
without wrapper:
R21 --> 40
test1 --> 65
test2 --> crash
If you want to test speed I really suggest you use vspipe as it will almost always have better throughput. It also shows the fps at the end now.
I'll take a serious look at it later tonight. It should be almost as fast as tdecimate at least.
lansing
8th November 2013, 20:05
If you want to test speed I really suggest you use vspipe as it will almost always have better throughput. It also shows the fps at the end now.
I'll take a serious look at it later tonight. It should be almost as fast as tdecimate at least.
I couldn't find any documentation on using vspipe on your site. I only know the most basic:
vspipe "clip.vpy" - -y4m | x264 --preset fast --demuxer y4m --output "clip.mkv" -
jackoneill
8th November 2013, 21:20
I couldn't find any documentation on using vspipe on your site.
It prints usage instructions if you run it with no parameters. Use NUL as output file.
lansing
9th November 2013, 02:14
It prints usage instructions if you run it with no parameters. Use NUL as output file.
Thanks, I got it working now
vspipe "clip.vpy" NUL
It's not so user friendly though, as it only showed the fps after the whole process was finished. not during the run.
Mystery Keeper
10th November 2013, 13:42
https://bitbucket.org/mystery_keeper/templinearapproximate-vapoursynth
Mature enough, or still needs improvements?
sl1pkn07
10th November 2013, 16:24
Hi Mystery Keeper
what is stdbool.h?
http://sl1pkn07.no-ip.com/paste/view/97611430
howto build? "gcc -o templinearapproximate.so main.c -I/usr/include/vapoursynth -I"put here stdbool.h path" ?
greetings
LoRd_MuldeR
10th November 2013, 16:42
what is stdbool.h?
Support for the "bool" type as well as the "true" and "false" constants in C language:
http://pubs.opengroup.org/onlinepubs/009696699/basedefs/stdbool.h.html
It's required, because C did not have a "bool" type before C99. Legacy code might still use "bool", "true" and "false" for other purposes, since they were not reserved before C99.
So if you want C++-style booleans in C, you have to include <stdbool.h> or just define those three macros yourself. MSVC still doesn't support C99 ;)
Myrsloik
10th November 2013, 17:13
https://bitbucket.org/mystery_keeper/templinearapproximate-vapoursynth
Mature enough, or still needs improvements?
https://bitbucket.org/mystery_keeper/templinearapproximate-vapoursynth/src/9f90c3faa3af9446c16a70cc7789357b591174e8/src/main.c?at=master#cl-196
The variable frames and planes can be allocated on the stack as an array of size 3. There will never be more than 3 planes in a format.
You should be able to eliminate most other allocations as well using variable length arrays since you went with C99.
https://bitbucket.org/mystery_keeper/templinearapproximate-vapoursynth/src/9f90c3faa3af9446c16a70cc7789357b591174e8/src/main.c?at=master#cl-208
You should pass input frame n instead of NULL. Otherwise all the existing properties such as colorimetry and times won't be copied over to your output frame.
"planes:int[]: opt:empty;" <- you probably don't want empty there, it's most likely an error if a user wants to filter no planes
https://bitbucket.org/mystery_keeper/templinearapproximate-vapoursynth/src/9f90c3faa3af9446c16a70cc7789357b591174e8/src/main.c?at=master#cl-114
"tla" should be "TempLinearApproximate". It makes more sense if the name reported when an error happens also matches the function used to create the filter.
That's all I could see. The only other small comment I have that should probably be ignored is that this would be a good function to implement with templates in C++ to avoid repeating it.
sl1pkn07
10th November 2013, 17:20
oks, build with
gcc -shared -fPIC -std=c99 -o templinearapproximate.so main.c -I/usr/include/vapoursynth
missing -shared and -fPIC
sorry. i'm not coder
greetings and thanks
Mystery Keeper
10th November 2013, 17:40
"planes:int[]: opt:empty;" <- you probably don't want empty there, it's most likely an error if a user wants to filter no planes
Actually intentional for testing purpose. Thank you for advices!
Also, silly me. Didn't free write pointers. That would cause a memory leak, so if anyone's already using it - you should update.
handaimaoh
10th November 2013, 18:02
And finally, someone started (https://github.com/handaimaoh/vsremovedirt) to port RemoveDirt to VS. :)
And it's getting close. I've ported it enough that it compiles. I just need the next couple of days to get the ASM ported to intrinsics (and most of it is pretty straightforward so it shouldn't be too hard) then to test it. The only other thing is that kassandro's RemoveDirt script (as of versions .8 and above it's merely a script around some functions in RemoveDirt and RemoveGrain) for Avisynth requires modes 16 and 17 in RemoveGrain. So before it can be used I'll work on implementing those modes for vsremovegrain since it currently doesn't support those modes.
Reel.Deel
11th November 2013, 13:46
Hi handaimaoh, welcome to the forum. :)
Great news about your progress/plans for RemoveDirt.
Regarding SCSelect what's your thoughts about adding functionality to be able to output a scene change log
and also make it compatible so that other plugins can use it as their scene change detector? (Similar to Chikuzen's scenechange plugin (http://forum.doom9.org/showthread.php?t=166769))
Myrsloik
11th November 2013, 14:21
Hi handaimaoh, welcome to the forum. :)
Great news about your progress/plans for RemoveDirt.
Regarding SCSelect what's your thoughts about adding functionality to be able to output a scene change log
and also make it compatible so that other plugins can use it as their scene change detector? (Similar to Chikuzen's scenechange plugin (http://forum.doom9.org/showthread.php?t=166769))
SCSelect should never be ported. It's trivial to write as a script using FrameEval and PlaneDifference. It only calculates the sum of absolute differences to make its decision.
Note that Chikuzen's scenechange plugin also uses the absolute difference and should produce almost identical results. If you want the relative threshold mode as well just write a feature request Chikuzen.
handaimaoh
11th November 2013, 14:55
Yeah, it will likely just get removed. It was only ported over simply for being able to test everything and the fact that it was like 2 minutes of effort since it was pretty simple.
cretindesalpes
11th November 2013, 16:15
SCSelect [...] only calculates the sum of absolute differences to make its decision.
Does it? The documentation states otherwise, Didée too (here (http://forum.doom9.org/showthread.php?p=1607246#post1607246)). I have to say that 2nd order differences are much more reliable, from my experience. Anyway, I don’t know if it’s better to compute the scene change using 3 input frames each time (dedicated plug-in) or to save the first order differences on additional temporary frames, wasting memory for these trivial operations.
Myrsloik
11th November 2013, 16:52
Does it? The documentation states otherwise, Didée too (here (http://forum.doom9.org/showthread.php?p=1607246#post1607246)). I have to say that 2nd order differences are much more reliable, from my experience. Anyway, I don’t know if it’s better to compute the scene change using 3 input frames each time (dedicated plug-in) or to save the first order differences on additional temporary frames, wasting memory for these trivial operations.
The relevant code for selecting:
if( dirmult * olddiff < lastdiff ) goto set_end;
if( dirmult * lastdiff < olddiff ) goto set_begin;
olddiff and and lastdiff are the absolute difference to the previous/next frame. I suppose that does make it second order but it's still trivial to recreate.
mastrboy
11th November 2013, 17:42
There's a speed difference between SCSelect and using Avisynth's built-in runtime functions (xDifferenceFromPrevious/xDifferenceToNext), SCSelect is quite faster, no idea if the same would apply to vapoursynth's internal functions though...
handaimaoh
11th November 2013, 18:07
There's a speed difference between SCSelect and using Avisynth's built-in runtime functions (xDifferenceFromPrevious/xDifferenceToNext), SCSelect is quite faster, no idea if the same would apply to vapoursynth's internal functions though...
Before any final decision is made I'll do some speed tests. If SCSelect is still substantially faster it'll be kept around until something else can replace it. It's not a ton of code as is.
StainlessS
11th November 2013, 18:23
SCSelect_Like function in script (behaves identically and not very good) from here:- http://forum.doom9.org/showthread.php?p=1644023#post1644023
Avisource("D:\avs\test.avi")
# RemoveDirt's SCSelect(clip input, clip scene_begin, clip scene_end, clip global_motion, float dfactor, bool debug, bool planar)
Function SCSelect_Like(clip dclip,clip Start,clip End,clip Motion, float "dfactor",bool "debug") {
# Start, End, Motion MUST all be same, dclip can be other colorspace/size (unlike SCSelect).
dfactor=Float(Default(dfactor,4.0))
debug=Default(debug,false)
Global SCM_A=0.0 Global SCM_B=0.0 Global SCM_SC=0 Global SCM_Prev=-1
Motion.ScriptClip("""
NotNext = (current_frame!=SCM_Prev+1)
Global SCM_A=(NotNext)? RT_LumaDifference(dclip,dclip,n=current_frame-1,n2=current_frame) : SCM_B
Global SCM_B= RT_LumaDifference(dclip,dclip,n=current_frame,n2=current_frame+1)
# 0 = Start of scene, 1 = End of scene, 2 = Global motion
Global SCM_SC=(current_frame==FrameCount-1)?1:(SCM_A>dfactor*SCM_B || current_frame==0)?0:(SCM_B>dfactor*SCM_A)?1:2
(SCM_SC==0) ? Start : (SCM_SC==1) ? End : Last # Choose Start, End or Motion(ie Last)
(debug)?RT_Subtitle("%d ] %6.2f %6.2f SC=%d",current_frame,SCM_A,SCM_B,SCM_SC):NOP
Global SCM_Prev=current_frame
Return Last
""",args="dfactor,Start,End,Dclip,debug") # Needs Grunt for args
return Last
}
Start=Subtitle("START OF SCENE",align=3,size=30)
End=Subtitle("END OF SCENE", align=1,size=30)
Motion=Subtitle("GLOBAL MOTION",align=5,size=30)
L=SCSelect_Like(Last,Start,End,Motion,debug=true)
R=SCSelect(Last,Start,End,Motion)
StackHorizontal(L,R)
Myrsloik
11th November 2013, 18:28
There's a speed difference between SCSelect and using Avisynth's built-in runtime functions (xDifferenceFromPrevious/xDifferenceToNext), SCSelect is quite faster, no idea if the same would apply to vapoursynth's internal functions though...
I think most of the speed difference is because avisynth recalculates the metric for both frames if you use scriptclip and friends. In vapoursynth the metric would be attached to frames and cached.
Experimentation welcome. Just keep in mind i didn't write any asm for the vapoursynth functions planedifference and planeaverage yet so for now it will be slightly slower.
Are_
11th November 2013, 18:34
On latest git from vapoursynth:
Python 3.3.2 (default, Aug 18 2013, 22:19:13)
[GCC 4.8.1] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import vapoursynth as vs
terminate called after throwing an instance of 'std::regex_error'
what(): regex_error
Aborted
It looks like it's compiler's fault. (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53631)
Anybody knows if this is supported on other compilers (4.9 looks far away for me)?
Myrsloik
11th November 2013, 20:14
On latest git from vapoursynth:
Python 3.3.2 (default, Aug 18 2013, 22:19:13)
[GCC 4.8.1] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import vapoursynth as vs
terminate called after throwing an instance of 'std::regex_error'
what(): regex_error
Aborted
It looks like it's compiler's fault. (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53631)
Anybody knows if this is supported on other compilers (4.9 looks far away for me)?
I use it for some trivial checks so I'll just rewrite it without regexp. I believe clang implements everything properly. Or you can just wait a day or two and I'll have it unbroken. There are like 0 functionality changes since r21, only cleanups and rewrites.
Are_
11th November 2013, 20:27
Nice to know there's an easy fix. Thx :)
Myrsloik
11th November 2013, 22:24
Nice to know there's an easy fix. Thx :)
I should be fixed now, I guess. Report any other new linux issues you find.
Joachim Buambeki
11th November 2013, 23:27
Great work so far Myrsloik. :-)
What about making Vapoursynth OpenFX (http://openfx.sourceforge.net/) compatible?
That would open the power of Vapoursynth to a lot of users, professionals and users of the free but powerful Resolve Lite but I am sure users of other apps like Nuke etc. would would also profit from it.
JB
kolak
11th November 2013, 23:44
This is a nice idea :)
Myrsloik
12th November 2013, 00:39
Great work so far Myrsloik. :-)
What about making Vapoursynth OpenFX (http://openfx.sourceforge.net/) compatible?
That would open the power of Vapoursynth to a lot of users, professionals and users of the free but powerful Resolve Lite but I am sure users of other apps like Nuke etc. would would also profit from it.
JB
To do what exactly? Be a simple source plugin?
Are_
12th November 2013, 09:09
If I prevent removegrain from building everything works great (also just as an informative note, clang throws the same error at runtime when regex are used).
gcc and clang complain on the new code:
gcc buildlog (http://pastebin.kde.org/pu5bupozn/prfcz5)
../src/filters/removegrain/clense.cpp:152:19: error: cast from ‘void*’ to ‘int’ loses precision [-fpermissive]
d.mode = (int)userData;
clang buildlog (http://pastebin.kde.org/pfi7ekydp/cvssz8)
../src/filters/removegrain/clense.cpp:152:14: error: cast from pointer to smaller type 'int' loses information
d.mode = (int)userData;
^~~~~~~~~~~~~
1 error generated.
../src/filters/removegrain/removegrainvs.cpp:1241:3: error: constant expression evaluates to -294912 which cannot be narrowed to type 'uint32_t' (aka 'unsigned int') [-Wc++11-narrowing]
{ -0x8000 * 9, -0x8000 * 9, -0x8000 * 9, -0x8000 * 9 };
^~~~~~~~~~~
../src/filters/removegrain/removegrainvs.cpp:1241:3: note: override this message by inserting an explicit cast
{ -0x8000 * 9, -0x8000 * 9, -0x8000 * 9, -0x8000 * 9 };
^~~~~~~~~~~
Joachim Buambeki
12th November 2013, 11:57
To do what exactly? Be a simple source plugin?
I am not sure what you mean with "source plugin", but my idea was to select Vapoursynth as a filter in the host application and then you can open a console or something similar where you can type in the filter effect (without the import video stuff of course because it does that automaticaly).
What would be even cooler if it would be possible if one could create wrappers to directly call a certain filter (script) from Vapoursynth like a regular plugin.
A similar suport for After Effects would be great but that would mean that a separare plugin would have to be written, since AE isn't OpenFX compatible unfortunately.
I can only guess but support for these applications should also speed up development of Vapoursynth alot if communicated through the right channels (forums where those people are - CreativeCow, LiftGammaGain, etc.). There should be a fair amount of pros that would be willing to donate their time to help with development I suppose.
Mystery Keeper
12th November 2013, 14:08
I'm trying to write a VapourSynth Python script function. When I pass an argument as None, I want AviSynth filter to use the default value for that argument. How can I do that? Can I form a string of AviSynth filter call and "Evaluate" it?
Myrsloik
12th November 2013, 14:16
I'm trying to write a VapourSynth phyton script function. When I pass an argument as None, I want AviSynth filter to use the default value for that argument. How can I do that? Can I form a string of AviSynth filter call and "Evaluate" it?
Something like this can be done in python:
d = dict(arg1=1, arg2=2) #args you always set here
if arg3 is not None: # optional arg that shouldn't be set when None
d['arg3name'] = arg3
clip = core.avs.AvsFunction(**d)
Mystery Keeper
12th November 2013, 15:07
Awesome! I can actually specify different AND matching arguments for multiple calls that way. Thanks a lot, Myrsloik!
Mystery Keeper
12th November 2013, 16:56
1) Is there mt_diff analog for VapourSynth? I can do it like this:
def absdiff(x, y):
return min(max(0, 127 + x - y), 255)
diff = core.std.Lut2([a, b], function = absdiff)
But it is bitdepth-specific and likely not very fast.
2) Is there HistogramAdjust analog for VapourSynth, or should we ask the author for port?
Myrsloik
12th November 2013, 17:06
1) Is there mt_diff analog for VapourSynth? I can do it like this:
def absdiff(x, y):
return min(max(0, 127 + x - y), 255)
diff = core.std.Lut2([a, b], function = absdiff)
But it is bitdepth-specific and likely not very fast.
2) Is there HistogramAdjust analog for VapourSynth, or should we ask the author for port?
1. No
2. No again
Mystery Keeper
15th November 2013, 11:31
AvsPMod silently crashed after several minutes of experimenting with this script. VirtualDub silently crashed after processing ~120000 of ~150000 frames.
Script uses this function. (https://bitbucket.org/mystery_keeper/templinearapproximate-vapoursynth/src/51c8968334b7952676ebb0c26df64f0ba2094b47/MCDenoise.py?at=master)
avisynth_plugins_path = 'E:\\avisynth-plugins\\'
vapoursyth_plugins_path = 'E:\\vapoursynth-plugins\\x32\\'
import vapoursynth as vs
import sys
sys.path.append(vapoursyth_plugins_path + 'E:\\vapoursynth-plugins\\py\\')
core = vs.get_core(threads=8)
core.set_max_cache_size(3500)
import os
for filename in os.listdir(vapoursyth_plugins_path):
if filename[-4:] != '.dll':
continue
core.std.LoadPlugin(vapoursyth_plugins_path + filename)
core.avs.LoadPlugin(path = avisynth_plugins_path + 'mvtools2.dll')
core.std.LoadPlugin(path = 'D:\\Programming\\TempLinearApproximate-VapourSynth\\build\\release-x32\\templinearapproximate.dll')
d2vfile = 'F:\\Video to Process\\Riaru Onigokko 2\\VTS_01_1.d2v'
ret = core.d2v.Source(input=d2vfile)
def pcToTv(input):
c = core.fmtc.resample (clip=input, css="444")
c = core.fmtc.matrix (clip=c, mats="601", matd="709")
c = core.fmtc.resample (clip=c, css="420")
c = core.fmtc.bitdepth (clip=c, bits=8)
return c
z = pcToTv(ret)
sys.path.append('D:\\Programming\\TempLinearApproximate-VapourSynth\\')
import MCDenoise
tlamc = MCDenoise.MCDenoise()
tlaArguments = dict(radius=2, BlockSize=8, Overlap=4, SubPel=4, SubPelInterp=2, Search=5, SearchParam=2, PelSearch=4, DCT=10, ThSAD=200)
ret = tlamc.TempLinearApproximate(ret, **tlaArguments)
ret = tlamc.TempLinearApproximate(ret, **tlaArguments)
ret = core.f3kdb.F3kdb(ret, dither_algo=2, grainy=0, grainc=0, keep_tv_range=True)
ret = pcToTv(ret)
ret.set_output()
def absdiff(x, y):
return min(max(0, 127 + x - y), 255)
unfiltered = core.text.Text(z, "unfiltered")
filtered = core.text.Text(ret, "filtered")
stack = core.std.StackHorizontal([unfiltered, filtered])
diffhist = core.std.Lut2([z, ret], function = absdiff)
#diffhist = core.generic.Levels(diffhist, planes=0, gamma = 3)
diffhist = core.text.Text(diffhist, "Difference")
filteredhist = core.generic.Levels(ret, planes=0, gamma = 2)
filteredhist = core.text.Text(filteredhist, "Filtered amplified")
diffstack = core.std.StackHorizontal([diffhist, filteredhist])
compare = core.std.StackVertical([stack, diffstack])
#compare.set_output()
Myrsloik
15th November 2013, 11:44
AvsPMod silently crashed after several minutes of experimenting with this script. VirtualDub silently crashed after processing ~120000 of ~150000 frames.
Script uses this function. (https://bitbucket.org/mystery_keeper/templinearapproximate-vapoursynth/src/51c8968334b7952676ebb0c26df64f0ba2094b47/MCDenoise.py?at=master)
Did you notice anything like the memory use going up or the script getting slower over time?
Mystery Keeper
15th November 2013, 11:50
The processing speed fluctuates relatively much. 5-11 FPS. But I don't know about the time when it crashed. Is there a way to profile at least the memory use without having to constantly monitor it? Is it possible to have on demand FPS and memory usage profiling and logging functionality in VapourSynth?
Myrsloik
15th November 2013, 11:55
The processing speed fluctuates relatively much. 5-11 FPS. But I don't know about the time when it crashed. Is there a way to profile at least the memory use without having to constantly monitor it? Is it possible to have on demand FPS and memory usage profiling and logging functionality in VapourSynth?
Never mind. I saw that you sneakily put a dll of TLA there.
Mystery Keeper
15th November 2013, 11:59
Right, sorry. Restarted the encode with memory limit changed to 2500. 9K frames so far. Memory usage isn't going over 840MB, but IS slowly rising.
Update: 100000 frames. Still the same fluctuating bitrate. Memory usage still not going over 840MB.
Myrsloik
15th November 2013, 16:03
Right, sorry. Restarted the encode with memory limit changed to 2500. 9K frames so far. Memory usage isn't going over 840MB, but IS slowly rising.
Update: 100000 frames. Still the same fluctuating bitrate. Memory usage still not going over 840MB.
You are running it from a command prompt, right? That way it will usually at least print a fatal error message to stderr. It could be that it simply went over the limit very shortly. I would never try to run it with a memory limit over 2GB since that's only the limit for when memory begins to get reclaimed. Combined with allocations inside filters you're still dangerously close to 3GB if you set it to 2.5GB.
Mystery Keeper
15th November 2013, 16:46
Nope. I'm simply encoding it in VirtualDub GUI. Right now it is over 145000 frames, and is still using around 830MB. No idea why it would crash back then.
Update. It has suddenly and silently crashed again.
Myrsloik
15th November 2013, 17:04
Nope. I'm simply encoding it in VirtualDub GUI. Right now it is over 145000 frames, and is still using around 830MB. No idea why it would crash back then.
Update. It has suddenly and silently crashed again.
Try doing the encoding with vspipe next time. That way you'll most likely see the fatal error printed. I'm going to try your script now myself and see what happens...
What's the resolution of your source?
Mystery Keeper
15th November 2013, 17:06
Quite ordinary 720x480 NTSC DVD.
handaimaoh
15th November 2013, 18:02
RemovePort is now done being ported and converted to intrinsics. If you want to test it out a binary is here (https://www.dropbox.com/s/omou1kyr8xgodkk/RemoveDirt.dll). I have not really tested it much so far so please let me know of any issues.
A simple Vapoursynth script to test would look like the following if your clip is not greyscale:
clip = core.ffms2.Source(src)
cleansed = core.rgvs.Clense(clip)
sbegin = core.rgvs.ForwardClense(clip)
send = core.rgvs.BackwardClense(clip)
scenechange = core.vsrd.SCSelect(clip, sbegin, send, cleansed)
alt = core.rgvs.Repair(scenechange, clip, mode=[16,16,1])
restore = core.rgvs.Repair(cleansed, clip, mode=[16,16,1])
corrected = core.vsrd.RestoreMotionBlocks(cleansed, restore, neighbour=clip, alternative=alt, gmthreshold=70, dist=1, dmode=2, noise=10, noisy=12, grey=0)
clip = core.rgvs.RemoveGrain(corrected, mode=[17,17,1])
clip.set_output()
If it is greyscale change the second value in the mode array of ints to -1. A more fancy function will be knocked up later.
Works with only YUV420P8 and YUV422P8 right now.
easyfab
15th November 2013, 19:21
I try vapoursynth for the first time. It's a little bit harder than avisynth.
But I succeed to run a script with qtgmc() thanks to aegisofrime script example http://forum.doom9.org/showthread.php?p=1649699#post1649699
although the cpu usage is 100% ( compare to ~50% with my avs script ) the speed is slower for x264 encoding ???
Are some plugins less optimized yet ?
Another question:
Is there a special way to load yadif.dll ? because it doesn't work for me
core.avs.LoadPlugin(path=r'C:\Program Files (x86)\AviSynth 2.5\plugins\yadif.dll')
core.avs.Load_Stdcall_Plugin(path=r'C:\Program Files (x86)\AviSynth 2.5\plugins\yadif.dll') ?
And if someone can give me a script example for yadifmod with edeint=nnedi3 It would be nice.
Vapoursynth look promising for the futur, I will keep an eye on it .
Myrsloik
15th November 2013, 19:32
I try vapoursynth for the first time. It's a little bit harder than avisynth.
But I succeed to run a script with qtgmc() thanks to aegisofrime script example http://forum.doom9.org/showthread.php?p=1649699#post1649699
although the cpu usage is 100% ( compare to ~50% with my avs script ) the speed is slower for x264 encoding ???
Are some plugins less optimized yet ?
Another question:
Is there a special way to load yadif.dll ? because it doesn't work for me
core.avs.LoadPlugin(path=r'C:\Program Files (x86)\AviSynth 2.5\plugins\yadif.dll')
core.avs.Load_Stdcall_Plugin(path=r'C:\Program Files (x86)\AviSynth 2.5\plugins\yadif.dll') ?
And if someone can give me a script example for yadifmod with edeint=nnedi3 It would be nice.
Vapoursynth look promising for the futur, I will keep an eye on it .
Avisynth C plugins can't be loaded. Only normal 2.5 API ones work. Exactly what were your QTGMC and x264 settings when testing it?
QTGMC is known to be a bit slower than when run in avisynth-mt at its best but the difference should be around 15% or so at most.
Myrsloik
15th November 2013, 19:33
Quite ordinary 720x480 NTSC DVD.
Did you overclock your computer or look at the core temperature at all when running the script? Just curious.
Mystery Keeper
15th November 2013, 19:46
Did you overclock your computer or look at the core temperature at all when running the script? Just curious.
Nope. Water cooled and not overclocked.
Myrsloik
15th November 2013, 19:49
Nope. Water cooled and not overclocked.
Running the script with a blankclip source now. Will see if it can pass 500000 frames in a couple of hours. Days like these I wish I'd gone with a 3770k cpu...
Mystery Keeper
15th November 2013, 19:55
That's why I'm saving for two 12 cores Xeons ^_^'
easyfab
15th November 2013, 20:11
Avisynth C plugins can't be loaded. Only normal 2.5 API ones work. Exactly what were your QTGMC and x264 settings when testing it?
QTGMC is known to be a bit slower than when run in avisynth-mt at its best but the difference should be around 15% or so at most.
For vapoursynth ( 100% cpu usage )
clip = haf.QTGMC(clip, Preset='slow',TFF=True)
clip = clip[::2]
and for avisynth (~50-60% cpu usage )
setmtmode(2)
QTGMC(preset="slow", EdiThreads=4).selecteven()
x264 --preset slower
And speed is about 20% less with vapoursynth
mastrboy
15th November 2013, 21:29
Running the script with a blankclip source now. Will see if it can pass 500000 frames in a couple of hours. Days like these I wish I'd gone with a 3770k cpu...
Now I'm curious, what did you get instead?
Myrsloik
15th November 2013, 21:43
Now I'm curious, what did you get instead?
The 3570k, because at the time I hadn't decided to work on very multithreaded things like VapourSynth. Maybe Intel will give me something better if I ask nicely...
Anyway, next investment will be a very fast graphics card that doesn't sound like a vacuum cleaner.
If someone happens to have a computer with lots of cores I could use remotely to test VapourSynth on that'd be very useful. It's hard for me to test how well things scale on lots of cores with only 4 here.
Myrsloik
16th November 2013, 00:44
Quite ordinary 720x480 NTSC DVD.
506k frames later and it still works. I don't think this method of testing will yield anything. I'll add logging of fatal errors and then let you try that build.
Reel.Deel
16th November 2013, 02:01
RemovePort is now done being ported and converted to intrinsics. If you want to test it out a binary is here (https://www.dropbox.com/s/omou1kyr8xgodkk/RemoveDirt.dll). I have not really tested it much so far so please let me know of any issues.
When I try to load RemoveDirt I get this error:
---------------------------
VirtualDub Error
---------------------------
Python exception: 'Failed to load C:\\RemoveDirt.dll'
Traceback (most recent call last):
File "vapoursynth.pyx", line 1082, in vapoursynth.vpy_evaluateScript (src\cython\vapoursynth.c:16736)
File "C:\test.vpy", line 4, in <module>
core.std.LoadPlugin(path=r'C:\RemoveDirt.dll')
File "vapoursynth.pyx", line 1005, in vapoursynth.Function.__call__ (src\cython\vapoursynth.c:15793)
vapoursynth.Error: 'Failed to load C:\\RemoveDirt.dll'
Also, since clense is now included with RemoveGrainVS shouldn't the script look something like this instead?
clip = core.ffms2.Source(src)
cleansed = core.rgvs.Clense(clip)
sbegin = core.rgvs.ForwardClense(clip)
send = core.rgvs.BackwardClense(clip)
scenechange = core.vsrd.SCSelect(clip, sbegin, send, cleansed)
alt = core.rgvs.Repair(scenechange, clip, mode=[16,16,1])
restore = core.rgvs.Repair(cleansed, clip, mode=[16,16,1])
corrected = core.vsrd.RestoreMotionBlocks(cleansed, restore, neighbour=clip, alternative=alt, gmthreshold=70, dist=1, dmode=2, noise=10, noisy=12, grey=0)
clip = core.rgvs.RemoveGrain(corrected, mode=[17,17,1])
clip.set_output()
Lastly, in my humble opinion I think RemoveDirt's namespace "vsrd" should be changed to "rdvs", making it familiar with RemoveGrain's "rgvs" namespace.
---
I wonder why Kassandro chose clense instead of cleanse? :confused:
handaimaoh
16th November 2013, 02:22
Yes, the calls should have been changed. My bad missing that. I'll look to see why it doesn't load. Last time I tested it it did.
Mystery Keeper
16th November 2013, 09:38
506k frames later and it still works. I don't think this method of testing will yield anything. I'll add logging of fatal errors and then let you try that build.
Sounds good. Thank you.
Update: got it crash faster while testing with vspipe. I think it said "fwrite error". Testing again with redirecting stderr to file.
Mystery Keeper
16th November 2013, 10:29
Ok, it has crashed with "fwrite() call failed" error while ran in windows console with output to stdout.
vspipe D:\Programming\TempLinearApproximate-VapourSynth\build\release-x32\test.vpy - -progress 2>E:\vsout.txt
Here's the log. (http://paste.org.ru/?4432tn)
It has not crashed for 1500 frames with stdout redirected to file (which wasn't intentional) before I've stopped it.
Used this script to give it harder time.
avisynth_plugins_path = 'E:\\avisynth-plugins\\'
vapoursyth_plugins_path = 'E:\\vapoursynth-plugins\\x32\\'
import vapoursynth as vs
import sys
sys.path.append(vapoursyth_plugins_path + 'E:\\vapoursynth-plugins\\py\\')
core = vs.get_core(threads=8)
core.set_max_cache_size(2500)
import os
for filename in os.listdir(vapoursyth_plugins_path):
if filename[-4:] != '.dll':
continue
core.std.LoadPlugin(vapoursyth_plugins_path + filename)
core.avs.LoadPlugin(path = avisynth_plugins_path + 'mvtools2.dll')
core.std.LoadPlugin(path = 'D:\\Programming\\TempLinearApproximate-VapourSynth\\build\\release-x32\\templinearapproximate.dll')
d2vfile = 'F:\\Video to Process\\Riaru Onigokko 2\\VTS_01_1.d2v'
ret = core.d2v.Source(input=d2vfile)
def pcToTv(input):
c = core.fmtc.resample (clip=input, css="444")
c = core.fmtc.matrix (clip=c, mats="601", matd="709")
c = core.fmtc.resample (clip=c, css="420")
c = core.fmtc.bitdepth (clip=c, bits=8)
return c
z = pcToTv(ret)
sys.path.append('D:\\Programming\\TempLinearApproximate-VapourSynth\\')
import MCDenoise
tlamc = MCDenoise.MCDenoise()
tlaArguments = dict(radius=5, BlockSize=8, Overlap=4, SubPel=4, SubPelInterp=2, Search=5, SearchParam=2, PelSearch=4, DCT=10, ThSAD=200)
ret = tlamc.TempLinearApproximate(ret, **tlaArguments)
ret = tlamc.TempLinearApproximate(ret, **tlaArguments)
ret = tlamc.TempLinearApproximate(ret, **tlaArguments)
ret = core.f3kdb.F3kdb(ret, dither_algo=2, grainy=0, grainc=0, keep_tv_range=True)
ret = pcToTv(ret)
ret.set_output()
def absdiff(x, y):
return min(max(0, 127 + x - y), 255)
unfiltered = core.text.Text(z, "unfiltered")
filtered = core.text.Text(ret, "filtered")
stack = core.std.StackHorizontal([unfiltered, filtered])
diffhist = core.std.Lut2([z, ret], function = absdiff)
#diffhist = core.generic.Levels(diffhist, planes=0, gamma = 3)
diffhist = core.text.Text(diffhist, "Difference")
filteredhist = core.generic.Levels(ret, planes=0, gamma = 2)
filteredhist = core.text.Text(filteredhist, "Filtered amplified")
diffstack = core.std.StackHorizontal([diffhist, filteredhist])
compare = core.std.StackVertical([stack, diffstack])
#compare.set_output()
Mystery Keeper
16th November 2013, 10:39
Actually, it might have been an unprintable character issue. Trying again with redirecting stdout to nul.
Myrsloik
16th November 2013, 11:56
Actually, it might have been an unprintable character issue. Trying again with redirecting stdout to nul.
Here's a slightly more verbose vspipe.exe (https://dl.dropboxusercontent.com/u/73468194/VSPipe.exe). Note that you need to have the VS2013 runtime installed for it to work.
Mystery Keeper
16th November 2013, 12:11
Thank you. I'll test it overnight.
kolak
16th November 2013, 14:43
The 3570k, because at the time I hadn't decided to work on very multithreaded things like VapourSynth. Maybe Intel will give me something better if I ask nicely...
Anyway, next investment will be a very fast graphics card that doesn't sound like a vacuum cleaner.
If someone happens to have a computer with lots of cores I could use remotely to test VapourSynth on that'd be very useful. It's hard for me to test how well things scale on lots of cores with only 4 here.
Can try to get you access to 32 threads machine :)
handaimaoh
16th November 2013, 17:32
When I try to load RemoveDirt I get this error:
I figured out the error. I did a find and replace and that messed up the parameter string for the RemoveDirt functions which made the plugin instantiation crash. Committing the fix and I'll have a new binary posted shortly. I will also make the changes to the naming to be consistent with Vapoursynth RemoveGrain.
handaimaoh
16th November 2013, 18:36
So fixed a few more bugs and now the new RemoveDirt dll is here (https://www.dropbox.com/s/hiupezbl5pahjtn/vsremovedirt.dll).
Updated script to use RemoveDirt is:
clip = core.ffms2.Source(source='clippath')
cleansed = core.rgvs.Clense(clip)
sbegin = core.rgvs.ForwardClense(clip)
send = core.rgvs.BackwardClense(clip)
scenechange = core.rdvs.SCSelect(clip, sbegin, send, cleansed)
alt = core.rgvs.Repair(scenechange, clip, mode=[16,16,1])
restore = core.rgvs.Repair(cleansed, clip, mode=[16,16,1])
corrected = core.rdvs.RestoreMotionBlocks(cleansed, restore, neighbour=clip, alternative=alt, gmthreshold=70, dist=1, dmode=2, noise=10, noisy=12, grey=0)
clip = core.rgvs.RemoveGrain(clip, mode=[17,17,1])
clip.set_output()
Changed the namespace to use rdvs instead of vsrd. This does require the latest version of RemoveGrainVS to make sure you have all the Clense functions and the extra implemented modes.
Octo-puss
16th November 2013, 20:33
Noob question: Can this replace AviSynth? Or rather... can this replace AviSynth in MeGui?
Mystery Keeper
16th November 2013, 21:51
Ok. Crashed again with vspipe. Error in console:
"No frame returned at the end of processing by TempLinearApproximate."
Also, this exception mesage:
http://s019.radikal.ru/i643/1311/56/8eb403e4b21c.png
Can this code (https://bitbucket.org/mystery_keeper/templinearapproximate-vapoursynth/src/51c8968334b7952676ebb0c26df64f0ba2094b47/src/main.c?at=master#cl-382) be the case? Are there other activation reasons I need to handle? Or should I return something other than 0?
Myrsloik
16th November 2013, 22:53
Ok. Crashed again with vspipe. Error in console:
"No frame returned at the end of processing by TempLinearApproximate."
Also, this exception mesage:
http://s019.radikal.ru/i643/1311/56/8eb403e4b21c.png
Can this code (https://bitbucket.org/mystery_keeper/templinearapproximate-vapoursynth/src/51c8968334b7952676ebb0c26df64f0ba2094b47/src/main.c?at=master#cl-382) be the case? Are there other activation reasons I need to handle? Or should I return something other than 0?
This is very odd. I have no idea why this happens. Your code looks correct to me. Does this only happen after processing 100k+ frames for you?
Mystery Keeper
16th November 2013, 23:40
Tested with short clip. Crashed again.
"Frame: 8498/8585
FNo frame returned at the end of processing by TempLinearApproximate"
Removed one line of "ret = tlamc.TempLinearApproximate(ret, **tlaArguments)". Vspipe has processed the clip up to the same 8498th frame and hanged. Seems to be looped in something.
Trimmed to 50 frames, then to 200, then to 400. Processed alright in all three tests.
Trimmed to 50 frames and returned the second line. Crashed again.
Does not happen with raw TempLinearApproximate, even stacked 5 times. Something with the MC script?
Mystery Keeper
17th November 2013, 01:09
More weirdness. For this clip the crash always happens if I try to request one of the last 10 frames in the sequence that belong to the original D2V. If I trim it to 150 - it crashes on 140th. If I trim it to 250 - it crashes on 240th. Yes, I tried with different radius. And if I splice it with blank clip - it still crashes at 240th.
Myrsloik
17th November 2013, 01:17
More weirdness. For this clip the crash always happens if I try to request one of the last 10 frames in the sequence that belong to the original D2V. If I trim it to 150 - it crashes on 140th. If I trim it to 250 - it crashes on 240th. Yes, I tried with different radius. And if I splice it with blank clip - it still crashes at 240th.
I have a new theory. Which mvtools2 versions are you using? I do all my testing with the svp version.
Mystery Keeper
17th November 2013, 01:24
Oh, I lied. It crashes at the last 10 frames of the sequence double-processed by MC TLA. Splicing with blank clip does help. I just spliced in the wrong place in the script the last time.
I'm using the vanilla MVTools 2. Can't tell exactly which version.
Myrsloik
17th November 2013, 01:31
Oh, I lied. It crashes at the last 10 frames of the sequence double-processed by MC TLA. Splicing with blank clip does help. I just spliced in the wrong place in the script the last time.
I'm using the vanilla MVTools 2. Can't tell exactly which version.
Can you try with svp mvtools? I'm curious if it crashes as much with it.
Mystery Keeper
17th November 2013, 01:35
It does. Actually, it seems I have been using SVP version >_<
Just tried with original. Still crashes.
Mystery Keeper
17th November 2013, 07:49
More experiments with stacking tlamc.TempLinearApproximate and guarding with blank clip.
I append the blank clip before processing and trim it after processing, so blank frames are not being requested, but are participating in processing. Thus, they give a guarding margin.
There's a certain pattern to how many guard frames are needed for certain number of tlamc lines and certain radius.
2 lines: blank clip of 3 frames prevents the crash for any radius.
3 lines: 7 guard frames are needed for radius 1, 8 for 2, 9 for 3, 10 for 4, 11 for 5
4 lines: 11 for 1, 13 for 2, 15 for 3, 17 for 4, 19 for 5
5 lines: 15 for 1, 18 for 2, 21 for 3, 24 for 4, 27 for 5
6 lines: 19 for 1, 23 for 2, 27 for 3, 31 for 4, 35 for 5
Myrsloik
17th November 2013, 11:11
More experiments with stacking tlamc.TempLinearApproximate and guarding with blank clip.
I append the blank clip before processing and trim it after processing, so blank frames are not being requested, but are participating in processing. Thus, they give a guarding margin.
There's a certain pattern to how many guard frames are needed for certain number of tlamc lines and certain radius.
2 lines: blank clip of 3 frames prevents the crash for any radius.
3 lines: 7 guard frames are needed for radius 1, 8 for 2, 9 for 3, 10 for 4, 11 for 5
4 lines: 11 for 1, 13 for 2, 15 for 3, 17 for 4, 19 for 5
5 lines: 15 for 1, 18 for 2, 21 for 3, 24 for 4, 27 for 5
6 lines: 19 for 1, 23 for 2, 27 for 3, 31 for 4, 35 for 5
Apparently I made a change which hid the bug. Going back a version closer to r21 and I get your crash every time.
The simple reason is that TLA can't handle frame requests beyond the clip end, which vs filters are supposed to do by returning the last existing frame. For example requesting frame 502 in a clip with 500 frames is what kills it here every time. Add n = MIN(n, numFrames - 1) at the top and it'll work. I guess.
Mystery Keeper
17th November 2013, 12:11
Thank you. That fixed it. Though I must ask, why was TLA requested a frame beyond the end?
Myrsloik
17th November 2013, 12:13
Thank you. That fixed it. Though I must ask, why was TLA requested a frame beyond the end?
To simplify filter writing. It's a quirk of the api. If you get a request for a frame beyond the end you're supposed to return the last existing one.
I'm going to change it for r22, that's why I didn't notice all the crashes you were getting.
Mystery Keeper
17th November 2013, 15:16
Ok, now it HANGS unless I trim 3 frames from the end of the source clip. My guess is d2v.Source has got the same issue.
Myrsloik
17th November 2013, 20:14
Here's R22 test1 (https://dl.dropboxusercontent.com/u/73468194/vapoursynth-r22-test1.exe). See if it crashes or does anything else odd.
The other major new is that the installer contains both 32 and 64 bit builds. Let the 64 bit revolution begin.
NO AVISYNTH PLUGINS CAN BE LOADED IN THE 64 BIT BUILDS. Not even the 64 bit ones. This will never change.
Changes:
vspipe now prints the fps as well
now arguments that are None in python aren't passed on to functions, this makes supplying defaults a lot easier
added core.version_number() so scripts can easily check for a supported core version
improved multithreaded locking, almost all functions in the vsscript and core API should be completely thread-safe now
Lut2, Merge and MaskedMerge functions changed, they now take two clip arguments named clipa and clipb instead of a 2 clip array, the old version is accepted as well for now, do vs.get_core(r21_arg_compat=False) to disable backward compatibility
minor API change, filters will no longer receive requests for frames beyond the end of a clip, instead the requested frame number is truncated, unknown length clip behavior is unchanged
simplified the vsscript api sample to use getFrame() and to be pure C code
added VS2013 projects
runtime registered formats now get automatically generated names so they're easier to identify
there should longer be "an exception happened when handling an exception" errors in python to keep the backtrace clearer
the python module now accepts any iterable as an array input
completely removed the Qt dependency on windows
added clense and the missing modes to removegrainvs
switched to C++11/C99 and VS2013, this means that both the VS2010 and VS2013 runtimes are both installed
added a port of vinverse (lachs0r)
lansing
17th November 2013, 21:42
I don't see the 64bit option in the installer
Mystery Keeper
17th November 2013, 21:46
Tried to install. Got a block-screen from Windows Defender. It hanged, and now I can't get rid of it or close file manager from which I've run the installer. Windows 8.1 Pro, admin user.
Ended it with task manager. When running "as admin", it doesn't hang. The reason of blocking is "Unknown publisher". Proceeded with "Run anyway".
Mystery Keeper
17th November 2013, 22:04
"Failed to initialize VapourSynth environment".
Installed it when Python x32 was the active distribution. Made Python x64 active and reinstalled. It worked. But obviously, VapourSynth x32 wouldn't work after that.
Myrsloik
17th November 2013, 22:10
I don't see the 64bit option in the installer
You need to have the 64 bit version of python 3.3 installed for it to appear.
Myrsloik
17th November 2013, 22:12
"Failed to initialize VapourSynth environment".
Installed it when Python x32 was the active distribution. Made Python x64 active and reinstalled. It worked. But obviously, VapourSynth x32 wouldn't work after that.
Make active? There's no selection needed with the default installer. You simply install the 32 and 64 bit python to different directories and it will just work. That's how I did it on my computer.
Mystery Keeper
17th November 2013, 22:18
I'm using portable winpython (http://code.google.com/p/winpython/). Maybe that's the case.
Myrsloik
17th November 2013, 22:25
I'm using portable winpython (http://code.google.com/p/winpython/). Maybe that's the case.
Probably. I only test with the official binaries form python.org.
Mystery Keeper
17th November 2013, 23:40
Works, handles >9GB RAM load, loads in x64 VirtualDub. For proper testing need more plugins built for x64. Also, AvsPmod isn't working with x64 version, so we need a new editor. Though that can wait. Personally I'm waiting for the MVTools port the most. Thank you for your great work, Myrsloik!
lansing
17th November 2013, 23:50
I got the 64bit version installed, is there any 64bit source filter available right now so I can just load in a video?
Mystery Keeper
17th November 2013, 23:53
I got the 64bit version installed, is there any 64bit source filter available right now so I can just load in a video?FFMS2 (https://github.com/FFMS/ffms2/releases/download/2.19/ffms2-2.19.7z)
lansing
18th November 2013, 00:17
there's some issue with the installer, on the step "preparing to install" stage, it's telling me to close a lot of apps like WD rules, WD backup, homegroup provider etc, which should have nothing to do with vapoursynth.
Myrsloik
18th November 2013, 00:20
there's some issue with the installer, on the step "preparing to install" stage, it's telling me to close a lot of apps like WD rules, WD backup, homegroup provider etc, which should have nothing to do with vapoursynth.
It's because it installs the runtime dolls. Just tell it to not close anything and go on.
lansing
18th November 2013, 00:23
FFMS2 (https://github.com/FFMS/ffms2/releases/download/2.19/ffms2-2.19.7z)
where do you put the file?
I put the 64bit ffms2.dll and ffmsindex.exe into plugins64 folder, but it still said "no attribute with the name ffms2 exists".
src = core.ffms2.Source(r"sample.vob")
UPDATE:
I got it working. I need to write the load plugin line in the script to make it work, it doesn't auto load like the older version on 32bit filters.
lansing
18th November 2013, 01:27
running the 32bit vapoursynth gives a out of bounds memory crash in vd
Mystery Keeper
18th November 2013, 05:03
running the 32bit vapoursynth gives a out of bounds memory crash in vd
Post your script. Might be too complex. Also tell the specs of the source video.
Also, Myrsloik, some core plugins are not present in x64 distribution.
lansing
18th November 2013, 06:27
Post your script. Might be too complex. Also tell the specs of the source video.
Also, Myrsloik, some core plugins are not present in x64 distribution.
it's the same script i put up few posts above, just a ffms2 filter to load in a video. The source is a DVD vob.
The same script works on 64bit.
UPDATE:
I found out what's the problem, I installed the 64bit python on top of the 32bit python, should had install them on different directories.
http://stackoverflow.com/questions/10187072/how-do-i-install-python-2-7-3-32-bit-and-64-bit-on-windows-side-by-side
handaimaoh
18th November 2013, 18:17
So now that I've finished RemoveDirt port I was going to start on aWarpSharp2 and Sangnom2. Any other plugins anyone wants?
Also, I'll start a separate RemoveDirtVS thread and post some 32-bit and 64-bit dll builds in it.
Mystery Keeper
18th November 2013, 18:26
So now that I've finished RemoveDirt port I was going to start on aWarpSharp2 and Sangnom2. Any other plugins anyone wants?
Also, I'll start a separate RemoveDirtVS thread and post some 32-bit and 64-bit dll builds in it.
Great. Thank you!
Dfttest is rather needed.
Toon would be nice as part of anime anti-aliasing.
Some kind of autolevels/HDR plugin for when I need to amplify subtle differences in comparison.
Reel.Deel
18th November 2013, 19:26
So a little after a year VapourSynth is finally becoming more and more useful natively.
Thanks to all that are making it possible!:thanks:
@handaimaoh
Thanks for RDVS, hopefully I'll have some time tonight to tested thoroughly.
Regarding other plugins, for what is worth here's a list (http://forum.doom9.org/showthread.php?p=1650695#post1650695) of some that I think would be useful.
Mystery Keeper
18th November 2013, 19:31
Tried to use VIVTC in x64, and it didn't autoload. Had to load it manually.
Mystery Keeper
18th November 2013, 19:40
http://i047.radikal.ru/1311/b9/b25aa0d0912at.jpg (http://radikal.ru/fp/8a1dddb552944c76a98cda9719a7abdd)
As you see, near the end crash bug is still present. Here's the script:
vapoursyth_plugins_path = 'E:\\vapoursynth-plugins\\x64\\'
import vapoursynth as vs
import sys
sys.path.append(vapoursyth_plugins_path + 'E:\\vapoursynth-plugins\\py\\')
core = vs.get_core(threads=8)
core.set_max_cache_size(16000)
import os
for filename in os.listdir(vapoursyth_plugins_path):
if filename[-4:] != '.dll':
continue
core.std.LoadPlugin(vapoursyth_plugins_path + filename)
core.std.LoadPlugin(path = 'D:\\Programming\\TempLinearApproximate-VapourSynth\\build\\release-x64\\templinearapproximate.dll')
core.std.LoadPlugin(path = 'C:\\Program Files (x86)\\VapourSynth\\core64\\plugins\\VIVTC.dll')
d2vfile = 'F:\\Video to Process\\Riaru Onigokko 2\\VTS_01_1.d2v'
#d2vfile = 'F:\\Video to Process\\KOTOKO - Chercher\\KOTOKO - Chercher.d2v'
ret = core.d2v.Source(input=d2vfile)
ret = core.vivtc.VFM(ret, order=1, mode=5)
ret = core.vivtc.VDecimate(ret)
def pcToTv(input):
c = core.fmtc.resample (clip=input, css="444")
c = core.fmtc.matrix (clip=c, mats="601", matd="709")
c = core.fmtc.resample (clip=c, css="420")
c = core.fmtc.bitdepth (clip=c, bits=8)
return c
z = pcToTv(ret)
ret = pcToTv(ret)
ret.set_output()
Myrsloik
18th November 2013, 21:33
http://i047.radikal.ru/1311/b9/b25aa0d0912at.jpg (http://radikal.ru/fp/8a1dddb552944c76a98cda9719a7abdd)
As you see, near the end crash bug is still present. Here's the script:
vapoursyth_plugins_path = 'E:\\vapoursynth-plugins\\x64\\'
import vapoursynth as vs
import sys
sys.path.append(vapoursyth_plugins_path + 'E:\\vapoursynth-plugins\\py\\')
core = vs.get_core(threads=8)
core.set_max_cache_size(16000)
import os
for filename in os.listdir(vapoursyth_plugins_path):
if filename[-4:] != '.dll':
continue
core.std.LoadPlugin(vapoursyth_plugins_path + filename)
core.std.LoadPlugin(path = 'D:\\Programming\\TempLinearApproximate-VapourSynth\\build\\release-x64\\templinearapproximate.dll')
core.std.LoadPlugin(path = 'C:\\Program Files (x86)\\VapourSynth\\core64\\plugins\\VIVTC.dll')
d2vfile = 'F:\\Video to Process\\Riaru Onigokko 2\\VTS_01_1.d2v'
#d2vfile = 'F:\\Video to Process\\KOTOKO - Chercher\\KOTOKO - Chercher.d2v'
ret = core.d2v.Source(input=d2vfile)
ret = core.vivtc.VFM(ret, order=1, mode=5)
ret = core.vivtc.VDecimate(ret)
def pcToTv(input):
c = core.fmtc.resample (clip=input, css="444")
c = core.fmtc.matrix (clip=c, mats="601", matd="709")
c = core.fmtc.resample (clip=c, css="420")
c = core.fmtc.bitdepth (clip=c, bits=8)
return c
z = pcToTv(ret)
ret = pcToTv(ret)
ret.set_output()
Can't reproduce in the 32 bit version. Does it only crash in the 64 bit one?
Mystery Keeper
18th November 2013, 21:56
Having problems running x32 version with my portable python distributions. Might do something about it when I have more free time, but for now I'm limited to testing x64.
Fullmetal Encoder
19th November 2013, 02:50
So now that I've finished RemoveDirt port I was going to start on aWarpSharp2 and Sangnom2. Any other plugins anyone wants?
Also, I'll start a separate RemoveDirtVS thread and post some 32-bit and 64-bit dll builds in it.
I would have to vote for Dfttest myself. It's quite amazing.
lansing
19th November 2013, 09:23
I'm unable to load both the 64bit nnedi3 and bifrost dll
Myrsloik
19th November 2013, 11:51
Here's test2 (https://dl.dropboxusercontent.com/u/73468194/vapoursynth-r22-test2.exe).
It fixes plugin autoloading on x64 and prevents out of range frame requests in getFrameAsync (and getFrame) that I missed.
@Mystery Keeper
Can you cut the last 100 frames of the vob and upload it if it still crashes after cutting? I'm beginning to think this also depends on the source file itself.
handaimaoh
19th November 2013, 17:18
I would have to vote for Dfttest myself. It's quite amazing.
Ok, creating a repo for it as well.
lansing
19th November 2013, 18:21
plugin autoloading for x64 still doesn't work in test2
Reel.Deel
19th November 2013, 18:55
Ok, creating a repo for it as well.
What codebase are using for dfttest? The reason I asked it's because dfttest included in the Dither package includes various updates including 16-bit processing and support for additional planar colorspaces. If you already know this, sorry for being redundant.
Mystery Keeper
19th November 2013, 19:08
Some plugins present in x32 distribution are still not present in x64. Autoloading still not working. Script still crashes. Searching for a tool to cut a vob file now.
mastrboy
19th November 2013, 19:13
So now that I've finished RemoveDirt port I was going to start on aWarpSharp2 and Sangnom2. Any other plugins anyone wants?
Also, I'll start a separate RemoveDirtVS thread and post some 32-bit and 64-bit dll builds in it.
Any chance to get a port of Tcomb? (http://bengal.missouri.edu/~kes25c/TCombv2B2.zip)
Myrsloik
19th November 2013, 19:21
Some plugins present in x32 distribution are still not present in x64. Autoloading still not working. Script still crashes. Searching for a tool to cut a vob file now.
Let me end your search: dgindex
Also, why so surprised that they aren't there? It's not like anyone said anything to imply they would be.
AND KEEP THIS FROM TURNING INTO A "REQUEST PLUGIN PORTS AND DON'T READ THE LAST POST THREAD"
handaimaoh
19th November 2013, 19:22
Any chance to get a port of Tcomb? (http://bengal.missouri.edu/~kes25c/TCombv2B2.zip)
Sure, it'll have to wait for other work to be done though.
Mystery Keeper
19th November 2013, 19:27
Here's the end of the video that leads to crash. (http://www.mediafire.com/?34e84dlmb707chd)
Also, tried with two other videos. No crash. So you might be right about source being the case.
Mystery Keeper
19th November 2013, 19:33
Let me end your search: dgindexYup. Already figured it out.
Also, why so surprised that they aren't there? It's not like anyone said anything to imply they would be.Because they are in x32 distribution. The difference in distributions is confusing.
AND KEEP THIS FROM TURNING INTO A "REQUEST PLUGIN PORTS AND DON'T READ THE LAST POST THREAD"Who? Me? I'd never do such thing ^_^
Mystery Keeper
20th November 2013, 18:30
Sharing a plugin loading snippet. Doesn't let load errors stop your script. Prints errors in vspipe. Does nothing in VirtualDub.
from __future__ import print_function
#This line must be in the beginning
vapoursyth_plugins_path = 'E:\\vapoursynth-plugins\\x64\\'
import vapoursynth as vs
import sys
sys.path.append(vapoursyth_plugins_path + 'E:\\vapoursynth-plugins\\py\\')
core = vs.get_core(threads=8)
core.set_max_cache_size(16000)
#Loading all plugins in path. On error - print and continue.
import os
for filename in os.listdir(vapoursyth_plugins_path):
if filename[-4:] != '.dll':
continue
try:
core.std.LoadPlugin(vapoursyth_plugins_path + filename)
except Exception as e:
print("Error: ", e, end='\n', file=sys.stderr)
Myrsloik
20th November 2013, 18:32
Sharing a plugin loading snippet. Prints errors in vspipe. Does nothing in VirtualDub.
from __future__ import print_function
#This line must be in the beginning
vapoursyth_plugins_path = 'E:\\vapoursynth-plugins\\x64\\'
import vapoursynth as vs
import sys
sys.path.append(vapoursyth_plugins_path + 'E:\\vapoursynth-plugins\\py\\')
core = vs.get_core(threads=8)
core.set_max_cache_size(16000)
#Loading all plugins in path. On error - print and continue.
import os
for filename in os.listdir(vapoursyth_plugins_path):
if filename[-4:] != '.dll':
continue
try:
core.std.LoadPlugin(vapoursyth_plugins_path + filename)
except Exception as e:
print("Error: ", e, end='\n', file=sys.stderr)
So? You have no console, hence no stderr, when running an application with windows. If you compile a vdub with a console window you'll see the printed errors just fine.
Mystery Keeper
20th November 2013, 18:36
I mean it is good it does nothing in VirtualDub. Like not raising any errors and just letting you encode. That wasn't a question post. Just sharing a snippet ^_^
Mystery Keeper
20th November 2013, 19:11
By the way, Myrsloik, I'm thinking about writing an editor for VapourSynth scripts in Qt. But there's something I don't quite understand now. What is the right way to present the output frame to user? Especially if it is high bit depth.
Myrsloik
20th November 2013, 19:14
By the way, Myrsloik, I'm thinking about writing an editor for VapourSynth scripts in Qt. But there's something I don't quite understand now. What is the right way to present the output frame to user? Especially if it is high bit depth.
Convert everything to 24bit RGB at high quality settings? It will end up converted to it sooner or later in the display process anyway*. (assuming you don't have a very expensive monitor and all that other asterisk stuff here)
Mystery Keeper
20th November 2013, 19:22
Hmm. I was thinking about using some existing libs. But I guess I can just reuse fmtconv code for it.
sl1pkn07
20th November 2013, 20:53
By the way, Myrsloik, I'm thinking about writing an editor for VapourSynth scripts in Qt. But there's something I don't quite understand now. What is the right way to present the output frame to user? Especially if it is high bit depth.
https://github.com/dubhater/vapoursynth-viewer
Mystery Keeper
20th November 2013, 21:02
Oh, awesome.
Joachim Buambeki
21st November 2013, 22:15
...my idea was to select Vapoursynth as a filter in the host application and then you can open a console or something similar where you can type in the filter effect (without the import video stuff of course because it does that automaticaly).
...
A similar suport for After Effects would be great but that would mean that a separate plugin would have to be written, since AE isn't OpenFX compatible unfortunately.
Is this something you would consider Myrsloik?
Myrsloik
21st November 2013, 23:24
Is this something you would consider Myrsloik?
You description is still so vague I'm not even certain what you want me to do. I can however say that it probably won't happen unless there's money involved. Those enterprise apis are just too annoying for me to want to deal with in my spare time.
I'm also curious how a command line could be integrated into any application like that. Sounds like it would be an ugly hack if it was done.
Myrsloik
22nd November 2013, 16:06
I just brought an i7 4470k and ran some speed test comparison between avisynth mt on the d2v source filter and tivtc/vivtc.
source was a 720x480 anime, all benchmark were measured by avsmeter.
avisynth-mt(fps)/cpu% vapoursynth(fps)/cpu%
d2v (mode 5)308/12% 912/12%
tfm (mode 2)215/17% 330/12%
tfm+tdecimate (mode 5)157/12% 255/12%
vfm 253/12%
vfm+vdecimate 31/13%
With vapoursynth, cpu was never fully utilized, not even 30%. And there's definitely something wrong with vdecimate, as running it alone also gives me 60fps.
I can't reproduce your results. To me all filters appear to perform similarly.
lansing
22nd November 2013, 18:28
I can't reproduce your results. To me all filters appear to perform similarly.
that benchmark was did on R21, they are running correctly in R22-test2 now.
Filters Vapoursynth 32bit/CPU% Vapoursynth 64bit/CPU%
d2v + VIVTC 202/17% 213/17%
ffms2 + VIVTC 266/23% 310/23%
This benchmark was based on the same 720x480 source before, running 10k frames with vspipe output to null.
Running ffms2 as the source filter was significantly faster than d2v.
The d2v+vivtc combination was 25% faster than d2v+tivtc in avisynth mt, while ffms2+tivtc also gave around 300fps comparing to ffms2+vivtc.
Mystery Keeper
22nd November 2013, 20:20
Tried opening Riaru Onigokko 2 movie VOB with FFMS2 isntead of d2v. Didn't crash near the end, but some frames were obviously misplaced, making the movie jerky.
Joachim Buambeki
26th November 2013, 23:36
You description is still so vague I'm not even certain what you want me to do. I can however say that it probably won't happen unless there's money involved. Those enterprise apis are just too annoying for me to want to deal with in my spare time.
I'm also curious how a command line could be integrated into any application like that. Sounds like it would be an ugly hack if it was done.
I am just a user, so I cannot tell how it would be implemented best. It would be just a pity to see all those great filters available for Avi-/Vapoursynth not available in professional applications, from what I've learned so far, alot of them are at least on par with professional PlugIns.
I guess it is a chicken egg/problem.
As a amateur coming from Avisynth currently progressing to professional tools (meaning easy to use for idiots if you can pay for it, not necessarily always because of professional quality) I can only make assumptions that something like a proper implementation of open source filters would be highly welcome by alot of pros and there may be a market for you. Of course those people will only pay/donate once there is something that shows potential by beeing usable at least on a basic level.
I can only throw in ideas, do your research on that topic and decide if it is worth the time for you. My previous posts shuld be a starting point what to look for.
Cheers
JB
Adub
27th November 2013, 00:37
Myrsloik,
I'm looking at performing a merge to renew my CUDA work to bring it up to date with the latest Vapoursynth mainline. I noticed that a large amount of the core has been refactored/regrouped recently, which is fine. The one thing I wonder about is if this is looking to be the "final" version of the core organization, or should I expect another reorganization soon? I ask, because I'd rather not start the merge work if I'm just going to have to do another large merge sometime soon.
I'm mostly talking about the standard filters extraction, along with a few other edits.
Myrsloik
27th November 2013, 00:45
Myrsloik,
I'm looking at performing a merge to renew my CUDA work to bring it up to date with the latest Vapoursynth mainline. I noticed that a large amount of the core has been refactored/regrouped recently, which is fine. The one thing I wonder about is if this is looking to be the "final" version of the core organization, or should I expect another reorganization soon? I ask, because I'd rather not start the merge work if I'm just going to have to do another large merge sometime soon.
I'm mostly talking about the standard filters extraction, along with a few other edits.
All big changes are done. There are only small fixes left on my to do list now. There's the last phase of the qt removal coming tomorrow or so but that's it.
I'm curious, how did you add cuda support? Do you keep two processing queues? One for cuda and one for cpu?
Adub
27th November 2013, 01:15
Essentially yes.
The memory usages of the CPU and GPU are tracked separately, and there is a frame level indicator identifying on which device the frame resides.
That way we can mix CPU filters with GPU filters, and optimize filter placement.
I added a core filter I call TransferFrame for moving data back and force between the CPU and GPU. This significantly simplifies the filter code, as they just ignore memory transfers, and optimizes performance by minimizing data transfer between devices.
TransferFrame lets me dictate when to transfer data and when to send it back, letting me "batch" filters accordingly.
All of this works, and I demoed it for my Masters Thesis defense, with a strong handful of the core filters being ported.
I wanted to add multi-GPU support but I didn't have time, but all GPU processing is completely asynchronous (took me a bit to get that right), meaning that it will see speed increases as scheduling hardware gets better on Nvidia's GPUs (I'm going to try and get my hands on a 780 Ti in a few months for future research).
It's a bit out of date with the current core, and still runs pre-vspipe, so I have some work to do with my test scripts and overall code base to bring it back in line. Not to mention CUDA 5.5 support, and handling the C++11 upgrades.
I wrote it with plugin developers in mind, so that they can easily add CUDA capable versions of their own plugins. Granted, I don't know how this will work with the latest core, so I'll need to dive into that as well.
Myrsloik
29th November 2013, 00:45
It's update time!
Have fun with R22 test 3 (https://dl.dropboxusercontent.com/u/73468194/vapoursynth-r22-test3.exe). It should be very close to the actual release now that almost all filters have x64 compiles ready. Just wanted to wait a bit for the plugin writers to keep up.
Changes since test 2:
Really fixed the autoloading, I mean it
A custom debug message handler can be set from python as well now
The MakeDiff and MergeDiff functions were added (mt_makediff/mt_adddiff)
The installer should no longer complain about files being in use unless it's really necessary
Chikuzen's generic filters plugin is included
Avisource for x64 is included
Known issues:
Still missing x64 compile of assvapour
Mystery Keeper
29th November 2013, 01:40
Thank you for a great release!
-Confirming autoloading working.
-Windows SmartScreen still blocks the installer due to "Unknown publisher".
-Still getting that crash with that particular video and d2vsource. This time I saved the crash report. (http://paste.org.ru/?esc0vc)
Mystery Keeper
30th November 2013, 15:26
Fiddled with Python paths in registry. Now my script opens fine by VirtualDub, but vspipe only outputs the plugins path and then crashes.
Added these keys in registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.7\PythonPath
HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\3.3\PythonPath
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\2.7\PythonPath
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\3.3\PythonPath
What is the way VapourSynth searches for Python distributions? How can I make it recognize my multiple portable distributions?
Also, here's an improved plugins load snippet for people (like me) unfamiliar with Python:
from __future__ import print_function
#put that in the beginning of script
import sys
sys.path.append('E:\\vapoursynth-plugins\\py\\')
import platform
architecture = platform.architecture()
if architecture[0] == '64bit':
vapoursynth_plugins_path = 'E:\\vapoursynth-plugins\\x64\\'
else:
vapoursynth_plugins_path = 'E:\\vapoursynth-plugins\\x32\\'
print('Plugins folder: ', vapoursynth_plugins_path, end='\n', file=sys.stderr)
import os
for filename in os.listdir(vapoursynth_plugins_path):
if filename[-4:] != '.dll':
continue
try:
core.std.LoadPlugin(vapoursynth_plugins_path + filename)
except Exception as e:
print('Error: ', e, end='\n', file=sys.stderr)
edit: Forgot to mention: I uninstalled and reinstalled VS after these changes.
Myrsloik
30th November 2013, 15:37
Fiddled with Python paths in registry. Now my script opens fine by VirtualDub, but vspipe only outputs the plugins path and then crashes.
Added these keys in registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\2.7\PythonPath
HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\3.3\PythonPath
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\2.7\PythonPath
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\3.3\PythonPath
What is the way VapourSynth searches for Python distributions? How can I make it recognize my multiple portable distributions?
Also, here's an improved plugins load snippet for people (like me) unfamiliar with Python:
from __future__ import print_function
#put that in the beginning of script
import sys
sys.path.append('E:\\vapoursynth-plugins\\py\\')
import platform
architecture = platform.architecture()
if architecture[0] == '64bit':
vapoursynth_plugins_path = 'E:\\vapoursynth-plugins\\x64\\'
else:
vapoursynth_plugins_path = 'E:\\vapoursynth-plugins\\x32\\'
print('Plugins folder: ', vapoursynth_plugins_path, end='\n', file=sys.stderr)
import os
for filename in os.listdir(vapoursynth_plugins_path):
if filename[-4:] != '.dll':
continue
try:
core.std.LoadPlugin(vapoursynth_plugins_path + filename)
except Exception as e:
print('Error: ', e, end='\n', file=sys.stderr)
edit: Forgot to mention: I uninstalled and reinstalled VS after these changes.
You only need the registry entries to trick the installer. VapourSynth itself is simply statically linked with python33.dll (i think that's the name) so as long as the relevant python dll can be found in the path it should work.
The rest is handled by python.
Mystery Keeper
30th November 2013, 16:34
Ok. I figured it out. Had to read your installer script for that. HKCU\SOFTWARE is shared for x32 and x64 applications, while HKLM\SOFTWARE is redirected. Read this. (http://msdn.microsoft.com/en-us/library/aa384253%28v=VS.85%29.aspx) I already had Python keys in HKCU, but created them manually in HKLM. That's why VS x32 wouldn't install for me - it already received the same key from HKCU for both x32 and x64. My keys were also wrong. So I moved the correct keys from HKCU to HKLM and created correct copies in Wow6432Node. Then installed VS again. It installed properly. Vspipe x32 works fine, but x64 still crashes.
You need to improve your installer logic somehow. I see it like this: when on x64, check HKLM first. If both keys are present - you can install both x32 and x64 VS. If that fails - check HKCU and only install one version. I don't know how to determine which one though.
edit: I think the safest logic would be this:
-Check HKCU key.
-If it is present - determine, which Python version it points to and install the corresponding VS version.
-Check HKLM keys for those versions that were not found in HKCU. Meaning one or both - you won't find the keys for both versions in HKCU.
-If present - check if they point to correct Python versions and install corresponding VS versions.
Myrsloik
30th November 2013, 16:56
Ok. I figured it out. Had to read your installer script for that. HKCU\SOFTWARE is shared for x32 and x64 applications, while HKLM\SOFTWARE is redirected. Read this. (http://msdn.microsoft.com/en-us/library/aa384253%28v=VS.85%29.aspx) I already had Python keys in HKCU, but created them manually in HKLM. That's why VS x32 wouldn't install for me - it already received the same key from HKCU for both x32 and x64. My keys were also wrong. So I moved the correct keys from HKCU to HKLM and created correct copies in Wow6432Node. Then installed VS again. It installed properly. Vspipe x32 works fine, but x64 still crashes.
You need to improve your installer logic somehow. I see it like this: when on x64, check HKLM first. If both keys are present - you can install both x32 and x64 VS. If that fails - check HKCU and only install one version. I don't know how to determine which one though.
Improve what? I support the official python distribution. If you want to play around with custom junk you're free to do so. The crashes you mention are most likely related to you not being able to put all needed python an vapoursynth dlls where they can be found.
Mystery Keeper
30th November 2013, 17:13
Oh. And now vspipe x64 printed "Frame returned not of the declared type" before crashing. VirtualDub still works perfectly fine.
Why so hostile? I'm sincerely trying to help by testing and suggesting improvements. I really appreciate your hard work.
Mystery Keeper
30th November 2013, 17:35
Played with my script. The source of crashes is core.std.MakeDiff.
Myrsloik
30th November 2013, 18:08
Oh. And now vspipe x64 printed "Frame returned not of the declared type" before crashing. VirtualDub still works perfectly fine.
Why so hostile? I'm sincerely trying to help by testing and suggesting improvements. I really appreciate your hard work.
Because it's a pointless problem to solve. I may as well put up an archive of all the files in the installer or make it possible to manually select the python install path(s). That would make more sense even for your odd portable case.
Anyway, I'll test makediff and see what happens...
Myrsloik
30th November 2013, 18:21
Played with my script. The source of crashes is core.std.MakeDiff.
Can't reproduce it. I used this script:
import vapoursynth as vs
core = vs.get_core()
clip = core.avisource.AVISource('a downloaded file.avi')
blur_clip = core.generic.Blur(clip, planes=0)
diff_clip = core.std.MakeDiff(clip, blur_clip, planes=0)
sharpened_clip = core.std.MergeDiff(clip, diff_clip, planes=0)
sharpened_clip.set_output()
Mystery Keeper
30th November 2013, 18:35
Tried your script, only with ffms2. The same result:
-perfectly fine with vspipe x32
-perfectly fine with VirtualDub x64
-crash with vspipe x64
Went as far as completely reinstalling all Python 3.3 distributions and VapourSynth. Still the same.
Are_
1st December 2013, 11:07
I'm able to reproduce this with some videos only when using ffms2 as source filter (linux.x86_64).
Investigating a little it looks like generic.Blur corrupts the frames (not sure why, how), and once this happens, if you pass this frames to std.MakeDiff it crashes vspipe (it also crashes vsviewer).
import vapoursynth as vs
core = vs.get_core()
clip = core.ffms2.Source('[some] random - 07 [file].mkv')
blur_clip = core.generic.Blur(clip, planes=0)
#diff_clip = core.std.MakeDiff(clip, blur_clip, planes=0)
diff_clip = blur_clip
sharpened_clip = core.std.MergeDiff(clip, diff_clip, planes=0)
sharpened_clip.set_output()
A corrupted frame. (http://i.imgur.com/wdqiedR.png)
But I'm not sure if its ffms2's fault, genericfilters's fault, or my hardware. :/
Mystery Keeper
1st December 2013, 12:21
For me it doesn't crash my 64-bit build of vsviewer. Though I modified it to compile with Qt5. Shouldn't make any difference. Also, no corrupted frames.
64-bit vspipe crashes regardless of the source, even if I replace Blur with BlankClip. Both MakeDiff and MergeDiff lead to crash. And the crash always happens right in the beginning.
Myrsloik
4th December 2013, 22:30
Here's R22 RC1 (https://dl.dropboxusercontent.com/u/73468194/vapoursynth-r22-rc1.exe).
Changes from test 3:
Generic filters not included at the moment since there probably are some bugs in it
Fixes reference leaks in some filters when a frame error occurs
The resize filter reports more errors immediately on instantiation
Sorting in list_functions()
Still looking at the crashiness created by generic filters and maybe makediff. Will probably be a few more days until I have time to investigate it thoroughly.
Myrsloik
5th December 2013, 12:48
Here's an x64 compile of genericfilters (https://dl.dropboxusercontent.com/u/73468194/GenericFilters.dll).
It fixes an access violation in the sse2 optimized 9/10 bit 3x3 convolution. If there still are any crahes at all remaining in VapourSynth it'd be helpful if you report them again.
Mystery Keeper
5th December 2013, 17:37
The same. 64-bit vspipe crashes on MakeDiff/MergeDiff. Now with error message.
http://s020.radikal.ru/i721/1312/c7/7fe84e517535.png
Edit: And I remind, the crash does NOT happen in 64-bit VirtualDub.
Myrsloik
5th December 2013, 22:32
The same. 64-bit vspipe crashes on MakeDiff/MergeDiff. Now with error message.
http://s020.radikal.ru/i721/1312/c7/7fe84e517535.png
Edit: And I remind, the crash does NOT happen in 64-bit VirtualDub.
Tried it again. It still works here in vspipe. I even tried YUV420P8/10/16 in valgrind and didn't see anything relevant. I simply can't reproduce it.
Any kind of debugging info would help or would it be possible for me to remotely control your computer for a few minutes?
Mystery Keeper
5th December 2013, 23:41
WunDBG output. (http://paste.org.ru/?sn3mwk)
http://s018.radikal.ru/i522/1312/fc/f1c97e611f48.png
Myrsloik
6th December 2013, 00:18
Find me on irc. I'm in #darkhold on Rizon and some other avisynth channels. This won't be solved without faster communication.
absence
6th December 2013, 16:39
Is the CUDA work general enough that OpenCL can be added as well? Hopefully CUDA and OpenCL can share common logic for handling filter placement, transfers to/from GPU, etc. even if the APIs are different.
Myrsloik
7th December 2013, 12:56
Here's R22 RC2 (https://dl.dropboxusercontent.com/u/73468194/vapoursynth-r22-rc2.exe).
After a long debugging session with mystery keeper a very rare asm bug on x64 windows has been fixed.
The installer will now refuse to install when the python installations are a mess.
Generic filters has been added again after finding the crash issue in the code.
This will most likely become the final released version.
lansing
9th December 2013, 18:54
I tried to run a vpy script in vsfs mode, the script has loaded mvtools2 from avs, and when I try to mount it, it returned an error.
Python exception: No attribute with the name avs exists. Did you mistype a plugin namespace?
Traceback (most recent call last):
File "vapoursynth.pyx", line 1148, in vapoursynth.vpy_evaluateScript (src\cython\vapoursynth.c:17833)
File "F:\source\1993.vpy", line 12, in <module>
core.avs.LoadPlugin(r"C:\Program Files (x86)\AviSynth 2.5\plugins\mvtools2.dll")
File "vapoursynth.pyx", line 789, in vapoursynth.Core.__getattr__ (src\cython\vapoursynth.c:12729)
vapoursynth.Error: No attribute with the name avs exists. Did you mistype a plugin namespace?
Myrsloik
9th December 2013, 19:02
I tried to run a vpy script in vsfs mode, the script has loaded mvtools2 from avs, and when I try to mount it, it returned an error.
Python exception: No attribute with the name avs exists. Did you mistype a plugin namespace?
Traceback (most recent call last):
File "vapoursynth.pyx", line 1148, in vapoursynth.vpy_evaluateScript (src\cython\vapoursynth.c:17833)
File "F:\source\1993.vpy", line 12, in <module>
core.avs.LoadPlugin(r"C:\Program Files (x86)\AviSynth 2.5\plugins\mvtools2.dll")
File "vapoursynth.pyx", line 789, in vapoursynth.Core.__getattr__ (src\cython\vapoursynth.c:12729)
vapoursynth.Error: No attribute with the name avs exists. Did you mistype a plugin namespace?
VSFS uses the x64 version by default and avisynth compatibility can't work there. You have to unregister the x64 vsfs handler and register the 32 bit one instead to do what you want.
lansing
9th December 2013, 19:11
VSFS uses the x64 version by default and avisynth compatibility can't work there. You have to unregister the x64 vsfs handler and register the 32 bit one instead to do what you want.
Got it working thanks.
Myrsloik
10th December 2013, 14:53
R22 released. Download links on the website as usual and the changelog is in the first post.
Don't forget to read the notes in the release blog post (http://www.vapoursynth.com/2013/12/r22-the-number-of-bits-shall-be-64/) about compatibility. Lut2, Merge and MaskedMerge got the arguments changed.
Have fun with the 64 bits in windows.
sneaker_ger
10th December 2013, 15:29
The following script does crash, not sure if l-smash's or vs' fault:
import vapoursynth as vs
core = vs.get_core()
ret = core.lsmas.LWLibavSource(source='park_joy_1080p50.y4m')
ret.set_output()
http://media.xiph.org/video/derf/y4m/park_joy_1080p50.y4m
Myrsloik
10th December 2013, 15:34
The following script does crash, not sure if l-smash's or vs' fault:
import vapoursynth as vs
core = vs.get_core()
ret = core.lsmas.LWLibavSource(source='park_joy_1080p50.y4m')
ret.set_output()
http://media.xiph.org/video/derf/y4m/park_joy_1080p50.y4m
Try it with other files and see if it works. Preferably one that's worked before.
sneaker_ger
10th December 2013, 15:55
Crashes with other y4m files as well, not with e.g. mov files. So I guess it's l-smash's fault?
Any other source filter for y4m?
Myrsloik
10th December 2013, 15:58
Crashes with other y4m files as well, not with e.g. mov files. So I guess it's l-smash's fault?
Any other source filter for y4m?
Probably.
You could try you luck with vsrawsource (http://forum.doom9.org/showthread.php?t=166075) if you don't mind fidgeting around a bit with offsets.
FFMS2 may also work. If you're really lucky.
sneaker_ger
10th December 2013, 16:06
ffms2 fails, too. vsrawsource works perfectly, seems to even read the header - did not expect that.
Adub
11th December 2013, 02:29
Excellent! Congrats on the R22 release!
I'm especially excited about the Qt removal, as it will make compiling CUDA enhancements on Mac significantly easier.
Thanks for the hard work Myrsloik!
Adub
19th December 2013, 07:42
Hmm, I seem to be durping with the latest version of Vapoursynth.
I can't get vspipe to work properly on a i7 Ubuntu 13.10 machine, 16GB of RAM.
adub@adub-desktop:/usr/local/lib $ python3
Python 3.3.2+ (default, Oct 9 2013, 14:50:09)
[GCC 4.8.1] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import vapoursynth as vs
>>> core = vs.get_core()
>>> print(core)
Core
VapourSynth Video Processing Library
Copyright (c) 2012-2013 Fredrik Mellbin
Core r22
API r3
Number of Threads: 8
Add Caches: True
Accept Lowercase: False
>>>
adub@adub-desktop:/usr/local/lib $ vspipe -version
Failed to initialize VapourSynth environment
adub@adub-desktop:/usr/local/lib $
What am I missing?
Ooops! Figured it out! I hadn't built and installed the Cython modules yet. Everything works like a champ now!
foxyshadis
21st December 2013, 01:38
Is there a location for the autoloading of .py or .vpy scripts? I didn't see anything about this in the docs, and site-packages has a LOT of junk in it, so I'd prefer not to replicate that folder to all of my systems.
Myrsloik
21st December 2013, 01:48
Is there a location for the autoloading of .py or .vpy scripts? I didn't see anything about this in the docs, and site-packages has a LOT of junk in it, so I'd prefer not to replicate that folder to all of my systems.
Python itself already has enough import mechanisms. I haven't added any additional ones. You can put all VapourSynth scripts in their own sub directory with minimal effort. Consult the python documentation on modules and look up .pth files for some hints on how it can be structured.
By autoloading I assume you mean that you can use import to load the script.
foxyshadis
21st December 2013, 02:15
Python itself already has enough import mechanisms. I haven't added any additional ones. You can put all VapourSynth scripts in their own sub directory with minimal effort. Consult the python documentation on modules and look up .pth files for some hints on how it can be structured.
By autoloading I assume you mean that you can use import to load the script.
I was hoping something like .avsi scripts in the Avisynth plugins folder. If site-packages or manual loading with a path is the only way to go, I'll do that then.
supernater
28th December 2013, 16:06
I'm trying to install vapoursynth on Ubuntu 12.04. When I was able to run ./waf configure/build/install just fine. However, when I run...
PYTHON=python3 ./setup.py build
I get....
running build
running build_ext
cythoning src/cython/vapoursynth.pyx to build/temp.linux-x86_64-2.7/pyrex/vapoursynth.c
Error compiling Cython file:
------------------------------------------------------------
...
mtDebug = 0,
mtWarning = 1,
mtCritical = 2,
mtFatal = 3
ctypedef void (__stdcall *VSFrameDoneCallback)(void *userData, const VSFrameRef *f, int n, VSNodeRef *node, const char *errorMsg)
^
------------------------------------------------------------
src/cython/vapoursynth.pxd:153:84: Expected ')', found '*'
Error compiling Cython file:
------------------------------------------------------------
...
return str(self.value)
def __repr__(self):
return repr(self.value)
cdef void __stdcall message_handler_wrapper(int msgType, const char *msg, void *userData) nogil:
^
------------------------------------------------------------
src/cython/vapoursynth.pyx:94:68: Expected ')', found '*'
building 'vapoursynth' extension
x86_64-linux-gnu-gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I. -Isrc/cython -I/usr/include/python2.7 -c build/temp.linux-x86_64-2.7/pyrex/vapoursynth.c -o build/temp.linux-x86_64-2.7/build/temp.linux-x86_64-2.7/pyrex/vapoursynth.o
build/temp.linux-x86_64-2.7/pyrex/vapoursynth.c:1:2: error: #error Do not use this file, it is the result of a failed Cython compilation.
error: command 'x86_64-linux-gnu-gcc' failed with exit status 1
At first I thought it was because I was using an older version of cython. The default cython version on ubuntu 12.04 is 0.17.4 I updated my repo list to include the cython ppa and installed cython 0.19.2 and the same error occurs. Is there a configuration setting I'm missing? Thanks.
qyot27
28th December 2013, 16:32
You're not supposed to use the 'build' rule on the Cython binding.
python3 ./setup.py install
is enough. Or more preferably, the install for VapourSynth itself and the Cython binding should be:
sudo checkinstall --pkgname=vapoursynth --pkgversion="$(grep Version build/pc/vapoursynth.pc | \
sed 's/ /"/g' | cut -f2 -d "\"")"R-r"$(git rev-list --count HEAD)" --default --backup=no --fstrans=no \
--nodoc ./waf install
sudo checkinstall --pkgname=vapoursynth-cython --pkgversion="$(grep Version build/pc/vapoursynth.pc | \
sed 's/ /"/g' | cut -f2 -d "\"")"R-r"$(git rev-list --count HEAD)" --default --requires=vapoursynth \
--backup=no --fstrans=no --nodoc python3 ./setup.py install
(I can't remember why --nodoc is there)
Two separate packages generated by checkinstall so that both are registered in the package management system.
supernater
29th December 2013, 03:21
Your instructions worked. I can see the two packages installed in synaptic. However, the installation instructions say to test the installation by running...
./waf test
When I run this I get this error...
Waf: Entering directory `/home/supernater/Desktop/vapoursynth/build'
Traceback (most recent call last):
File "test/test.py", line 2, in <module>
import vapoursynth as vs
ImportError: libvapoursynth.so: cannot open shared object file: No such file or directory
Is this test necessary?
qyot27
29th December 2013, 14:28
I have no idea. But always remember to follow up the install of shared libraries with 'sudo ldconfig' - otherwise, the system won't be able to find the .so.
supernater
30th December 2013, 00:49
Thanks for the tip. It worked. I was able to run the tests, only two of the 39 failed.
Waf: Entering directory `/home/supernater/Desktop/vapoursynth/build'
..................................EE...
======================================================================
ERROR: test_suffleplanes_arg2 (__main__.CoreTestSequence)
----------------------------------------------------------------------
Traceback (most recent call last):
File "test/test.py", line 161, in test_suffleplanes_arg2
self.core.std.ShufflePlanes(clip, planes=[0, 1, 2], format=vs.YCOCG)
File "vapoursynth.pyx", line 1044, in vapoursynth.Function.__call__ (build/temp.linux-x86_64-3.3/pyrex/vapoursynth.c:16573)
vapoursynth.Error: ShufflePlanes: Function does not take argument(s) named format
======================================================================
ERROR: test_suffleplanes_arg3 (__main__.CoreTestSequence)
----------------------------------------------------------------------
Traceback (most recent call last):
File "test/test.py", line 165, in test_suffleplanes_arg3
self.core.std.ShufflePlanes(clip, planes=[1, 1, 2], format=vs.RGB)
File "vapoursynth.pyx", line 1044, in vapoursynth.Function.__call__ (build/temp.linux-x86_64-3.3/pyrex/vapoursynth.c:16573)
vapoursynth.Error: ShufflePlanes: Function does not take argument(s) named format
----------------------------------------------------------------------
Ran 39 tests in 0.721s
FAILED (errors=2)
Test test/test.py failed
Not sure what that means, but at least it found the .so file.
Mystery Keeper
30th December 2013, 03:05
That means argument of ShufflePlanes was renamed from "format" to "colorfamily", but the test wasn't updated.
As far as I understand, this commit (https://github.com/vapoursynth/vapoursynth/commit/068c6c463a50db63712dd1b3261ef0d87f149bb9) fixes it.
supernater
31st December 2013, 15:19
Yup that did it! All tests ran successfully!
MeteorRain
3rd January 2014, 13:21
Had a script that calls 2 avisynth plugins / functions on a clip. On r19 it did not report frame not prefetched, but on r22 it does.
I have read your blog but couldn't find anything useful regarding to this change.
Is there anything I can do to quick fix the issue? like specify the prefetch frame list without rewrite the plugin.
FYI one of it is the overlay()
Thanks.
Myrsloik
3rd January 2014, 13:39
Had a script that calls 2 avisynth plugins / functions on a clip. On r19 it did not report frame not prefetched, but on r22 it does.
I have read your blog but couldn't find anything useful regarding to this change.
Is there anything I can do to quick fix the issue? like specify the prefetch frame list without rewrite the plugin.
FYI one of it is the overlay()
Thanks.
The default for prefetching changed to make a bit more sense around r20 I think. It was necessary to fix the huge performance issues that would otherwise should up in decimate/tdecimate/any serious framerate changing filter. Now frames are only prefetched if a filter is known, before that the prefetching assumed that one input frame needed to be fetched. Sometimes not the right one...
Anyway, if it isn't slower don't bother doing anything. It's only a warning. If you simply want to overlay things you can usually use Lut2 or Expr to accomplish something similar.
MeteorRain
3rd January 2014, 14:06
The default for prefetching changed to make a bit more sense around r20 I think. It was necessary to fix the huge performance issues that would otherwise should up in decimate/tdecimate/any serious framerate changing filter. Now frames are only prefetched if a filter is known, before that the prefetching assumed that one input frame needed to be fetched. Sometimes not the right one...
Anyway, if it isn't slower don't bother doing anything. It's only a warning. If you simply want to overlay things you can usually use Lut2 or Expr to accomplish something similar.
:thanks:
For overlay I'm using it's slicing part. I wrote a function to do the cropping & stacking manually, but still wonder if there are any better / faster methods.
Currently vapoursynth can't consume all the CPU resources. I have to run 2 tasks in parallel to archive 100% usage. I guess there's still some space to improve multi-thread performance.
Is it possible to add a "FIFO prefecher" inside a script if given all following operations are linear?
Myrsloik
3rd January 2014, 14:08
:thanks:
For overlay I'm using it's slicing part. I wrote a function to do the cropping & stacking manually, but still wonder if there are any better / faster methods.
Currently vapoursynth can't consume all the CPU resources. I have to run 2 tasks in parallel to archive 100% usage. I guess there's still some space to improve multi-thread performance.
Is it possible to add a "FIFO prefecher" inside a script if given all following operations are linear?
I need to see the whole script you're using if you want more hints.
MeteorRain
3rd January 2014, 14:19
I need to see the whole script you're using if you want more hints.
https://github.com/msg7086/MyECTools/blob/master/MyECTools.py
v = core.avs.MPEG2Source("main.d2v")
v = haf.QTGMC(v, Preset="super fast", SubPel=2, TFF=True, FPSDivisor=2)
v = core.avs.EraseLOGO(v, logoFile)
v = ect.ECSlice(v, l=1292, t=32, r=64, b=996, sp1=(lambda c: core.avs.fft3dGPU(c, sigma=4, plane=4)), spmode=1) # Also tried FFT3DFilter
#crop&resize etc
Core is initialized with threads=6, using 4c6t on i7 4770, CPU affinity enforced, CPU resources separated from x264 using pipe
Myrsloik
6th January 2014, 11:38
https://github.com/msg7086/MyECTools/blob/master/MyECTools.py
v = core.avs.MPEG2Source("main.d2v")
v = haf.QTGMC(v, Preset="super fast", SubPel=2, TFF=True, FPSDivisor=2)
v = core.avs.EraseLOGO(v, logoFile)
v = ect.ECSlice(v, l=1292, t=32, r=64, b=996, sp1=(lambda c: core.avs.fft3dGPU(c, sigma=4, plane=4)), spmode=1) # Also tried FFT3DFilter
#crop&resize etc
Core is initialized with threads=6, using 4c6t on i7 4770, CPU affinity enforced, CPU resources separated from x264 using pipe
I don't understand why you set thread affinity. I suspect that fft3dgpu is still the limiting filter in your script though. If you tell me what resolution the input clip is I can try running the whole thing myself a bit later.
MeteorRain
7th January 2014, 09:33
I don't understand why you set thread affinity. I suspect that fft3dgpu is still the limiting filter in your script though. If you tell me what resolution the input clip is I can try running the whole thing myself a bit later.
I set affinity for the process because it'll be faster than not to do so. Even way faster for some specific program. And I guess if it cannot consume all resources under 4c6t, it cannot do under 4c8t as well. Vice versa.
I also tried fft3dfilter but that doesn't make much difference.
The source was captured from TV and is 1920x1080 30i/1.001
Well, my (original) question was, if I see lots of "frame # not prefetched" where same frame number appears multiple time, does this mean that it is slower than it should be?
========== EDIT:
Well I'll try to read the source code and see if I can do something
========== EDIT2:
FYI the fft3dgpu has a function name of "fft3dGPU" which is not the same as in the prefetch list.
Myrsloik
7th January 2014, 18:20
========== EDIT:
Well I'll try to read the source code and see if I can do something
========== EDIT2:
FYI the fft3dgpu has a function name of "fft3dGPU" which is not the same as in the prefetch list.
Sigh... capiTAliZation. Here's a dll (https://dl.dropboxusercontent.com/u/73468194/VapourSynth.dll) with the proper prefetch name.
Replace the one in Python33\Lib\site-packages\vapoursynth and see if it speeds up.
MeteorRain
8th January 2014, 05:23
Sigh... capiTAliZation. Here's a dll (https://dl.dropboxusercontent.com/u/73468194/VapourSynth.dll) with the proper prefetch name.
Replace the one in Python33\Lib\site-packages\vapoursynth and see if it speeds up.
Not faster. Actually I found the bottleneck sort of from the source filter. Either mpeg2source or d2v.source uses ~12% even if I give them 4c8t and set threads=1 or 4 or 8. I suspect that these filters are single threaded.
Myrsloik
8th January 2014, 11:15
Not faster. Actually I found the bottleneck sort of from the source filter. Either mpeg2source or d2v.source uses ~12% even if I give them 4c8t and set threads=1 or 4 or 8. I suspect that these filters are single threaded.
Actually d2vsource should be multithreaded. Guess I'll have to try it myself and see what happens...
Myrsloik
10th January 2014, 20:24
Not faster. Actually I found the bottleneck sort of from the source filter. Either mpeg2source or d2v.source uses ~12% even if I give them 4c8t and set threads=1 or 4 or 8. I suspect that these filters are single threaded.
Are you sure you're using the latest version of d2vsource? It's the only remaining explanation I can think of (apart from d2vsource bugs/weird source file).
Iznogûd
15th January 2014, 18:48
I've succesfully encoded a short clip (1000 frames) using this simple script
import vapoursynth as vs
core = vs.get_core()
ret = core.ffms2.Source(source=r'test.mkv')
ret = core.std.AssumeFPS(ret, fpsnum=24000, fpsden=1001)
ret = core.std.Trim(clip=ret, first=2000, length=1000)
ret = core.resize.Spline(clip=ret, width=1280, height=720)
ret.set_output()
and this command line
"C:\Program Files (x86)\VapourSynth\core32\vspipe.exe" "test.vpy" - -y4m | D:\MeGUI\tools\x264\x264_64.exe --crf 19 --output "out_test.mkv" --demuxer y4m --stdin y4m -
However, when I try it with the 64 bit version,
"C:\Program Files (x86)\VapourSynth\core64\vspipe.exe" "test.vpy" - -y4m | D:\MeGUI\tools\x264\x264_64.exe --crf 19 --output "out_test.mkv" --demuxer y4m --stdin y4m -
it crashes at the very beginning with this message:
x264 [error]: could not open input file '-'
Error: fwrite() call failed when writing frame: 0, plane: 0, line: 12, errno: 22
Output 4 frames in 0.30 seconds (10.39 fps)
Phyton 3.3.3 (32 and 64 bits) on separate folders and Vapoursynth R22, but I also tried each version separately as well as the 32 and 64 bits x264 and the results are always the same: 32 bits work, 64 doesn't.
Am I missing anything obvious? :confused:
Iznogûd
16th January 2014, 08:31
Yes, it does:
Width: 1280
Height: 720
Frames: 1000
FPS: 24000/1001
Format Name: YUV420P8
Color Family: YUV
Bits: 8
SubSampling W: 1
Subsampling H: 1
Output 0 frames in 0.20 seconds (0.00fps)
Vspipe 32 yields up the same info. Furthermore, I'm able to mount the script and watch it OK.
Thanks for your help
Myrsloik
16th January 2014, 16:06
Yes, it does:
Vspipe 32 yields up the same info. Furthermore, I'm able to mount the script and watch it OK.
Thanks for your help
Odd, there's certainly no obvious problem here. The only other test I can think of is to do something like:
"C:\Program Files (x86)\VapourSynth\core64\vspipe.exe" "test.vpy" - -y4m > file.y4m
And then see if anything was written to the file after a few seconds.
Iznogûd
16th January 2014, 17:58
@Myrsloik:
Both versions do indeed write a file with .y4m extension, about 1.30 Gb, but whereas Mediainfo gives this log for the 32 bit one (which I can encode with x264),
General
Complete name : E:\test_vs\file32.y4m
Format : YUV4MPEG2
File size : 1.29 GiB
Duration : 41s 708ms
Overall bit rate : 265 Mbps
Video
Format : YUV
Duration : 41s 708ms
Bit rate : 265 Mbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Scan type : Progressive
Compression mode : Lossless
Bits/(Pixel*Frame) : 12.000
Stream size : 1.29 GiB (100%)
only sees the 64 bit as a mere big file (which x264 can't open):
General
Complete name : E:\test_vs\file64.y4m
File size : 1.29 GiB
I repeated the test after uninstalling everything (Python, Pismo & VapourSynth) and reinstalling the 64 bit versions only, but the result is the same.
Please let me know if you need me to perform further testing.
Thanks for your help.
MasterNobody
16th January 2014, 20:04
Iznogûd
Can you upload the first few MBs (5 MBs should be enough) of this bad y4m? Or look at it yourself with any HEX/text editor. The first two lines should start from "YUV4MPEG2" and "FRAME" i.e. should looks like:
YUV4MPEG2 W1280 H720 F24000:1001 Ip A1:1
FRAME
<some binary data>
Iznogûd
16th January 2014, 21:18
@MasterNobody
Indeed, the 64bit file shows two initial bytes (0a 0a) which are not present in the 32bit one.
13975
If I delete these two offending bytes with an hex editor, the file is happily accepted by x264. So it would seem that vspipe64 is writing the wrong header.
I think you've nailed it. :thanks:
Myrsloik
17th January 2014, 00:00
I forgot a debug printf in there. Here's a fixed x64 dll. (https://dl.dropboxusercontent.com/u/73468194/VapourSynth.dll) Remember to put it in <Python64>\Lib\site-packages\vapoursynth.
Iznogûd
17th January 2014, 00:38
Done! It works OK now.
Thank you very much for your help, folks.
Adub
17th January 2014, 19:25
Quick update on my merge of the latest mainline with my CUDA enhancements.
I'm about 80% of the way there. Unfortunately, CUDA's nvcc compiler is a bit of a...bugger when it comes to C++11 support. Normally this isn't a problem as long as I don't use C++11 constructs/headers in my .cu files. This the case for almost all of my files, except for two. One should be relatively easy to fix, the other not quite as easy.
In order to get around nvcc's C++11 issues, I need to isolate the bare CUDA work to it's own CUDA file, with my constructors in a separate, C++11 compatible .cpp file. The .cpp file will essentially act as a wrapper, allowing me to overload some of the central 'vscore' constructors while still allowing for proper compilation using C++11.
It's a bit unfortunate that I have to try and do it this way, but that's the way it's going to have to be until CUDA offers better C++11 handling (which it really should, but it handles it in a stupid way at times).
If you want to look at the latest version of the code, Myrsloik, just ping me. Not all of it is working yet (obviously) but it can give you an idea of what I'm doing.
Adub
2nd February 2014, 02:12
Good news! I was able to handle all of the C++11 incompatibilities and get my branch back to a reliable, testable implementation.
I'm also in the process of getting Vapoursynth working on my Mac for additional testing purposes. I've got the master branch working and compiling and all tests are passing 100%, so I'll switch over to making sure my CUDA branch works on Mac as well.
Depending on how easy that is, I'm going to write up a quick testing tool/framework for automated performance analysis, so that I can track performance differences between CPU/GPU implementations and differences in performance between commits.
Just checking in.
Mystery Keeper
2nd February 2014, 12:53
What exactly are you implementing in CUDA?
Adub
2nd February 2014, 20:25
Essentially the core filters, and the associated memory management/control routines required to support a high performance CUDA GPU.
I ported over a section of the core filters for my Thesis work, but some still remain. That, and my earlier work became outdated with the move to C++11 from Qt.
Filters that see the most benefit are CPU-bound filters like Expr. Stuff like Transpose and LUT actually suffer a performance degradation when performed alone (since most of the time is spent transferring the data to and from the GPU), but it's possible to perform a variety of operations while keeping the data on the GPU, which eventually leads to a cumulative performance boost.
Mystery Keeper
3rd February 2014, 09:55
Well, like you said, the bottleneck of GPGPU is data transferring between CPU and GPU memory. Filter would only gain performance boost if actual computing takes significantly more time than memory transfer. You'd do well to port dfttest, which uses FFT and windowing and what not. High complexity AND high parallelism potential. As for core filters - I don't know how you would "perform a variety of operations while keeping the data on the GPU" on an arbitrary filters chain. Are you making your own cache?
Youka
3rd February 2014, 16:16
I tried to compile vapoursynth from github source on lubuntu 13.10 (virtualbox) yesterday, but got some problems:
- configure doesn't search for python3, just looking for the default python interpreter which is 2.7.5 (fix: changed symbolic link of '/usr/bin/python' from python2 to python3)
- build threw an error because of missing sse2 support in "src/filters/removegrain/clense.cpp" (fix: configure with disabled filters)
- test couldn't import vapoursynth, on some systems "/usr/local/lib" isn't visible for the runtime linker (fix: configure with changed installdir or added local directory to ldconfig)
Are 1) & 3) usual and 2) a new bug or am i doing something wrong?
Adub
3rd February 2014, 19:14
1) A simple "PYTHON=python3 ./waf configure build" works just fine.
2) Missing SSE2 support? What processor are you presenting to your virt? Any processor made within the past 10 years has SSE2 support.
3) I've never seen this before, as long as I've installed the Cython modules using "./setup.py install" (possibly with sudo).
Adub
3rd February 2014, 19:28
Well, like you said, the bottleneck of GPGPU is data transferring between CPU and GPU memory. Filter would only gain performance boost if actual computing takes significantly more time than memory transfer. You'd do well to port dfttest, which uses FFT and windowing and what not. High complexity AND high parallelism potential. As for core filters - I don't know how you would "perform a variety of operations while keeping the data on the GPU" on an arbitrary filters chain. Are you making your own cache?
You are correct, most speed boosts are only seen on computationally intensive filters.
As for my "variety of operations", yes, I do keep my own cache of sorts on the GPU. The GPU cache is tracked independently of the main CPU cache.
All frame transfers are dictated by the user using a function called TransferFrame. This keeps the transfer logic in one place and prevents sending data back and forth after every function execution.
Each filter identifies where the data is located for the particular frame and executes a GPU or CPU kernel accordingly. All GPU kernels are executed asynchronously using CUDA streams, which let the GPU schedule work as efficiently as possible, and sometimes operate on multiple planes at once depending on resources.
Example of what I'm talking about:
clip = ...
clip = core.TransferFrame(clip, 1)
clip = core.filterA(clip)
clip = core.filterB(clip)
clip = core.filterC(clip)
clip = core.TransferFrame(clip, 0)
clip = core.filterD(clip)
etc...
Filters A, B, and C operate on the clip's data entirely on the GPU, with Filter D operating on frame data on the CPU. That way you can mix and match filters that may not have GPU support with those that do.
Youka
3rd February 2014, 19:31
1) Creating an alias is maybe the best solution, but it would be better when configure test for python3 too.
2) Error comes from emmintrin.h:
#ifndef __SSE2__
# error "SSE2 instruction set not enabled"
#else
...__SSE2__ isn't set by the compiler (-msse2 could solve it). The processor is surely not the problem.
3) Test still doesn't find the module. "ldd vspipe" shows an incompatibility too...
Myrsloik
3rd February 2014, 19:39
A bonus question about your secret CUDA/GPU build...
Can it handle SLI/multiple graphics cards as well? I suspect you'd need to have a function to transfer between different GPUs as well to get around the latency.
Myrsloik
3rd February 2014, 19:43
I tried to compile vapoursynth from github source on lubuntu 13.10 (virtualbox) yesterday, but got some problems:
- configure doesn't search for python3, just looking for the default python interpreter which is 2.7.5 (fix: changed symbolic link of '/usr/bin/python' from python2 to python3)
- build threw an error because of missing sse2 support in "src/filters/removegrain/clense.cpp" (fix: configure with disabled filters)
- test couldn't import vapoursynth, on some systems "/usr/local/lib" isn't visible for the runtime linker (fix: configure with changed installdir or added local directory to ldconfig)
Are 1) & 3) usual and 2) a new bug or am i doing something wrong?
1. Known issue due to how waf autodetects things, a note has been added to the installation instructions
2. Fixed in git right after you mentioned it
3. It's the way it is in the unixy world (or so I've heard)
Adub
3rd February 2014, 19:46
Haha, I'd hardly call it secret : https://github.com/adworacz/vapoursynth/tree/cuda
Don't hate on all of the code yet, as I've got some refactoring and code cleanup to do after the C++11 merge, not to mention more filters to port.
Multiple cards is definitely something that I want to handle as well. I almost started implementing it on two massive Kepler machines during my thesis research, but I didn't have the time to do it before I had to graduate. So, multiple graphics card support is pending my getting a hold of a pair of GTX 780 Ti's. :D Those were the first consumer cards with fully unlocked CUDA cores based on the Kepler architecture.
That, and CUDA 6 offers some interesting support of a "universal memory" paradigm for GPU memory, which may make programming for multiple cards easier. That is something I will have to dig into more when I get a chance. I think I presented a few ideas in my thesis, but I'll have to remind myself of them again. :P
Edit: I think one idea I had was striping frames across GPUs, sort of a load balance technique. Of course, this mostly just works for spatial filters, but since the core filters are essentially spatial filters, it can work as a proof of concept.
Mystery Keeper
4th February 2014, 15:06
Adub, I'd recommend to wait for the new generation of nVidia cards coming in April. Not only they'll have three times more cores, but also some kind of memory improvements.
Adub
4th February 2014, 18:36
Do you have a link on details about the new cards? I'm curious to see what the differences are.
Mystery Keeper
5th February 2014, 01:07
http://www.itworld.com/hardware/397985/nvidias-next-generation-gpus-coming-sooner-expected
For example. You can google for GTX 800.
lansing
10th February 2014, 07:30
Is there any source filter that can open grf file created from graphicstudio?
Myrsloik
10th February 2014, 10:31
Is there any source filter that can open grf file created from graphicstudio?
No, I didn't adapt directshowsource from avisynth since I didn't think anyone would actually need it.
lansing
10th February 2014, 20:14
I was trying the work around way to use the intel quicksync hw decoding from the LAV filter using graphicstudio. I tried ran it along with tivtc in avisynth mt on a blu ray video, but the speed is not good, so I'm just curious how it will do in vapoursynth.
Myrsloik
11th February 2014, 15:21
Short summary for those who can't be bothered to click links: I'm sneezing and a R23 will be done soon as a simple maintenance release.
Here's a slightly longer post (http://www.vapoursynth.com/2014/02/the-yearly-slowdown/) with a few more points. Most of them filler material.
foxyshadis
12th February 2014, 03:24
Cool, I'm looking forward to giving it a whirl.
Myrsloik
16th February 2014, 23:32
It's time for R23 RC1 (https://dl.dropboxusercontent.com/u/73468194/vapoursynth-r23-rc1.exe). Changes:
r23:
the frame range to output can now be set in vspipe as well using -start and -end
documentation fixes
minor build system improvement/fix (Zor)
removed debug printfs in windows x64 build, fixes piping to stdout
fixed tests
installer improvements
The included genericfilters also contains a fix for Canny. Test it, especially if your name is Mystery Keeper.
On a side note I secretly updated my vsrawsource builds to include Daemon404's large file support fix on windows. The links are in that other thread.
Mystery Keeper
17th February 2014, 02:55
Myrsloik, please specify the publisher in the installer. Good thing I remembered to run it as admin. Because last time I did not, and Windows 8 security warning (not UAC) hanged my PC big time.
Canny in 32bit works well where it crashed before. Thank you for your hard work.
Myrsloik
17th February 2014, 08:42
Myrsloik, please specify the publisher in the installer. Good thing I remembered to run it as admin. Because last time I did not, and Windows 8 security warning (not UAC) hanged my PC big time.
Canny in 32bit works well where it crashed before. Thank you for your hard work.
What do you mean by "specify the publisher"? That I didn't sign the installer binary?
Mystery Keeper
17th February 2014, 12:18
Yes. When I try to run it under Windows 8, its security kicks in (think it was Smart Screen) telling me "I shan't run it". If I just double click it, that message blocks everything, not reacting to mouse. Seems like a bug. I managed to get rid of it, but that's still annoying.
Myrsloik
17th February 2014, 14:23
Yes. When I try to run it under Windows 8, its security kicks in (think it was Smart Screen) telling me "I shan't run it". If I just double click it, that message blocks everything, not reacting to mouse. Seems like a bug. I managed to get rid of it, but that's still annoying.
You seem to be the only person with this issue. If it bothers you a lot we can try another session of remote computer control to try to figure it out.
I've just applied for a free open source project code signing certificate so hopefully I'll be able to use it to sign the final release.
Mystery Keeper
17th February 2014, 14:53
Hm. Tested it with explorer and SmartScreen didn't block. Don't bother. The bug seems to be in Unreal Commander.
kamineko
18th February 2014, 15:26
I'm also in the process of getting Vapoursynth working on my Mac for additional testing purposes. I've got the master branch working and compiling and all tests are passing 100%, so I'll switch over to making sure my CUDA branch works on Mac as well.
That sounds like it could save me a ton of work. Could you just outline in a few bullet points what needed to be done to compile Vapoursynth on Mac OSX?
Myrsloik
18th February 2014, 15:30
That sounds like it could save me a ton of work. Could you just outline in a few bullet points what needed to be done to compile Vapoursynth on Mac OSX?
It already works perfectly. See the compilation instructions included in the source.
lansing
19th February 2014, 04:38
Is there any native plugin for loading virtualdub filters?
Myrsloik
19th February 2014, 09:23
Is there any native plugin for loading virtualdub filters?
No. Which vdub filters do you want to use?
lansing
19th February 2014, 09:32
No. Which vdub filters do you want to use?
I use many, such as camcoder color denoise, neatvideo, acobw, color mill.
Myrsloik
19th February 2014, 23:38
I use many, such as camcoder color denoise, neatvideo, acobw, color mill.
Maybe I'll write a vdub plugin loader some day. Or sneakily hack out that one that's in avisynth. But first I'm going to do some other things...
Adub
20th February 2014, 05:20
It already works perfectly. See the compilation instructions included in the source.
Indeed, although you have to work a little bit harder to get a supported version of GCC for C++11 support working on Mac.
I recommend you install GCC using Homebrew, as it will handle the dependencies and guide you through the proper PATH updates, etc.
I haven't had a chance to dive into it again as work as been crazy but I plan on jumping on it again. Maybe I'll write up a blog post about my process...
kamineko
20th February 2014, 23:45
Indeed, although you have to work a little bit harder to get a supported version of GCC for C++11 support working on Mac.
I recommend you install GCC using Homebrew, as it will handle the dependencies and guide you through the proper PATH updates, etc.
I haven't had a chance to dive into it again as work as been crazy but I plan on jumping on it again. Maybe I'll write up a blog post about my process...
Yes, please do. I had Vapoursynth installed on Linux in less than 10 minutes, but I had almost all of the toolchain pre-installed. On Mac, I would start from zero. Your hints already indicate that there might be surprises on the way if you start from scratch.
EDIT: As an alternative, I would also be happy with a link to a pre-compiled one (OSX 10.9). I'd rather not have to start from scratch on the Mac just to compile this one app.
qyot27
21st February 2014, 00:28
If memory serves:
A) Install Xcode from the App Store and/or just the Command Line Tools package. Install Git (obviously). I can't remember if you need to install XQuartz for any of this stuff (possibly for mpv; you definitely need it if you plan to install Wine).
B) Install Homebrew
C) Install GCC 4.8, Automake, Libtool, Autoconf, Python 3, and the GNU binutils through Homebrew (am I missing anything?). Install Cython through pip3. Install libass (I guess the brew recipe is okay? I just compile it myself to be sure).
D) Install any of the FFmpeg-related library dependencies (optional). Homebrew can be used for the dependencies if you prefer, but for some you probably need to compile from source (x265, for instance).
E) Compile FFmpeg, only because I don't trust repositories to ever get the configuration right:
git clone git://source.ffmpeg.org/ffmpeg.git
cd ffmpeg
./configure --enable-gpl --enable-version3 --enable-avresample --enable-avisynth [insert other --enable- stuff for libraries here] --cc=gcc-4.8
make
sudo make install
F) Compile FFMS2:
git clone git://github.com/FFMS/ffms2.git
cd ffms2
./configure --enable-shared
make
sudo make install
G) Compile VapourSynth (you may also need to pass AR=gar RANLIB=granlib to ./waf configure; I'm not sure):
git clone git://github.com/vapoursynth/vapoursynth.git
cd vapoursynth
./bootstrap.py
CC=gcc-4.8 ./waf configure
./waf build
sudo ./waf install
sudo ./setup.py install
# Optionally, you'll probably want to symlink FFMS2's dylib into VapourSynth's autoload directory.
H) Install mpv through either Homebrew or by compiling it yourself (which you may need to do if you built FFmpeg rather than brewing it). It also uses Waf:
git clone git://github.com/mpv-player/mpv.git
cd mpv
./bootstrap.py
./waf configure --disable-debug-build --disable-vdpau
./waf build
sudo ./waf install
And I'm assuming Mavericks since, well, there's little reason not to. Even though when I reinstalled all this stuff fresh last weekend I did it on Lion and didn't upgrade to Mavericks until Monday or Tuesday. Since Mavericks' version of Xcode doesn't provide Apple-provided duplicates of some tools (autotools, notably), it should be easier to set up on Mavericks, rather than having to force symlinking into the Cellar like you have to do under Lion. I'm not sure if Mountain Lion still had them or not.
sl1pkn07
21st February 2014, 08:35
@Qyot27
why avisynth in ffmpeg? is need in linux/MacOS?
qyot27
21st February 2014, 18:21
@Qyot27
why avisynth in ffmpeg? is need in linux/MacOS?
There's no absolute need for it as far as VapourSynth's concerned, but it's
A) Completely free to enable, unlike the other external libraries.
B) Even though AvxSynth exists, the real usefulness of getting people into the habit of using --enable-avisynth will be for whenever cross-platform support is added to AviSynth+.
cretindesalpes
2nd March 2014, 01:29
HolyWu & Myrsloik:
Indeed. The removegrainvs.cpp modification below seems to fix it and gives much more accurate results. Add these lines:
add_x16_s32(sum_0, sum_1, a6, zero);
add_x16_s32(sum_0, sum_1, a7, zero);
add_x16_s32(sum_0, sum_1, a8, zero);
const __m128i fix_0 = _mm_srai_epi32 (sum_0, 15);
const __m128i fix_1 = _mm_srai_epi32 (sum_1, 15);
sum_0 = _mm_sub_epi32 (sum_0, fix_0);
sum_1 = _mm_sub_epi32 (sum_1, fix_1);
const __m128i mult =
_mm_load_si128(reinterpret_cast <const __m128i *> (_mult));
const __m128i val = mul_s32_s15_s16(sum_0, sum_1, mult);
And change this one:
ALIGNED_ARRAY(const int32_t OpRG20::_bias[4], 16) =
{ -0x8000 * 9 + 4, -0x8000 * 9 + 4, -0x8000 * 9 + 4, -0x8000 * 9 + 4 };
I fixed Dither_removegrain16 in Dither too.
Mystery Keeper
9th March 2014, 01:08
Still no motion compensation. Maybe someone who understands math better could try implementing this method (http://www.mia.uni-saarland.de/Publications/brox-eccv04-of.pdf)?
Myrsloik
9th March 2014, 12:57
Here's R23 RC2 (https://dl.dropboxusercontent.com/u/73468194/vapoursynth-r23-rc2.exe).
Should really be final this time.
All changes for R23:
fixed an issue with rearranging old order arguments for Lut2, Merge and MaskedMerge
fixed bugs in rgvs mode 20, eedi3 crash on windows and genericfilters crash in canny
the frame range to output can now be set in vspipe as well using -start and -end
documentation fixes
minor build system improvement/fix (Zor)
removed debug printfs in windows x64 build, fixes piping to stdout
fixed tests
installer improvements
Mystery Keeper
9th March 2014, 13:27
As always, thank you for your hard work.
Myrsloik
9th March 2014, 19:18
I tested rgvs mode 20 in new build and it seems that the bug still exists.
:thanks:
Try this x86 dll (https://dl.dropboxusercontent.com/u/73468194/RemoveGrainVS.dll). Used the wrong conversion because of a typo.
Myrsloik
12th March 2014, 18:18
I sneakily released r23. Only change from rc2 is the rgvs mode 20 fix (part 2). Full changelog and download link in the first post as usual.
sl1pkn07
12th March 2014, 23:53
thanks for the new version!
but always forget release the sources and update tags in github XD
greetings
Myrsloik
16th March 2014, 13:05
thanks for the new version!
but always forget release the sources and update tags in github XD
greetings
Internet connection broke 1 min before I could tag it and then I forgot. It's tagged now.
sl1pkn07
22nd March 2014, 14:26
Hi
my distro has update python 3(.3) to 3.4. now stop build (waf problem?)
http://sl1pkn07.no-ip.com/paste/view/6906276f
greetings
RTW47
22nd March 2014, 15:40
import vapoursynth as vs
core = vs.get_core()
video = core.avisource.AVISource(path=r'D:\ULRG.avi')
video.set_output()
Python exception: 'list' object has no attribute 'set_output'
Traceback (most recent call last):
File "vapoursynth.pyx", line 1148, in vapoursynth.vpy_evaluateScript
(src\cython\vapoursynth.c:18441)
File "D:\test.vpy", line 4, in <module>
video.set_output()
AttributeError: 'list' object has no attribute 'set_output'
#vapoursynth r23 on win32
#edit:. ~for me it looks like problem(s) only occur then loading Ut Video RGB (ULRG) or RGBA (ULRA)
Myrsloik
22nd March 2014, 17:26
import vapoursynth as vs
core = vs.get_core()
video = core.avisource.AVISource(path=r'D:\ULRG.avi')
video.set_output()
Python exception: 'list' object has no attribute 'set_output'
Traceback (most recent call last):
File "vapoursynth.pyx", line 1148, in vapoursynth.vpy_evaluateScript
(src\cython\vapoursynth.c:18441)
File "D:\test.vpy", line 4, in <module>
video.set_output()
AttributeError: 'list' object has no attribute 'set_output'
#vapoursynth r23 on win32
#edit:. ~for me it looks like problem(s) only occur then loading Ut Video RGB (ULRG) or RGBA (ULRA)
It's probably working. Since you have alpha (or avisource guessed alpha more likely in the first case) the return isn't a single clip. It's an array of two clips, one with rgb video and one gray clip containing the alpha channel.
You most likely intended to do: video[0].set_output()
RTW47
23rd March 2014, 00:19
@Myrsloik, thanks for the note.
got video preview in vdub working the following way:
...
video = core.resize.Bicubic(video[0], format=vs.COMPATBGR32)
video = core.std.FlipVertical(video) #converting with COMPATBGR32, still flips output upside down;
video.set_output()
Myrsloik
6th April 2014, 22:17
I guess it's time for a status update. I've been busy working on the mvtools replacement and that's why there haven't been any other visible activity. It's still far from even being a proof of concept so don't expect it to be done soon.
Unfortunately I'm probably going to be too busy to make any real progress until July.
pokazene_maslo
14th April 2014, 11:16
Myrsloik: good luck with those mvtools, i'm looking forward to them
LoRd_MuldeR
6th May 2014, 00:27
Is there are particular reason why VapourSynth explicitly requires Python 3.3 and won't work with Python 3.4?
I'm asking, because I had installed the latest official Python 3.x, which current is Python 3.4.0. But the VapourSynth installer refused to install, until I installed Python 3.3 as well.
sl1pkn07
6th May 2014, 02:40
use waf 1.7.15 instead of waf download by bootstrap
Myrsloik
6th May 2014, 04:01
Is there are particular reason why VapourSynth explicitly requires Python 3.3 and won't work with Python 3.4?
I'm asking, because I had installed the latest official Python 3.x, which current is Python 3.4.0. But the VapourSynth installer refused to install, until I installed Python 3.3 as well.
Because 3.3 was the most recent branch when I made the last release on Windows. To compile it for more than one python version at a time is simply too much work. I already need to prepare both 32 and 64 bit binaries.
So which python version do you want to see the next release work with? 3.3 like now or 3.4 since it's the latest?
LoRd_MuldeR
6th May 2014, 10:50
Because 3.3 was the most recent branch when I made the last release on Windows. To compile it for more than one python version at a time is simply too much work. I already need to prepare both 32 and 64 bit binaries.
So Python sub-versions like v3.3 and v3.4 are not binary compatible and it's really not possible to make a VapourSynth binary that works with both? Or is that more an installer issue?
(I would have expected that Python v2.x and v3.x are not compatible, but v3.x sub-versions should be - at least if they follow the rules of semantic versioning (http://semver.org/)!)
So which python version do you want to see the next release work with? 3.3 like now or 3.4 since it's the latest?
Unless there are any known regressions, I would probably go with the latest release?
Myrsloik
6th May 2014, 11:26
So Python sub-versions like v3.3 and v3.4 are not binary compatible and it's really not possible to make a VapourSynth binary that works with both? Or is that more an installer issue?
It's a python issue, I think. Or at least a windows python/cython one. All modules compiles with cython link against a specific python version. There are actually sometimes quite big api changes between python releases even if the numbers don't hint at it.
I'll make one more maintenance release using python 3.3 and then I'm going to switch.
itzkin
6th May 2014, 15:38
Hello
First I want to say that Vapoursynth is great. While I've only just started, I think it has huge potential.
I have 2 questions:
1) My clips get no audio?
In Avisynth there is FFVideoSource(clip) and FFAudioSource(clip). In Vapoursynth I know only of core.ffms2.Source(). Maybe there is another function I don't know about and can't find in the documentation?
Speaking of which are there any other sources of information except this thread and vapoursynth.com?
2) While I managed to get it working, I am still not sure what happens when I use the VSFS? Reading about Avisynth it was relatively easy for me to grasp the idea that the script is faking as a video file for the next piece of software, but now I am getting confused. How viable is VSFS in a web environment?
Linked python API library is controlled by pragma in pyconfig.h in case of MSVC.
By adding Py_LIMITED_API definition, generic python3.lib will be picked (this can be done by adding define_macros to setup.py).
HOWEVER, this doesn't work anyway. Generated C source (by Cython) seems to have references to _typeobject related things that is not visible when Py_LIMITED_API is defined.
Reel.Deel
6th May 2014, 15:45
I have 2 questions:
1) My clips get no audio?
In Avisynth there is FFVideoSource(clip) and FFAudioSource(clip). In Vapoursynth I know only of core.ffms2.Source(). Maybe there is another function I don't know about and can't find in the documentation?...
VapourSynth only supports video.
itzkin
6th May 2014, 20:42
VapourSynth only supports video.
Might be a good idea to have that mentioned in the first post or anywhere on its website.
foxyshadis
11th May 2014, 02:46
2) While I managed to get it working, I am still not sure what happens when I use the VSFS? Reading about Avisynth it was relatively easy for me to grasp the idea that the script is faking as a video file for the next piece of software, but now I am getting confused. How viable is VSFS in a web environment?
VSFS allows applications that don't understand VS to see a plain avi file instead, that is a real uncompressed avi to the app. VSFS (via Pismo, which makes writing filesystem filters much easier) intercepts all of the read calls and inserts its own fake data to create a simulacrum of an avi. AVFS works the same way.
foxyshadis
12th May 2014, 09:32
OK, getting VS to build and run was one of the least fun experiences in a while, thanks in no small part to python, but now that I have it up and running I can start submitting a few patches. First, boosting the avisynth compatibility library to read all cpu levels avisynth supports, via VS's already-existing detection. (Allows JpegSource to run, perhaps others.)
Myrsloik
12th May 2014, 11:40
OK, getting VS to build and run was one of the least fun experiences in a while, thanks in no small part to python, but now that I have it up and running I can start submitting a few patches. First, boosting the avisynth compatibility library to read all cpu levels avisynth supports, via VS's already-existing detection. (Allows JpegSource to run, perhaps others.)
Is there any way I could convince you to make it pull requests on github? I can easily merge and comment patches even while I'm out travelling that way. If you don't this won't be applied for many weeks.
The patch itself is ok if you remove the
+ if (cpuf.fma3) ; // no equivalent
+ if (cpuf.avx2) ; // no equivalent
lines since they're dead code that will generate warnings.
If you tried to build it on linux recently there probably are some problems since lachs0r recently replaced most of the build system. Just create bugs for any odd stuff you find and he'll try to fix it.
jackoneill
12th May 2014, 11:53
OK, getting VS to build and run was one of the least fun experiences in a while, thanks in no small part to python, but now that I have it up and running I can start submitting a few patches. First, boosting the avisynth compatibility library to read all cpu levels avisynth supports, via VS's already-existing detection. (Allows JpegSource to run, perhaps others.)
Some of your lines are indented with tabs.
foxyshadis
13th May 2014, 10:30
Never used pull requests, hope this is how you do it.
Some of your lines are indented with tabs.
Oops, I thought I caught all of those. Thanks.
The build problems were dependency building problems (getting ffmpeg and python to build), which never fully worked even with a cross-compile, in the end I just picked up pre-built dev builds. Eventually I'll get them going. The rest was figuring out more about how pyd extensions work, I did learn a lot.
The core Vapoursynth.dll project in MSVC links to the libraries libswscale.a and libavutil.a, but using those, I consistently got dll import problems. I had to change them to swscale.lib and avutil.lib from zeranoe's builds to get them to link right, otherwise it was looking for sws imports in libavutil.dll (maybe a static build would avoid this problem? I used dynamic libraries). When I hunted for answers on stackoverflow, it seems to be a problem with library file formats. Maybe 2013 Update 2 will fix that.
YamashitaRen
15th July 2014, 18:30
Hello.
I'm trying to compile vapoursynth on ARM but waf absolutely wants to use -msse2 ...
How can I disable this switch ?
Here is the config.log : http://pastebin.com/f83FKA9g
Thanks :)
edit : wrong config.log, now it's corrected
Myrsloik
27th July 2014, 00:38
VapourSynth R24 test 2 (https://www.dropbox.com/s/3zis87bhaxbj53l/vapoursynth_r24_test2.exe)
Will be released as is unless someone finds issues or suggests simple awesome features.
Needs Python 3.4
Things that could use extra testing: vivtc and vspipe
Changes:
r24:
vsvfw now properly returns an error message when no output has been set instead of silently failing
fixed a reference leak in vsscript
vspipe has a new argument for passing on values to the script environment from the command line
vspipe now has improved command line parsing and short forms, however old command lines will have to be modified to work
re-added clip.output()
fixed a filter error propagation issue
mixed improvements to vivtc (nodame)
fixed mac compilation of genericfilters
added FreezeFrames, DuplicateFrames and DeleteFrames, they can all delete/duplicate/freeze multiple frames with one command (nodame)
mixed documentation improvements (nodame)
fixed tracking of memory usage that was broken in r22 (nodame)
vivtc now uses framedifference internally and runs completely in parallel, also minor metric reporting fixes (nodame)
I'M BACK!
THIS PROJECT ISN'T EVEN HALF AS DEAD AS CERTAIN OTHER PROJECTS!
LoRd_MuldeR
27th July 2014, 13:04
Thanks for the update.
However I noticed that with the new VSPIPE version querying the VapourSynth version doesn't work, which breaks the VapourSynth detection code in my GUI program:
C:\Program Files (x86)\VapourSynth\core32>vspipe.exe -v
No script file specified
C:\Program Files (x86)\VapourSynth\core32>vspipe.exe -version
No output file specified
C:\Program Files (x86)\VapourSynth\core32>vspipe.exe --version
No script file specifiedVapourSynth detection is running, please stand by...
VSPIPE.EXE failed with code 0x00000001 -> disable Vapousynth support!
VapourSynth thread finished.
VapourSynth thread failed to detect installation!
Also, maybe more a cosmetic problem, but anyway: Is it supposed to show those $s's there?
VSPipe usage:
$s [options] <script> <outfile>
Examples:
Show script info:
$s --info script.vpy -
BTW: Changing the CLI syntax in a non-backward-compatible way is generally bad for GUI front-end's, since we either need to support old and new variants (which is pain) or we support only a specific VapourSynth version (then user is doomed if program A wants VapourSynth r23 and program B wants VapourSynth r24).
Myrsloik
27th July 2014, 14:15
VapourSynth R24 test 3 (https://www.dropbox.com/s/ltool5u7cok51c4/vapoursynth_r24_test3.exe)
Fixes the vspipe issues.
...
BTW: Changing the CLI syntax in a non-backward-compatible way is generally bad for GUI front-end's, since we either need to support old and new variants (which is pain) or we support only a specific VapourSynth version (then user is doomed if program A wants VapourSynth r23 and program B wants VapourSynth r24).
I know changing things is bad, that's why I keep a list of major things I'm going to break all at once at an unspecified later time for the core API. The rest of the project is kinda in an evolutionary state though.
However having saner argument parsing is just too attractive to not do it and adding additional options would've been difficult without re-writing it all anyway. Now it follows standard command line conventions and makes more sense. The user base is also still small and fast enough to adapt to the changes. You're the only one making a GUI front end that I know of. Feel free to drop support for older versions of VS if it's too much work. I really try to make each release better than the last, or at least release a fix quickly if a major issue is found.
Anyway, no more major vspipe changes. Now it's done.
LoRd_MuldeR
27th July 2014, 14:40
VapourSynth R24 test 3 (https://www.dropbox.com/s/ltool5u7cok51c4/vapoursynth_r24_test3.exe)
Fixes the vspipe issues.
Confirmed :)
c:\Program Files (x86)\VapourSynth\core32>vspipe.exe --version
VapourSynth Video Processing Library
Copyright (c) 2012-2014 Fredrik Mellbin
Core r24
API r3
Anyway, no more major vspipe changes. Now it's done.
From your lips to God's ears ;)
zerowalker
27th July 2014, 20:58
How is Vapoursynth looking?
It's been awhile since it came, so i wonder, is the improvements as expected and all that?
I know it's still far from done, so not expecting it to be comparable, but i just mean in the sense that it's using a more modern approach and how that compares.
Mystery Keeper
28th July 2014, 00:34
VapourSynth is rather great. Especially compared to the current state of AviSynth. But it lacks some essential plugins. NNEDI3 is only supporting 8bit colordepth so far. No motion compensation. No DFTTest.
zerowalker
28th July 2014, 02:09
How's the speed compared to Avisynth, in stuff that's working as expected?
Myrsloik
6th August 2014, 22:12
I'm back AGAIN!
Here's R24 RC1 (https://www.dropbox.com/s/juqrl9fqobxfzcu/vapoursynth_r24_rc1.exe) with a pile of important additional fixes.
Test everything a bit so it doesn't crashe too often. I had to change a lot of python code to fix some of the bugs.
All changes in R24 so far:
r24:
fixed reference leak in FrameEval
more functions in the vsscript api now return success or failure
improved handling of the vsfunc type in python, it should now have all the functionality originally intended
removed r21 argument compatibility since all scripts should have been changed by now
include file paths in the windows sdk have been changed to better match linux and osx
the core will no longer be completely freed until all filter instances belonging to it have been released, this prevents crashes in some circumstances
vsvfw now properly returns an error message when no output has been set instead of silently failing
fixed a reference leak in vsscript
vspipe has a new argument for passing on values to the script environment from the command line
vspipe now has improved command line parsing and short forms, however old command lines will have to be modified to work
re-added clip.output()
fixed a filter error propagation issue
mixed improvements to vivtc (nodame)
fixed mac compilation of genericfilters
added FreezeFrames, DuplicateFrames and DeleteFrames, they can all delete/duplicate/freeze multiple frames with one command (nodame)
mixed documentation improvements (nodame)
fixed tracking of memory usage that was broken in r22 (nodame)
vivtc now uses framedifference internally and runs completely in parallel, also minor metric reporting fixes (nodame)
Myrsloik
6th August 2014, 22:13
How's the speed compared to Avisynth, in stuff that's working as expected?
About the same speed for single threaded. Good scaling with the number of cores on medium-complex scripts when multithreaded. Not much more to say about it.
anonymlol
9th August 2014, 10:01
I'm back AGAIN!
Here's R24 RC1 (https://www.dropbox.com/s/juqrl9fqobxfzcu/vapoursynth_r24_rc1.exe) with a pile of important additional fixes.
Chrome is blocking it: http://puu.sh/aL12Q/c8c109f5b2.png
Myrsloik
9th August 2014, 12:09
Chrome is blocking it: http://puu.sh/aL12Q/c8c109f5b2.png
It's chrome acting like shit antivirus software. Use IE or something else to download where you can ignore the warnings.
Installers are regularly blacklisted/blocked by incompetence.
alexxdls
10th August 2014, 04:49
Can I maintain aspect ratio while resizing?
v = core.resize.Lanczos(clip=v, width=1920, height=new_height)new_height = original_height / original_width x 1920How can I get original_height and original_width with VapourSynth? Please give a detailed example.
jackoneill
10th August 2014, 06:53
Can I maintain aspect ratio while resizing?
v = core.resize.Lanczos(clip=v, width=1920, height=new_height)new_height = original_height / original_width x 1920How can I get original_height and original_width with VapourSynth? Please give a detailed example.
http://www.vapoursynth.com/doc/pythonreference.html
new_height = int(v.height / v.width * 1920 + 0.5)
This rounds up to the next integer, which may not be what you need (if you have subsampling).
alexxdls
10th August 2014, 10:20
Is it correct calculation (rounding to the neares even value)?new_height = v.height / v.width * new_width - 0.5
new_height = lambda new_height : round( new_height / 2.) * 2
v = core.resize.Lanczos(clip=v, width=new_width , height=new_height)
alexxdls
12th August 2014, 16:59
import vapoursynth as vs
core = vs.get_core()
import os
core.std.LoadPlugin(path=r"d:\TOOLS\MyDCPConverter\Tools\imwri-64.dll")
core.std.LoadPlugin(path=r"d:\TOOLS\MyDCPConverter\Tools\fmtconv.dll")
ext = 'L.png'
dir = r"F:\TEMP\TRAIN-DRAGON-2_TLR-G-3D_RU-XX_RU-00_51_2K_TCF_20140417_DWA_IOP-3D\REEL1/"
srcs = [dir + src for src in os.listdir(dir) if src.endswith(ext)]
vl1 = core.imwri.Read(srcs)
vl1 = core.fmtc.matrix(vl1, mat="709", col_fam=vs.YUV, csp=vs.YUV444P16, bits=16, fulls=1, fulld=1)
vl = vl1
dir = r"F:\TEMP\TRAIN-DRAGON-2_TLR-G-3D_RU-XX_RU-00_51_2K_TCF_20140417_DWA_IOP-3D\REEL2/"
srcs = [dir + src for src in os.listdir(dir) if src.endswith(ext)]
vl2 = core.imwri.Read(srcs)
vl2 = core.fmtc.matrix(vl2, mat="709", col_fam=vs.YUV, csp=vs.YUV444P16, bits=16, fulls=1, fulld=1)
vl = vl + vl2
vl = core.std.CropRel(vl, left=15, right=15, top=0, bottom=0)
new_height = round(vl.height / vl.width * 1920 / 2) * 2
vl = core.resize.Lanczos(vl, width=1920, height=new_height)
border_height = round((1080 - vl.height) / 2)
vl = core.std.AddBorders(vl, top=border_height, bottom=border_height)
ext = 'R.png'
dir = r"F:\TEMP\TRAIN-DRAGON-2_TLR-G-3D_RU-XX_RU-00_51_2K_TCF_20140417_DWA_IOP-3D\REEL1/"
srcs = [dir + src for src in os.listdir(dir) if src.endswith(ext)]
vr1 = core.imwri.Read(srcs)
vr1 = core.fmtc.matrix(vr1, mat="709", col_fam=vs.YUV, csp=vs.YUV444P16, bits=16, fulls=1, fulld=1)
vr = vr1
dir = r"F:\TEMP\TRAIN-DRAGON-2_TLR-G-3D_RU-XX_RU-00_51_2K_TCF_20140417_DWA_IOP-3D\REEL2/"
srcs = [dir + src for src in os.listdir(dir) if src.endswith(ext)]
vr2 = core.imwri.Read(srcs)
vr2 = core.fmtc.matrix(vr2, mat="709", col_fam=vs.YUV, csp=vs.YUV444P16, bits=16, fulls=1, fulld=1)
vr = vr + vr2
vr = core.std.CropRel(vr, left=15, right=15, top=0, bottom=0)
vr = core.resize.Lanczos(vr, width=1920, height=new_height)
border_height = round((1080 - vr.height) / 2)
vr = core.std.AddBorders(vr, top=border_height, bottom=border_height)
v = core.std.StackHorizontal([vl,vr])
v = core.std.AssumeFPS(v, fpsnum=24)
v = core.fmtc.resample(v, css="420")
v = core.fmtc.bitdepth(v, bits=8, dmode=3)
v.set_output()
I get an errorunable to destroy mutex: Resource devicetrying to encode this script. The same thing in FRIMEncode and x264 (with vspipe). Checking the script with VapourSynthEditor-64bit goees wellScript was successfully evaluated. Output video info:
Frames: 72 | Time: 0:00:03.000 | Size: 3840x1080 | FPS: 24/1 = 24 | Format: YUV420P8But previewing fails and VapourSynthEditor-64bit crushes.
Mystery Keeper
12th August 2014, 17:09
Evaluates, but crashes on processing? The error is in GetFrame().
alexxdls
13th August 2014, 03:10
Replacing
v = core.std.StackHorizontal([vl,vr])with
v = vl + vrorv = core.std.StackHorizontal([vr,vr])orv = core.std.StackHorizontal([vl,vl])gives positive result and VapourSynthEditor-64bit doesn't crash anymore.
Even the simplest script with one frame in vl and vr crushes the same wayimport vapoursynth as vs
core = vs.get_core()
import os
core.std.LoadPlugin(path=r"d:\TOOLS\MyDCPConverter\Tools\imwri-64.dll")
core.std.LoadPlugin(path=r"d:\TOOLS\MyDCPConverter\Tools\fmtconv.dll")
vl = core.imwri.Read(r"F:\TEMP\TRAIN-DRAGON-2_TLR-G-3D_RU-XX_RU-00_51_2K_TCF_20140417_DWA_IOP-3D\REEL2\000034L.png")
vr = core.imwri.Read(r"F:\TEMP\TRAIN-DRAGON-2_TLR-G-3D_RU-XX_RU-00_51_2K_TCF_20140417_DWA_IOP-3D\REEL2\000034R.png")
v = core.std.StackHorizontal([vl,vr])
v.set_output()Script was successfully evaluated. Output video info:
Frames: 1 | Time: 0:00:00.033 | Size: 4096x858 | FPS: 30/1 = 30 | Format: RGB48
What is wrong with std.StackHorizontal???
Myrsloik
13th August 2014, 09:02
What is wrong with std.StackHorizontal???
I will take a look at it. I just happen to have plenty of other things as well to test. And a job. Posting in more threads about it won't make me happier or make me work faster.
nu774
13th August 2014, 10:07
Build of vapoursynth.pyd fails here (on windows) due to failure of "cimport windows". I needed to create the following file named "windows.pxd" placed under Cython directory.
cdef extern from "windows.h" nogil:
bint WriteFile(void *hFile, void *lpBuffer, int nNumberOfBytesToWrite, int *lpNumberOfBytesWritten, void *lpOverlapped) nogil
Myrsloik
13th August 2014, 10:09
Build of vapoursynth.pyd fails here (on windows) due to failure of "cimport windows". I needed to create the following file named "windows.pxd" placed under Cython directory.
cdef extern from "windows.h" nogil:
bint WriteFile(void *hFile, void *lpBuffer, int nNumberOfBytesToWrite, int *lpNumberOfBytesWritten, void *lpOverlapped) nogil
I forgot to add it. It's committed now.
alexxdls
13th August 2014, 14:57
Posting in more threads about it won't make me happier or make me work faster.I sumply thought it is VS and Python issue and posted here. But then did some optimizations with my script to have just basic funtions to use Stack. And tests pointed me out that it could be the plugin issue.
Myrsloik
13th August 2014, 21:02
Here's R24 RC2 (http://www.vapoursynth.com/downloads/vapoursynth-r24-rc2.exe).
This really should be final now. I guess. I'll give it 24 hours of testing and then I'll release it. Unfortunately for me people keep finding real crash bugs...
Going to focus on the imagemagick stuff after this is done.
Top 3 items are new in RC2.
r24:
fixed rare crashes in 64 bit windows asm in a few filters
core.max_cache_size should now be used instead of core.set_max_cache_size()
num_threads, add_cache and accept_lowercase can now be set at any time in python and not only during the first call to get_core()
fixed reference leak in FrameEval
more functions in the vsscript api now return success or failure
improved handling of the vsfunc type in python, it should now have all the functionality originally intended
removed r21 argument compatibility since all scripts should have been changed by now
include file paths in the windows sdk have been changed to better match linux and osx
the core will no longer be completely freed until all filter instances belonging to it have been released, this prevents crashes in some circumstances
vsvfw now properly returns an error message when no output has been set instead of silently failing
fixed a reference leak in vsscript
vspipe has a new argument for passing on values to the script environment from the command line
vspipe now has improved command line parsing and short forms, however old command lines will have to be modified to work
re-added clip.output()
fixed a filter error propagation issue
mixed improvements to vivtc (nodame)
fixed mac compilation of genericfilters
added FreezeFrames, DuplicateFrames and DeleteFrames, they can all delete/duplicate/freeze multiple frames with one command (nodame)
mixed documentation improvements (nodame)
fixed tracking of memory usage that was broken in r22 (nodame)
vivtc now uses framedifference internally and runs completely in parallel, also minor metric reporting fixes (nodame)
Myrsloik
14th August 2014, 21:51
Final version of R24 posted. It's identical to RC2.
The theme for this release is making things more sane in general and fixing bugs. The usual release post (http://www.vapoursynth.com/2014/08/r24-making-vsscript-sane/) also exists with a small summary.
Mystery Keeper
21st August 2014, 23:46
Time to give VapourSynth its own forum section?
foxyshadis
22nd August 2014, 03:19
I brought it up a while back, and Doom9 said maybe when it gets bigger. Changing the forum names to Avisynth & Vapoursynth is a possibility, though.
vcmohan
13th September 2014, 14:46
I am a newbie and trying to port my avisynth plugins. I require a particular frame from a clip in the INIT function. I tried several ways but nothing seems to be correctly coded. Can you please guide me as to how the statement should read? I am using
const VSFrameRef *matchf = VSGetFrame getFrame(d->mf, d->node[1], NULL, NULL);
jackoneill
13th September 2014, 15:57
I am a newbie and trying to port my avisynth plugins. I require a particular frame from a clip in the INIT function. I tried several ways but nothing seems to be correctly coded. Can you please guide me as to how the statement should read? I am using
const VSFrameRef *matchf = VSGetFrame getFrame(d->mf, d->node[1], NULL, NULL);
Based on a real working plugin that does this:
#include <stdint.h>
#include <string>
#include <VapourSynth.h>
#include <VSHelper.h>
typedef struct {
VSNodeRef *node;
const VSVideoInfo *vi;
} TestData;
static void VS_CC testInit(VSMap *in, VSMap *out, void **instanceData, VSNode *node, VSCore *core, const VSAPI *vsapi) {
TestData *d = (TestData *) * instanceData;
vsapi->setVideoInfo(d->vi, 1, node);
}
static const VSFrameRef *VS_CC testGetFrame(int n, int activationReason, void **instanceData, void **frameData, VSFrameContext *frameCtx, VSCore *core, const VSAPI *vsapi) {
TestData *d = (TestData *) * instanceData;
if (activationReason == arInitial) {
vsapi->requestFrameFilter(n, d->node, frameCtx);
} else if (activationReason == arAllFramesReady) {
const VSFrameRef *src = vsapi->getFrameFilter(n, d->node, frameCtx);
VSFrameRef *dst = vsapi->copyFrame(src, core);
vsapi->freeFrame(src);
return dst;
}
return 0;
}
static void VS_CC testFree(void *instanceData, VSCore *core, const VSAPI *vsapi) {
TestData *d = (TestData *)instanceData;
vsapi->freeNode(d->node);
free(d);
}
static void VS_CC testCreate(const VSMap *in, VSMap *out, void *userData, VSCore *core, const VSAPI *vsapi) {
TestData d;
TestData *data;
d.node = vsapi->propGetNode(in, "clip", 0, 0);
d.vi = vsapi->getVideoInfo(d.node);
char errorMsg[1024];
const VSFrameRef *evil = vsapi->getFrame(0, d.node, errorMsg, 1024);
if (!evil) {
vsapi->setError(out, std::string("Test: failed to retrieve first frame from input clip. Error message: ").append(errorMsg).c_str());
vsapi->freeNode(d.node);
return;
}
// Do things with the frame.
vsapi->freeFrame(evil);
data = (TestData *)malloc(sizeof(d));
*data = d;
vsapi->createFilter(in, out, "Test", testInit, testGetFrame, testFree, fmParallel, 0, data, core);
}
VS_EXTERNAL_API(void) VapourSynthPluginInit(VSConfigPlugin configFunc, VSRegisterFunction registerFunc, VSPlugin *plugin) {
configFunc("com.nodame.test", "test", "Test plugin for VapourSynth", VAPOURSYNTH_API_VERSION, 1, plugin);
registerFunc("Test",
"clip:clip;"
, testCreate, 0, plugin);
}
vcmohan
14th September 2014, 04:16
Documentation regarding vapoursynth API states that the getFrame can be used in the Init section of a plugin to get a particular frame. It returns immediately that frame. The code for Init part given
static void VS_CC testInit(VSMap *in, VSMap *out, void **instanceData, VSNode *node, VSCore *core, const VSAPI *vsapi) {
TestData *d = (TestData *) * instanceData;
vsapi->setVideoInfo(d->vi, 1, node);
}
has no call for the frame.
I am refering to the following write up.
VSGetFrame getFrame
typedef const VSFrameRef *(VS_CC *VSGetFrame)(int n, VSNodeRef *node, char *errorMsg, int bufSize)
Generates a frame directly. The frame is available when the function returns.
This function is meant for external applications using the core as a library, or if frame requests are necessary during a filter’s initialization.
n
The frame number. Negative values will cause an error.
node
The node from which the frame is requested.
bufSize
Maximum length for the error message, in bytes (including the trailing ‘0’). Can be 0 if no error message is wanted.
errorMsg
Pointer to a buffer of bufSize bytes to store a possible error message. Can be NULL if no error message is wanted.
Returns a reference to the generated frame, or NULL in case of failure. The ownership of the frame is transferred to the caller.
Warning
Never use inside a filter’s “getframe” function.
jackoneill
14th September 2014, 04:38
Documentation regarding vapoursynth API states that the getFrame can be used in the Init section of a plugin to get a particular frame. It returns immediately that frame. The code for Init part given
static void VS_CC testInit(VSMap *in, VSMap *out, void **instanceData, VSNode *node, VSCore *core, const VSAPI *vsapi) {
TestData *d = (TestData *) * instanceData;
vsapi->setVideoInfo(d->vi, 1, node);
}
has no call for the frame.
Yeah, the initialisation of VapourSynth filters is split into two functions (testCreate and testInit in this case). I forget why exactly. I think you can do this in either one, but in testCreate it definitely works.
The documentation will get another review soon™.
vcmohan
16th September 2014, 03:33
I could make it compile properly now. I need to test it. My OS is windows 8.1 64 bit. The VC++ 2010 does not say whether it is 64 or 32 bit. r24 dll when I downloaded it says 32 bit. Hope they will all work together.
foxyshadis
18th September 2014, 01:46
VS will let you switch between Win32 and x64 (and IA64 or ARM) at the top, next to the Debug/Release. Normally it defaults to Win32, and in the Configuration Manager you can enable others by adding a <New...> config. 32-bit plugins only work on 32-bit VS, and vice versa for 64-bit. Everything will work on 64-bit Windows.
vcmohan
18th September 2014, 06:05
Does this mean that every plugin be made available in both 32 and 64 bit versions?pre compiled binary for windows r24 dll did not give an option of 64 bit
foxyshadis
18th September 2014, 23:16
The installer now gives you both 32 and 64 bit versions, with separate plugin folders for each. Which one gets used depends on either what the opening application is (for AvsP and VapourSynth Editor), or what version of Python is called if it's piped.
Mystery Keeper
19th September 2014, 01:46
Also note that to use both 32 and 64 bit versions of VapourSynth you need to also have installed both versions of Python.
vcmohan
20th September 2014, 12:36
So looks safe to compile in 32 bit format.
I have 2 doubts.
1. arFrameReady and arAllFramesReady. I thought that if only a single frame is requested in the initial, then arFrameReady need be used. But the invert example eventhough requested a single frame it uses arAllFramesReady. So when arFrameReady to be used?
2. In the create section I have an optional 2nd clip parameter. If not specified I use d.node[1] = d.node[0]. When freeing due either error or end of frame processing should both node[0] and node[1] are to be freed or only one? I assumed both need to be freed.
Myrsloik
20th September 2014, 12:56
So looks safe to compile in 32 bit format.
I have 2 doubts.
1. arFrameReady and arAllFramesReady. I thought that if only a single frame is requested in the initial, then arFrameReady need be used. But the invert example eventhough requested a single frame it uses arAllFramesReady. So when arFrameReady to be used?
2. In the create section I have an optional 2nd clip parameter. If not specified I use d.node[1] = d.node[0]. When freeing due either error or end of frame processing should both node[0] and node[1] are to be freed or only one? I assumed both need to be freed.
1. arAllFramesReady is when all frames that have been requested are ready. It's what all almost filters should wait for.
arFrameReady happens whenever a frame is ready (no particular order) and is mostly meant to be used by filters with a huge number of input frames.
An example:
Your filter calls requestFrameFilter() 3 times and then returns.
Then your filter will get called with arFrameReady, arFrameReady, arAllFramesReady. Waiting for arAllFramesReady means that all frames you wanted can be used.
2. There is no automatic reference counting since the API is pure C. You need to clone the reference when assigning it. If you don't do this you will free the same memory twice and crash. I assume your cleanup code looks something like:
vsapi->freeNode(d.node[0])
vsapi->freeNode(d.node[1])
This is probably what you want:
d.node[1] = vsapi->cloneNodeRef(d.node[0])
vcmohan
20th September 2014, 13:19
Thanks. I have created a folder vsfiles and placed my script file with extension.py. I tried to open it with virtualdub, but vdub says unknown format. What file extension I need to use?
Is there a video player that takes in floating point formats? Do I need to convert by resize to input to a player?
Myrsloik
20th September 2014, 15:20
Thanks. I have created a folder vsfiles and placed my script file with extension.py. I tried to open it with virtualdub, but vdub says unknown format. What file extension I need to use?
Is there a video player that takes in floating point formats? Do I need to convert by resize to input to a player?
The extension has to be .vpy for it to be opened. And no, no players support floating point formats. If you use madvr as the renderer most players support 16 bit formats but if you want to preview in vdub you have to convert it to 8bit.
vcmohan
21st September 2014, 07:21
Thanks. I am having some problems with script
ret = core.std.BlankClip(width=720,height=480,format=vs.RGB24,color=255,255,255)
using the 32 bit editor gives a syntax error stating that 'non keyword arg after keyword arg with an arrow pointing under format.
when I use BlankClip() with all default arguments it proceeds to next step.
There I have a call to my plugin Grid
core.std.LoadPlugin(path=r'c:\transplugins\bin_vapoursynth\Grid\release\Grid.dll')
this was accepted. but the call
ret = core.std.Grid(ret, color = 0x7fff)
produced an error stating no function named Grid.
In the plugin code I have the following statements at the appropriate places
vsapi->createFilter(in, out, "Grid", gridInit, gridGetFrame, gridFree, fmParallel, 0, data, core);
}
VS_EXTERNAL_API(void) VapourSynthPluginInit(VSConfigPlugin configFunc, VSRegisterFunction registerFunc, VSPlugin *plugin)
{
configFunc("in.vcmohan.grid", "grid", "VapourSynth grid plugin", VAPOURSYNTH_API_VERSION, 1, plugin);
registerFunc("Grid", "clip:clip;lineint:int:opt;bold:int:opt;vbold:int:opt;color:int:opt;bcolor:int:opt;vbcolor:int:opt;grid:int:opt;axis:int:opt;", invertCreate, 0, plugin);
}
Incidentally the example Invert in SDK gives name as "Filter" and not "invert" which I think is not correct.
Request guidance in scripting
vcmohan
21st September 2014, 11:55
Thanks. I tried color = 255,255,255 without the side brackets and it has accepted. One more question. In case of an array. I have integer array with flags opt:empty. In case there is no entry of this parameter then I presume I get err in the propGetInt call. What is then an empty signify? If one enters color=[], is this called an empty array and I get not an err but numElements = 0. Is my understanding correct?
Myrsloik
21st September 2014, 20:44
Empty controls the argument checks that happen before the arguments are passed to your filter. Without empty specified all array arguments must have at least one element (or in combination with opt it can also be undefined).
I think your understanding is correct. [] is an empty array.
vcmohan
22nd September 2014, 05:36
thanks.
in the invert example d.vi is at two places
in the Create it is
d.node = vsapi->propGetNode(in, "clip", 0, 0);
d.vi = vsapi->getVideoInfo(d.node);
and in the Init part it is
vsapi->setVideoInfo(d->vi, 1, node);
Is the SetVideoInfo required if one is not changing any part of vi
as in the invert example case?
jackoneill
22nd September 2014, 08:32
thanks.
in the invert example d.vi is at two places
in the Create it is
d.node = vsapi->propGetNode(in, "clip", 0, 0);
d.vi = vsapi->getVideoInfo(d.node);
and in the Init part it is
vsapi->setVideoInfo(d->vi, 1, node);
Is the SetVideoInfo required if one is not changing any part of vi
as in the invert example case?
It is required even if you don't change the video info. You get a fatal error if you don't do it.
vcmohan
24th September 2014, 03:56
in plugin coding, the configure has a id, namespace etc; I find that the namespace need to be unique. I tried with different urls as id, but same namespace. It refused to load stating that particular namespace is already populated. Then how can one be sure that the namespace is not already used by some other plugin? What exactly the reverse url id does then?
Myrsloik
24th September 2014, 22:40
in plugin coding, the configure has a id, namespace etc; I find that the namespace need to be unique. I tried with different urls as id, but same namespace. It refused to load stating that particular namespace is already populated. Then how can one be sure that the namespace is not already used by some other plugin? What exactly the reverse url id does then?
Every loaded plugin has to be in its own namespace. This is to make sure there are no overlapping names of functions. It is possible to specify a plugin to have another namespace when loading it with LoadPlugin.
This is the reason a plugin has both a namespace and an id, the id is the only thing that can never change.
There's no easy way to make sure your plugin will never have the same namespace as someone else's. Just look at the already existing plugins to see what they used. I probably should make a list of the already taken ones for easy reference.
lansing
25th September 2014, 22:24
I'm trying to load a 64bit avs plugin with core.avs.LoadPlugin(r"xyz.dll"), but it's giving me error "No attribute with the name avs exists". Loading a 32bit avs plugin works fine.
TheFluff
25th September 2014, 22:38
I'm trying to load a 64bit avs plugin with core.avs.LoadPlugin(r"xyz.dll"), but it's giving me error "No attribute with the name avs exists". Loading a 32bit avs plugin works fine.
IIRC the avs compatibility layer doesn't work for 64-bit Avisynth. I think it had something to do with the plane offsets still being 32-bit in Avisynth or something, making frame memory layout incompatible between VS and AVS.
edit: yep, see http://www.vapoursynth.com/2013/12/r22-the-number-of-bits-shall-be-64/
lansing
26th September 2014, 15:31
I see, I'll stay away from it then
vcmohan
30th September 2014, 03:56
I find that resize does not accept floating point samples. How can one test software for these formats?
feisty2
30th September 2014, 06:33
fmtconv
Mystery Keeper
30th September 2014, 09:57
I find that resize does not accept floating point samples. How can one test software for these formats?In one of my letters to you I have written exactly how to do that.
vcmohan
1st October 2014, 03:55
Thanks. Sorry I forgot about it @mysteryKeeper.
I want to know whether there is any player that accepts all these formats? On XP vdub was playing RGB, but on my win8.1, it does not and complains that the vfw has no decompressor for it.Tried to install ffdshow (sorry name may not be correct) but it did not allow me unless I allow a task bar, change default search engine etc; So got vexed and did not install it.
vcmohan
1st October 2014, 04:02
There's no easy way to make sure your plugin will never have the same namespace as someone else's. Just look at the already existing plugins to see what they used. I probably should make a list of the already taken ones for easy reference.
I find there are many threads for plugins and becomes difficult to select a unique namespace. Can a special (sticky preferably) thread be started wherin plugin developers are forced to list the namespace? Possibly it may be too much work if a master list is maintained by the vapoursynth team.
Mystery Keeper
1st October 2014, 08:54
Thanks. Sorry I forgot about it @mysteryKeeper.
I want to know whether there is any player that accepts all these formats? On XP vdub was playing RGB, but on my win8.1, it does not and complains that the vfw has no decompressor for it.Tried to install ffdshow (sorry name may not be correct) but it did not allow me unless I allow a task bar, change default search engine etc; So got vexed and did not install it.I'll try to make my editor preview all VapourSynth supported formats sometime soon.
foxyshadis
1st October 2014, 09:27
Thanks. Sorry I forgot about it @mysteryKeeper.
I want to know whether there is any player that accepts all these formats? On XP vdub was playing RGB, but on my win8.1, it does not and complains that the vfw has no decompressor for it.Tried to install ffdshow (sorry name may not be correct) but it did not allow me unless I allow a task bar, change default search engine etc; So got vexed and did not install it.
The links from the home page (http://ffdshow-tryout.sourceforge.net/download.php) do NOT contain any adware, Sourceforge-provided or otherwise. I don't know where you got the others, but you might want to scan your system in case anything did get installed despite cancelling.
vcmohan
2nd October 2014, 03:57
I clicked on the home page and I was taken to that page. So I did not download it. I will try again.
vcmohan
3rd October 2014, 03:22
I have output a avi file from virtualdub. When I read it directly by vdub or through avisynth with avisource it renders correctly. But with vapoursynth avisource.AVISource it appears upside down. Is there a problem?
RTW47
3rd October 2014, 12:44
I remember there was a problem in the past, then converting from/to COMPATBGR32. But if (after some colorspace conversions or for other reasons) output is flipped upside down you can always include core.std.FlipVertical afterwards.
vcmohan
4th October 2014, 03:27
I know that one can get around by doing turnleft twice, but first of all rendering must be correct. When I use pixel position coordinates in several processings like rotate, correct for barrel and pincushion aberrations, quadrilateral perspective etc, I need to know how the frame is rendered. Topside down or normal. But avisource.AVISource rendering appears to be incorrect.
vcmohan
20th October 2014, 04:07
How do I access from core numThreads? core->numThreads is a compiler error.
Myrsloik
20th October 2014, 08:52
How do I access from core numThreads? core->numThreads is a compiler error.
You probably shouldn't use the number of threads explicitly in a filter. Exactly why do you need to know the number of threads?
YamashitaRen
20th October 2014, 08:56
Hello,
Removegrain can't be compiled on my ARM board (cause of SSE2 things if I understood clearly). Is it a known issue or should I write something on github ?
Myrsloik
20th October 2014, 09:23
Hello,
Removegrain can't be compiled on my ARM board (cause of SSE2 things if I understood clearly). Is it a known issue or should I write something on github ?
Post the compilation errors in a bug report. It should compile everywhere.
vcmohan
21st October 2014, 03:22
You probably shouldn't use the number of threads explicitly in a filter. Exactly why do you need to know the number of threads?
I use libFFTW3f-3.dll in my fftquiver plugin. It is thread safe but needs to be initialized with calls fftw_init_threads and then fftw_with_nthreads(nthreads). So I would like to get this info from vapoursynth and use it here.
Selur
21st October 2014, 10:35
@Mystery Keeper: Reading that you are using a portable Winpython, did you manage to get Vapoursynth portable? (I like the idea of having vapoursynth on an usb stick) If you did manage to create a portable Vapoursynth package, could you share it or write a small guide on how to set it up?
Mystery Keeper
21st October 2014, 17:04
@Selur: I've never tried. VapourSynth uses Windows registry to get both its own and Python paths. "Portable" Python modifies these entries to be accessible from any folder. But that's likely something you wouldn't like to do from USB stick on different PCs. In short: while VapourSynth uses Python, there's no convenient way to make it portable. Maybe there's some way to emulate registry, but I don't know about it.
By the way, VapourSynth as it is does not depends on Python. Python is used for filters graph construction. Other language can be created for that with its own interpreter. But that's a lot of work. I personally haven't got knowledge for such task.
Myrsloik
21st October 2014, 17:39
@Mystery Keeper: Reading that you are using a portable Winpython, did you manage to get Vapoursynth portable? (I like the idea of having vapoursynth on an usb stick) If you did manage to create a portable Vapoursynth package, could you share it or write a small guide on how to set it up?
Patches or suggestions on what to change to make it portable are welcome. Personally I never need to drag applications around that way so I just don't keep it in mind.
Myrsloik
21st October 2014, 17:40
I use libFFTW3f-3.dll in my fftquiver plugin. It is thread safe but needs to be initialized with calls fftw_init_threads and then fftw_with_nthreads(nthreads). So I would like to get this info from vapoursynth and use it here.
HolyWu probably has the right answer for you then. It should be a reasonable default value at least.
Mystery Keeper
21st October 2014, 17:58
Patches or suggestions on what to change to make it portable are welcome. Personally I never need to drag applications around that way so I just don't keep it in mind.
Application launcher with code injector for registry access functions is the only way I can think of.
Limit64
23rd October 2014, 19:33
Python's default search path for modules contains the cwd. If you put all needed libraries into the cwd it should work. Alternatively you can just put the sys and os module into the cwd and use them to modify Python's search path in your script.
import sys
import os
sys.path.append(os.getcwd() + "/my_python_libraries")
# Your normal script
Mystery Keeper
24th October 2014, 15:15
@Limit64, problem is: both VapourSynth and Python are used as libraries. CWD is CWD of different programs that load them.
Selur
24th October 2014, 15:24
may be the path could be taken from an .ini file,...
Mystery Keeper
24th October 2014, 16:43
may be the path could be taken from an .ini file,...
And where could .ini file be taken from? Again, CWD can differ.
nu774
24th October 2014, 16:49
I think the following procedure should work (Registry is not required).
1) Open command prompt and set up PYTHONHOME and PATH environment variable by SET command. Both of location of python DLLs and Vapoursynth DLLs have to be included in the PATH environment variable so that they could be loaded.
2) After that, launch any program that uses Vapoursynth from the command prompt.
Path rule for Python on MS Windows is written in:
https://github.com/python/cpython/blob/master/PC/getpathp.c.
chainik_svp
24th October 2014, 22:26
Just curious - is there any chance VapourSynth will be available from ffdshow as a post processing filter or may be directly built into some video player (like AVS processing now built in Daum PotPlayer)
???
foxyshadis
25th October 2014, 00:13
Not without a patch. clsid is the only current maintainer of ffdshow, and he only makes trivial changes or commits patches.
Mystery Keeper
25th October 2014, 00:44
Just curious - is there any chance VapourSynth will be available from ffdshow as a post processing filter or may be directly built into some video player (like AVS processing now built in Daum PotPlayer)
???Probably can easily be built in. But the program will have to care about loading plugins and building the graph.
Myrsloik
2nd November 2014, 21:50
Just curious - is there any chance VapourSynth will be available from ffdshow as a post processing filter or may be directly built into some video player (like AVS processing now built in Daum PotPlayer)
???
It should be fairly easy to integrate into ffdshow or any other player in the same way as avisynth itnegration works. If I didn't hate the ffdshow codebase so much in general because it's a huge mess maybe I'd try to add it myself...
JEEB
3rd November 2014, 17:40
The mplayer{,2} fork mpv (http://mpv.io/) has already integrated VapourSynth for filtering purposes, so it is very much possible.
Myrsloik
3rd November 2014, 17:44
The mplayer{,2} fork mpv (http://mpv.io/) has already integrated VapourSynth for filtering purposes, so it is very much possible.
It also found a few bugs in the VS code by doing so. The next release will be the first one working well I think (or if you use git).
chainik_svp
3rd November 2014, 23:00
It should be fairly easy to integrate into ffdshow or any other player in the same way as avisynth itnegration works. If I didn't hate the ffdshow codebase so much in general because it's a huge mess maybe I'd try to add it myself...
I really think you should make this move. ffdshow integration is a good point to start to spread VS over the world :) the only thing is ffdshow is almost dead too, as the Avisynth is...
May be you could find a way to work together with nevcairiel as he was mentioned about possibility of integration VS into LAV?
The mplayer fork mpv (http://mpv.io/) has already integrated VapourSynth for filtering purposes, so it is very much possible.
thanks, will try it!
YamashitaRen
4th November 2014, 03:00
It also found a few bugs in the VS code by doing so. The next release will be the first one working well I think (or if you use git).
Ah ! So I assume that you're expecting VS to ~always compile ?
Didn't dare to bring the issue before R25 release ^^'
I have currently trouble building the cython wrapper. Bug report tomorrow ;)
Myrsloik
4th November 2014, 08:10
Ah ! So I assume that you're expecting VS to ~always compile ?
Didn't dare to bring the issue before R25 release ^^'
I have currently trouble building the cython wrapper. Bug report tomorrow ;)
Yes, it should compile most of the time. AND NEVER SAVE ISSUES UNTIL AFTER RELEASE.
Myrsloik
4th November 2014, 20:00
Does anyone actually use avisource? I'm beginning to think it's already kinda obsolete as a filter.
Mystery Keeper
4th November 2014, 21:14
I do use avisource.
Reel.Deel
5th November 2014, 03:41
Does anyone actually use avisource? I'm beginning to think it's already kinda obsolete as a filter.
I still use AviSource. Lately I've started using the MagicYUV (http://magicyuv.com/) codec and since there's currently no decoder for FFmpeg /Libav I'm force to use AviSource. (I don't keep up with FFmpeg/Libav development so I'm assuming this is still true)
Myrsloik
5th November 2014, 23:24
Here's R25 test 1 (https://www.dropbox.com/s/1jknougdnaf88ut/vapoursynth-r25-test1.exe?dl=0). Test it and all that. It should be realease quality.
The most interesting additions are the verticalcleaner filter and dot syntax like avisynth:
core.Source('Rule 6 violation.mkv').FlipVertical().FlipHorizontal()[:100].set_output()
A few important points (get it?):
Namespaces may still be used in combination with dots if so desired
If there are multiple functions with the same name in different namespaces an exception will be thrown. Prefix the function with its namespace to disambiguate.
Lowercase only function names won't work without being prefixed by a namespace even if accept_lowercase it set.
The full list of changes:
r25:
DuplicateFrames and DeleteFrames no longer needs to have the frame number argument sorted
fixed handling of indeterminate length clips in DuplicateFrames and DeleteFrames
added experimental . syntax, for example core.BlankClip().VFM(order=1) will now work, if multiple functions have the same name they still need to be prefixed with the namespace
now uses the proper python exception for missing attributes
added getPluginPath function to the api so it's possible for plugins to load resources in relative paths in a reliable way, the returned paths are always absolute and use forward slashes
registerFormat now returns null instead of terminating the program on invalid formats, this is so plugin developers won't have to duplicate logic and instead can simply try if a format is valid
frame data is now exposed in a more python friendly way, use the get_read_frame and get_write_frame methods to get fast and efficient arrays
enabled x86 mmx state checks on all platforms
fixed a filter error propagation issue that could lead to crashes
fixed a race condition that could lead to too many threads being spawned to do nothing
added verticalcleaner and missing repair modes to rgvs (HolyWu)
fixed negative single frame indexing of clips in python
vspipe now reports the correct number of frames as output when a non-zero start frame is specified
fixed ctrl-c handling in clip.output() and some other small adjustments
clip.output() now accepts normal python file-like objects
automatically generated names for runtime registered yuv formats now make sense
TurboPascal7
7th November 2014, 12:50
It was correctly pointer out on IRC that optional namespaces feature is fundamentally broken - the same script can silently get completely different behavior when executed with different set of loaded plugins (another system/same system some time later/just a different script).
So, even though the feature is nice and definitely removes some useless verbosity from the script, it's too late to introduce it now and it should probably be removed or at least strongly discouraged/enabled explicitly.
Myrsloik
7th November 2014, 12:59
It was correctly pointer out on IRC that optional namespaces feature is fundamentally broken - the same script can silently get completely different behavior when executed with different set of loaded plugins (another system/same system some time later/just a different script).
So, even though the feature is nice and definitely removes some useless verbosity from the script, it's too late to introduce it now and it should probably be removed or at least strongly discouraged/enabled explicitly.
Yes, I'll probably remove the no namespace thing completely in the release. It causes more problems than it solves.
Just like accept_lowercase is a bad idea too I want to kill off some day...
TurboPascal7
7th November 2014, 13:04
Just like accept_lowercase is a bad idea too I want to kill off some day...
I couldn't agree more. It might also cause problems if someone writes a script with lowercase names, tests it on his PC and it works, then distributes it to someone else and the script fails because the core was created with accept_lowercase=False.
So yeah, it should be removed and the function lookup should always be case-insensitive/accept lowercase names. :)
vcmohan
13th November 2014, 12:10
I have 3 problems|
1. I have a parameter plane:int[];opt; I check with numElements. If zero I have default values, otherwise check the numElements to be 3, if not error message. In script if I omit plane, I am always getting an error. How do I get over this problem?
2. In imwri if my image name starts with t, then It appears to interpret as a tab, and does not find the file. I am on windows
3. I have one reverse url. I use this for different plugins. loading more than one plugin gets an error. Do I need to conjure a different URL for each separate plugin?
Myrsloik
13th November 2014, 13:29
I have 3 problems|
1. I have a parameter plane:int[];opt; I check with numElements. If zero I have default values, otherwise check the numElements to be 3, if not error message. In script if I omit plane, I am always getting an error. How do I get over this problem?
2. In imwri if my image name starts with t, then It appears to interpret as a tab, and does not find the file. I am on windows
3. I have one reverse url. I use this for different plugins. loading more than one plugin gets an error. Do I need to conjure a different URL for each separate plugin?
1. Look closely, you have a ; instead of :
2. Will try it later
3. It has to be unique for every plugin, you can't load several plugins with the same id
TheFluff
13th November 2014, 17:11
2. In imwri if my image name starts with t, then It appears to interpret as a tab, and does not find the file. I am on windows
\t expands to a tab in a regular Python string, could it be that? Possible solutions: prefix the string with r (so r"folder\t.jpg"; this tells python to not expand backslash stuff like \t and \n), use a / instead, or escape the backslash (so \\t).
vcmohan
18th November 2014, 03:53
1. Look closely, you have a ; instead of :
2. Will try it later
In my code it is : not :. While typing in this message I did wrong. So the issue remains.
i[Quote}3. It has to be unique for every plugin, you can't load several plugins with the same id issue still remains. {\Quote]
That means both reverse url and namespace need to be unique.
Myrsloik
20th November 2014, 13:43
In my code it is : not :. While typing in this message I did wrong. So the issue remains.
i[Quote}3. It has to be unique for every plugin, you can't load several plugins with the same id issue still remains. {\Quote]
That means both reverse url and namespace need to be unique.
Then I don't know why it happens. It would help to see both the source code (or at least the full string declaring arguments) and the test script you use. There's nothing obviously wrong.
vcmohan
22nd November 2014, 08:35
The string is
registerFunc("Median", "clip:clip;maxgrid:int:opt;plane:int[]:opt;", adaptivemedianCreate, 0, plugin);
The code to test is
[code]
int temp = 0;
temp = vsapi->propNumElements(in, "plane");
if( temp == 0)
{
d.yy = 1, d.uu = 0, d.vv = 0;
}
else if(temp < 3)
{
vsapi->setError(out, "Median: values of each of 3 planes as one or zero must be specified");
vsapi->freeNode(d.node);
return;
}
elsetemp = 0;
temp = vsapi->propNumElements(in, "plane");
if( temp == 0)
{
d.yy = 1, d.uu = 0, d.vv = 0;
}
else if(temp < 3)
{
vsapi->setError(out, "Median: values of each of 3 planes as one or zero must be specified");
vsapi->freeNode(d.node);
return;
}
else
vcmohan
22nd November 2014, 08:42
Then I don't know why it happens. It would help to see both the source code (or at least the full string declaring arguments) and the test script you use. There's nothing obviously wrong.
The string is
registerFunc("Median", "clip:clip;maxgrid:int:opt;plane:int[]:opt;", adaptivemedianCreate, 0, plugin);
The code to test is
int temp = 0;
temp = vsapi->propNumElements(in, "plane");
if( temp == 0)
{
d.yy = 1, d.uu = 0, d.vv = 0;
}
else if(temp < 3)
{
vsapi->setError(out, "Median: values of each of 3 planes as one or zero must be specified");
vsapi->freeNode(d.node);
return;
}
else ................
I do not get zero as numElements if this optional parameter is not specified.
Myrsloik
22nd November 2014, 11:48
If an argument isn't spwcified at all then numElements is -1.
You should check if (temp <= 0) as the first condition.
Mystery Keeper
23rd November 2014, 17:49
This thread should be made sticky.
LoRd_MuldeR
23rd November 2014, 19:16
This thread should be made sticky.
Accomplished.
Myrsloik
24th November 2014, 00:20
Windows XP support will be dropped in the next version. Supporting Vista+ is enough for me and I don't want to have different plugin loading behavior in different versions.
You have 24 hours to object.
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
Myrsloik
16th January 2015, 00:30
I made a typo when I changed the installer so it skipped some files. Fixed installer here (https://www.dropbox.com/s/2wc2w8891p17qre/vapoursynth-r26-rc1.exe?dl=1).
buchanan
16th January 2015, 00:36
Thank you !
Myrsloik
21st January 2015, 22:02
Here's R26 RC3 (https://www.dropbox.com/s/tzexvry78vw34nm/vapoursynth-r26-rc3.exe?dl=1). It has several fixes in avisource to make it less crashy and more likely to work or return an error message.
Myrsloik
27th January 2015, 01:04
R26 RC4 (https://www.dropbox.com/s/zl11h8kadtwlc0a/vapoursynth-r26-RC4.exe?dl=1)
Finally finished all my own testing and fixed some more reported issues. Will be released if no serious regressions are found in 48h.
Myrsloik
28th January 2015, 00:23
R26 is released (https://github.com/vapoursynth/vapoursynth/releases/tag/R26). Download it from the usual place. Blog post with minor points here (http://www.vapoursynth.com/2015/01/r26-speed/).
Speed comparisons between R25 and R26 are also very welcome... and a good marketing tool for me in my quest to make Avisynth irrelevant.
smok3
28th January 2015, 00:28
Myrsloik: I will try to run it on wheezy (with python 3.4 compiled/installed into /opt/something), any pointers to correct install procedure?
Myrsloik
28th January 2015, 00:32
Myrsloik: I will try to run it on wheezy (with python 3.4 compiled/installed into /opt/something), any pointers to correct install procedure?
I even have documentation (http://www.vapoursynth.com/doc/installation.html#linux-and-os-x-installation-instructions)!
smok3
28th January 2015, 00:34
I even have documentation (http://www.vapoursynth.com/doc/installation.html#linux-and-os-x-installation-instructions)!
:) I read that allready.
edit:
a. Cant see any bootstrap.py, so those instructions are probably for something else?
b. the usual autogen, ./configure --disable-osd, make, ends with:
/usr/bin/ld: /usr/local/lib/libswscale.a(swscale.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/usr/local/lib/libswscale.a: could not read symbols: Bad value
collect2: error: ld returned 1 exit status
make: *** [libvapoursynth.la] Error 1
YamashitaRen
29th January 2015, 02:54
That's quite clear, you have to recompile ffmpeg with -fPIC iirc.
Are you using the Debian avconv ?
On Jessie armhf, with Marillat ffmpeg, I have not this error...
@Myrsloik
Are you interested in a simple QTGMC comparison on arm ?
It might be a good reason for me to encode interlaced content :p
Myrsloik
29th January 2015, 02:58
@Myrsloik
Are you interested in a simple QTGMC comparison on arm ?
It might be a good reason for me to encode interlaced content :p
The speed increase is windows only so that's not necessary. But I am curious about how slow it will run on arm...
zerowalker
29th January 2015, 09:46
Fast question, does things like SMDegrain work? (know MVTools isn't fully supported etc).
And what can be expected in performance gain if/when it's supported (without any hacks of course) compared to Avisynth.
jackoneill
29th January 2015, 12:50
Fast question, does things like SMDegrain work? (know MVTools isn't fully supported etc).
And what can be expected in performance gain if/when it's supported (without any hacks of course) compared to Avisynth.
Not fully supported? What do you mean?
There are some speed comparisons here (http://forum.doom9.org/showthread.php?p=1694674#post1694674) and in a few subsequent posts.
YamashitaRen
29th January 2015, 20:23
The speed increase is windows only so that's not necessary. But I am curious about how slow it will run on arm...
Unfortunately I just discovered that scenechange needs SSE2 so your curiosity will not be satisfied today...
edit : And if I apparently found how to build scenechange without SSE2, I have now discovered that QTGMC relies even more on fmtconv than what I expected...
So no benchs for the time being ~~
zerowalker
2nd February 2015, 19:00
Not fully supported? What do you mean?
There are some speed comparisons here (http://forum.doom9.org/showthread.php?p=1694674#post1694674) and in a few subsequent posts.
Yeah it's slower, isn't that cause it's a port and not "native" or something?
Are_
2nd February 2015, 19:35
Slower? It is faster than vanilla (don't know about the rest). Keep scrolling down to see the other tests. And you didn't respond about what features it is lacking.
Also, it is a port and native.
zerowalker
2nd February 2015, 19:41
As far as i see it's sometimes faster and other times slower?
No one said anything that features was lacking, but i assumed that cause i am pretty sured it was (or is), that's why i said "fully support" before:)
Nice that it's native, i thought it was like a bad hacking implementation to get it working (and that's after i read about it -_-).
Are_
2nd February 2015, 19:48
I feel really lazy about login into windows to redo these tests, but I'm almost sure right now it is always faster than avisynth flavors.
Also it supports multithreading, in avisynth you are limited to one thread, and don't make laugh mentioning avisynth_mt, that is almost as funny as 64bit avisynth.
zerowalker
2nd February 2015, 21:44
Are_ by no means am i telling you to.
Wait, you sure?
When i am using SMDegrain (which should use MVTools?) it uses much more than 25% (quad core) even though i don't use any MT thing.
Perhaps i am missing something, it could be using other stuff as well.
Don't worry i am not a fan of MT hacks, it's too risky to be used for the things i do (i need to be sure the file it intact and correct).
Myrsloik
2nd February 2015, 22:05
As far as i see it's sometimes faster and other times slower?
No one said anything that features was lacking, but i assumed that cause i am pretty sured it was (or is), that's why i said "fully support" before:)
Nice that it's native, i thought it was like a bad hacking implementation to get it working (and that's after i read about it -_-).
Note that all pre R26 benchmarks are obsolete now as well. Especially on windows. A new set of comparisons is definitely needed.
zerowalker
2nd February 2015, 22:41
Ah, has things improved or is it both ways?
jackoneill
2nd February 2015, 22:47
Are_ by no means am i telling you to.
Wait, you sure?
When i am using SMDegrain (which should use MVTools?) it uses much more than 25% (quad core) even though i don't use any MT thing.
Perhaps i am missing something, it could be using other stuff as well.
Don't worry i am not a fan of MT hacks, it's too risky to be used for the things i do (i need to be sure the file it intact and correct).
If it's Firesledge's version, that has some internal multithreading. You can tell by the version number (it's 2.6.x.x) or by the presence of the "lsb_out" parameter in Degrain. The original MVTools, with no internal multithreading, only goes up to version 2.5.11.3 and has no "lsb_out" parameter.
zerowalker
2nd February 2015, 22:57
Pretty sure it's that version, not the 2.5 version.
May be wrong, but as it's not single threaded that's must be it.
zerowalker
4th February 2015, 06:36
Okay trying to get things going on Vapoursynth, was able to replicate the "Degrain" test from MVTools and indeed Vapoursynth was better (though it was single threaded on Avisynth, compared to the script i normally use).
The script i use is.
fft3dgpu(sigma=1.3, plane=3)
smdegrain(tr=2,lsb=true,thsad=500,lsb_out=true,search=3)
Dither_convey_yuv4xxp16_on_yvxx()
I don't find anything about fft3dgpu except that it seems to be the limit, which makes me conclude it hasn't been ported?
And also how is 16bit, think i read that 16bit output isn't supported or something like that, perhaps confusing it with something else.
(Does it exist anything like avspmod for Vapoursynth, that has Auto completion and stuff, found VapourSynth Editor. Also read that Avspmod had some temp support but can't really get it to work).
Kupildivan
13th February 2015, 07:47
Is there any really working plugin which allows to import 16-bit PNG sequence?
When I'm trying to use ImageMagick writer/reader it says:
Script evaluation failed:
Python exception: Read: Failed to read image properties: vspipe.exe: RegistryKeyLookupFailed `CoderModulesPath' @ error/mode.c/GetMagickModulePath/662
Traceback (most recent call last):
File "vapoursynth.pyx", line 1488, in vapoursynth.vpy_evaluateScript (src\cython\vapoursynth.c:25136)
File "G:\Sintel\VS48.vpy", line 9, in <module>
v = core.imwri.Read(r'G:\Sintel\00002564.png',24000,1001)
File "vapoursynth.pyx", line 1387, in vapoursynth.Function.__call__ (src\cython\vapoursynth.c:23631)
vapoursynth.Error: Read: Failed to read image properties: vspipe.exe: RegistryKeyLookupFailed `CoderModulesPath' @ error/mole.c/GetMagickModulePath/662
Also VS doesn't want to import with vsimagereader-0.2.1:
"No frame returned at the end of processing by Read"
and vspipe crushes.
Tried both 32 and 64 versions of both plugins and nothing.
Myrsloik
13th February 2015, 12:51
Is this really with imwri test6?
Kupildivan
13th February 2015, 15:34
Thanks for help! I had imwri test4, but with test6 now it's ok.
RTW47
17th February 2015, 17:50
1. was expecting to receive error then concatenating two or more different fps clips. I'm right that vs will take fps value from the first clip and then automatically apply AssumeFPS/(speed adjustment) on the rest of the segments? If so, there should be no difference between adding AssumeFPS manually and letting vs do this internally?
2. noticed also there is an optional parameter for vapoursynth resizers,- yuvrange, but not mentioned in the documentation for some reason(s)
Myrsloik
17th February 2015, 18:06
1. was expecting to receive error then concatenating two or more different fps clips. I'm right that vs will take fps value from the first clip and then automatically apply AssumeFPS/(speed adjustment) on the rest of the segments? If so, there should be no difference between adding AssumeFPS manually and letting vs do this internally?
2. noticed also there is an optional parameter for vapoursynth resizers,- yuvrange, but not mentioned in the documentation for some reason(s)
1. The check has now been fixed in both splice and interleave
2. It's because swscale rarely cares about it.
I plan to rip out swscale and use zimg instead in the next release if I have enough time to work on it.
lo1t3yu
19th February 2015, 16:11
Hello. How use qtgmc in vapoursynth for doubled frame rate deinterlacing?
MonoS
19th February 2015, 17:40
Hello. How use qtgmc in vapoursynth for doubled frame rate deinterlacing?
In the same way you used it in avs, be sure to have all the necessary plugins :D
Kupildivan
20th February 2015, 19:18
Are they have to be the ported ones? Or native avisynth plugins will work too?
Are_
20th February 2015, 19:28
Vapoursynth's QTGMC works with vapoursynth filters only, except for the denoising. It uses avisynth's fft3dGPU and FFT3DFilter if they are selected, else it uses native dfttest.
MonoS
20th February 2015, 20:15
As Are_ said all plugin are native, for avoiding to use avs plugin remember to set denoising to at least Slow or set manually the denoiser to dfttest [also you can use 16bit precision if you want :D]
lo1t3yu
20th February 2015, 22:25
In the same way you used it in avs, be sure to have all the necessary plugins :D
It's clear, but interestingly how ffms2 decoding interlaced sources now. Is correctly (for smoothed 2x fps with phases saving)? I don't know about 2.20, may be interlaced sources now is fully supported... Else have need to use directshowsource2 that impossible in vapoursynth.
Thanks to all vapoursynth's (and plugins) devs for the crossplatform and modern frameserver!
MonoS
21st February 2015, 16:44
It's clear, but interestingly how ffms2 decoding interlaced sources now. Is correctly (for smoothed 2x fps with phases saving)? I don't know about 2.20, may be interlaced sources now is fully supported... Else have need to use directshowsource2 that impossible in vapoursynth.
Thanks to all vapoursynth's (and plugins) devs for the crossplatform and modern frameserver!
Have you tried with lsmash??
YamashitaRen
21st February 2015, 16:45
Have you tried with lsmash??
I confirm that lsmash works fine. ffms2 with "threads=1" should works too.
https://github.com/vapoursynth/vapoursynth/issues/139
lo1t3yu
23rd February 2015, 15:27
Have you tried with lsmash??
No, i will try later.
ffms2 works even without param 'threads=1'.
Also, vs works and all needed plugins loaded.
libaddgrain.so libdeblock.so libffms2.so libgenericfilters.so libmvtools.so libscenechange.so libtemporalsoften2.so libyadifmod.so
libdctfilter.so libeedi2.so libfmtconv.so liblsmash.so libnnedi3.so libtdeintmod.so libtemporalsoften.so
import vapoursynth as vs
import havsfunc as haf
core = vs.get_core()
v = core.ffms2.Source(source='2_1080i.mkv', fpsnum=25, fpsden=1)
v = haf.QTGMC(v, Preset='Slow', TFF=True)
v = core.fmtc.resample(v, w=1280, h=720, kernel="spline64")
v.set_output()
vspipe --y4m script.vpy - | x264 - --demuxer y4m --crf 20 --profile high --level 4.1 --preset slow --output encode.mkv
Script don't show errors, but x264 breaks:
x264 [error]: could not open input file `-'
Streaming into pipe also don't works.
If script runned without qtgmc then x264 encodes stream.
import vapoursynth as vs
import havsfunc as haf
core = vs.get_core()
v = core.ffms2.Source(source='2_1080i.mkv', fpsnum=25, fpsden=1)
v = core.nnedi3.nnedi3(v, field=3)
v = core.fmtc.resample(v, w=1280, h=720, kernel="spline64")
v.set_output()
vspipe --y4m script.vpy - | x264 - --demuxer y4m --crf 20 --profile high --level 4.1 --preset slow --output encode.mkv
It works.
x264 compiled with options: --enable-static, --enable-shared
jackoneill
23rd February 2015, 15:45
vspipe should output some error message, but if you don't see one, run this instead, to make sure x264's output isn't overwriting it:
vspipe script.py /dev/null --progress
lo1t3yu
23rd February 2015, 16:00
vspipe should output some error message, but if you don't see one, run this instead, to make sure x264's output isn't overwriting it:
vspipe script.py /dev/null --progress
This breaks segfault.
Are_
23rd February 2015, 16:20
Maybe are you using an outdated version of some filter? This does not crash for me.
lo1t3yu
23rd February 2015, 16:43
Maybe are you using an outdated version of some filter? This does not crash for me.
All libs have been compiled from sources (from here or git). May be required libs were missed? What plugins and which versions are you using?
jackoneill
23rd February 2015, 16:59
A missing plugin would result in a different error message (usually).
Did you compile GenericFilters from here? https://github.com/chikuzen/GenericFilters
The original author disappeared and left behind a number of bugs which have been fixed here: https://github.com/myrsloik/GenericFilters.
lo1t3yu
23rd February 2015, 19:18
A missing plugin would result in a different error message (usually).
Did you compile GenericFilters from here? https://github.com/chikuzen/GenericFilters
The original author disappeared and left behind a number of bugs which have been fixed here: https://github.com/myrsloik/GenericFilters.
Thanks! Myrsloik's version of GenericFilters works fine.
lo1t3yu
27th February 2015, 09:16
Will VS be supporting audio proccessing? (it's may be helpful for ts hdtv videos with errors).
MonoS
27th February 2015, 11:08
Will VS be supporting audio proccessing? (it's may be helpful for ts hdtv videos with errors).
Jackoneill alredy wrote something http://forum.doom9.org/showthread.php?t=171555
mawen1250
2nd March 2015, 16:20
I encountered a problem with plugin loading on my friend's computer.
Windows7 SP1 64bit
Python 3.4.3 32bit&64bit
VapourSynth R26 32bit&64bit
With print(core.list_functions()) in Python command line(both 32bit and 64bit were tested), only the core functions were displayed. None of the plugins in VapousSynth\coreXX\plugins and VapousSynth\pluginsXX were auto loaded.
Trying loading those plugins manually, it didn't work either. Running the script with vsedit64 or vspipe64, it always returns the error 'Failed to load XXX.dll'.
I've confirmed that all the required MSVC runtime dlls were installed.
The error message is something like this one:
http://i683.photobucket.com/albums/vv197/mawen1250/QQ20150302231015_zpszgijldfd.jpg
kolak
3rd March 2015, 21:07
I have the same issue.
Myrsloik is aware.
I see that we use same/latest Python- can this be the reason?
RTW47
3rd March 2015, 23:50
updated Python 3.4.1 > 3.4.2 > 3.4.3, but don;t seem to have any problems with it (so far);
Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 24 2015, 22:44:40) [MSC v.1600 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import vapoursynth as vs
>>> c=vs.get_core()
>>> c.std.LoadPlugin(path=r'F:\L-SMASH-Works_r728-g34b1526\VapourSynth\x64\vslsmashsource.dll')
>>> c.lsmas.list_functions()
'LWLibavSource(source:data; stream_index:int:opt; cache:int:opt; threads:int:opt; seek_mode:int:opt; seek_threshold:int:opt; variab
le:int:opt; format:data:opt; dr:int:opt; repeat:int:opt; dominance:int:opt)\nLibavSMASHSource(source:data; track:int:opt; threads:i
nt:opt; seek_mode:int:opt; seek_threshold:int:opt; variable:int:opt; format:data:opt; dr:int:opt)\n'
>>>
Myrsloik
6th March 2015, 08:50
I encountered a problem with plugin loading on my friend's computer.
Windows7 SP1 64bit
Python 3.4.3 32bit&64bit
VapourSynth R26 32bit&64bit
With print(core.list_functions()) in Python command line(both 32bit and 64bit were tested), only the core functions were displayed. None of the plugins in VapousSynth\coreXX\plugins and VapousSynth\pluginsXX were auto loaded.
Trying loading those plugins manually, it didn't work either. Running the script with vsedit64 or vspipe64, it always returns the error 'Failed to load XXX.dll'.
I've confirmed that all the required MSVC runtime dlls were installed.
...
I'll try to make the error message when loading plugins more informative. Unfortunately the windows api will never reveal to you the name of a missing file (if any).
Pat357
7th March 2015, 14:52
I'll try to make the error message when loading plugins more informative. Unfortunately the windows api will never reveal to you the name of a missing file (if any).
For Avisynth an excellent tool for this purpose (and a lot more) was created by Groucho2004 : it's called AVS Infotool (see http://forum.doom9.org/showthread.php?t=170647 )
The "plugin" function from this tool shows all the auto-loaded plugins with their dependencies : see images.
Maybe something similar can be created for VS ?
You could also use "Dependency Walker" to check the dependences from this .DLL plugin.
Kupildivan
9th March 2015, 21:41
OK. Where to download all compiled plugins for QTGMC?
jackoneill
9th March 2015, 23:38
OK. Where to download all compiled plugins for QTGMC?
https://github.com/HomeOfVapourSynthEvolution/VapourSynth-DFTTest/releases/
http://ldesoras.free.fr/src/vs/fmtconv-r8.zip
https://github.com/dubhater/vapoursynth-mvtools/releases/
https://github.com/dubhater/vapoursynth-nnedi3/releases
http://www.mediafire.com/download.php?dnld4p98i333idp or http://uloz.to/x6gvxpbB/scenechange-win64-7z
Kupildivan
19th March 2015, 17:38
Script evaluation failed:
Python exception: No attribute with the name scd exists. Did you mistype a plugin namespace?
Traceback (most recent call last):
File "vapoursynth.pyx", line 1488, in vapoursynth.vpy_evaluateScript (src\cython\vapoursynth.c:25136)
File "VSQTGMC.vpy", line 7, in <module>
v = haf.QTGMC (v, Preset='Medium', TFF=True)
File "C:\Python34-64\lib\site-packages\havsfunc.py", line 871, in QTGMC
if TR0 > 0: ts1 = TemporalSoften(bobbed, 1, 255, CMts, 28, 2) # 0.00 0.33 0.33 0.33 0.00
File "C:\Python34-64\lib\site-packages\havsfunc.py", line 3238, in TemporalSoften
clip = set_scenechange(clip, scenechange)
File "C:\Python34-64\lib\site-packages\havsfunc.py", line 3260, in set_scenechange
sc = core.scd.Detect(sc, thresh)
File "vapoursynth.pyx", line 1109, in vapoursynth.Core.__getattr__ (src\cython\vapoursynth.c:19250)
AttributeError: No attribute with the name scd exists. Did you mistype a plugin namespace?
Some plugin is absent? But which?
Myrsloik
19th March 2015, 17:52
Script evaluation failed:
Python exception: No attribute with the name scd exists. Did you mistype a plugin namespace?
Traceback (most recent call last):
File "vapoursynth.pyx", line 1488, in vapoursynth.vpy_evaluateScript (src\cython\vapoursynth.c:25136)
File "VSQTGMC.vpy", line 7, in <module>
v = haf.QTGMC (v, Preset='Medium', TFF=True)
File "C:\Python34-64\lib\site-packages\havsfunc.py", line 871, in QTGMC
if TR0 > 0: ts1 = TemporalSoften(bobbed, 1, 255, CMts, 28, 2) # 0.00 0.33 0.33 0.33 0.00
File "C:\Python34-64\lib\site-packages\havsfunc.py", line 3238, in TemporalSoften
clip = set_scenechange(clip, scenechange)
File "C:\Python34-64\lib\site-packages\havsfunc.py", line 3260, in set_scenechange
sc = core.scd.Detect(sc, thresh)
File "vapoursynth.pyx", line 1109, in vapoursynth.Core.__getattr__ (src\cython\vapoursynth.c:19250)
AttributeError: No attribute with the name scd exists. Did you mistype a plugin namespace?
Some plugin is absent? But which?
Scenechange. Linked in the previous post.
Kupildivan
19th March 2015, 18:04
Fixed. I had mistakingly copied 32-bit version of that scenechange into 64 folder.
But then appeared another error:
Python exception: nnedi3: Couldn't open file 'C:/Program Files (x86)/VapourSynth/plugins64/nnedi3_weights.bin'. Error message: No such file or directory
captainadamo
19th March 2015, 18:14
Fixed. I had mistakingly copied 32-bit version of that scenechange into 64 folder.
But then appeared another error:
Python exception: nnedi3: Couldn't open file 'C:/Program Files (x86)/VapourSynth/plugins64/nnedi3_weights.bin'. Error message: No such file or directory
You need to download the renamed weights file for NNEDI3 v4.
https://github.com/dubhater/vapoursynth-nnedi3/blob/master/src/nnedi3_weights.bin?raw=true
Kupildivan
19th March 2015, 18:18
Thanks. I have done that already after looking at download page more attentively.
Now it works.
How about importing avisynth plugins in 64-bit vapoursynth? It always shows me the same error: "No attribute with the name avs exists".
RTW47
20th March 2015, 11:14
How about importing avisynth plugins in 64-bit vapoursynth? It always shows me the same error: "No attribute with the name avs exists".
64-bit version of VapourSynth cannot load 64-bit AviSynth plugins. You have to either work in 32-bit mode or port particular avs plugin.
Picky_editor
24th March 2015, 20:31
When I click on the link for the file below, Avast Antivirus is reporting that the file below is a "Suspicious Item".
https://github.com/vapoursynth/vapoursynth/releases/download/R26/vapoursynth-r26.exe
It lists the URL as:
https://s3.amazonaws.com/github-cloud/releases/11136031/1c246d40-a680-11e4-93c3-543cf55e
with the remainder of the link truncated.
Please advise
Myrsloik
24th March 2015, 20:43
When I click on the link for the file below, Avast Antivirus is reporting that the file below is a "Suspicious Item".
https://github.com/vapoursynth/vapoursynth/releases/download/R26/vapoursynth-r26.exe
It lists the URL as:
https://s3.amazonaws.com/github-cloud/releases/11136031/1c246d40-a680-11e4-93c3-543cf55e
with the remainder of the link truncated.
Please advise
All antivirus is shit. I find your post suspicious.
You have been advised.
LoRd_MuldeR
24th March 2015, 20:44
When I click on the link for the file below, Avast Antivirus is reporting that the file below is a "Suspicious Item".
https://github.com/vapoursynth/vapoursynth/releases/download/R26/vapoursynth-r26.exe
It lists the URL as:
https://s3.amazonaws.com/github-cloud/releases/11136031/1c246d40-a680-11e4-93c3-543cf55e
with the remainder of the link truncated.
Please advise
Check the file again with multiple anti-virus engines, which will probably show that this is a False Positive (http://en.wikipedia.org/wiki/Antivirus_software#Problems_caused_by_false_positives):
https://www.virustotal.com/
If so, please report the problem to the developer of your so-called "anti-virus" software!
Picky_editor
24th March 2015, 22:21
I can't actually download the file to be able to check it with other software. It is blocked as soon as I click in the download link, before I indicate where to save the file.
I was hoping that someone else could check the link and see if they are getting a warning as well.
LoRd_MuldeR
24th March 2015, 22:41
I can't actually download the file to be able to check it with other software. It is blocked as soon as I click in the download link, before I indicate where to save the file.
If your "anti-virus" software really doesn't allow you to manually ignore/override the (false) alarm, I suggest to get something less intrusive...
I was hoping that someone else could check the link and see if they are getting a warning as well.
See here:
https://www.virustotal.com/en/file/2abb6e45400796e06d3375bfd22f67563d3234ceeece22f95abbd4a6bfadaf71/analysis/1427233228/
SHA256: 2abb6e45400796e06d3375bfd22f67563d3234ceeece22f95abbd4a6bfadaf71
File name: vapoursynth-r26.exe
Detection ratio: 0 / 57
Analysis date: 2015-03-24 21:40:28 UTC ( 2 minutes ago )
Kupildivan
25th March 2015, 18:46
When piping the script with --y4m to x264 or ffmpeg they don't know total number of frames. Remaining encode time is unknown. How it should be fixed?
captainadamo
25th March 2015, 18:50
Tell x264 the number of frames using the --frames switch.
Kupildivan
25th March 2015, 19:01
It works, but requires its manual adding every time to new script.
I'm asking about automatical defining.
So
v.output (sys.stdout, y4m=True)
for me worked nice before, but something has changed. Don't know what but now it has no effect.
sl1pkn07
25th March 2015, 19:13
i use scripting with vspipe --info
this is for linux. but you can adapt to your system
_frames="$(vspipe --info "${1}" - | grep Frames | cut -d ' ' -f2)"
vspipe -y "${1}" - | "${x264}" - --output "${2}" --frames "${_frames}" --stdin y4m --foo
'$1' is the vpy script and '$2' the output file
sneaker_ger
25th March 2015, 19:14
While we're at it: it's a bit strange for "--info" to require an output file name.
Myrsloik
25th March 2015, 19:18
While we're at it: it's a bit strange for "--info" to require an output file name.
You're the first one to mention it. I guess it is slightly unusual. Other opinions?
LoRd_MuldeR
25th March 2015, 20:13
It works, but requires its manual adding every time to new script.
I'm asking about automatical defining.
You could use a GUI like the Simple x264/x265 Launcher, if you are not too much into scripting ;)
http://forum.doom9.org/showthread.php?t=144140
Sangan
31st March 2015, 18:29
You could use a GUI like the Simple x264/x265 Launcher, if you are not too much into scripting ;)
http://forum.doom9.org/showthread.php?t=144140
... I would like to use that too... on a Mac, not in Wine, because in Wine (the up to date one via Homebrew) neither VS 25 nor 26 will install...
shekh
5th April 2015, 11:43
Hi,
What do you think about outputting b48r, b64a from vfw interface?
I am developing VirtualDub modification with 16bit pipeline, and it seems interesting to support VapourSynth.
Also I noticed this:
when I open in VirtualDub vpy script with utf8 BOM, it is not interpreted (error message complains on bad 1st character). Python commandline does interpret it fine.
Myrsloik
5th April 2015, 14:35
Hi,
What do you think about outputting b48r, b64a from vfw interface?
I am developing VirtualDub modification with 16bit pipeline, and it seems interesting to support VapourSynth.
Also I noticed this:
when I open in VirtualDub vpy script with utf8 BOM, it is not interpreted (error message complains on bad 1st character). Python commandline does interpret it fine.
Output to other formats is easy to add. The biggest reason I didn't add those formats yet is that no applications that accept them use the normal vfw code for reading files.
The bom problem is odd. It should work exactly the same.
lo1t3yu
12th April 2015, 05:43
Hello.
When lsmash lib loading vs give error:
>>> core.std.LoadPlugin('/home/user/liblsmash.so.2')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "vapoursynth.pyx", line 1387, in vapoursynth.Function.__call__ (src/cython/vapoursynth.c:23550)
vapoursynth.Error: No entry point found in /home/user/liblsmash.so.2
>>> core.std.LoadPlugin('/home/user/libvslsmashsource.so.')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "vapoursynth.pyx", line 1387, in vapoursynth.Function.__call__ (src/cython/vapoursynth.c:23550)
vapoursynth.Error: Failed to load /home/user/libvslsmashsource.so.. Error given: /home/user/libvslsmashsource.so.: undefined symbol: avcodec_default_get_buffer2
Maybe lsmash vs plugin compiled without required libs/codecs?
Solved. Vapoursynth's lsmash plugin has been compiled with old libav* inc headers, but now vs break error:
import vapoursynth as vs
#import havsfunc as haf
core = vs.get_core()
core.std.LoadPlugin('/home/user/libvslsmashsource.so.')
v = core.LWLibavSource('/home/user/1.ts')
AttributeError: No attribute with the name LWLibavSource exists. Did you mistype a plugin namespace?
What func name need to use?
RTW47
12th April 2015, 15:01
AttributeError: No attribute with the name LWLibavSource exists. Did you mistype a plugin namespace?
What func name need to use?
you need to additionally specify lsmas namespace eg:.
v = core.lsmas.LWLibavSource(source=r'D:\video.m2ts')
lo1t3yu
12th April 2015, 15:41
you need to additionally specify lsmas namespace eg:.
v = core.lsmas.LWLibavSource(source=r'D:\video.m2ts')
Thanks! It works.
Myrsloik
26th April 2015, 18:37
Just go to the FFMS2 thread to find links instead.
Myrsloik
6th May 2015, 20:54
Here's R27 RC1 (https://www.dropbox.com/s/a6yobbz7xz5nkf9/vapoursynth-r27-rc1.exe?dl=1). It's needed to use plugins such as the new FFMS2 compiles by me and fmtconv r9.
The big news is that genericfilters no longer will be a separate plugin. Instead most of it has been rewritten (and corrected) and integrated into the core. Simply replace stuff like core.generic.Maximum() with core.std.Maximum(). The new versions may be slightly slower but also have less unexpected bugs to find.
Changes:
r27:
added a rewritten version of genericfilters to the core (nodame)
fixed the not (required two operands instead of one, asm broken) and swap (only required one operand instead of two) operators in the expr filter
renamed the x and y arguments in cropabs to left and top to be clearer and match croprel
addborders now rejects negative borders properly and passes through clips unchanged when all borders are 0
several bugfixes to the bundled genericfilters
added compile time option to have additional guard memory around frames to detect out of bounds writes in filters
added setframeprop filter (nodame)
the framerate and the frame duration property should now be a normalized number
all internal filters now return an error if the returned clip is longer than INT_MAX instead of undefined behavior
"unknown" length clips have been deprecated and a fatal error will happen if any plugin returns them, this change is because it was complicated, annoying and accomplished nothing compared to INT_MAX length clips
freezeframes now doesn't need to have the ranges specified in ascending order
interleave, separatefield and selectevery now properly adjusts the framerate including the durations
changed the meaning of _FieldBased to be able to signal progressive/bff/tff material, this is now used by ffms2, eedi3 and separatefields
fixed memory leak in assvapour destructor
the identifiers used for keys in vsmap can only be alphanumeric and _, anything else will be rejected
the expr filter now does constant folding which makes it faster in many cases (nodame)
vspipe can now output timecode v2 files (nodame)
splice and interleave now properly reject clips with mismatched fps unless mismatch is set
fixed possible bad behavior/crash in FrameEval under rare circumstances
fixed truncation of last digit of integers in text.FrameProps
speedyrazor
9th May 2015, 10:36
Hi, I currently write python applications which then call on and create avisynth avs files which use Quicktime Prores files as an input and feed the avs files to ffmpeg, this works, but is very slow, as avisynth is. I came upon this post and wondered if I could switch to using VapourSynth instead. I primarily do conversions between HD and SD and speed change the video, so for example going from HD 23.98 to SD PAL 25 via a speed change, pitch correcting the audio so it remains the same pitch. Below is the sort of script I currently use in Avisynth, so my question is can I achieve the same thing in VapourSynth?
Avisynth Script:
QTInput("test.mov", quality=100, audio=2)
ColorMatrix(mode="Rec.709->Rec.601", clamp=0)
Spline36Resize(720, 576)
TimeStretch(tempo = 25.0/24.0*100.0)
AssumeFPS(25, 1)
Kind regards.
Myrsloik
9th May 2015, 13:46
No, you can't. The audio support isn't there yet.
Myrsloik
11th May 2015, 15:23
It's time for R27 RC4 (https://www.dropbox.com/s/wswdr9lvfdwj34z/vapoursynth_r27-rc4.exe?dl=1)!
It will probably be the last RC unless huge bugs are discovered. Changes from RC1:
Fixed PropToClip crash on certain errors
Improved ClipInfo to show more useful information
An updated version of generic filters with a few more bugs fixed
Btw, you should stop using the old generic filters and instead use the new one integrated into the VS core.
sl1pkn07
11th May 2015, 16:50
what is the default icon for .vpy files in windows?
is for copy to my linux installation
buchanan
11th May 2015, 16:55
Hi Myrsloik,
Since R27 RC1, it seems to me there is a memory bug with Selectevery. Simply load a 1920*1080 clip, apply vid=core.std.SelectEvery(clip=vid, cycle=2, offsets=1) and output the clip : vspipe.exe memory consumption is constantly increasing
Myrsloik
11th May 2015, 17:03
There is no official icon. Contributions welcome.
Hi Myrsloik,
Since R27 RC1, it seems to me there is a memory bug with Selectevery. Simply load a 1920*1080 clip, apply vid=core.std.SelectEvery(clip=vid, cycle=2, offsets=1) and output the clip : vspipe.exe memory consumption is constantly increasing
Fixed, a line of code disappeared by mistake... I've updated the rc4 installer.
jackoneill
12th May 2015, 19:58
PSA: If you're writing a script and you want it to be usable forever, pass filter parameters using their names.
Good:
core.ns.Filter(clip=asdf, param=value, etc=etc)
Bad:
core.ns.Filter(asdf, value, etc)
Filter parameters may be rearranged to look better in the source, new parameters may be added, who knows.
splinter98
12th May 2015, 22:18
PSA: If you're writing a script and you want it to be usable forever, pass filter parameters using their names.
Good:
core.ns.Filter(clip=asdf, param=value, etc=etc)
Bad:
core.ns.Filter(asdf, value, etc)
Filter parameters may be rearranged to look better in the source, new parameters may be added, who knows.
...Although parameters may also be renamed so no guarantees for forever reuse... (Some form of depreciation warning system might be useful to implement)
At least it ensures you no transposed arguments get unnoticed. :(
Myrsloik
13th May 2015, 20:28
R27 is released! Links and changelog in the first post as usual.
Here's my blog post about the important compatibility changes (http://www.vapoursynth.com/2015/05/r27-revising-stuff-and-things/).
Start switching to the internal version of GenericFilters because the plugin version will disappear in R28.
foxyshadis
13th May 2015, 21:33
Thanks! I changed the title of the GenericFilters thread to reflect that.
lo1t3yu
19th May 2015, 09:04
What namespace is using in newer VapourSynth?
Try use
import vapoursynth as vs
import havsfunc as haf
core = vs.get_core()
v = core.ffms2.Source(source='1080i_25.ts', fpsnum=25, fpsden=1)
File "vapoursynth.pyx", line 1469, in vapoursynth.vpy_evaluateScript (src/cython/vapoursynth.c:24726)
File "script.vpy", line 5, in <module>
v = core.ffms2.Source(source='1080i_25.ts', fpsnum=25, fpsden=1)
File "vapoursynth.pyx", line 1090, in vapoursynth.Core.__getattr__ (src/cython/vapoursynth.c:18928)
AttributeError: No attribute with the name ffms2 exists. Did you mistype a plugin namespace?
VapourSynth R27 and ffms2 2.21. VS and ffms2 have been successfully compiled with latest ffmpeg/libav libs.
Myrsloik
19th May 2015, 09:32
What namespace is using in newer VapourSynth?
Try use
VapourSynth R27 and ffms2 2.21. VS and ffms2 have been successfully compiled with latest ffmpeg/libav libs.
It's the same namespace. Are you sure you placed the plugin in the right location for it to be autoloaded?
lo1t3yu
19th May 2015, 17:08
It's the same namespace. Are you sure you placed the plugin in the right location for it to be autoloaded?
Yep. I try to set plugin path in $HOME/.config/vapoursynth/vapoursynth.conf, but it doesn't works.
Also, using R27 plugins in system dir (/usr/lib/vapoursynth) aren't loading. However,
nobody talks about the issues with plugins autoloading. Maybe, this depends on the system libs and bashrc configs? Now is clean.
captainadamo
19th May 2015, 17:52
Did you try doing a manual loading of the plugin to make sure there is not some other issue at play?
lo1t3yu
20th May 2015, 07:36
Did you try doing a manual loading of the plugin to make sure there is not some other issue at play?
Sure. If plugin load in script then it works fine.
feisty2
22nd May 2015, 16:10
@Myrsloik
can you add "mt_luts" and "mt_lutsx" from masktools to vs core as well, I want them for "masking" stuff
Myrsloik
22nd May 2015, 16:14
@Myrsloik
can you add "mt_luts" and "mt_lutsx" from masktools to vs core as well, I want them for "masking" stuff
No, never going into the core. They're simply far too specific operations.
feisty2
22nd May 2015, 16:21
No, never going into the core. They're simply far too specific operations.
okay, that's true... how about getting them into "GenericFilters", I would've done it if I wasn't a C/C++ numb..
lanzorg
24th May 2015, 01:02
Does someone know if it's possible to use vapoursynth with mpc-be x64 on windows ?
If yes, how to ?
8-BaLL
29th May 2015, 13:07
Hey guys,
I would like to ask you something about vapoursynth. Right now im using qtgmc preset very slow + spline64 resize (1280x720) To rncode my hdtv caps using avisynth 2.6.
The encoding speed is 1.75 fps on my system, but the cpu load is only around 45-50% only
Will the vapoursynth use the 4 cores of the cou better when using qtgmc and does it have a qtgmc preset very slow for vapoursynth?
8-BaLL
29th May 2015, 13:40
Alright, thanks. I will install and test it. I hope megui can handle vapoursynth scripts.
feisty2
1st June 2015, 14:56
will "rgvs" and std.Median have float point support someday?
Myrsloik
1st June 2015, 15:00
will "rgvs" and std.Median have float point support someday?
I guess so. At least the core functions where it makes sense. Honestly I see the future of removegrain as being chopped up into functions with names that make sense and maybe then I'll add floating point versions of that too.
Is there any particular reason you want to use floats?
feisty2
1st June 2015, 15:07
Is there any particular reason you want to use floats?
I'll output the final result as an uncompressed 32bpc float point TIFF sequence to minimize the precision loss, cuz I'll do some color grading after that, and color grading is famous for demanding precision :)
Myrsloik
1st June 2015, 15:09
I'll output the final result as an uncompressed 32bpc float point TIFF sequence to minimize the precision loss, cuz I'll do some color grading after that, and color grading is famous for demanding precision :)
Real professional stuff. I like that. Tell me which functions you need and I'll take a look at them at some point in the future (unfortunately for you I have plenty of real work stuff to do).
feisty2
1st June 2015, 15:19
dfttest (with float point), rawsource (with float point), luts/lutsx (guess 8bpc would be enough for them, cuz I only need them to create masks), eedi3 (with high bitdepth support, and SSE2 opt from cretindesalpes, nnedi3 is awesome as an upscaler, but just not the right tool to deinterlace)
edit: I don't know if you'll ever have time to do those above, but thx for vaporsynth anyway, it's awesometastic :)
foxyshadis
2nd June 2015, 10:12
Turns out my old request was a lot easier to accomplish than I thought; merely adding another line, <VS_FOLDER>\scripts, to vapoursynth.pth let me put all of the common scripts in that folder instead of polluting my relatively difficult to access Python folder.
jeremy33
11th June 2015, 20:57
Hello,
I use this PPA (https://launchpad.net/~djcj/+archive/ubuntu/vapoursynth) to install vapoursynth and some python scripts, like finesharp, on Ubuntu.
I'm in touch with djcj, the ppa maintainer, to allow the use of the python scripts without the need to make some /home config files like :
$ mkdir -p "${HOME}/.config/vapoursynth"
$ tee "${HOME}/.config/vapoursynth/vapoursynth.conf" << 'EOF'
UserPluginDir=/Path/To/filters/
EOF
- add to ~/.profile
export PYTHONPATH=$PYTHONPATH:/Path/To/filters/
The scripts are installed here "/usr/lib/python3/dist-packages/vapoursynth-scripts/".
Is it possible to do that and how ?
Maybe at the compile time we have to use something like that (http://www.vapoursynth.com/doc/autoloading.html#linux):
SystemPluginDir, whose default value is set at compile time to $libdir/vapoursynth, or to the location passed to the --with-plugindir argument to configure.
feisty2
13th June 2015, 09:24
rgvs mode13 and 14 are broken
Myrsloik
13th June 2015, 09:25
rgvs mode13 and 14 are broken
Broken how?
feisty2
13th June 2015, 09:29
Broken how?
the right half of the image looks like "interlaced" kinda stuff, I'm testing on Gray16 clips
feisty2
13th June 2015, 09:44
and mode15/16 are broken as well, same issue like 13/14
Myrsloik
13th June 2015, 11:24
and mode15/16 are broken as well, same issue like 13/14
You're right, and it only seems to happen with gray16 input. That's very odd...
Myrsloik
13th June 2015, 18:31
Here's just a R28 work in progress version (https://www.dropbox.com/s/wecntdf9xve68qc/vapoursynth-r28-test1.exe?dl=1) for you to try.
Changes:
fixed an image corruption bug with 9-16 bit input to rgvs when the c++ code is used
fixed division by zero issues in muldivrational in vshelper.h
blankclip can now create 0 (unknown/variable) fps clips
added float support to planedifference and planeaverage
added half support to addborders
relevant compile time options are now in the version string
feisty2
14th June 2015, 05:07
rgvs works okay now
good news
jeremy33
16th June 2015, 11:33
Is somebody have an idea ?
Hello,
I use this PPA (https://launchpad.net/~djcj/+archive/ubuntu/vapoursynth) to install vapoursynth and some python scripts, like finesharp, on Ubuntu.
I'm in touch with djcj, the ppa maintainer, to allow the use of the python scripts without the need to make some /home config files like :
$ mkdir -p "${HOME}/.config/vapoursynth"
$ tee "${HOME}/.config/vapoursynth/vapoursynth.conf" << 'EOF'
UserPluginDir=/Path/To/filters/
EOF
- add to ~/.profile
export PYTHONPATH=$PYTHONPATH:/Path/To/filters/
The scripts are installed here "/usr/lib/python3/dist-packages/vapoursynth-scripts/".
Is it possible to do that and how ?
Maybe at the compile time we have to use something like that (http://www.vapoursynth.com/doc/autoloading.html#linux):
SystemPluginDir, whose default value is set at compile time to $libdir/vapoursynth, or to the location passed to the --with-plugindir argument to configure.
Are_
16th June 2015, 13:11
Sincerely, I fail to understand what is your problem.
jeremy33
16th June 2015, 15:51
We simply try to install vapoursynth and some python scripts, like finesharp, on Ubuntu with this PPA (https://launchpad.net/~djcj/+archive/ubuntu/vapoursynth) and we want to make these scripts (eg. finesharp) works "out of the box".
At the moment Vapoursynth doesn't find the scripts and we need to make some config files after the install to make them work.
This is what I need to use after the install :
$ mkdir -p "${HOME}/.config/vapoursynth"
$ tee "${HOME}/.config/vapoursynth/vapoursynth.conf" << 'EOF'
UserPluginDir=/Path/To/filters/
EOF
- add to ~/.profile
export PYTHONPATH=$PYTHONPATH:/Path/To/filters/
So the question is how can we tell to Vapoursynth where the scripts are without the need of some config files after the install ?
sl1pkn07
16th June 2015, 18:35
install in the python3 sites-package
python -c "from distutils.sysconfig import get_python_lib; print(get_python_lib())" for get the path
example for Arch https://aur4.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=vapoursynth-plugin-finesharp-git
jeremy33
16th June 2015, 20:07
Thank you I will try
kaefert
16th June 2015, 22:30
I have a long vapoursynth script working on many videos resulting in a clip "sum" with RGB48 colorspace.
I want to output yuv 10bit to ffmpeg to encode as x265 mp4.
previously, I converted my RGB48 clip to YUV16 like that:
c=core.fmtc.matrix (clip=sum, mat="601", col_fam=vs.YUV, bits=16)
c=core.fmtc.resample (clip=c, css="420")
c.set_output()
but now the core.fmtc package is gone and the only replacement I could find is
core.resize.Bicubic(clip=sum, format=vs.YUV420P10) # vs.YUV420P16
but this does not seem to work: both P10 and P16 give this error:
$ "/cygdrive/c/Program Files (x86)/VapourSynth/core64/vspipe.exe" -y "join_prepared.vpy" -
YUV4MPEG2 C420 W3840 H2160 F0:0 Ip A0:0
[swscaler @ 00000015D3790020] gbrp16le is not supported as output pixel format
[swscaler @ 00000015D3790020] gbrp16le is not supported as output pixel format
[swscaler @ 00000015D379A020] gbrp16le is not supported as output pixel format
[swscaler @ 00000015D379A020] gbrp16le is not supported as output pixel format
[swscaler @ 00000015D379A020] gbrp16le is not supported as output pixel format
[swscaler @ 00000015D379A020] gbrp16le is not supported as output pixel format
[swscaler @ 00000015D379A020] gbrp16le is not supported as output pixel format
[swscaler @ 00000015CDE28020] gbrp16le is not supported as output pixel format
Error: Failed to retrieve frame 1 with error: Resize: context creation failed
Output 0 frames in 492.19 seconds (0.00 fps)
whats the correct way to do it, or do I need to step back to an older vapoursynth version still containing the core.fmtc package?
sneaker_ger
16th June 2015, 22:42
You can download fmtc here:
http://forum.doom9.org/showthread.php?t=166504
kaefert
17th June 2015, 09:53
thanks sneaker_ger!
now my next problem is: I have a ton of 16bit color-depth tif files, which all work fine to import into vapoursynth using the imwri.Read plugin, and turning up as clips in RGB48 format, just as I want them to.
But I have this one tif file, which looks just the same as all the others with all the tools I could think of like picture viewers, MediaInfo.exe and GIMP. But imported into Vapoursynth it results in a clip with the Format: Gray16
What could cause that? Or do I need to ask this question over there? http://forum.doom9.org/showthread.php?t=170981
UPDATE: strike that. I did not read MediaInfo.exe output exactly enough. color space of my problematic tif is "Y" instead of "RGB" as all the others. though I have no idea why it is a different color space, all have been created the same way by loading a JPG into imagemagick manipulating it a bit and exporting to a 16 bit tif file.
UPDATE2: okey, so it seems ImageMagick has decided based on the image content that RGB is not needed, and gray is enough. The image looked to me to have not only gray but also a little yellowish and redish taint, but maybe thats just my screen ;)
So I found I need to force ImageMagick to output an RGB color space TIF by using the option "-type truecolor"
Myrsloik
17th June 2015, 09:55
thanks sneaker_ger!
now my next problem is: I have a ton of 16bit color-depth tif files, which all work fine to import into vapoursynth using the imwri.Read plugin, and turning up as clips in RGB48 format, just as I want them to.
But I have this one tif file, which looks just the same as all the others with all the tools I could think of like picture viewers, MediaInfo.exe and GIMP. But imported into Vapoursynth it results in a clip with the Format: Gray16
What could cause that? Or do I need to ask this question over there? http://forum.doom9.org/showthread.php?t=170981
No idea. Does it work if you use the imagemagick commandline stuff to convert it?
kaefert
17th June 2015, 10:27
No idea. Does it work if you use the imagemagick commandline stuff to convert it?
sorry Myrsloik for causing this confusion. I've updated my previous post to reflect what I've found: I needed to force ImageMagick to write my tif with RGB color space using -type truecolor since apperantly this one picture only had gray pixels (althought to my eyes through my screen it looked like having a yellow and/or redish taint)
jeremy33
18th June 2015, 02:10
install in the python3 sites-package
python -c "from distutils.sysconfig import get_python_lib; print(get_python_lib())" for get the path
example for Arch https://aur4.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=vapoursynth-plugin-finesharp-git
I didn't try yet but is there a "cleaner" way to do that because I think it's better to put all the scripts in a folder inside python3 dist-package (dist-package is for ubuntu) like "/usr/lib/python3/dist-packages/vapoursynth-scripts/" whereas to put them directly in "dist-packages".
sl1pkn07
18th June 2015, 05:39
https://github.com/vapoursynth/vapoursynth/issues/156
foxyshadis
18th June 2015, 07:22
Turns out my old request was a lot easier to accomplish than I thought; merely adding another line, <VS_FOLDER>\scripts, to vapoursynth.pth let me put all of the common scripts in that folder instead of polluting my relatively difficult to access Python folder.
I prefer autoloading from a subfolder of VS, Avisynth style, but you can arrange yours as you wish. I found that VS will overwrite vapoursynth.pth each install, so creating a new vs-scripts.pth was more reliable. These files all go in the site-packages folder. As soon as you do that, you can import the script without loading it.
Note that .pth files actually add their contained folders to the runtime path, not just the import path, if that affects anything you do.
feisty2
18th June 2015, 08:15
@Myrsloik
will you add float point support to core functions and rgvs in the next release?
if so, that means I get to process my vids again pretty soon, and I will decide to make peace with 16bits mvtools
if not, that means I still got a lot of time to mess with filters, then I will stick to mvtools modification
Myrsloik
18th June 2015, 11:07
I won't have time to change that much before the next release. So no.
jeremy33
18th June 2015, 17:06
install in the python3 sites-package
python -c "from distutils.sysconfig import get_python_lib; print(get_python_lib())" for get the path
example for Arch https://aur4.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=vapoursynth-plugin-finesharp-git
I tried to install them in python3 dist-package and I have this error : "Instruction not allowed".
Do you know why ?
https://github.com/vapoursynth/vapoursynth/issues/156
Thank you, I hope it will be add.
sl1pkn07
18th June 2015, 17:32
I tried to install them in python3 dist-package and I have this error : "Instruction not allowed".
Do you know why ?
when install? when load (in vpy script)? when?
└───╼ python -c "from distutils.sysconfig import get_python_lib; print(get_python_lib())"
/usr/lib/python3.4/site-packages
└───╼ ls $(python -c "from distutils.sysconfig import get_python_lib; print(get_python_lib())")/fine*
-rw-r--r-- 1 root root 6927 jun 16 19:30 /usr/lib/python3.4/site-packages/finesharp.py
testcase
import vapoursynth as vs
core = vs.get_core()
import finesharp
clip = core.std.BlankClip(format=vs.YUV420P8)
clip = finesharp.sharpen(clip)
clip.set_output()
└───╼ vspipe prueba.vpy -y --info -
Width: 640
Height: 480
Frames: 240
FPS: 24/1 (24.000 fps)
Format Name: YUV444P8
Color Family: YUV
Bits: 8
SubSampling W: 0
SubSampling H: 0
EDITED: do'h, i'm still noob
jeremy33
18th June 2015, 21:30
python3 -c "from distutils.sysconfig import get_python_lib; print(get_python_lib())"
/usr/lib/python3/dist-packages
ls $(python3 -c "from distutils.sysconfig import get_python_lib; print(get_python_lib())")/fine*
/usr/lib/python3/dist-packages/finesharp.py
I have the error when I play a movie with mpv and, of course, vapoursynth :
mpv --vf-add=vapoursynth=/media/Data/vapoursynth.py "big buck bunny 480p h264.mkv"
Playing: big buck bunny 480p h264.mkv
(+) Video --vid=1 (h264)
Opening video filter: [vapoursynth file=/media/Data/vapoursynth.py]
Instruction non permise
"Instruction non permise" = "Instruction not allowed"
foxyshadis
18th June 2015, 22:53
So what's in your vapoursynth.py? Have you tested it (replacing video_in with an actual source filter) in vsedit? Have you asked for help from mpv devs?
jeremy33
19th June 2015, 00:13
MPV and Vapoursynth work perfectly if I use these config files after the installation of MPV and Vapoursynth from the ppa :
$ mkdir -p "${HOME}/.config/vapoursynth"
$ tee "${HOME}/.config/vapoursynth/vapoursynth.conf" << 'EOF'
UserPluginDir=/Path/To/filters/
EOF
- add to ~/.profile
export PYTHONPATH=$PYTHONPATH:/Path/To/filters/
I tested with a simple vapoursynth.py script like this one from sl1pkn07 but I have the same error
import vapoursynth as vs
core = vs.get_core()
import finesharp
clip = core.std.BlankClip()
clip = core.fmtc.matrix(clip, mat="709", col_fam=vs.YUV)
clip = finesharp.sharpen(clip)
clip.set_output()
I don't asked for help from MPV devs because it's a Vapoursynth "problem". I just want to use Vapoursynth with the python scripts like finesharp right after the install without the need of some config files after the install.
They manage to do it on Arch so it can be possible on Ubuntu.
sl1pkn07
19th June 2015, 05:51
works for me (edited my last post)
input.vpy
import vapoursynth as vs
core = vs.get_core()
clip = core.std.BlankClip(format=vs.YUV420P8)
clip.set_output()
filter.vpy
import vapoursynth as vs
import finesharp
core = vs.get_core()
clip = video_in
clip = finesharp.sharpen(clip)
clip.set_output()
http://wstaw.org/m/2015/06/19/Screenshot_20150619_064924.png
jackoneill
19th June 2015, 10:59
python3 -c "from distutils.sysconfig import get_python_lib; print(get_python_lib())"
/usr/lib/python3/dist-packages
ls $(python3 -c "from distutils.sysconfig import get_python_lib; print(get_python_lib())")/fine*
/usr/lib/python3/dist-packages/finesharp.py
I have the error when I play a movie with mpv and, of course, vapoursynth :
mpv --vf-add=vapoursynth=/media/Data/vapoursynth.py "big buck bunny 480p h264.mkv"
Playing: big buck bunny 480p h264.mkv
(+) Video --vid=1 (h264)
Opening video filter: [vapoursynth file=/media/Data/vapoursynth.py]
Instruction non permise
"Instruction non permise" = "Instruction not allowed"
Last time I tried to use one of the plugins from that PPA (fmtconv), it was compiled incorrectly. It was not suitable for distribution due to the use of AVX instructions in some code path that is supposed to run on any old CPU with SSE2, not just those that have AVX. The result is exactly the error message you got.
Here is how to check:
gdb --args mpv etc
run
[prints "Instruction non permise"]
set disassembly-flavor intel
disassemble
[hit enter until you see "=>" on the left next to the illegal instruction]
jeremy33
19th June 2015, 11:29
works for me (edited my last post)
Ok, little mistake ;) so I tried that and that works ! Thank you.
import vapoursynth as vs
import finesharp
core = vs.get_core()
clip = video_in
clip = finesharp.sharpen(clip)
clip.set_output()
Now if I use my script that still don't work and I think jackoneill is probably right.
Last time I tried to use one of the plugins from that PPA (fmtconv), it was compiled incorrectly. It was not suitable for distribution due to the use of AVX instructions in some code path that is supposed to run on any old CPU with SSE2, not just those that have AVX. The result is exactly the error message you got.
I run the gdb command and this is the error :
Program received signal SIGILL, Illegal instruction.
0x00007fffaeb57750 in vsutl::compute_fmt_mac_cst(double&, double&, VSFormat const&, bool, VSFormat const&, bool, int) () from /usr/lib/x86_64-linux-gnu/vapoursynth/libfmtconv.so
That's weird because Vapoursynth works if I use the config files after the install (mkdir -p "${HOME}/.config/vapoursynth" ...)
jackoneill
19th June 2015, 12:40
Maybe you have more than one copy of fmtconv.
jeremy33
19th June 2015, 12:53
That don't seem to be the case. I search on my entire drive and I only found one copy of fmtconv.
jeremy33
20th June 2015, 21:58
That works !
djcj now use the original Makefiles from "https://github.com/EleonoreMizo/fmtconv/tree/master/build/unix" to build fmtconv on the PPA.
Thank you very much
feisty2
24th June 2015, 10:22
http://i.imgur.com/ZV4LT6z.png
dunno why but vspipe failed to ouput "GrayS" clips, and preview in vseditor works good, so the vaporsynth core gotta be alright, guess it's a vspipe problem
did this on r28 test1
jackoneill
24th June 2015, 11:34
http://i.imgur.com/ZV4LT6z.png
dunno why but vspipe failed to ouput "GrayS" clips, and preview in vseditor works good, so the vaporsynth core gotta be alright, guess it's a vspipe problem
did this on r28 test1
What is the script?
feisty2
24th June 2015, 13:04
now it's freaking me out...
I removed my modified RGVS.dll and FLT.dll from plugin folder, and it just works, like suddenly, I mean, I didn't even call things from RGVS.dll or FLT.dll in the python script, that doesn't make any sense at all, how's that even possible? and even if I just call things from RGVS.dll/FLT.dll, preview in vseditor works perfectly without any problem, why?
anyways, script
import vapoursynth as vs
core = vs.get_core()
def nlmcleansef (src, local=2.4, nlocal=0.8):
core = vs.get_core ()
lflt = core.knlm.KNLMeansCL (src, d=0, a=24, s=1, h=local).knlm.KNLMeansCL (d=0, a=24, s=0, h=local)
ldif = core.std.MakeDiff (src, lflt).knlm.KNLMeansCL (d=0, a=2, s=4, h=local)
clip = core.std.MergeDiff (lflt, ldif).knlm.KNLMeansCL (d=0, a=24, s=4, h=nlocal)
return clip
clp = core.raws.Source("Y.rgb", 736, 480, src_fmt="GRAYS")
clp = nlmcleansef (clp)
clp.set_output ()
jackoneill
24th June 2015, 13:51
now it's freaking me out...
I removed my modified RGVS.dll and FLT.dll from plugin folder, and it just works, like suddenly, I mean, I didn't even call things from RGVS.dll or FLT.dll in the python script, that doesn't make any sense at all, how's that even possible? and even if I just call things from RGVS.dll/FLT.dll, preview in vseditor works perfectly without any problem, why?
anyways, script
import vapoursynth as vs
core = vs.get_core()
def nlmcleansef (src, local=2.4, nlocal=0.8):
core = vs.get_core ()
lflt = core.knlm.KNLMeansCL (src, d=0, a=24, s=1, h=local).knlm.KNLMeansCL (d=0, a=24, s=0, h=local)
ldif = core.std.MakeDiff (src, lflt).knlm.KNLMeansCL (d=0, a=2, s=4, h=local)
clip = core.std.MergeDiff (lflt, ldif).knlm.KNLMeansCL (d=0, a=24, s=4, h=nlocal)
return clip
clp = core.raws.Source("Y.rgb", 736, 480, src_fmt="GRAYS")
clp = nlmcleansef (clp)
clp.set_output ()
Memory corruption is funny like that. See if Visual Studio can tell you where it happens.
foxyshadis
25th June 2015, 04:22
Build everything in debug, especially VS. You'll find the culprit quickly enough.
feisty2
25th June 2015, 07:58
after failed to trace any error down in the code
I tried to compile the original removegrain code from the vaporsynth master branch
and the same vspipe crash showed it fucking unwanted self again.. :(
so the error actually comes from wrong compiling settings, what kind of special compiling parameter I gotta add to keep it from crashing?
feisty2
25th June 2015, 17:49
@Myrsloik
to find out what went wrong in float nnedi3 exactly, I decide to do something similar but somehow easier, adding 16bits support to eedi3
lucky me, I got the same problem here just like nnedi3
here are the differences between the original version and the incorrect 16bits version
https://github.com/IFeelBloated/eedi3/commit/d232f207e02dd53e8abf9c6261f729b7358694fa
some guide about what I did wrong, plz?
it might help me figure out what's the float nnedi3 problem and we'll have a high bitdepth eedi3 also :)
Myrsloik
25th June 2015, 18:16
@Myrsloik
to find out what went wrong in float nnedi3 exactly, I decide to do something similar but somehow easier, adding 16bits support to eedi3
lucky me, I got the same problem here just like nnedi3
here are the differences between the original version and the incorrect 16bits version
https://github.com/IFeelBloated/eedi3/commit/d232f207e02dd53e8abf9c6261f729b7358694fa
some guide about what I did wrong, plz?
it might help me figure out what's the float nnedi3 problem and we'll have a high bitdepth eedi3 also :)
I don't see anything obviously wrong in the code. You'll just have to step through it and see if something weird happens somewhere. Compare the behavior to the 8 bit version.
feisty2
26th June 2015, 05:34
aside from eedi3, I uninstalled r28 test1 and rolled back to r27, and vspipe crash is gone, it's somehow compatible to plugins compiled by vs2015 rc again...
feisty2
26th June 2015, 08:49
eedi3 16bits: guess I'm getting there, now the upper half of the image is good and the lower half is gone... like blank and all black..
damn, never thought programming would be painful like this..
chainik_svp
29th June 2015, 20:57
Myrsloik
I'm feeling very stupid to ask such a dumb question - but do you have a Windows build of mpv, compiled with VapourSynth support?
In other words - where can I find .lib/.dll files suitable for linking with gcc?
jackoneill
30th June 2015, 04:58
In other words - where can I find .lib/.dll files suitable for linking with gcc?
They're in the installer. Nothing keeps you from compiling your program with GCC. I didn't need the .lib file, even.
x86_64-w64-mingw32-g++ -o app.exe app.o -L/path/to/vsscriptdll -lvsscript
chainik_svp
30th June 2015, 09:54
C:/msys32/mingw32/lib/vapoursynth.lib: error adding symbols: File in wrong format
const VSAPI *vs = getVapourSynthAPI(VAPOURSYNTH_API_VERSION);
qDebug()<<"VS: "<<(vs!=0);
return 0;
g++ .... -L"C:\Program Files (x86)\VapourSynth\core32" -lvapoursynth
undefined reference to `_imp__getVapourSynthAPI@4'
What am I doing wrong?
jackoneill
30th June 2015, 21:18
C:/msys32/mingw32/lib/vapoursynth.lib: error adding symbols: File in wrong format
const VSAPI *vs = getVapourSynthAPI(VAPOURSYNTH_API_VERSION);
qDebug()<<"VS: "<<(vs!=0);
return 0;
g++ .... -L"C:\Program Files (x86)\VapourSynth\core32" -lvapoursynth
undefined reference to `_imp__getVapourSynthAPI@4'
What am I doing wrong?
Ugh. I'm revising my answer above: Nothing keeps you from compiling your program with GCC, if you're compiling a 64 bit program. If you're compiling a 32 bit program, apparently you need to create your own .lib files. (if someone knows why it's not the same for both, I would love to hear about it.)
For vsscript.dll this worked:
LIBRARY vsscript
EXPORTS
vsscript_clearEnvironment@4
vsscript_clearOutput@8
vsscript_clearVariable@8
vsscript_createScript@4
vsscript_evaluateFile@12
vsscript_evaluateScript@16
vsscript_finalize@0
vsscript_freeScript@4
vsscript_getCore@4
vsscript_getError@4
vsscript_getOutput@8
vsscript_getVSApi@0
vsscript_getVariable@12
vsscript_init@0
vsscript_setVariable@8
Save as vsscript.def and run
dlltool -d vsscript.def -l vsscript.lib
Link the resulting vsscript.lib into your application. You don't need to point ld to vsscript.dll.
For vapoursynth.dll, this .def file should work:
LIBRARY vapoursynth
EXPORTS
getVapourSynthAPI@4
This is annoying stuff. Have you considered creating only 64 bit applications?
chainik_svp
30th June 2015, 22:23
jackoneill
Have you actually tried to execute compiled binary?
Yeah, it links w/o errors, but gives "procedure entry point "getVapourSynthAPI@4" couldn't be located" at runtime
depends.exe shows that .exe asks for "getVapourSynthAPI@4" while the library contains "_getVapourSynthAPI@4"
You may think that adding "_" to the .def file could help? no :D it that case linking fails again
===============
The correct answer is:
dlltool --add-stdcall-underscore -d vsscript.def -l vsscript.lib
Now it works! :)
I wonder why it isn't included into "SDK"?
jackoneill
1st July 2015, 06:57
I tried to run it in Wine, but VapourSynth isn't installed there, so it only got as far as reporting that Python34.dll was missing. I'm glad you got it to work.
Pat357
20th July 2015, 15:02
jackoneill
The correct answer is:
dlltool --add-stdcall-underscore -d vsscript.def -l vsscript.lib
Now it works! :)
I wonder why it isn't included into "SDK"?
Thank you ! I was looking for this too ;-)
Do you need to link in both the vapoursynth.lib and the vsscript.lib ?
Can you show me how you do this linking ?
Thanks again, man !
jackoneill
21st July 2015, 20:38
Thank you ! I was looking for this too ;-)
Do you need to link in both the vapoursynth.lib and the vsscript.lib ?
Can you show me how you do this linking ?
Thanks again, man !
If you use VSScript, only vsscript.lib needs to be linked.
I think a command similar to this works:
g++ -o asdf.exe asdf.cpp -L. -lvsscript
Give -L the folder where vsscript.lib is.
Q3CPMA
30th July 2015, 04:31
Hello,
I tried to search in the thread, but I didn't find anything related. How are we supposed to process variable framerate videos?
jackoneill
30th July 2015, 07:52
Hello,
I tried to search in the thread, but I didn't find anything related. How are we supposed to process variable framerate videos?
That's a fairly vague question. Can you elaborate?
Q3CPMA
30th July 2015, 14:18
That's a fairly vague question. Can you elaborate?
Well, when using ffsm2 to open clips with variable framerate, it gives me a constant framerate in the end (only in the metadata, since the doc says that there's the same number of frame), so, how would I do to get the same framerate in the output file?
sneaker_ger
30th July 2015, 14:24
Raw video, Y4M etc. don't know about variable framerate. You have to save timecodes into external file using vspipe and load into encoder/muxer.
vspipe script.vpy - --y4m --timecodes timecodes.txt | x264 - --demuxer y4m --tcfile-in timecodes.txt -o output.mkv
(btw.: vspipe help is missing "--tcfile-in" part of x264)
I have not tested this:
1.) I don't know if ffms2 creates frame duration metadata
2.) I don't know if timecodes.txt is created immediately for use
At least in AviSynth ffms2 also has a parameter to create timecode file directly. I don't know if that parameter is available in the VapourSynth version. (And of course it would be useless in case you actually want to work with the frame duration metadata within VapourSynth)
Q3CPMA
30th July 2015, 15:20
Raw video, Y4M etc. don't know about variable framerate. You have to save timecodes into external file using vspipe and load into encoder/muxer.
vspipe script.vpy - --y4m --timecodes timecodes.txt | x264 - --demuxer y4m --tcfile-in timecodes.txt -o output.mkv
(btw.: vspipe help is missing "--tcfile-in" part of x264)
I have not tested this:
1.) I don't know if ffms2 creates frame duration metadata
2.) I don't know if timecodes.txt is created immediately for use
At least in AviSynth ffms2 also has a parameter to create timecode file directly. I don't know if that parameter is available in the VapourSynth version. (And of course it would be useless in case you actually want to work with the frame duration metadata within VapourSynth)
Thanks, I'll try. It would be cool to have a wrapper that transfer all metadata automatically into a matrovska container.
jackoneill
30th July 2015, 16:20
1) ffms2 does attach the frame duration to each frame.
2) The timecodes file is only complete after vspipe writes all the frames.
If sneaker_ger's command doesn't work, you'll have to pass the timecodes file to the muxer after x264 is done.
Q3CPMA
30th July 2015, 18:03
1) ffms2 does attach the frame duration to each frame.
2) The timecodes file is only complete after vspipe writes all the frames.
If sneaker_ger's command doesn't work, you'll have to pass the timecodes file to the muxer after x264 is done.
It worked perfectly, except the fact that I couldn't use a pipe.
vspipe script.vpy --y4m --timecodes tc.dat out.y4m
x264 out.y4m --demuxer y4m --tcfile-in tc.dat -o out.mkv
did the trick.
sneaker_ger
30th July 2015, 18:19
Yes, like jackoneill said timecode file is not ready at start of conversion (when x264 needs it), so my example does not work.
You could do like he suggested without having to save huge y4m file:
vspipe script.vpy --y4m --timecodes tc.dat - | x264 - --demuxer y4m -o es.264
mkvmerge -o out.mkv --timecodes "0:tc.dat" es.264
(but since x264 does not have timecodes it cannot do things like framerate aware CRF if you care about that)
Q3CPMA
30th July 2015, 19:07
Actually, this doesn't work well. I have two problems:
- The output video is offset by -0.217s
- I have random passages where I get garbled frame order and/or frame repetition. Original segment (http://104.233.78.12/share/original.mp4), garbled segment (http://104.233.78.12/share/vapoursynth.mp4). (I hope it's okay with the rules; it's only a less than 2s segment :scared:). I insist on the fact that this problem appears randomly.
I also tried with the mkvmerge method, still fucked.
sneaker_ger
30th July 2015, 19:22
Can you test latest RC?
http://forum.doom9.org/showpost.php?p=1724748&postcount=2088
Q3CPMA
30th July 2015, 19:45
Can you test latest RC?
http://forum.doom9.org/showpost.php?p=1724748&postcount=2088
I can't since I'm not on Windows. Tried with the latest git, and the second problem is still here. Well, only the second one, at least.
Q3CPMA
30th July 2015, 19:47
Maybe it's time to hit the ffms2 bug tracker.
ZMachine95
2nd August 2015, 08:19
Hi guys, I have the exact same problem of Q3CPMA.
Randomly on certain film it happens the same thing... I use always Blu-Ray Source and I noticed that happens randomly.
I used Lsmash and ffm2 and both have random problem but NOT IN THE SAME VIDEOS.
The strange thing is that if I extract the passage when it start to get offset and repeat frames (with AVC it simply repeat frames, when with HEVC it completely ruin the video from the beginning getting an effect of slowmo with frames repeated quickly with a "disco effect") and encode from my pc (same source, plugins, version, script and encoding params) the output is PERFECT.
Now I will try to encode the same file from the beginning in my pc and see if the problem show up. If it doesn't I cannot find a real cause for the problem.
I use latest versions of alll plugins and Vapoursynth R27 (64bit). Latest cli build of x264 and x265.
jackoneill
2nd August 2015, 10:15
Hi guys, I have the exact same problem of Q3CPMA.
Randomly on certain film it happens the same thing... I use always Blu-Ray Source and I noticed that happens randomly.
I used Lsmash and ffm2 and both have random problem but NOT IN THE SAME VIDEOS.
The strange thing is that if I extract the passage when it start to get offset and repeat frames (with AVC it simply repeat frames, when with HEVC it completely ruin the video from the beginning getting an effect of slowmo with frames repeated quickly with a "disco effect") and encode from my pc (same source, plugins, version, script and encoding params) the output is PERFECT.
Now I will try to encode the same file from the beginning in my pc and see if the problem show up. If it doesn't I cannot find a real cause for the problem.
I use latest versions of alll plugins and Vapoursynth R27 (64bit). Latest cli build of x264 and x265.
Do you get the same broken output if you run the same commands with the same input a second time?
Also for Q3CPMA: put core.text.FrameNum right after the source filter and see what frame numbers come out at the end.
Q3CPMA
3rd August 2015, 01:29
Do you get the same broken output if you run the same commands with the same input a second time?
Also for Q3CPMA: put core.text.FrameNum right after the source filter and see what frame numbers come out at the end.
The frame count isn't disrupted during the fuckup. What does it mean? That the timecode file is wrong?
jackoneill
3rd August 2015, 08:06
The frame count isn't disrupted during the fuckup. What does it mean? That the timecode file is wrong?
It means that whatever goes wrong happens in the source filter, not in VapourSynth and not in x264.
Q3CPMA
3rd August 2015, 15:23
It means that whatever goes wrong happens in the source filter, not in VapourSynth and not in x264.
Wait, it seem that using both ffms2-git and the mkvmerge method solve it.
Now, does anyone know when the imagemagick plugin will support the HDRI version? Most distro distribute this version :( .
Nevermind, managed to reproduce it.
jose1711
6th August 2015, 20:45
hi, i am getting the following issue with a particular dv video (for others it works fine):
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0xb1001b40 (LWP 11289)]
[New Thread 0xb1802b40 (LWP 11288)]
[New Thread 0xb29b3b40 (LWP 11287)]
[New Thread 0xb2003b40 (LWP 11286)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb1001b40 (LWP 11289)]
0xb7d65740 in __memcpy_ssse3 () from /usr/lib/libc.so.6
(gdb) bt
#0 0xb7d65740 in __memcpy_ssse3 () from /usr/lib/libc.so.6
#1 0xb70deeb9 in vs_bitblt(void*, int, void const*, int, int, int) () from /usr/lib/libffms2.so.4.0.0
#2 0xb70e08e6 in VSVideoSource::OutputFrame(FFMS_Frame const*, VSFrameRef*, VSAPI const*) ()
from /usr/lib/libffms2.so.4.0.0
#3 0xb70dfa14 in VSVideoSource::GetFrame(int, int, void**, void**, VSFrameContext*, VSCore*, VSAPI const*) ()
from /usr/lib/libffms2.so.4.0.0
#4 0xb7540d78 in VSNode::getFrameInternal(int, int, VSFrameContext&) () from /usr/lib/libvapoursynth.so
#5 0xb754f72a in VSThreadPool::runTasks(VSThreadPool*, std::atomic<bool>&) () from /usr/lib/libvapoursynth.so
#6 0xb75506d0 in std::thread::_Impl<std::_Bind_simple<void (*(VSThreadPool*, std::reference_wrapper<std::atomic<bool> >))(VSThreadPool*, std::atomic<bool>&)> >::_M_run() () from /usr/lib/libvapoursynth.so
#7 0xb7eadaee in std::(anonymous namespace)::execute_native_thread_routine (__p=0xb2d00544)
at /build/gcc/src/gcc-5.2.0/libstdc++-v3/src/c++11/thread.cc:84
#8 0xb793f1c3 in start_thread () from /usr/lib/libpthread.so.0
#9 0xb7d24e8e in clone () from /usr/lib/libc.so.6
test.vpy:
import vapoursynth as vs
import havsfunc as haf
core = vs.get_core()
ret = core.ffms2.Source(source=sourcefile)
ret = haf.QTGMC( ret, Preset='Placebo', TFF=True)
ret.set_output()
vapoursynth-git r27.38.gf2e10bb
ffms2-git 2.21.32.gd7dd577
thank you for any hints,
jose
Myrsloik
6th August 2015, 20:47
hi, i am getting the following issue with a particular dv video (for others it works fine):
...
1. Does it still crash if you don't use QTGMC?
2. I need a sample that makes it crash
jose1711
6th August 2015, 21:05
1. yes, it crashes even when qtgmc line is removed
2. sample will be provided via dropbox (link in pm)
jose1711
8th August 2015, 10:48
@Myrsloik: just curious, have you been able to retrieve the sample video?
Windy Core
10th August 2015, 17:20
Hi
I come across a strange problem
When I tried to load a native vapoursynth plugin like this
import vapoursynth as vs
core = vs.get_core()
core.std.LoadPlugin('C:/f3kdb.dll')
It always get error:
Failed to evaluate the script:
Python exception: Failed to load C:/f3kdb.dll
Traceback (most recent call last):
File "vapoursynth.pyx", line 1467, in vapoursynth.vpy_evaluateScript (src\cython\vapoursynth.c:24719)
File "", line 4, in <module>
File "vapoursynth.pyx", line 1366, in vapoursynth.Function.__call__ (src\cython\vapoursynth.c:23214)
vapoursynth.Error: Failed to load C:/f3kdb.dll
I tried a lot of plugins and found that none of native vapoursynth plugin can be load.
The version of vapoursynth is R27,and the version of python is 3.4.3
Though it can't load native plugins,it still can load avisynth plugins by "core.avs.LoadPlugin" and work well with them.
I search a lot but found nothing about such problem.So I can only ask for help here.Can somebody tell me what's going on and how to solved it?
~ VEGETA ~
11th August 2015, 12:32
I get this:
Failed to initialize VapourSynth
I have Windows 7 x64 (on a dedi server). I tried this with the editor and the shell but still no use.
my script is just the one that prints the core version. I use the R27 official binary.
~ VEGETA ~
11th August 2015, 19:57
Now I put this:
import sys
import vapoursynth as vs
core = vs.get_core()
core.std.LoadPlugin(r'C:\Program Files (x86)\VapourSynth\plugins32\ffms2.dll')
it outputs:
Failed to evaluate the script:
Python exception: Failed to load C:\Program Files (x86)\VapourSynth\plugins32\ffms2.dll
Traceback (most recent call last):
File "vapoursynth.pyx", line 1467, in vapoursynth.vpy_evaluateScript (src\cython\vapoursynth.c:24719)
File "C:/Users/VEGETA/Desktop/Untitled.vpy", line 4, in <module>
core.std.LoadPlugin(r'C:\Program Files (x86)\VapourSynth\plugins32\ffms2.dll')
File "vapoursynth.pyx", line 1366, in vapoursynth.Function.__call__ (src\cython\vapoursynth.c:23214)
vapoursynth.Error: Failed to load C:\Program Files (x86)\VapourSynth\plugins32\ffms2.dll
I know I haven't set an output, but I did and no use. It doesn't load the native plugins.
Are_
11th August 2015, 20:23
What about...
import sys
import vapoursynth as vs
core = vs.get_core()
core.std.LoadPlugin(r'C:\Program Files (x86)\VapourSynth\plugins32\ffms2.dll')
... or the actuall name of the dll?
~ VEGETA ~
11th August 2015, 20:29
Are_
I put it as you did, I just didn't copy it here properly.
I have loaded it as avs and it worked greatly... However, when loaded as vs (std) it doesn't.
Windy Core
11th August 2015, 22:25
It seems that ~ VEGETA ~ faced the same problem as mine
I tried the Vapoursynth R20 with Python 3.3.5
To my suprise, it work.The problem occured on R27 didn't appear on R20.
But maybe R20 is too old for some plugins
When I tried to load BM3D and flash3kyuu_deband, it always say
Failed to evaluate the script:
Python exception: 'Core only supports API R3 but the loaded plugin uses API R196610'
Traceback (most recent call last):
File "vapoursynth.pyx", line 1060, in vapoursynth.vpy_evaluateScript (src\cython\vapoursynth.c:16489)
File "", line 4, in <module>
File "vapoursynth.pyx", line 983, in vapoursynth.Function.__call__ (src\cython\vapoursynth.c:15542)
vapoursynth.Error: 'Core only supports API R3 but the loaded plugin uses API R196610'
I also tried the version above R24,but same problem come again,all native vapoursynth plugins can't be loaded while avs plugins can be load normally.
Failed to evaluate the script:
Python exception: Failed to load C:/f3kdb.dll
Traceback (most recent call last):
File "vapoursynth.pyx", line 1467, in vapoursynth.vpy_evaluateScript (src\cython\vapoursynth.c:24719)
File "", line 4, in <module>
File "vapoursynth.pyx", line 1366, in vapoursynth.Function.__call__ (src\cython\vapoursynth.c:23214)
vapoursynth.Error: Failed to load C:/f3kdb.dll
I also tried on my friend's computer.The same python, same vapoursynth, same script,same plugins, but there is no problem at all.Everything seems good on his PC.
This confuse me a lot.
foxyshadis
12th August 2015, 08:42
vapoursynth.Error: 'Core only supports API R3 but the loaded plugin uses API R196610'This means either "You have to update VapourSynth to run this plugin" or "You have to fix your plugin." It looks like the memory is corrupted, so I'd try loading only f3kdb, no BM3D and no video, nothing but the core= and LoadPlugin lines, and see if that changes the error.
Actually, what download are you using? There are several floating around, from the official release (https://github.com/SAPikachu/flash3kyuu_deband/releases) to a build from a few months ago (https://forum.doom9.org/showthread.php?p=1712577#post1712577). That might help narrow down the problem.
jackoneill
12th August 2015, 10:21
Windy Core and VEGETA: here is a vapoursynth.dll (win32 (http://ulozto.net/xqCDFLhn/vapoursynth-dll-f2e10bb3-loadplugin-fail-win32-7z) | win64 (http://ulozto.net/xC2yWeZv/vapoursynth-dll-f2e10bb3-loadplugin-fail-win64-7z)) that should provide more information than just "failed to load f3kdb.dll". Just replace the vapoursynth.dll found in Python's site-packages and type this in a Python prompt:
import vapoursynth as vs
c = vs.get_core()
c.std.LoadPlugin(r'C:\f3kdb.dll') # Or some other native plugin.
The last line won't be needed if get_core() already prints some error messages from the autoloaded plugins.
This means either "You have to update VapourSynth to run this plugin" or "You have to fix your plugin." It looks like the memory is corrupted, so I'd try loading only f3kdb, no BM3D and no video, nothing but the core= and LoadPlugin lines, and see if that changes the error.
Actually, what download are you using? There are several floating around, from the official release (https://github.com/SAPikachu/flash3kyuu_deband/releases) to a build from a few months ago (https://forum.doom9.org/showthread.php?p=1712577#post1712577). That might help narrow down the problem.
The weird version number is likely not memory corruption. The API version gained a "minor" part at some point in the last few releases. Older VapourSynth releases don't know the "major" part is now in the higher bytes of the version number.
foxyshadis
12th August 2015, 11:26
The weird version number is likely not memory corruption. The API version gained a "minor" part at some point in the last few releases. Older VapourSynth releases don't know the "major" part is now in the higher bytes of the version number.
Makes sense, the f3kdb repo still hosts the old vs.h, while the new build (without source) must use the new header. I'll update mine, then, since they still pass VERSION as 3.
Windy Core
12th August 2015, 11:47
What version of operating system are you using? Do the official included plugins (under core32/plugins and core64/plugins) can't be autoloaded as well?
My OS is windows 7.Yes,all offical included plugins can't be autoloaded
Windy Core and VEGETA: here is a vapoursynth.dll (win32 | win64) that should provide more information than just "failed to load f3kdb.dll". Just replace the vapoursynth.dll found in Python's site-packages and type this in a Python prompt
get_core() print error:
Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 24 2015, 22:44:40) [MSC v.1600 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import vapoursynth as vs
>>> c = vs.get_core()
Failed to load library 'C:\Program Files (x86)\VapourSynth\core64\plugins\assvapour.dll'. Error code: 87. Error message:
Failed to load library 'C:\Program Files (x86)\VapourSynth\core64\plugins\avisource.dll'. Error code: 87. Error message:
Failed to load library 'C:\Program Files (x86)\VapourSynth\core64\plugins\EEDI3.dll'. Error code: 87. Error message:
Failed to load library 'C:\Program Files (x86)\VapourSynth\core64\plugins\genericfilters.dll'. Error code: 87. Error message:
Failed to load library 'C:\Program Files (x86)\VapourSynth\core64\plugins\libhistogram.dll'. Error code: 87. Error message:
Failed to load library 'C:\Program Files (x86)\VapourSynth\core64\plugins\libtemporalsoften.dll'. Error code: 87. Error message:
Failed to load library 'C:\Program Files (x86)\VapourSynth\core64\plugins\RemoveGrainVS.dll'. Error code: 87. Error message:
Failed to load library 'C:\Program Files (x86)\VapourSynth\core64\plugins\Vinverse.dll'. Error code: 87. Error message:
Failed to load library 'C:\Program Files (x86)\VapourSynth\core64\plugins\VIVTC.dll'. Error code: 87. Error message:
Failed to load library 'C:\Program Files (x86)\VapourSynth\plugins64\AddGrain.dll'. Error code: 87. Error message:
Failed to load library 'C:\Program Files (x86)\VapourSynth\plugins64\BM3D.dll'. Error code: 87. Error message:
Failed to load library 'C:\Program Files (x86)\VapourSynth\plugins64\flash3kyuu_deband.dll'. Error code: 87. Error message:
Failed to load library 'C:\Program Files (x86)\VapourSynth\plugins64\libmvtools.dll'. Error code: 87. Error message:
Failed to load library 'C:\Program Files (x86)\VapourSynth\plugins64\libnnedi3.dll'. Error code: 87. Error message:
Failed to load library 'C:\Program Files (x86)\VapourSynth\plugins64\vslsmashsource.dll'. Error code: 87. Error message:
>>>
Myrsloik
12th August 2015, 12:35
My OS is windows 7.Yes,all offical included plugins can't be autoloaded
get_core() print error:
Did you install all windows updates? This one may be required to make it work: https://support.microsoft.com/en-us/kb/2533623
Windy Core
12th August 2015, 16:00
Did you install all windows updates? This one may be required to make it work: https://support.microsoft.com/en-us/kb/2533623
It work.Thank you Myrsloik
And thanks jackoneill and HolyWu for your help.
Well I have learn a valuable lesson that I should install updates of OS in time.
~ VEGETA ~
12th August 2015, 21:13
Windy Core and VEGETA: here is a vapoursynth.dll (win32 (http://ulozto.net/xqCDFLhn/vapoursynth-dll-f2e10bb3-loadplugin-fail-win32-7z) | win64 (http://ulozto.net/xC2yWeZv/vapoursynth-dll-f2e10bb3-loadplugin-fail-win64-7z)) that should provide more information than just "failed to load f3kdb.dll". Just replace the vapoursynth.dll found in Python's site-packages and type this in a Python prompt:
import vapoursynth as vs
c = vs.get_core()
c.std.LoadPlugin(r'C:\f3kdb.dll') # Or some other native plugin.
The last line won't be needed if get_core() already prints some error messages from the autoloaded plugins.
this happens:
Traceback (most recent call last):
File "<pyshell#0>", line 1, in <module>
import vapoursynth as vs
ImportError: DLL load failed: The specified procedure could not be found.
it is when I do what you said.
I am using windows 7 32 bit (the one I tried this on) and have a dedicated server running windows 7 64 bit (didn't try it on it yet).
jackoneill
20th August 2015, 19:07
I installed everything but when running wibbly I get:
______________
The procedure entry point vsscript_creatscript@4 could not be located in the dynamic link library vsscript.dll
______________
and the same for wobbly. but @8 rather than @4.
All right. Here are some random questions, in the hope that one of them is the right one:
This is a 32 bit Windows 7, yes?
Which version of VapourSynth did you install?
Does the same thing happen with r27 and this r28-test1 (https://www.dropbox.com/s/wecntdf9xve68qc/vapoursynth-r28-test1.exe?dl=1)? What about r26?
Did you change anything at all in the installer, like the destination path?
Can you verify that vspipe.exe, vsscript.dll, vapoursynth.dll (both copies), vapoursynth.pyd, and your Python installation are all 32 bit? Perhaps the Properties window tells you this. If not, Dependency Walker tells you, in the "CPU" column. Where is each of these located? While you're there, Dependency Walker can tell you if your copy of vsscript.dll has the function that the error message is complaining about.
Does this KB2533623 (https://support.microsoft.com/en-us/kb/2533623) magically fix everything, if it's not installed already?
~ VEGETA ~
20th August 2015, 19:37
All right. Here are some random questions, in the hope that one of them is the right one:
This is a 32 bit Windows 7, yes?
Which version of VapourSynth did you install?
Does the same thing happen with r27 and this r28-test1 (https://www.dropbox.com/s/wecntdf9xve68qc/vapoursynth-r28-test1.exe?dl=1)? What about r26?
Did you change anything at all in the installer, like the destination path?
Can you verify that vspipe.exe, vsscript.dll, vapoursynth.dll (both copies), vapoursynth.pyd, and your Python installation are all 32 bit? Perhaps the Properties window tells you this. If not, Dependency Walker tells you, in the "CPU" column. Where is each of these located? While you're there, Dependency Walker can tell you if your copy of vsscript.dll has the function that the error message is complaining about.
Does this KB2533623 (https://support.microsoft.com/en-us/kb/2533623) magically fix everything, if it's not installed already?
Well, installing VS-r26-test1 worked well regarding previous problem of being unable to load native plugins... Now it does!
this script worked well:
import sys
import vapoursynth as vs
core = vs.get_core()
#core.std.LoadPlugin(r'D:\plugins32\ffms2.dll')
a = core.ffms2.Source(r'C:/video.mkv')
a = core.f3kdb.F3kdb(a, y=49, output_depth=10, dither_algo=2)
a.set_output()
However, the problem I reported regarding Wobbly still exactly the same.
About your questions, here are my answers:
1- I run Windows 7 32-bit. (My dedicated server Windows 7 60-bit, but didn't try r28 on it yet. Probably it will work)
2- Now it is r28. previously official r27. Didn't try anything else.
3- As I said above, loading native plugins now works well. The other problem of Wobbly didn't change. didn't try 26.
4- Did not change anything.
5- Hmm... vsscript.dll is located in system32. In properties window of vspipe.exe, it shows the options of Windows XP which indicates it is 32-bit (unless this info is wrong). Python is 32-bit.
Could not check the .dll files, but as I said above, it ran a script very well... So they must be 32-bit.
jackoneill
20th August 2015, 20:05
Ah, so VapourSynth is working correctly on your device now...
~ VEGETA ~
20th August 2015, 20:13
Ah, so VapourSynth is working correctly on your device now...
Yes. I ran the script shown above which previously didn't work at all.
~ VEGETA ~
21st August 2015, 22:18
I've tested the exact same VS-R28 on Windows 7 x64-bit (server), but it turns out it has the same problem.
it gives back:
Failed to evaluate the script:
Python exception: No attribute with the name ffms2 exists. Did you mistype a plugin namespace?
Traceback (most recent call last):
File "vapoursynth.pyx", line 1467, in vapoursynth.vpy_evaluateScript (src\cython\vapoursynth.c:24719)
File "PATH\Untitled.vpy", line 4, in <module>
v = core.ffms2.Source(PATH/[SS] Dragon Ball 1-28 (Son Gokū Arc)(DVD.AAC)/[SS] DB - 01 (DVD.AAC)[68AED4FF].mkv')
File "vapoursynth.pyx", line 1088, in vapoursynth.Core.__getattr__ (src\cython\vapoursynth.c:18921)
AttributeError: No attribute with the name ffms2 exists. Did you mistype a plugin namespace?
the script:
import sys
import vapoursynth as vs
core = vs.get_core()
v = core.ffms2.Source(PATH/[SS] Dragon Ball 1-28 (Son Gokū Arc)(DVD.AAC)/[SS] DB - 01 (DVD.AAC)[68AED4FF].mkv')
v.set_output()
so the new VS-R28 solved the problem of not loading native plugins on windows 7 32-bit, but it is not solved in windows 7 64-bit.
jackoneill
21st August 2015, 22:36
Install https://support.microsoft.com/en-us/kb/2533623 and try again.
~ VEGETA ~
22nd August 2015, 02:48
Install https://support.microsoft.com/en-us/kb/2533623 and try again.
That worked perfectly, thanks for your continuous efforts. So now with that Windows update and VS-R28... it should work on 32-bit and 64-bit Windows 7 (It is for me).
~ VEGETA ~
22nd August 2015, 03:50
I'd like to run some speed comarisions with AVS, can you tell me the best method (fair)? I am using x264 right now but for avs it is just ffvideosource and feed the script directly into x264. However, for VS there is the vspipe stuff which is an extra... So the comparision is not fair I think.
~ VEGETA ~
22nd August 2015, 12:34
I have used x264-32bit-8bit-tmod to do some comparison...
Settings:
10-bit SD source (24 min)
x264 with no options [Defaults]
script: ffms2 source + f3kdb
Result:
vs : fps=81.42 - duration=0:06:06
avs: fps=78.19 - duration=0:06:21
x264 tried vsimport but failed, it tried avisource and succeeded. I wonder why?
Is there any faults in this method of comparison? I ask because I got different file size in both methods.
tona69
22nd August 2015, 23:15
Hi, in Vapoursynth R27-R28 when I want to use subtitles, mark this error
Fontconfig error: Cannot load default config file
import vapoursynth as vs
core = vs.get_core( )
outClip = core.std.BlankClip( width=1280, height=720, format=vs.YUV420P8, length=10, fpsnum=24000, fpsden=1001, color=[255, 127, 127] )
subs = core.assvapour.AssRender( outClip, file="video.ass" )
subs[0] = core.resize.Bicubic( subs[0], format=vs.YUV420P8 )
outClip = core.std.MaskedMerge(outClip, subs[0], subs[1])
outClip.set_output( )
video.ass
[Script Info]
; Script generated by Aegisub 3.2.0
; http://www.aegisub.org/
Title: Default Aegisub file
ScriptType: v4.00+
WrapStyle: 0
ScaledBorderAndShadow: yes
YCbCr Matrix: None
PlayResX: 1280
PlayResY: 720
[Aegisub Project Garbage]
Last Style Storage: Default
Video File: ?dummy:23.976000:40000:1280:720:215:215:215:c
Video AR Value: 1.777778
Video Zoom Percent: 0.531944
Active Line: 2
[V4+ Styles]
Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour, OutlineColour, BackColour, Bold, Italic, Underline, StrikeOut, ScaleX, ScaleY, Spacing, Angle, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR, MarginV, Encoding
Style: Default,Arial,50,&H00FFFFFF,&H000000FF,&H00000000,&H00000000,0,0,0,0,100,100,0,0,1,4,0,5,10,10,10,1
[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:00:00.00,0:00:00.39,Default,,0,0,0,,{\move(235,70,135,640,0,375)}move1
Dialogue: 0,0:00:00.00,0:00:00.39,Default,,0,0,0,,{\t(\fscx75\fscy75\bord3)\move(630,70,530,640,0,375)}move2
Dialogue: 0,0:00:00.00,0:00:00.39,Default,,0,0,0,,{\org(235,70)\pos(1125,70)\t(\frz-40\fscx125\fscy125\bord5)}move3
vspipe -y video.vpy - | x264 --crf 18 --output video.mp4 --demuxer y4m -
jackoneill
23rd August 2015, 05:58
Hi, in Vapoursynth R27-R28 when I want to use subtitles, mark this error
Is it fatal?
stax76
29th August 2015, 18:35
Hello Myrsloik,
Windows-1252 covered characters ä, ü and ö in source filenames cause an exception.
https://en.wikipedia.org/wiki/Windows-1252
Python exception: 'utf-8' codec can't decode byte 0xe4 in position 192: invalid continuation byte
Traceback (most recent call last):
File "vapoursynth.pyx", line 1466, in vapoursynth.vpy_evaluateScript (src\cython\vapoursynth.c:24692)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe4 in position 192: invalid continuation byte
clip = core.ffms2.Source(source = r'D:\Temp\Encoding\häh.mp4', cachefile = r'D:\Temp\Encoding\häh temp files\häh.ffindex')
sneaker_ger
29th August 2015, 18:37
Save your script as UTF-8?
stax76
29th August 2015, 20:22
Save your script as UTF-8?
produces a different error:
Python exception: invalid character in identifier (häh_Source.vpy, line 1)
Traceback (most recent call last):
File "vapoursynth.pyx", line 1466, in vapoursynth.vpy_evaluateScript (src\cython\vapoursynth.c:24705)
File "D:\Temp\Encoding\häh temp files\häh_Source.vpy", line 1
import vapoursynth as vs
^
SyntaxError: invalid character in identifier
clip = core.ffms2.Source(source = r'D:\Temp\Encoding\häh.mp4', cachefile = r'D:\Temp\Encoding\häh temp files\häh.ffindex')
sneaker_ger
29th August 2015, 20:28
Save as UTF-8 without BOM.
foxyshadis
29th August 2015, 22:20
That's odd, python can read source files with a BOM just fine, so the same script will work on the command-line. VS should probably trap this exception in vpy_evaluateScript and retry with script.decode('utf-8-sig'). (And perhaps the user's default locale, but discouraging the use of code pages as much as possible in every form is probably wise.)
Myrsloik
29th August 2015, 22:28
That's odd, python can read source files with a BOM just fine, so the same script will work on the command-line. VS should probably trap this exception in vpy_evaluateScript and retry with script.decode('utf-8-sig'). (And perhaps the user's default locale, but discouraging the use of code pages as much as possible in every form is probably wise.)
Judging by the description only using utf-8-sig should always do the right thing. Correct me of I'm wrong.
stax76
29th August 2015, 22:30
Save as UTF-8 without BOM.
works! :)
foxyshadis
29th August 2015, 23:04
Judging by the description only using utf-8-sig should always do the right thing. Correct me of I'm wrong.
Looks like it. Double-checked the source and it does handle it either way.
Kupildivan
30th August 2015, 12:04
Is there compiled FFT3DFilter.dll for VS?
feisty2
30th August 2015, 12:06
fft3d is old and obsolete cuz dfttest kicks its ass.
Kupildivan
30th August 2015, 12:13
Forgot to mention, dfttest is too slow for me. That's why I ask.
feisty2
30th August 2015, 12:21
then, no.
no one seems to, well, want to port fft3d...
but, you can pick smaller sb/so/tb/tosize values and speed dfttest up.
Kupildivan
30th August 2015, 12:33
OK then. Thanks for info.
Reel.Deel
30th August 2015, 13:23
no one seems to, well, want to port fft3d...
VFR-maniac ported FFT3DFilter (https://github.com/VFR-maniac/VapourSynth-FFT3DFilter) (along with a few other plugins (https://github.com/VFR-maniac?tab=repositories)) but as usual he did not release any binaries.
feisty2
30th August 2015, 13:37
VFR-maniac ported FFT3DFilter (https://github.com/VFR-maniac/VapourSynth-FFT3DFilter) (along with a few other plugins (https://github.com/VFR-maniac?tab=repositories)) but as usual he did not release any binaries.
http://i.imgur.com/D6id5Us.png
got not much luck with it :)
Are_
30th August 2015, 14:45
It compiles just fine with gcc.
feisty2
30th August 2015, 14:49
It compiles just fine with gcc.
then you should probably post the binaries and do Kupildivan a favor :)
I'm just too newbie to be a gcc guy
Are_
30th August 2015, 20:18
Also I think Linux binaries will not be much useful to him. :/
Myrsloik
4th September 2015, 12:10
Don't forget to install all updates. Here's a friendly reminder. (http://www.vapoursynth.com/2015/09/windows-update-use-it/)
Myrsloik
5th September 2015, 17:25
Now for a small poll. Should the next version be compiled for python 3.4 or 3.5?
This of course assumes python 3.5 will be released by then. It's probably less than a week away.
stax76
5th September 2015, 18:23
I would prefer 3.5.
Khanattila
6th September 2015, 00:21
Unfortunately VS-FFT3DFilter's processing is single-threaded, which make it not significantly faster than DFTTest. More importantly, it supports only 8-bit input and will introduce banding after denoising. I'd recommend KNLMeans as one of the other choices if he has a decent GPU.
Without offending anyone, I'd recommend always KNLMeans :rolleyes:
Sparktank
6th September 2015, 00:39
python 3.4 or 3.5?
I remember some time before when I first tried to install, VS was done using older python and I had already installed newest updates for python. I had decided to wait for VS to update to newest python, but by then a lot of time had passed and I forgot.
So, I would vote for the newest python, 3.5.
Anyone new looking into VS will be off to a very fresh start, as fresh as possible, at least.
feisty2
6th September 2015, 07:45
3.5, always not a bad thing tryna stay update
Myrsloik
8th September 2015, 22:00
Here's R28 test 2 (https://dl.dropboxusercontent.com/u/73468194/vapoursynth-r28-test2.exe).
WARNING! The VS2015 runtime needs to be installed manually for now
Note that this build was made with VS2015 and without tcmalloc. Speed comparisons to R27 would be interesting to see. Apart from the compiler switch it's more or less purely a bugfix release.
r28:
get_core() can now be used in callbacks and other external functions in python
now returns an error message saying that windows needs to be updated in certain cases when plugin loading fails
fixed loop filter (nodame)
lut and lut2 can now output float as well
now accepts scripts that start with a BOM as well
fixed an image corruption bug with 9-16 bit input to rgvs when the c++ code is used
fixed division by zero issues in muldivrational in vshelper.h
blankclip can now create 0 (unknown/variable) fps clips
added float support to planedifference and planeaverage
added half support to addborders
relevant compile time options are now in the version string
Still uses python 3.4 obviously.
mastrboy
11th September 2015, 19:50
How do one use a similar function to avisynths import() ?
I tried the "python way": exec(open('filter.vpy').read()) but that just resulted in a error message: Unhandled C++ Exception...
Edit: Nevermind, I forgot to remove the source filter from the filter.vpy template, now it works...
Myrsloik
11th September 2015, 20:11
How do one use a similar function to avisynths import() ?
I tried the "python way": exec(open('filter.vpy').read()) but that just resulted in a error message: Unhandled C++ Exception...
Edit: Nevermind, I forgot to remove the source filter from the filter.vpy template, now it works...
How did you get the unhandled C++ exception? If you can describe it and provide the exact scripts you used it'd help a lot. It should never crash because of python exec...
mastrboy
11th September 2015, 20:18
How did you get the unhandled C++ exception? If you can describe it and provide the exact scripts you used it'd help a lot. It should never crash because of python exec...
Here here was my ep01.vpy
import vapoursynth as vs
core = vs.get_core(threads=8)
vid = core.avisource.AVIFileSource('I:/ep01.avs')
exec(open('filter.vpy').read())
and here was my filter.vpy when it crashed:
import vapoursynth as vs
core = vs.get_core(threads=8)
vid = core.avisource.AVIFileSource('I:/filter.avs')
vid = core.resize.Spline(clip=vid, width=960, height=540)
super = core.mv.Super(vid)
mvbw3 = core.mv.Analyse(super, isb=True, delta=3, overlap=4,blksize=8)
mvbw2 = core.mv.Analyse(super, isb=True, delta=2, overlap=4,blksize=8)
mvbw = core.mv.Analyse(super, isb=True, delta=1, overlap=4,blksize=8)
mvfw = core.mv.Analyse(super, isb=False, delta=1, overlap=4,blksize=8)
mvfw2 = core.mv.Analyse(super, isb=False, delta=2, overlap=4,blksize=8)
mvfw3 = core.mv.Analyse(super, isb=False, delta=3, overlap=4,blksize=8)
out = core.mv.Degrain3(clip=vid, super=super, mvbw=mvbw, mvfw=mvfw, mvbw2=mvbw2, mvfw2=mvfw2, mvbw3=mvbw3, mvfw3=mvfw3, thsad=275)
#out = core.hist.Luma(clip=out)
out.set_output()
ep01.avs is:
DGsource("ep01.dgi")
As you can see, I forgot to comment some stuff out in filter.vpy when it crashed, also filter.avs did not exist since I renamed that to ep01.avs
cybersharky
13th September 2015, 09:56
What python path's are needed to install vapoursynth? What registry locations does the installer check?
On attempting to install I get:
https://photos-4.dropbox.com/t/2/AACZw7bGXksnp_Ji-gOSp3oxxr_FosnShSSGLvOiWlcu6Q/12/47490038/png/32x32/1/_/1/2/Screenshot%202015-09-13%2010.44.52.png/EP7stSQYzh4gAigC/lgyts8TZNo7z2lRBYEcs2Ux4qn3xsUTJAIVBAPXKQLI?size=1280x960&size_mode=2
my user and system paths start with:
C:\Python34\;C:\Python34\Scripts;
but they do also have:
C:\Enthought\Canopy32\User;C:\Enthought\Canopy32\User\Scripts;
I need Canopy's python 2 version for courses I'm doing.
Yes, I have installed python 3.4.3 for all users.
I'm on Windows 8.1 x64, all the latest updates installed.
Are_
13th September 2015, 11:13
We can't see your image because it looks like it's not public.
Myrsloik
13th September 2015, 11:25
What python path's are needed to install vapoursynth? What registry locations does the installer check?
On attempting to install I get:
https://photos-4.dropbox.com/t/2/AACZw7bGXksnp_Ji-gOSp3oxxr_FosnShSSGLvOiWlcu6Q/12/47490038/png/32x32/1/_/1/2/Screenshot%202015-09-13%2010.44.52.png/EP7stSQYzh4gAigC/lgyts8TZNo7z2lRBYEcs2Ux4qn3xsUTJAIVBAPXKQLI?size=1280x960&size_mode=2
my user and system paths start with:
C:\Python34\;C:\Python34\Scripts;
but they do also have:
C:\Enthought\Canopy32\User;C:\Enthought\Canopy32\User\Scripts;
I need Canopy's python 2 version for courses I'm doing.
Yes, I have installed python 3.4.3 for all users.
I'm on Windows 8.1 x64, all the latest updates installed.
It check for HKCU/HKLM(32/64) SOFTWARE\Python\PythonCore\3.4\InstallPath. The standard keys written by the python installer.
cybersharky
13th September 2015, 12:39
It check for HKCU/HKLM(32/64) SOFTWARE\Python\PythonCore\3.4\InstallPath. The standard keys written by the python installer.
Thanks deleted the 64 bit references and was able to install vapoursynth :)
hajj_3
14th September 2015, 07:40
python 3.5.0 is out now.
~ VEGETA ~
14th September 2015, 11:38
python 3.5.0 is out now.
Is it necessary to update from 3.4 to 3.5?
hajj_3
14th September 2015, 16:56
Is it necessary to update from 3.4 to 3.5?
when the creator of vapoursynth releases a new version you will need to upgrade to v3.5.
Myrsloik
14th September 2015, 17:09
Python 3.5 will be required for the next release (and the test versions before that from now on). If someone with VS2010 wants to step up and compile modules for older Pythons I won't object. The biggest reason I don't support multiple versions on windows is testing.
Theoretically 2.x could work too but once again, testing. And ancient compilers. From now on I will only use VS2015 (or later) to compile this project on windows.
So now we should all celebrate Python 3.5 and its switch to a modern compiler. I can finally remove that old crap from my computer.
Btw, you should all use VS2015 too, the community edition is free.
feisty2
14th September 2015, 17:35
From now on I will only use VS2015 (or later) to compile this project on windows.
I assume that would fix the mysterious vs2015 plugin vspipe crash?
Myrsloik
14th September 2015, 18:04
I assume that would fix the mysterious vs2015 plugin vspipe crash?
It should already be fixed in R28 test 2 actually.
Boulder
14th September 2015, 18:48
In MVTools for Vapoursynth,
bv3 = core.mv.Analyse(clip=superanalyse, dct=dct, blksize=blksize, overlap=overlap,
search=search, searchparam=searchparam, pelsearch=pelsearch, isb=true, lambda=lda,
chroma=chromamotion, delta=3, truemotion=truemotion, lsad=lsad, global=true, pnew=pnew,
badsad=badsad, badrange=badrange)
causes a syntax error (SyntaxError: invalid syntax) pointing around "search". If I remove that, it points to the next item around the same position. Is there some weird overflow going on?
jackoneill
14th September 2015, 19:45
In MVTools for Vapoursynth,
bv3 = core.mv.Analyse(clip=superanalyse, dct=dct, blksize=blksize, overlap=overlap,
search=search, searchparam=searchparam, pelsearch=pelsearch, isb=true, lambda=lda,
chroma=chromamotion, delta=3, truemotion=truemotion, lsad=lsad, global=true, pnew=pnew,
badsad=badsad, badrange=badrange)
causes a syntax error (SyntaxError: invalid syntax) pointing around "search". If I remove that, it points to the next item around the same position. Is there some weird overflow going on?
I don't know about "search", but "lambda" and "global" are Python keywords. Prefix them with an underscore:
_lambda=lda, ... _global=True
Oh, and maybe it's pointing at "search" because it's on a new line. Maybe Python needs all of that on a single line.
Are_
14th September 2015, 20:18
The auto indentation of my IDE indents it like this:
bv3 = core.mv.Analyse(clip=superanalyse, dct=dct, blksize=blksize, overlap=overlap,
search=search, searchparam=searchparam, pelsearch=pelsearch,
isb=true, _lambda=lda, chroma=chromamotion, delta=3, truemotion=truemotion,
lsad=lsad, _global=true, pnew=pnew, badsad=badsad, badrange=badrange)
Remember indentation is part of the syntax in python.
Boulder
14th September 2015, 20:21
I put it on a new line due to readability here, in my script it's all on the same line. Using the underscore seems to help, thanks :) The error message really didn't help there..
You might want to update the docs on the MVTools page to reflect this one.
foxyshadis
15th September 2015, 08:56
Since those arguments already break avisynth compatibility, by requiring an underscore, it'd be better to just rename them from the get-go. This is a pretty serious submarine problem that's just going to catch more people out over time.
Myrsloik
16th September 2015, 23:40
Here's R28 test3 (https://dl.dropboxusercontent.com/u/73468194/vapoursynth-r28-test3.exe). It's mostly for the brave only.
Changes from test2 is that it needs a python 3.5 installation made for all users (next test will also support per user installations).
The new compile of assvapour is completely untested so report your findings there if you dare. It no longer uses fontconfig so if it works it should start up much quicker.
The expr filter has also been greatly sped up and now uses runtime code generation. Log, exp and pow currently aren't implemented though and will probably crash it if you try to use them. Everything else should work as expected.
Report your findings there as well.
Speed comparisons with R28 test2 (or R27) welcome.
Boulder
17th September 2015, 17:15
I just ran into a deadlock situation with R27, trying to use contrasharpening with 16-bit input.
import vapoursynth as vs
import scoll
core = vs.get_core()
cs = scoll.SColl()
clp = core.ffms2.Source(source='c:/x265/hotfuzz.vc1')
clp = core.fmtc.bitdepth(clp, bits=16)
clp = cs.contrasharpening(clp,clp)
clp.set_output()
SColl is from here: https://github.com/4re/vapoursynth-modules/blob/master/scoll.py
When using vspipe to display clip info, it utilizes one CPU thread at 100% and the Task Manager shows that memory usage just keeps on increasing (it went over 2GB before I interrupted the execution). If I remove the conversion to 16-bit video, there's no problem.
Don't worry about the silly contrasharpening line, it's just to reproduce the problem.
jackoneill
17th September 2015, 19:00
I just ran into a deadlock situation with R27, trying to use contrasharpening with 16-bit input.
import vapoursynth as vs
import scoll
core = vs.get_core()
cs = scoll.SColl()
clp = core.ffms2.Source(source='c:/x265/hotfuzz.vc1')
clp = core.fmtc.bitdepth(clp, bits=16)
clp = cs.contrasharpening(clp,clp)
clp.set_output()
SColl is from here: https://github.com/4re/vapoursynth-modules/blob/master/scoll.py
When using vspipe to display clip info, it utilizes one CPU thread at 100% and the Task Manager shows that memory usage just keeps on increasing (it went over 2GB before I interrupted the execution). If I remove the conversion to 16-bit video, there's no problem.
Don't worry about the silly contrasharpening line, it's just to reproduce the problem.
It uses std.Lut2 inside. With two 16 bit clips, that means there will be a table of 65536 * 65536 elements, which is over 4 billion. With 2 bytes per element, that requires 8 GiB of RAM and probably takes a while to initialise.
Myrsloik
17th September 2015, 19:02
It uses std.Lut2 inside. With two 16 bit clips, that means there will be a table of 65536 * 65536 elements, which is over 4 billion. With 2 bytes per element, that requires 8 GiB of RAM and probably takes a while to initialise.
Actually that should be rejected and the memory allocation would fail first. But there's probably something weird going on in general.
Definitely sounds like a 16bit bug in one filter.
Boulder
17th September 2015, 19:10
But basically it doesn't make sense to try contrasharpening 16-bit clips?
Are_
17th September 2015, 20:06
Actually that should be rejected and the memory allocation would fail first. But there's probably something weird going on in general.
Definitely sounds like a 16bit bug in one filter.
Not actually, because that function tries to allocate the full table in memory before sending it to std.Lut2 (I think).
lut = []
for y in lut_range:
for x in lut_range:
lut.append(clamp(0, expr(x, y), vmax))
return self.core.std.Lut2(c1, c2, lut=lut, planes=planes)
@Boulder: That module is like super unmaintained, it's surprising it even loads. For contrasharpening try with the one in havsfunc, it uses std.Expr so it should work OK with 16 bit clips.
feisty2
17th September 2015, 20:07
Replace lut2 with expr
Edit: too slow :)
Edit2: lut stuff needs to initialize before running, and that would burn your poor machine up if the bit depth is too high, basically it works fine on low bit depth clips
Expr doesn't need to initialize, it executes the RPN on each pixel at runtime, it's the right tool to work around high bit depth pixel manipulations, it works even at 96 bits input (32 bits float input x3)
Boulder
18th September 2015, 05:08
@Boulder: That module is like super unmaintained, it's surprising it even loads. For contrasharpening try with the one in havsfunc, it uses std.Expr so it should work OK with 16 bit clips.Yes, it seems to work fine. Funny that there's at least three versions of contrasharpening out and I end up picking the wrong one :D
feisty2
18th September 2015, 08:28
That one's not wrong, just gotta take some more time...
Myrsloik
19th September 2015, 22:02
R28 test4 (https://dl.dropboxusercontent.com/u/73468194/vapoursynth-r28-test4.exe). Now works with (and prefers) per user python installations. Expr has also had several big fixes (ternary operator, crashes and so on) so give it a try again. Log, pow and maybe exp is probably not working properly. Everything else should be working though so try it out.
On the positive size Expr can now have up to 26 inputs, x-z, a-w.
Expr correctness and speed comparisons welcome.
nu774
20th September 2015, 02:51
The following script works via VSScipt, but fails when directly executed from python3.5 command.
Using Python3.5 on windows, vapoursynth git latest. Both of 32bit/64bit result in the same.
Error:
Traceback (most recent call last):
File "Baloon.issue.vpy", line 5, in <module>
last = core.std.FrameEval(last, lambda n, c=last: c)
File "src\cython\vapoursynth.pyx", line 1360, in vapoursynth.Function.__call__ (build\temp.win32-3.5\Release\pyrex\vapoursynth.c:24919)
vapoursynth.Error: FrameEval: Internal environment id not set. Report this function wrapper creation error.
Script:
import vapoursynth as vs
core = vs.get_core()
last = core.lsmas.LibavSMASHSource('baloon-pops.mp4')
last = core.std.FrameEval(last, lambda n, c=last: c)
last.set_output()
Are_
20th September 2015, 11:53
Is current git supposed to compile with gcc? I was about to give new expr a try but no luck.
Loads of:
/var/tmp/portage/media-libs/vapoursynth-9999/work/vapoursynth-9999/src/core/jitasm.h:1935:11: error: expected ‘)’ before ‘const’
/var/tmp/portage/media-libs/vapoursynth-9999/work/vapoursynth-9999/src/core/jitasm.h:1935:10: error: expected ‘;’ at end of member declaration
void and(const Reg8& dst, const Imm8& imm) {AppendInstr(I_AND, 0x80, E_SPECIAL, Imm8(4), RW(dst), imm);}
^
/var/tmp/portage/media-libs/vapoursynth-9999/work/vapoursynth-9999/src/core/jitasm.h:1935:28: error: expected unqualified-id before ‘const’
void and(const Reg8& dst, const Imm8& imm) {AppendInstr(I_AND, 0x80, E_SPECIAL, Imm8(4), RW(dst), imm);}
^
EDIT: I didn't say anything, jackoneill fixed it while I was typing this.
Myrsloik
20th September 2015, 12:00
Is current git supposed to compile with gcc? I was about to give new expr a try but no luck.
Loads of:
/var/tmp/portage/media-libs/vapoursynth-9999/work/vapoursynth-9999/src/core/jitasm.h:1935:11: error: expected ‘)’ before ‘const’
/var/tmp/portage/media-libs/vapoursynth-9999/work/vapoursynth-9999/src/core/jitasm.h:1935:10: error: expected ‘;’ at end of member declaration
void and(const Reg8& dst, const Imm8& imm) {AppendInstr(I_AND, 0x80, E_SPECIAL, Imm8(4), RW(dst), imm);}
^
/var/tmp/portage/media-libs/vapoursynth-9999/work/vapoursynth-9999/src/core/jitasm.h:1935:28: error: expected unqualified-id before ‘const’
void and(const Reg8& dst, const Imm8& imm) {AppendInstr(I_AND, 0x80, E_SPECIAL, Imm8(4), RW(dst), imm);}
^
No, still working on the not windows part.
Myrsloik
22nd September 2015, 21:35
Another test version. This one should have a fully working Expr with no bugs at all. It also fixes the issue nu774 reported that was introduced in the test versions.
This version is also compiled with some extra checks to see if any plugins trigger them. Report any that do.
R28 test5 (https://dl.dropboxusercontent.com/u/73468194/vapoursynth-r28-test5.exe)
Are_
22nd September 2015, 22:14
Some speed comparasions:
r27
finesharp-lut
Output 2001 frames in 29.26 seconds (68.38 fps)
Output 2001 frames in 30.64 seconds (65.31 fps)
Output 2001 frames in 32.25 seconds (62.05 fps)
Average fps for finesharp-lut: 65.24
finesharp
Output 2001 frames in 56.01 seconds (35.73 fps)
Output 2001 frames in 55.35 seconds (36.15 fps)
Output 2001 frames in 54.97 seconds (36.40 fps)
Average fps for finesharp: 36.09
psharpen
Output 2001 frames in 40.66 seconds (49.21 fps)
Output 2001 frames in 41.05 seconds (48.74 fps)
Output 2001 frames in 41.24 seconds (48.52 fps)
Average fps for psharpen: 48.82
git
finesharp
Output 2001 frames in 47.69 seconds (41.95 fps)
Output 2001 frames in 46.86 seconds (42.70 fps)
Output 2001 frames in 47.46 seconds (42.16 fps)
Average fps for finesharp: 42.27
psharpen
Output 2001 frames in 28.09 seconds (71.24 fps)
Output 2001 frames in 27.21 seconds (73.53 fps)
Output 2001 frames in 26.59 seconds (75.25 fps)
Average fps for psharpen: 73.34
Myrsloik
23rd September 2015, 00:15
Interesting comparison. But where can I find psharpen for vs?
I think I can make it even faster by combining several expr calls. At least finesharp is kinda inefficient in that eay.
Reel.Deel
23rd September 2015, 00:40
Interesting comparison. But where can I find psharpen for vs?
I think I can make it even faster by combining several expr calls. At least finesharp is kinda inefficient in that eay.
I'm not aware of psharpen for vs but here's the avs version: http://forum.doom9.org/showthread.php?t=172422
Are_
23rd September 2015, 01:27
Sorry, I somehow f..... up the test, speed is a little better, results updated. psharpen.py (https://gist.github.com/4re/2545a281e3f17ba6ef82)
foxyshadis
23rd September 2015, 12:09
I can'y get assvapour to do anything at all, and as far as I can tell I'm using it right:
import vapoursynth as vs
core = vs.get_core()
std = core.std
vid = core.lsmas.LWLibavSource(r'C:\train\karaoke\work\Rilo Kiley - Portions for Foxes.mkv')
subs = core.assvapour.AssRender(vid,r'Rilo Kiley - Portions for Foxes.ass (https://www.dropbox.com/s/ock9pb1ukz9v1qn/Rilo%20Kiley%20-%20Portions%20for%20Foxes.ass?dl=0)')
subs[0] = core.resize.Bicubic(subs[0], format=vid.format.id)
vid = std.MaskedMerge(vid, subs[0], subs[1])
vid.set_output()
I get pure black video. What it should look like (https://www.dropbox.com/s/kj9utyui52tlck5/Rilo%20Kiley%20-%20Portions%20for%20Foxes.mkv?dl=0), you can use this as input above. The subs are muxed and work fine in MPC and MPDN.
Edit: Also attempted
vsfilter = core.avs.LoadPlugin(r'vsfilter_avs.dll')
subs = vsfilter.TextSub(vid,r'Rilo Kiley - Portions for Foxes.ass')
and that was also a no-go, with error "Python exception: 'NoneType' object has no attribute 'TextSub'", although it worked perfectly from Avisynth.
splinter98
23rd September 2015, 13:08
Edit: Also attempted
vsfilter = core.avs.LoadPlugin(r'vsfilter_avs.dll')
subs = vsfilter.TextSub(vid,r'Rilo Kiley - Portions for Foxes.ass')
and that was also a no-go, with error "Python exception: 'NoneType' object has no attribute 'TextSub'", although it worked perfectly from Avisynth.
That's because you're using avs Loadplugin incorrectly. Loadedplugins go into the core.avs namespace
Try: (untested)
core.avs.LoadPlugin(r'vsfilter_avs.dll')
subs = core.avs.vsfilter.TextSub(vid,r'Rilo Kiley - Portions for Foxes.ass')
Regarding AssRender not working, I get the same output on the latest build, however on an older build it works as expected.
Myrsloik
23rd September 2015, 13:27
I can'y get assvapour to do anything at all, and as far as I can tell I'm using it right:
import vapoursynth as vs
core = vs.get_core()
std = core.std
vid = core.lsmas.LWLibavSource(r'C:\train\karaoke\work\Rilo Kiley - Portions for Foxes.mkv')
subs = core.assvapour.AssRender(vid,r'Rilo Kiley - Portions for Foxes.ass (https://www.dropbox.com/s/ock9pb1ukz9v1qn/Rilo%20Kiley%20-%20Portions%20for%20Foxes.ass?dl=0)')
subs[0] = core.resize.Bicubic(subs[0], format=vid.format.id)
vid = std.MaskedMerge(vid, subs[0], subs[1])
vid.set_output()
I get pure black video. What it should look like (https://www.dropbox.com/s/kj9utyui52tlck5/Rilo%20Kiley%20-%20Portions%20for%20Foxes.mkv?dl=0), you can use this as input above. The subs are muxed and work fine in MPC and MPDN.
Edit: Also attempted
and that was also a no-go, with error "Python exception: 'NoneType' object has no attribute 'TextSub'", although it worked perfectly from Avisynth.
Your assvapour script works perfectly for me with r28 test5.
jackoneill
23rd September 2015, 13:37
Look at the output of Assvapour directly, both clips. How do they compare to the last working version?
foxyshadis
23rd September 2015, 14:22
That's because you're using avs Loadplugin incorrectly. Loadedplugins go into the core.avs namespace
Thanks! I'm sure I knew this before, but I've been VS-only so long now that I screwed up the syntax. The VS docs are good, but this is one of the areas that isn't written up.
Your assvapour script works perfectly for me with r28 test5.
I'm cranky now because I tested with both r27 and r28t5 and neither showed. Now they do and I don't know why. Sigh. Computers, man.
splinter98
23rd September 2015, 15:07
Look at the output of Assvapour directly, both clips. How do they compare to the last working version?
Hmm I can get it to work using the R27 assvapour. I use a custom build (which has minor changes to Subtitle which I keep meaning to create a pull request with) which don't work. Those custom builds use the latest version of libass (0.12.3) (exact library used here (http://repo.msys2.org/mingw/x86_64/mingw-w64-x86_64-libass-0.12.3-1-any.pkg.tar.xz)).
feisty2
23rd September 2015, 15:38
so "^(pow)" is working in Expr now?
splinter98
24th September 2015, 15:01
Hmm I can get it to work using the R27 assvapour. I use a custom build (which has minor changes to Subtitle which I keep meaning to create a pull request with) which don't work. Those custom builds use the latest version of libass (0.12.3) (exact library used here (http://repo.msys2.org/mingw/x86_64/mingw-w64-x86_64-libass-0.12.3-1-any.pkg.tar.xz)).
Must have been my build of libass, built against the latest git and now working again :)
jose1711
24th September 2015, 15:11
fwiw even with the latest (today's) ffms2 i still get the same crash as here: http://forum.doom9.org/showthread.php?p=1733283#post1733283
6 of such videos in my small home video library. here: http://stackoverflow.com/questions/11507675/memcpy-ssse3-segmentation-fault a few guys suggest it may be due to misaligned memory, could it be this problem? just wondering.
Khanattila
26th September 2015, 16:51
It is probably a stupid question but, while compiling VapourSynth, which features can be disabled?
Besides '--disable-ocr'.
jackoneill
26th September 2015, 17:39
It is probably a stupid question but, while compiling VapourSynth, which features can be disabled?
Besides '--disable-ocr'.
The plugins are all optional. The average user will need all the other components.
If you have an application that only uses VapourSynth through the C API, you won't need VSScript, vspipe, or the Python module. If you want to use VapourSynth only through Python.exe or an application like vsedit, you won't need vspipe. That's about it.
videoh
26th September 2015, 20:35
@Myrsloik
It would be sweet if at your convenience you could add DGDecNV to your list of native plugins. Thank you.
Myrsloik
26th September 2015, 21:42
@Myrsloik
It would be sweet if at your convenience you could add DGDecNV to your list of native plugins. Thank you.
I will be there the next time I regenerate the docs. Which I usually only do when I release a new version.
Maybe I should have a small wiki as a complement to the static docs.
videoh
26th September 2015, 22:52
That's great, thanks.
"Maybe I should have a small wiki"
Something else to maintain! It might be easier to just update the lists somewhat more frequently, IMHO.
Sparktank
26th September 2015, 23:07
(+1 on the wiki. at the very least, a consolidated pile of examples)
Myrsloik
27th September 2015, 17:52
Here's R28 test6 (https://dl.dropboxusercontent.com/u/73468194/vapoursynth-r28-test6.exe). The biggest change is the installer which will now automatically download and install the VS2013 and VS2015 runtimes if they're not present. It also has minor fixes here and there.
vcmohan
28th September 2015, 06:48
Is the imwri plugin in the autoload folder of included plugins correct version? When I make a call to imwri , it does not recognise. and an error message
Failed to evaluate the script:
Python exception: No attribute with the name imwri exists. Did you mistype a plugin namespace?
It works if I load plugin imwri from another folder where I had a another version of imwri. However it is about 20+ mb while the included is only 44kb. I remember once I downloaded a version of that size(44kb), but it had a additional folder having a number of dlls.
vcmohan
28th September 2015, 12:04
Where did you see the imwri plugin is included? IIRC the imwri plugin is never included in the official installer.
Here in the documentation (http://www.vapoursynth.com/doc/includedplugins.html)
sneaker_ger
28th September 2015, 13:07
Like HolyWu said it's not in the installer.
That should be read as "included in the source tree"
It's not included and never will be due to its insane size.
vcmohan
28th September 2015, 13:33
Like HolyWu said it's not in the installer.
All other plugins listed on that page are included. So it gives impression that imwri also is included. Documentation needs to be corrected then.
Boulder
28th September 2015, 13:34
Is there an equivalent in the core to Spline36Resize(2560,1440,src_left=0.25, src_top=0.25)?
mawen1250
28th September 2015, 14:40
For top-left aligned resizing:
fmtc.resample(clip, 2560, 1440, center=False)
jackoneill
28th September 2015, 15:04
All other plugins listed on that page are included. So it gives impression that imwri also is included. Documentation needs to be corrected then.
It has been corrected in git.
Reel.Deel
29th September 2015, 01:26
Maybe I should have a small wiki as a complement to the static docs.
A GitHub wiki would be nice, very easy to set up set up also.
edit: didn't notice you had already created one (https://github.com/vapoursynth/vapoursynth/wiki).
stax76
29th September 2015, 11:50
I'm also using the github wiki for StaxRip but can't really tell how it compares to other solutions. What could also be interesting is readthedocs.org, most people here know it from the excellent x265 docs, it looks like it's built with Python so a natural fit for VapourSynth.
https://readthedocs.org
https://x265.readthedocs.org
Myrsloik
29th September 2015, 13:36
I've now enabled the github wiki. Anyone with a github account can freely edit it. It's empty right now so suggest a good structure.
https://github.com/vapoursynth/vapoursynth/wiki
stax76
29th September 2015, 13:59
I suggests a Tools page like so:
Editors
VapourSynth Editor
GUIs
StaxRip
Simple x264/x265 Launcher
Encoders
QSVEncC
NVEncC
VCEEncC
Misc
vspipe
VirtualDub
splinter98
29th September 2015, 16:53
I'm also using the github wiki for StaxRip but can't really tell how it compares to other solutions. What could also be interesting is readthedocs.org, most people here know it from the excellent x265 docs, it looks like it's built with Python so a natural fit for VapourSynth.
https://readthedocs.org
https://x265.readthedocs.org
+1 for read the docs it should be a simple case of sign up, link to the github and enable the webhook and it will build on pull updates (and should support tag based version history which is useful for people using older versions for whatever reason). (it could also be set up as a cname for docs.vapoursynth.com if desired).
The wiki still useful for user contributed items, such as example snippets.
foxyshadis
29th September 2015, 23:29
Myrsloik, would you consider extending clip.format with min and max (or minval/maxval)? 2**clip.format.bits_per_sample-1 works for integer formats, though ugly, but that should be 1.0 for floats. Making it generic would be even uglier, like:
maxval=2**clip.format.bits_per_sample-1 if clip.format.sampletype==vs.INTEGER else 1.0
foxyshadis
29th September 2015, 23:35
I've made a new page for the community to list AviSynth equivalents to ease the transition to VS: https://github.com/vapoursynth/vapoursynth/wiki/Avisynth-Equivalents
Hopefully this will keep others from banging their head as much as I did on the path to enlightenment. Also helps me, since I'm so forgetful.
Myrsloik
29th September 2015, 23:51
I guess I could add a function for it but it's actually a bit more complicated. For floating point it also depends on the plane and format. I'll think about it a bit because it definitely could be useful to have in many scripts.
And when you write about function equivalents, don't always assume Lut is faster than expr. The jit compilation in r28 gives a huge speedup.
foxyshadis
30th September 2015, 00:00
I guess I could add a function for it but it's actually a bit more complicated. For floating point it also depends on the plane and format. I'll think about it a bit because it definitely could be useful to have in many scripts.
And when you write about function equivalents, don't always assume Lut is faster than expr. The jit compilation in r28 gives a huge speedup.
Didn't know that, nice. Even then I was going to edit it to say that it'd only be useful for 8-bit, since memory bandwidth on most luts is likely to be a much bigger speed-killer, unless it's a very expensive expression.
DarkSpace
30th September 2015, 09:53
For the integer formats, will your min/max values handle limited/full/custom ranges, too?
Myrsloik
2nd October 2015, 23:25
For the integer formats, will your min/max values handle limited/full/custom ranges, too?
Don't go there. Limited/full range is a frame property so that's per frame. There's a reason I didn't add a simple function. It's not simple at all. Ever.
Myrsloik
2nd October 2015, 23:27
Behold R28 RC1 (https://dl.dropboxusercontent.com/u/73468194/vapoursynth-r28-rc1.exe). No more changes planned unless a serious bug is found. Most of the performance regression relative to R27 should be fixed.
All R28 changes:
r28:
the installer will now download and install the vs2013 and vs2015 runtimes if needed
now uses python 3.5
fixed vdecimate parallel mode
pow is now accepted in expr expressions
expr now accepts up to 26 inputs (x-z, a-w)
expr now has runtime code generation on x86 cpus using jitasm
now normalizes the framerate returned from avisynth filters
it is now a fatal error to set the videoinfo of a filter to a non-normalized framerate
added a few more checks for proper api usage
get_core() can now be used in callbacks and other external functions in python
now returns an error message saying that windows needs to be updated in certain cases when plugin loading fails
fixed loop filter (nodame)
lut and lut2 can now output float as well
now accepts scripts that start with a BOM as well
fixed an image corruption bug with 9-16 bit input to rgvs when the c++ code is used
fixed division by zero issues in muldivrational in vshelper.h
blankclip can now create 0 (unknown/variable) fps clips
added float support to planedifference and planeaverage
added half support to addborders
relevant compile time options are now in the version string
Myrsloik
7th October 2015, 22:42
Look at me! I'm multitasking! I can argue on the interweb and release stuff at once! R28 is ready. Prepare to have FATAL ERRORS IN YOUR NIGHTMARES!
The usual summary blog (http://www.vapoursynth.com/2015/10/r28-econtroversy/) of interesting changes. Full changelog in the first post as usual.
mawen1250
12th October 2015, 13:09
core.resize in R28 returns "Warning: data is not aligned! This can lead to a speedloss" in command line.
jackoneill
12th October 2015, 13:23
core.resize in R28 returns "Warning: data is not aligned! This can lead to a speedloss" in command line.
It always (?) does that. You shouldn't use it anyway. zimg now has a drop-in replacement all-in-one filter.
Myrsloik
12th October 2015, 14:55
core.resize in R28 returns "Warning: data is not aligned! This can lead to a speedloss" in command line.
That's very odd. All buffers should be aligned. I'll have to figure out why that happens.
NailBomber
12th October 2015, 17:00
Is there currently a way to get frame data out of video and write it into an image? Something like using clip.get_frame() then writing it with opencv?
Myrsloik
12th October 2015, 17:02
Is there currently a way to get frame data out of video and write it into an image? Something like using clip.get_frame() then writing it with opencv?
If you want it written as text you can simply use FrameProps (http://www.vapoursynth.com/doc/functions/frameprops.html) to print the relevant ones.
TurboPascal7
12th October 2015, 18:21
Is there currently a way to get frame data out of video and write it into an image? Something like using clip.get_frame() then writing it with opencv?
src = core.ffms2.Source(...)
src = core.resize.Bicubic(src, format=vs.RGB24)
planes_count = src.format.num_planes
for x in range(10):
frame = src.get_frame(x)
image = cv2.merge([np.array(frame.get_read_array(i), copy=False) for i in reversed(range(planes_count))])
cv2.imshow("", image) # or something like cv2.imwrite("{0}.png".format(x), image) if you want it saved
cv2.waitKey(0)
Something like this works for now (converted to rgb because working with subsampled formats in opencv is all kinds of painful). Basically you use get_read_array to get the raw bytes, convert them to numpy arrays and then do whatever you want with them.
NailBomber
12th October 2015, 20:07
Myrsloik, sorry, I meant the frame itself.
Thank you, TurboPascal7.
splinter98
12th October 2015, 22:36
src = core.ffms2.Source(...)
src = core.resize.Bicubic(src, format=vs.RGB24)
planes_count = src.format.num_planes
for x in range(10):
frame = src.get_frame(x)
image = cv2.merge([np.array(frame.get_read_array(i), copy=False) for i in reversed(range(planes_count))])
cv2.imshow("", image) # or something like cv2.imwrite("{0}.png".format(x), image) if you want it saved
cv2.waitKey(0)
Something like this works for now (converted to rgb because working with subsampled formats in opencv is all kinds of painful). Basically you use get_read_array to get the raw bytes, convert them to numpy arrays and then do whatever you want with them.
Don't forget if you just want to write out the video as a series of images, then imwri is likley to be faster. (If you want to then go on and do some other processing then yes the way TurboPascal7 has suggested is the way to go about it.)
Also if you then want to go about editing the images, you need to do:
src = core.ffms2.Source(...)
src = core.resize.Bicubic(src, format=vs.RGB24)
planes_count = src.format.num_planes
for x in range(10):
frame = src.get_frame(x)
image = cv2.merge([np.array(frame.copy().get_write_array(i), copy=False) for i in reversed(range(planes_count))])
cv2.imshow("", image) # or something like cv2.imwrite("{0}.png".format(x), image) if you want it saved
cv2.waitKey(0)
mawen1250
14th October 2015, 17:15
For GRAY and YUV mask (haven't tested RGB), with first_plane=True, std.MaskedMerge will unexpectedly change the color. Probably because it clamps the UV mask to limited range.
I found this issue when trying to use AssVapour since the clipa and clipb are very different under this case.
Myrsloik
14th October 2015, 19:02
For GRAY and YUV mask (haven't tested RGB), with first_plane=True, std.MaskedMerge will unexpectedly change the color. Probably because it clamps the UV mask to limited range.
I found this issue when trying to use AssVapour since the clipa and clipb are very different under this case.
That shouldn't happen. Exampöe script?
Myrsloik
14th October 2015, 19:44
Nicely spotted. That's a nasty bug.
feisty2
18th October 2015, 15:09
@Myrsloik
any chance to add PlaneSSIM?
gonna need it for self adaptive denoising
feisty2
24th October 2015, 13:19
any plans about adding CIE colorspaces (XYZ and Lab) to the core in future releases?
Khanattila
24th October 2015, 23:49
any plans about adding CIE colorspaces (XYZ and Lab) to the core in future releases?
If needed, I could write it in OpenCL.
Myrsloik
25th October 2015, 00:56
any plans about adding CIE colorspaces (XYZ and Lab) to the core in future releases?
No? What would it be useful for? There are so many ways to transform things I'd prefer to only keep the most used ones.
Khanattila
4th November 2015, 17:08
Feature request. 'subSamplingW' and 'subSamplingH' separate for second and third plane.
In function plugin 'fooPluginCreate' anyone is forced to read 'format.id' to manage 422 and 440 format.
Myrsloik
4th November 2015, 17:10
Feature request. 'subSamplingW' and 'subSamplingH' separate for second and third plane.
In function plugin 'fooPluginCreate' one is forced to read 'format.id' to manage 422 and 440 format.
There's no meaningful format that needs it. I don't understand how it'd help you.
Khanattila
4th November 2015, 17:19
There's no meaningful format that needs it. I don't understand how it'd help you.
I have to create a different OpenCLMemoryObject for each plan.
But I need the width and height of each.
The only format noteworthy is the 422. The other doesn't matter.
Ofekmeister
13th November 2015, 00:29
I have a question. Is it possible to use VSFilter.dll for its TextSub & VobSub functions?
https://github.com/Cyberbeing/xy-VSFilter
https://github.com/Cyberbeing/xy-VSFilter/tree/xy_sub_filter_rc4 <- newest branch
http://www.videohelp.com/software/VSFilter-DirectVobSub <-- original
I'm using Windows 7 x64 and current release of Vapoursynth btw. The newest release .dll x64 says could not find entry point when loaded. I ask this because I am in great need of burning in not only text based subtitle formats like srt, ass/ssa, etc. but also many .sub/.idx VobSub format pairs. I'm ok at C so maybe if someone could just describe how to make it Vapoursynth compatible, and I'll try to keep builds maintained. I really have no idea.
Thank you kindly.
jackoneill
13th November 2015, 08:53
I have a question. Is it possible to use VSFilter.dll for its TextSub & VobSub functions?
https://github.com/Cyberbeing/xy-VSFilter
https://github.com/Cyberbeing/xy-VSFilter/tree/xy_sub_filter_rc4 <- newest branch
http://www.videohelp.com/software/VSFilter-DirectVobSub <-- original
I'm using Windows 7 x64 and current release of Vapoursynth btw. The newest release .dll x64 says could not find entry point when loaded. I ask this because I am in great need of burning in not only text based subtitle formats like srt, ass/ssa, etc. but also many .sub/.idx VobSub format pairs. I'm ok at C so maybe if someone could just describe how to make it Vapoursynth compatible, and I'll try to keep builds maintained. I really have no idea.
Thank you kindly.
It might work in the 32 bit version of VapourSynth. You need to use avs.LoadPlugin.
But if you're okay at C, maybe you can create a native VapourSynth plugin. Then you could use it with the 64 bit VapourSynth.
Ofekmeister
14th November 2015, 06:20
Is there a good guide or reference?
Boulder
19th November 2015, 12:53
Is there a tutorial for compiling Vapoursynth for Windows (x64) on MinGW or VS2015?
Myrsloik
19th November 2015, 13:02
Is there a tutorial for compiling Vapoursynth for Windows (x64) on MinGW or VS2015?
No, there isn't. Simply open the project in VS2015, add the obviously missing libraries and yasm and off you go. That's it.
Why do you feel a need to compile the core part of VapourSynth?
Boulder
19th November 2015, 13:06
I just noticed that the VDecimate fix is there, and I didn't know if a release is due any time soon.
Myrsloik
19th November 2015, 13:08
I just noticed that the VDecimate fix is there, and I didn't know if a release is due any time soon.
I'll compile a new test version later today.
Boulder
19th November 2015, 13:12
Thanks, I'd appreciate that :)
jackoneill
19th November 2015, 14:45
Is there a tutorial for compiling Vapoursynth for Windows (x64) on MinGW or VS2015?
In Linux:
./autogen.sh
./configure --host=x86_64-w64-mingw32 --disable-core --disable-python-module --disable-vsscript --disable-plugins --enable-vivtc
make
Boulder
19th November 2015, 14:55
Thanks, I'll check it out in Windows - it should be quite close in MinGW. Even if Myrsloik releases a test build, it's not bad to learn new things anyway :)
Myrsloik
20th November 2015, 10:08
Here'a R29 test 1 (https://dl.dropboxusercontent.com/u/73468194/vapoursynth_r29_test1.exe).
Changes:
fixed vdecimate crash (nodame)
now internally prioritizes frames based on original request order, should improve speed and frame time consistency in certain conditions
more specific error messages in many filters (nodame)
fixed the shown matrix names in clipinfo
fixed compilation on non x86 targets, in imwri and vshelper.h without c++11 enabled, all introduced in r28
fixed vsfatal corrupt output (nodame)
fixed uninitialized value in frame pool
Myrsloik
21st November 2015, 23:12
Here's R29 test 2 (https://dl.dropboxusercontent.com/u/73468194/vapoursynth_r29_test2.exe).
IT HAS HUGE CHANGES
SWSCALE HAS BEEN REPLACED BY ZIMG.
This means that ALL CONVERSIONS TO YUV NEED TO SET THE MATRIX. And SOME CONVERSIONS FROM YUV need it to be set too.
This will probably break a few scripts. But in practice these scripts were already broken since yuv has can have several different sets of coefficients.
THERE WILL BE BUGS. Report them.
And the build is currently broken outside windows until jackoneill has time to fix it.
sl1pkn07
22nd November 2015, 02:38
then the zimg is now used like a dependence lib instead of a external plugin, rigth?
Myrsloik
22nd November 2015, 14:25
then the zimg is now used like a dependence lib instead of a external plugin, rigth?
Yes, it will be a normal library dependency.
dipje
22nd November 2015, 23:57
for my curiousity, is there a reason to go with zimg over fmtconv or something else?
and for me important (although I could figure the answer out by actually trying): Does this have any impact in the things like 'compatbgr32' colorspace? Wouldn't be surprised if that was a swscale-thing-only.
Myrsloik
23rd November 2015, 00:18
for my curiousity, is there a reason to go with zimg over fmtconv or something else?
and for me important (although I could figure the answer out by actually trying): Does this have any impact in the things like 'compatbgr32' colorspace? Wouldn't be surprised if that was a swscale-thing-only.
Why zimg and not fmtconv or something else? That's because something else simply doesn't exist. It's a horrible world out there where too few people appreciate accurate colors and scaling with a bit of dithering on top.
It's actually a very close race between zimg and fmtconv. In the end I picked zimg mostly because it's design is more library-ish so hopefully the rest of the world will start using it too. I hope fmtconv will continue to be developed and used as well since it has a few more dithering modes and a few other minor differences.
This shouldn't change anything apart from the fact you'll have to specify matrix and matrix_in for certain conversions. And a generally higher quality of the operations.
Kupildivan
27th November 2015, 16:36
Is it possible to install and work with both 32 and 64 versions simultaneously?
Myrsloik
27th November 2015, 16:37
Is it possible to install and work with both 32 and 64 versions simultaneously?
Yes. All you have to do is install both versions of python before installing VS.
Kupildivan
27th November 2015, 16:42
32-bit works ok.
But 64 is not.
Failed to initialize VapourSynth environment
What I did wrong?
splinter98
27th November 2015, 17:07
32-bit works ok.
But 64 is not.
What I did wrong?
did you use R28 release or a R29 test build?
R28 has a bug that causes the python build to be mismatched with the vapoursynth build.
Should be fixed in R29.
Kupildivan
27th November 2015, 17:09
did you use R28 release or a R29 test build?
R28 has a bug that causes the python build to be mismatched with the vapoursynth build.
Should be fixed in R29.
I have installed R28.
splinter98
27th November 2015, 17:12
I have installed R28.
Try the R29 build that should allow you to use both.
Kupildivan
27th November 2015, 17:29
Try the R29 build that should allow you to use both.
Your advice fixed the problem. Thanks, bro!
Myrsloik
4th December 2015, 00:30
Here's R29 RC4 (https://dl.dropboxusercontent.com/u/73468194/vapoursynth_r29_rc5.exe). I'll release this build unless serious bugs are found the next few days.
Make sure to test all scripts with format conversion in them because the matrix now needs to be specified for conversion to (and sometimes from) yuv.
r29:
fixed bug where vfm wouldn't set _Combed property properly unless micout=true or micmatch=2 used
vfm now sets _fieldbased=0 after matching
added XLENGTH field to y4m headers so the total number of frames can be automatically passed to encoders
imwri will now always output a float image when built against a hdri imagemagick
imwri now supports QD32 with and without hdri
added . as a special output filename to vspipe, specifying it will simply skip all output writing
maskedmerge should now properly resize the mask without truncating it to limited range
made zimg the default resizer, swscale is no longer used
fixed crash in vdecimate (nodame)
now internally prioritizes frames based on original request order, should improve speed and frame time consistency in certain conditions
more specific error messages in many filters (nodame)
fixed the shown matrix names in clipinfo
fixed compilation on non x86 targets, in imwri and vshelper.h without c++11 enabled, all introduced in r28
fixed vsfatal corrupt output (nodame)
fixed uninitialized value in frame pool
Myrsloik
8th December 2015, 18:24
Finally R29 is done after a long series of RCs with annoying bugs. Changelog in the previous post. The biggest news is that zimg is now integrated into the core for higher quality resizing. This should to some extent remove the need for additional resizing libraries (but not completely, fmtconv still has a whole pile of dither methods and stuff zimg can't do).
The usual blog post (http://www.vapoursynth.com/2015/12/r29-death-to-swscale/) with examples of the resize changes and stuff.
There are also some performance improving changes so speed comparisons with R28 are welcome as usual. Especially with many threads.
sl1pkn07
8th December 2015, 18:25
tnx bro
luigizaninoni
9th December 2015, 14:22
There are also some performance improving changes so speed comparisons with R28 are welcome as usual. Especially with many threads.
For my script, R29 is slower than R28:
core.std.LoadPlugin(r'C:\Users\luigi.TZMS\Desktop\Video\Staxrip64\Apps\Plugins\both\knlmeanscl\knlmeanscl.dll')
import adjust
clip = core.lsmas.LWLibavSource(source = r'C:\Users\luigi.TZMS\Desktop\Rocky (1976) temp files\Rocky (1976).m2v')
cropwidth = clip.width - 0 - 0
cropheight = clip.height - 4 - 4
clip = core.std.CropAbs(clip, cropwidth, cropheight, 0, 4)
clip = havsfunc.QTGMC(Input = clip, TFF = True, Preset = 'Slow', InputType=1, EZDenoise=1.0, Denoiser="knlmeanscl", NoiseTR=1, DenoiseMC=True, NoiseProcess=1, ChromaNoise=True)
clip = core.std.Expr(clip, expr=["","x 1.0 *", "x 1.01 *"])
clip = adjust.Tweak(clip,sat=1.02,hue=0.0,bright=0.0,cont=1.0)
R29: 4.08 fps
R28: 4.28 fps
Myrsloik
9th December 2015, 14:29
How many threads?
luigizaninoni
9th December 2015, 14:37
How many threads?
I suppose 8 threads, the same as my cpu. I didn't specify any number of threads in my script
Myrsloik
9th December 2015, 18:33
I suppose 8 threads, the same as my cpu. I didn't specify any number of threads in my script
I tested your script and ran it several times. What you're seeing is most likely variations between run which can happen when threads trip over each other. R29 was marginally faster in my tests with the speed averaged over multiple runs. But the difference is only like 3%... on average... with a fairly big variation.
The work on making things even more consistent will continue in R30.
aegisofrime
18th December 2015, 19:30
Hi, I have a simple question here.
I found a script to convert framerates, like so:
src_fps = 24
dst_fps = 60
clip = core.std.AssumeFPS(video_in, fpsnum=src_fps)
super = core.mv.Super(clip, pel=2)
bv = core.mv.Analyse(super, isb=True, overlap=0)
fv = core.mv.Analyse(super, isb=False, overlap=0)
# FlowFPS() is too slow to be run in real-time
#clip = core.mv.FlowFPS(clip, super, bv, fv, dst_fps)
clip = core.mv.BlockFPS(clip, super, bv, fv, dst_fps)
clip.set_output()
However, my source video is 29.97 fps, so I would like to pass that to src_fps. However simply plugging in 29.97 to src_fps returned the following error:
vapoursynth.Error: AssumeFPS: argument fpsnum was passed an unsupported type
What is the correct syntax for this? Thanks!
Are_
18th December 2015, 20:19
That's because the name of that variables is a little bit missleading in that script:
clip = core.mv.BlockFPS(clip, super, bv, fv, num=30000, den=1001)
Myrsloik
20th December 2015, 00:28
Here's R30 test1 (https://dl.dropboxusercontent.com/u/73468194/vapoursynth_installer_r30_test1.exe) with AVISYNTH 2.6 PLUGIN SUPPORT FOR BOTH 32 AND 64 BIT!!!!!111111
(no 2.5 plugin support for 64 bit stuff though)
r30:
planeaverage is now deprecated, use planestats instead
added planestats, a function that calculates min, max, average and difference of a frame at the same time
removed planedifference, deprecated since r28
added avisynth 2.6 and x64 support, note that x64 can only load 2.6 but not 2.5 plugins
no longer installs vsvfw.dlls into system dirs
added nfMakeLinear, this flag will make the immediately following cache do its best to make requests more linear, set it on source filters where seeking is slow
the installer will no longer fail if a newer than expected version of the visual studio runtimes are installed
vspipe now displays the correct number of total frames when -s is used
Lynx_TWO
21st December 2015, 13:43
Hello!
It appears the Sinc re-size algorithm is no longer present in VapourSynth R29. Any chance of getting that added back in?
feisty2
21st December 2015, 14:17
Hello!
It appears the Sinc re-size algorithm is no longer present in VapourSynth R29. Any chance of getting that added back in?
go get fmtconv
Myrsloik
21st December 2015, 14:42
Hello!
It appears the Sinc re-size algorithm is no longer present in VapourSynth R29. Any chance of getting that added back in?
No, it probably won't be added back. And as feisty2 says fmtconv has a higher quality version of it anyway.
The spline resizers were also changed to be morr like the ones in avisynth than the swscale stuff.
Lynx_TWO
22nd December 2015, 00:51
Oh, yes that works great! To use with Staxrip:
clip = core.fmtc.resample(clip, %target_width%, %target_height%, kernel="sinc", taps=128)
feisty2
22nd December 2015, 02:21
Why do you want 128-tap sinc...
You do realize there's something called ringing right?...
Never mind..
cretindesalpes
22nd December 2015, 10:42
Ringing appears with a just few taps with sinc, because this kernel has a slow decrease. So if you feel the need use it, you want it with many taps.
Myrsloik
3rd January 2016, 21:54
R30 RC1 (https://dl.dropboxusercontent.com/u/73468194/vapoursynth_installer_r30_rc1.exe). The only thing left to do is to test imwri thoroughly and then I'll release it.
Try out all four 64 bit Avisynth 2.6 plugins and report your findings.
Changes:
r30:
added half precision float input/output to expr on cpus that have the f16c extension (ivy bridge or later)
added the possibility for plugins to print messages through the standard logging as well, don't use it unless you really have to
the build system should now autodetect which optional libraries are available
fixed ycocg conversions
planeaverage is now deprecated, use planestats instead
added planestats, a function that calculates min, max, average and difference of a frame at the same time
removed planedifference, deprecated since r28
added avisynth 2.6 and x64 support, note that x64 can only load 2.6 but not 2.5 plugins
no longer installs vsvfw.dlls into system dirs
added nfMakeLinear, this flag will make the immediately following cache do its best to make requests more linear, set it on source filters where seeking is slow
the installer will no longer fail if a newer than expected version of the visual studio runtimes are installed
vspipe now displays the correct number of total frames when -s is used
salty1
6th January 2016, 16:05
Hello,
i suggest to seperate the props of Planestats.
in r30 RC minmax is in one props,not very easy to use.
i'm sorry for my poor english.
thank you very much
Myrsloik
6th January 2016, 16:20
Hello,
i suggest to seperate the props of Planestats.
in r30 RC minmax is in one props,not very easy to use.
i'm sorry for my poor english.
thank you very much
Why do you think it's hard to use? Example?
salty1
6th January 2016, 16:42
Why do you think it's hard to use? Example?
for example:
if Ymax < 180 do something with this frame
else do something with this frame
i dont know how to use current props to complete that.
i am a rookie ripper and i dont know python at all...
so i suggest to seperate min and max:thanks:
Myrsloik
6th January 2016, 18:42
Hint, it's an array:
if Yminmax[1] < 180:
salty1
7th January 2016, 01:45
Hint, it's an array:
if Yminmax[1] < 180:
:thanks::thanks::thanks:
LigH
9th January 2016, 11:13
It seems that the media-autobuild_suite supports compiling mpv with support for VapourSynth, but only if VapourSynth is installed. So I wonder, how would I install VapourSynth inside an MSYS2/MinGW building environment? I guess I would more or less follow Linux installation steps, but I don't know if MSYS2 prefers different package managers...
__
P.S.:
VapourSynth installed in Windows is recognized only when it was installed to the default "Program Files (x86)" folder. In addition, it is not meant to recognize *.vpy files as media source now; but you might be able to use VapourSynth video filters inside mpv then (e.g. dare to apply QTGMC to a decoded video stream)... check if it is available:
mpv -vf help
Myrsloik
14th January 2016, 00:27
It seems that the media-autobuild_suite supports compiling mpv with support for VapourSynth, but only if VapourSynth is installed. So I wonder, how would I install VapourSynth inside an MSYS2/MinGW building environment? I guess I would more or less follow Linux installation steps, but I don't know if MSYS2 prefers different package managers...
__
P.S.:
VapourSynth installed in Windows is recognized only when it was installed to the default "Program Files (x86)" folder. In addition, it is not meant to recognize *.vpy files as media source now; but you might be able to use VapourSynth video filters inside mpv then (e.g. dare to apply QTGMC to a decoded video stream)... check if it is available:
mpv -vf help
That's an unsupported solution really, nobody does that. You're probably actually better off modifying the mpv build so it'll find the headers needed. If you really want to try that. Or poking wm4 to demand better windows support.
Myrsloik
14th January 2016, 00:34
I made a portable version of VapourSynth for those of you who hate installing things. Simply get the appropriate embedded python (https://www.python.org/downloads/release/python-351/) and unzip VapourSynth in the same directory (overwrite existing files).
Obviously only vspipe works for output (vfw and vsfs require installed files).
It's possible to use VapourSynth Editor if extracted into the python/vapoursynth dir as well.
64bit (https://dl.dropboxusercontent.com/u/73468194/vapoursynth64-portable-test.7z)
32bit (https://dl.dropboxusercontent.com/u/73468194/vapoursynth32-portable-test.7z)
LigH
14th January 2016, 01:26
I made a portable version of VapourSynth for those of you who hate installing things.
Hooray! Selur (Hybrid) will praise you for this version! :D
Selur
14th January 2016, 05:46
Nice! -> Doing some testing over the weekend. :)
an3k
15th January 2016, 11:52
Is it normal that there is no auto completion for the core functions? Eg. for core.[TAB][TAB] or core.std.[TAB][TAB]
First I thought something is broken but print(core.get_plugins()) (and a manual formatting afterwards) showed me all available plugins, their names and functions and a simple tryout of core.lsmas.LibavSMASHSource() showed that it is actually available and working.
I know it's Python but to be honest I'm not using VapourSynth to learn Python but as an replacement for AviSynth on Linux. The documentation definitely needs to be improved, eg. remove the Python reference and instead add a short howto of how users can find out how to load a given plugin as well as a list of basic functions like set_output()
Currently most of the doc (even the one of each plugin) is written for Windows which is kind of useless because AviSynth is still much better and since VS is running inside of Python there shouldn't be a difference between VS on Windows and VS on Linux beside path formatting.
I'm sorry for sounding ungrateful. I'm definitely not. I'm just a bit tired to trying things out when there could be a doc giving you hints so you know where to look (again, Python reference is not a hint). I actually made a build script that installs all dependencies (apt-get), grabs the latest sources for yasm, libenca, ffmpeg, x264, L-SMASH, etc. and builds these into your home directory so that you have a kind-of-portable user-installation of VapourSynth. It already builds without errors and VS is working but it's in preAlpha stage thus I haven't released it yet but definitely will.
Myrsloik
15th January 2016, 11:59
Is it normal that there is no auto completion for the core functions? Eg. for core.[TAB][TAB] or core.std.[TAB][TAB]
First I thought something is broken but print(core.get_plugins()) (and a manual formatting afterwards) showed me all available plugins, their names and functions and a simple tryout of core.lsmas.LibavSMASHSource() showed that it is actually available and working.
I know it's Python but to be honest I'm not using VapourSynth to learn Python but as an replacement for AviSynth on Linux. The documentation definitely needs to be improved, eg. remove the Python reference and instead add a short howto of how users can find out how to load a given plugin as well as a list of basic functions like set_output()
Currently most of the doc (even the one of each plugin) is written for Windows which is kind of useless because AviSynth is still much better and since VS is running inside of Python there shouldn't be a difference between VS on Windows and VS on Linux beside path formatting.
I'm sorry for sounding ungrateful. I'm definitely not. I'm just a bit tired to trying things out when there could be a doc giving you hints so you know where to look (again, Python reference is not a hint). I actually made a build script that installs all dependencies (apt-get), grabs the latest sources for yasm, libenca, ffmpeg, x264, L-SMASH, etc. and builds these into your home directory so that you have a kind-of-portable user-installation of VapourSynth. It already builds without errors and VS is working but it's in preAlpha stage thus I haven't released it yet but definitely will.
What's windows specific in the docs? Apart from maybe one or two example paths which linux users easily should identify as such.
If you have no intention of learning any Python at all you're going to have a horrible day. That's the way it is.
And WHY would I ever remove the parts of the docs that are useful for people who know Python? That makes absolutely no sense.
Hint:
core.list_functions() for formatted string output
an3k
15th January 2016, 12:36
What's windows specific in the docs? Apart from maybe one or two example paths which linux users easily should identify as such.
If you have no intention of learning any Python at all you're going to have a horrible day. That's the way it is.
And WHY would I ever remove the parts of the docs that are useful for people who know Python? That makes absolutely no sense.
Hint:
core.list_functions() for formatted string output
Nobody would have to learn Python if the documentation would be written for the users point of view. Just as an example: http://www.vapoursynth.com/doc/functions/crop.html says that eg. std.CropRel(clip,0,0,132,132) will work. It doesn't. You know how to call CropRel corrently because you wrote VS but beginners (= those who need a documentation and for whose the documentation was written) don't and wonder what's going on. I know that core (or c or whatever the user chooses) has to specified before and depending on what is specified the std.CropRel() path is different but just use some defaults, eg. core, clip, etc. because it doesn't matter at all if you use core, C0R3, c or whatever to specify vs.get_core().
That way users can copy&paste from the documentation and learn what's the difference between eg. core.std.CropRel() and core.lsmas.LSMASHVideoSource()
People who know Python do need the Python reference? Nevermind. Remove it from the Documentation not from the website or put it into the "Advanced Users" section. It just discourages new users to get into VapourSynth like "Why do I need all of this, I just want to do simple cropping and deinterlacing." Python reference for advanced users is fine.
EDIT: I'm sorry, I mixed two links. Instead of Python Reference I meant the Python Tutorial. "If you don’t know the basics of Python, you may want to check out the tutorial." - If a new user don't know Python he definitely does NOT want to read the whole 16 chapters of Python documentation or digg through it, especially NOT after just getting VapourSynth installed. A better approach would be to post an example script that creates a eg. 10 second video with the text "Yeah, VapourSynth is alive and kickin'" or something you prefer but also cheers the users victory of being done. And with comments in the script the user will learn what to use, etc.
As I said: you wrote the documentation from your point of view but since you know Python very well and also how VS works it's 100% clear to you what each bit of the doc means. From the users point of view it's just confusing.
Whatsoever, you feel affronted and very likely will me ignore completely from now on. That's funny because I just said that the documentation could be improved and AFAIK you are not a professional technical documentation writer!?!
Myrsloik
15th January 2016, 14:27
Nobody would have to learn Python if the documentation would be written for the users point of view. Just as an example: http://www.vapoursynth.com/doc/functions/crop.html says that eg. std.CropRel(clip,0,0,132,132) will work. It doesn't. You know how to call CropRel corrently because you wrote VS but beginners (= those who need a documentation and for whose the documentation was written) don't and wonder what's going on. I know that core (or c or whatever the user chooses) has to specified before and depending on what is specified the std.CropRel() path is different but just use some defaults, eg. core, clip, etc. because it doesn't matter at all if you use core, C0R3, c or whatever to specify vs.get_core().
That way users can copy&paste from the documentation and learn what's the difference between eg. core.std.CropRel() and core.lsmas.LSMASHVideoSource()
People who know Python do need the Python reference? Nevermind. Remove it from the Documentation not from the website or put it into the "Advanced Users" section. It just discourages new users to get into VapourSynth like "Why do I need all of this, I just want to do simple cropping and deinterlacing." Python reference for advanced users is fine.
EDIT: I'm sorry, I mixed two links. Instead of Python Reference I meant the Python Tutorial. "If you don’t know the basics of Python, you may want to check out the tutorial." - If a new user don't know Python he definitely does NOT want to read the whole 16 chapters of Python documentation or digg through it, especially NOT after just getting VapourSynth installed. A better approach would be to post an example script that creates a eg. 10 second video with the text "Yeah, VapourSynth is alive and kickin'" or something you prefer but also cheers the users victory of being done. And with comments in the script the user will learn what to use, etc.
As I said: you wrote the documentation from your point of view but since you know Python very well and also how VS works it's 100% clear to you what each bit of the doc means. From the users point of view it's just confusing.
Whatsoever, you feel affronted and very likely will me ignore completely from now on. That's funny because I just said that the documentation could be improved and AFAIK you are not a professional technical documentation writer!?!
I don't know Python very well. I just look up what I need in the python docs usually... For some reason they have a scary similarity to the VapourSynth doc structure... I wonder why.
And reading the python tutorial is of course optional too. I simply didn't see any reason to spend the time to recreate something that says almost the same things. Basic control flow you have to learn whether you want it or not. Normal Avisynth barely does it so yes, you need to know more to use VapourSynth.
No, I'm not a technical documentation writer. You can tell I'm not because the documentation doesn't start with 5 pages of legal disclaimers such as "don't lick the power cord while in use". Are you?
Selur
15th January 2016, 19:20
I made a portable version of VapourSynth for those of you who hate installing things.
Tried it and failed,...
Here's what I did:
created a folder named Vapoursynth
extracted vapoursynth64-portable-test into that folder (after downloading it from https://dl.dropboxusercontent.com/u/73468194/vapoursynth64-portable-test.7z)
extracted python-3.5.1-embed-amd64 into that folder (after downloading it from https://www.python.org/ftp/python/3.5.1/python-3.5.1-embed-amd64.zip)
extracted the vslsmashsource.dll from L-SMASH-Works-r859-20160109-64bit into a subfolder of Vapoursynth\vapoursynth64\plugins named LSmashSource (after downloading L-SmASH-Works from https://www.dropbox.com/sh/3i81ttxf028m1eh/AAABkQn4Y5w1k-toVhYLasmwa?dl=0)
created a new Temp-folder and saved a test.vpy file in it:
import vapoursynth as vs
core = vs.get_core()
core.std.LoadPlugin(path=r'G:\Hybrid\VapourSynth\vapoursynth64\plugins\vslsmashsource.dll')
clip = core.lsmas.LWLibavSource(source="F:\TestClips&Co\test.avi")
clip.set_output().
opened a Windows command prompt and changed into the Vapoursynth folder.
called the following call:
VSPipe.exe h:\Temp\test.vpy - --y4m | g:\Hybrid\x264.exe --demuxer y4m -o h:\Output\test.264 -
and got this:
y4m [info]: 640x352p 0:0 @ 25/1 fps (cfr)
No frame returned at the end of processing by LWLibavSourcex264 [
info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 AVX2 LZCNT BMI2
x264 [info]: profile High, level 3.0
right before I got a 'VSPipe.exe has stopped working'
I'm new to Vapoursynth, so did I miss something obvious?
Cu Selur
Ps.: I really like the idea of a portable Vapoursynth version for Windows. :)
TheFluff
15th January 2016, 20:53
words
While it is true that Vapoursynth could definitely use a better tutorial/more gentle introduction on how to do things, I don't think you should criticize the reference documentation for being reference documentation. It has its place.
That being said, if you don't have at least basic programming knowledge and/or are willing to learn, Vapoursynth is probably not for you. With Avisynth you can get away with not really being a coder, you can just copypaste a bunch of filter lines, but with VS you sorta need to write actual code. Or at least you should, because the possibility of doing that is kinda the raison d'etre of VS.
Myrsloik
15th January 2016, 21:45
Tried it and failed,...
Here's what I did:
...
I'm new to Vapoursynth, so did I miss something obvious?
Cu Selur
Ps.: I really like the idea of a portable Vapoursynth version for Windows. :)
I tried in a completely clean windows 10 x64 vm with all updates. And used the same links as you in order. It works.
The only thing I had to change was comment out the loadplugin line (since it's already autoloaded when placed in vapoursynth64\plugins) and to add an r to escape the source path which your script doesn't.
So I have no idea why it won't work for you. Try simplifying it, like encode a blankclip with instead of lsmash source. Or run "vspipe -v" which will fail if vapoursynth is completely broken. Maybe you can narrow it down a bit more.
Btw, OS?
Selur
15th January 2016, 22:03
Btw, OS?
Win 10 pro 64bit
Or run "vspipe -v"
reports:
VapourSynth Video Processing Library
Copyright (c) 2012-2015 Fredrik Mellbin
Core R30
API R3.4
Options: -
and to add an r to escape the source path which your script doesn't.
using:
import vapoursynth as vs
core = vs.get_core()
core.std.LoadPlugin(path=r'G:/Hybrid/VapourSynth/vapoursynth64/plugins/LSmashSource/vslsmashsource.dll')
clip = core.lsmas.LWLibavSource(source=r"F:/TestClips&Co/test.avi")
clip.set_output() still crashes VSPipe.exe.
using:
import vapoursynth as vs
core = vs.get_core()
#core.std.LoadPlugin(path=r'G:/Hybrid/VapourSynth/vapoursynth64/plugins/LSmashSource/vslsmashsource.dll')
#clip = core.lsmas.LWLibavSource(source=r"F:/TestClips&Co/test.avi")
clip = core.std.BlankClip()
clip.set_output()
gives me:
import vapoursynth as vs
core = vs.get_core()
#core.std.LoadPlugin(path=r'G:/Hybrid/VapourSynth/vapoursynth64/plugins/LSmashSource/vslsmashsource.dll')
#clip = core.lsmas.LWLibavSource(source=r"F:/TestClips&Co/test.avi")
clip = core.std.BlankClip()
clip.set_output()
using:
import vapoursynth as vs
core = vs.get_core()
#core.std.LoadPlugin(path=r'G:/Hybrid/VapourSynth/vapoursynth64/plugins/LSmashSource/vslsmashsource.dll')
#clip = core.lsmas.LWLibavSource(source=r"F:/TestClips&Co/test.avi")
clip = core.std.BlankClip(format=vs.YUV420P8)
clip.set_output() works,... (using YUV420P16 instead of YUV420P8 works too)
Not sure if it helps, but the test.avi I use can be downloaded through my GoogleDrive (https://drive.google.com/folderview?id=0B_WxUS1XGCPASUZibG5XZkRfeTg&usp=sharing).
Cu Selur
Myrsloik
15th January 2016, 22:25
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.
Selur
15th January 2016, 22:30
Okay, still it seems strange that VSPipe is crashing, so even if the plugin crashes, VSPipe should throw an error but not crash the way it does.
Myrsloik
15th January 2016, 22:42
Okay, still it seems strange that VSPipe is crashing, so even if the plugin crashes, VSPipe should throw an error but not crash the way it does.
It's actually a check in the core. I do this to catch naughty plugin writers. Turns out that people only report things when they crash and ignore huge warning output otherwise...
Selur
15th January 2016, 22:49
Okay, if that is how it's supposed to be. :)
btw. is http://www.vapoursynth.com/doc/pluginlist.html kept up-to-date or is there another resource to look for Vapoursynth plugins?
Myrsloik
15th January 2016, 22:51
Okay, if that is how it's supposed to be. :)
btw. is http://www.vapoursynth.com/doc/pluginlist.html kept up-to-date or is there another resource to look for Vapoursynth plugins?
It's mostly up to date. There may be a few less common ones at https://github.com/HomeOfVapourSynthEvolution I forgot but that's it.
jackoneill
16th January 2016, 22:28
Is it normal that there is no auto completion for the core functions? Eg. for core.[TAB][TAB] or core.std.[TAB][TAB]
But there is. (I had no idea the Python interpreter has tab completion.)
vs.[tab][tab], core.[tab][tab], and core.std.[tab][tab] work here. core.[tab][tab] doesn't list the namespaces because they are looked up on demand, if I remember correctly. The functions are listed, though.
Lynx_TWO
16th January 2016, 23:59
Ringing appears with a just few taps with sinc, because this kernel has a slow decrease. So if you feel the need use it, you want it with many taps.
You are correct. The sinc function implemented in AviSynth 2.6(?) used 256 taps, however, for some reason you can only use a maximum of 128 taps in fmtconv (at least, using more gave me an error). The best re-size I have ever seen was sinc used with 1024 taps (it took a while to resize). As taps increase, you get closer and closer to a perfect resize, albeit at significant calculation cost, and the differences become less and less clear on an exponential scale. The movie industry has known this for a long time, hence the reason they prefer the sinc algorithm. I would love to have the ability to use sinc with 2048 or 4096 taps in fmtconv. I suspect the ringing would become a non-issue... Anyone willing to try it? :)
an3k
17th January 2016, 03:29
So I have this script:import vapoursynth as vs
import havsfunc as havs
core = vs.get_core()
clip = core.lsmas.LWLibavSource("/var/tmp/S01E01_1.vob")
clip = havs.QTGMC(clip,Preset="Slow",FPSDivisor=2,Sharpness=1.2,SLMode=1,EZDenoise=2.5,NoisePreset="Slow",TFF=True)
# left, right, top, bottom
clip = core.std.CropRel(clip,4,4,4,2)
clip = core.resize.Lanczos(clip,960,720)
clip.set_output()Command line is:vspipe vs_qtgmc_1.78.vpy - | x264 --level 4.0 --crf 22 --deblock -3:-3 --keyint 240 --ref 4 --chroma-qp-offset -2 --vbv-bufsize 31250 \
--vbv-maxrate 25000 --me umh --sar 1:1 --fps 25 --input-res 960x720 --input-csp i420 -o /var/tmp/recoded.264 -And I get this:
http://i.imgur.com/qNgl3vD.png
and this
http://i.imgur.com/WRyjtM6.png
With the very same script (but for AviSynth) on my ~8 year old Core2Quad Q9650 with 8 GB RAM on Windows 7 Professional 64-Bit I also get ~8 fps and 100% CPU usage. Where does this huge performance impact comes from?LoadPlugin("C:\Program Files (x86)\MeGUI\tools\avisynth_plugin\mvtools2.dll")
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\avisynth_plugin\mt_masktools-26.dll")
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\avisynth_plugin\nnedi3.dll")
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\avisynth_plugin\RemoveGrainSSE2.dll")
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\avisynth_plugin\RepairSSE2.dll")
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\avisynth_plugin\SSE2Tools.dll")
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\avisynth_plugin\FFT3DFilter.dll")
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\avisynth_plugin\dfttest.dll")
Import("C:\Program Files (x86)\MeGUI\tools\avisynth_plugin\QTGMC-3.32.avsi")
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("C:\RIPS\Neon Genesis Evangelion\S01E01\S01E01.d2v", cpu=4, info=3)
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\avisynth_plugin\ColorMatrix.dll")
ColorMatrix(hints=true, threads=0)
QTGMC(Preset="Slow",FPSDivisor=2,Sharpness=1.2,SLMode=1,EZDenoise=2.5,NoisePreset="Slow")
crop(4, 4, -4, -2)
Lanczos4Resize(960,720)
ConvertToYV12()
feisty2
17th January 2016, 11:01
You are correct. The sinc function implemented in AviSynth 2.6(?) used 256 taps, however, for some reason you can only use a maximum of 128 taps in fmtconv (at least, using more gave me an error). The best re-size I have ever seen was sinc used with 1024 taps (it took a while to resize). As taps increase, you get closer and closer to a perfect resize, albeit at significant calculation cost, and the differences become less and less clear on an exponential scale. The movie industry has known this for a long time, hence the reason they prefer the sinc algorithm. I would love to have the ability to use sinc with 2048 or 4096 taps in fmtconv. I suspect the ringing would become a non-issue... Anyone willing to try it? :)
ideal sinc (something like taps=infinite) is like, some "theoretically" perfect low pass filter...
there are other methods that have better "visual" quality than sinc
downscaling: bicubic (b=-1,c=0) (http://forum.doom9.org/showthread.php?p=1748631#post1748631) or bicubic (-0.5,0.25) (http://forum.doom9.org/showthread.php?p=1748922#post1748922)
upscaling: EEDI3, NNEDI3
LigH
17th January 2016, 11:19
And I get this:
and this
With the very same script...
This is what I see. There are no images for me. The IMG tag may require static URLs to image files sometimes, depending on the forum software, often they don't support PHP locations with parameters as image URLs.
There are a few cooperative and simple image hosters out in the web, like imgur.com or frupic.frubar.net; may be recommendable instead of trying to embed attachments.
foxyshadis
17th January 2016, 12:52
This is what I see. There are no images for me. The IMG tag may require static URLs to image files sometimes, depending on the forum software, often they don't support PHP locations with parameters as image URLs.
There are a few cooperative and simple image hosters out in the web, like imgur.com or frupic.frubar.net; may be recommendable instead of trying to embed attachments.
They were attached but were deleted by another mod. I didn't see them so I dunno why.
Sangan
17th January 2016, 13:36
While it is true that Vapoursynth could definitely use a better tutorial/more gentle introduction on how to do things, I don't think you should criticize the reference documentation for being reference documentation. It has its place.
That being said, if you don't have at least basic programming knowledge and/or are willing to learn, Vapoursynth is probably not for you. With Avisynth you can get away with not really being a coder, you can just copypaste a bunch of filter lines, but with VS you sorta need to write actual code. Or at least you should, because the possibility of doing that is kinda the raison d'etre of VS.
Well... I kind of support the gist of an3k's post there... It looks like a massive amount of learning Phyton if you havent done that before and arent really a coder, before you could start using VS. I would really like to use VS for encoding, because it runs native on a Mac, not like AviSynth using Wine on 32 bit. I just really lack a starting point. Most people wanting to use VS actually come from AS, so it might be a help for starting, if you perhaps could put a small section in, that kind of explains steps, like taking an AS section/loading the index of a file/applying one filter... and show the code, that would be the appropriate one in VS. People learn in different ways, but I think some kind of practical starting point would be nice.
Maybe some time :)
sneaker_ger
17th January 2016, 13:46
http://www.vapoursynth.com/doc/gettingstarted.html
?
Sangan
17th January 2016, 13:54
http://www.vapoursynth.com/doc/gettingstarted.html
?
Yes, and no. It hasn't clicked yet... Maybe I should just brood some more.
an3k
17th January 2016, 23:48
I've linked the screenshots to imgur now.
Anyway, firstly you are using different source filter in your scripts. Why don't you use d2vsource in the vpy script as well? Secondly, to compare pure performance of the script, you should simply use vspipe --progress for vpy and AVSMeter for avs, without the encoder getting involved.
1) I don't want to use d2vsource as I did on Windows because it would be another circumstance (Indexing on Windows, moving the files onto linux, editing the d2v file). What's the problem with L-SMASH Works?
2) vspipe --progress shows just at what frame vapoursynth currently is. It doesn't show what plugin is eating up 100% cpu power.
Myrsloik
18th January 2016, 00:27
I've linked the screenshots to imgur now.
1) I don't want to use d2vsource as I did on Windows because it would be another circumstance (Indexing on Windows, moving the files onto linux, editing the d2v file). What's the problem with L-SMASH Works?
2) vspipe --progress shows just at what frame vapoursynth currently is. It doesn't show what plugin is eating up 100% cpu power.
1. I guess it should work. I haven't tried it much though. You can also try the new d2v creation thingy I guess.
2. The answer is probably mvanalyse. It usually is. Per filter instance cpu statistics are actually on my todo list... some day.
I'm curious. What hardware are you running it on since you have 24 threads? There could also be some issue with too many threads tripping over each other. Try vs.get_core(threads=6) or 12 or 18 or just some more random numbers smaller than 24 and see if it improves things. That'd be a great help.
I only regularly test things with 12 threads.
sl1pkn07
18th January 2016, 00:49
dgindex works with wine(-staging)
I also have 24 threads (double xeon x5650), for me works ok. but i'm not sure what is the problem
an3k
18th January 2016, 08:37
1. I guess it should work. I haven't tried it much though. You can also try the new d2v creation thingy I guess.
2. The answer is probably mvanalyse. It usually is. Per filter instance cpu statistics are actually on my todo list... some day.
I'm curious. What hardware are you running it on since you have 24 threads? There could also be some issue with too many threads tripping over each other. Try vs.get_core(threads=6) or 12 or 18 or just some more random numbers smaller than 24 and see if it improves things. That'd be a great help.
I only regularly test things with 12 threads.Sorry, I didn't understand what you mean in 1. and 2.
Hardware is a Xeon E5-2680 v3 (12 real cores + HyperThreading). I tried with threads=12, 4, 2 and 1 (thought there is a multi-threading issue) but processing just got slower and slower.
The source and target file is read from/written to /var/tmp. /var is on a 4-HDD RAID 0. If I just have to crop I do native encoding with x264 itself and here I get more than 100 fps for a 1920x1080p so I doubt the issue is caused by slow reading from/writing to HDD.
an3k
18th January 2016, 09:39
Ok, I did some more tests and I guess the problem is dfttest:
System A:
Intel Core2Quad Q9650
8 GB DDR2 RAM
Windows 7 Professional 64-Bit
System B:
Intel Xeon E5-2680 v3
32 GB DDR4 RAM
Ubuntu Server 14.04.3 64-Bit
Script AA:LoadPlugin("C:\Program Files (x86)\MeGUI\tools\avisynth_plugin\mvtools2.dll")
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\avisynth_plugin\mt_masktools-26.dll")
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\avisynth_plugin\nnedi3.dll")
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\avisynth_plugin\RemoveGrainSSE2.dll")
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\avisynth_plugin\RepairSSE2.dll")
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\avisynth_plugin\dfttest.dll")
Import("C:\Program Files (x86)\MeGUI\tools\avisynth_plugin\QTGMC-3.32.avsi")
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("E:\RIPS\Neon Genesis Evangelion\S01E01\S01E01.d2v", cpu=4, info=3)
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\avisynth_plugin\ColorMatrix.dll")
ColorMatrix(hints=true, threads=0)
QTGMC(Preset="Slow",FPSDivisor=2,Sharpness=1.2,SLMode=1,EZDenoise=2.5,NoisePreset="Slow")
crop(4, 4, -4, -2)
Lanczos4Resize(960,720)
ConvertToYV12()results in ~2,60 fps on System A with ~60 % CPU usage
Script BA:LoadPlugin("C:\Program Files (x86)\MeGUI\tools\avisynth_plugin\mvtools2.dll")
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\avisynth_plugin\mt_masktools-26.dll")
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\avisynth_plugin\nnedi3.dll")
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\avisynth_plugin\RemoveGrainSSE2.dll")
Import("C:\Program Files (x86)\MeGUI\tools\avisynth_plugin\QTGMC-3.32.avsi")
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("E:\RIPS\Neon Genesis Evangelion\S01E01\S01E01.d2v", cpu=4, info=3)
LoadPlugin("C:\Program Files (x86)\MeGUI\tools\avisynth_plugin\ColorMatrix.dll")
ColorMatrix(hints=true, threads=0)
QTGMC(FPSDivisor=2)
crop(4, 4, -4, -2)
Lanczos4Resize(960,720)
ConvertToYV12()results in ~6 fps on System A with ~40 to ~50 % CPU usage
Script AB:import vapoursynth as vs
import havsfunc as havs
core = vs.get_core()
core.std.LoadPlugin("libvslsmashsource.so.868")
core.std.LoadPlugin("libfmtconv.so")
core.std.LoadPlugin("libscenechange.so")
core.std.LoadPlugin("libtemporalsoften2.so")
core.std.LoadPlugin("libmvtools.so")
core.std.LoadPlugin("libdfttest.so")
core.std.LoadPlugin("libnnedi3.so")
clip = core.lsmas.LWLibavSource("/var/tmp/S01E01_1.vob")
clip = havs.QTGMC(clip,Preset="Slow",FPSDivisor=2,Sharpness=1.2,SLMode=1,EZDenoise=2.5,NoisePreset="Slow",TFF=True)
clip = core.std.CropRel(clip,4,4,4,2)
clip = core.resize.Lanczos(clip,960,720)
clip.set_output()results in ~8,50 fps on System B with ~100 % CPU usage
Script BB:import vapoursynth as vs
import havsfunc as havs
core = vs.get_core()
core.std.LoadPlugin("libvslsmashsource.so.868")
core.std.LoadPlugin("libfmtconv.so")
core.std.LoadPlugin("libscenechange.so")
core.std.LoadPlugin("libtemporalsoften2.so")
core.std.LoadPlugin("libmvtools.so")
core.std.LoadPlugin("libnnedi3.so")
clip = core.lsmas.LWLibavSource("/var/tmp/S01E01_1.vob")
clip = havs.QTGMC(clip,FPSDivisor=2,TFF=True)
clip = core.std.CropRel(clip,4,4,4,2)
clip = core.resize.Lanczos(clip,960,720)
clip.set_output()results in ~32 fps on System B with ~66 % CPU usage
sl1pkn07
18th January 2016, 10:41
@an3k
for creating d2v on linux you can use this: http://forum.doom9.org/showthread.php?t=173090 or this https://dl.dropboxusercontent.com/u/6596386/dgindex-modoki-20100428.tar.bz2. all CLI
an3k
18th January 2016, 17:04
@an3k
If you have a decent GPU in your rig, I'd suggest trying Denoiser='KNLMeansCL' instead of the default DFTTest/FFT3DFilter denoiser in QTGMC. It's probably faster.
Thanks for that suggestion but the problem is a) There is no space for a GPU, b) GPU Deinterlacer are really bad regards quality and c) It wouldn't be that slow if there weren't a bottleneck in dfttest. On Windows it is much faster than this port is on Linux.
feisty2
18th January 2016, 17:13
Thanks for that suggestion but the problem is a) There is no space for a GPU, b) GPU Deinterlacer are really bad regards quality and c) It wouldn't be that slow if there weren't a bottleneck in dfttest. On Windows it is much faster than this port is on Linux.
except knlmeanscl is not a deinterlacer..
Stephen R. Savage
18th January 2016, 17:45
You are correct. The sinc function implemented in AviSynth 2.6(?) used 256 taps, however, for some reason you can only use a maximum of 128 taps in fmtconv (at least, using more gave me an error). The best re-size I have ever seen was sinc used with 1024 taps (it took a while to resize). As taps increase, you get closer and closer to a perfect resize, albeit at significant calculation cost, and the differences become less and less clear on an exponential scale. The movie industry has known this for a long time, hence the reason they prefer the sinc algorithm. I would love to have the ability to use sinc with 2048 or 4096 taps in fmtconv. I suspect the ringing would become a non-issue... Anyone willing to try it? :)
Just use Nfinity-tap Lanczos. It converges (http://fooplot.com/plot/t9szbkz8ik)to sinc, and should in fact have lower error than a truncated sinc.
Myrsloik
19th January 2016, 17:09
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
19th January 2016, 23:20
As a note, autobuild suite (https://github.com/jb-alvarado/media-autobuild_suite) has been updated to also work with portable installations.
jmartinr
20th January 2016, 10:45
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
20th January 2016, 11:00
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
20th January 2016, 11:40
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
20th January 2016, 11:45
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
20th January 2016, 12:43
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
20th January 2016, 19:45
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
21st January 2016, 16:36
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
22nd January 2016, 04:22
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
22nd January 2016, 04:48
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
23rd January 2016, 14:01
where should i put the .py scripts in for the portable version?:confused::confused:
tObber166
25th January 2016, 20:11
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
25th January 2016, 20:51
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
25th January 2016, 21:13
:thanks:
speedyrazor
25th January 2016, 23:01
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
25th January 2016, 23:15
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
25th January 2016, 23:38
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
25th January 2016, 23:44
You should output the format your encoder needs as input.
speedyrazor
25th January 2016, 23:51
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
25th January 2016, 23:55
That does not tell me anything about what the format you want to encode to.
speedyrazor
25th January 2016, 23:59
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
26th January 2016, 00:01
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
26th January 2016, 00:04
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
26th January 2016, 00:13
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
26th January 2016, 07:07
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
26th January 2016, 14:12
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
26th January 2016, 16:42
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
26th January 2016, 17:42
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
26th January 2016, 17:53
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
26th January 2016, 18:53
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
26th January 2016, 19:02
Or easier, compile tivtc with an avs2.6 header
littlepox
26th January 2016, 19:03
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
26th January 2016, 19:16
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
26th January 2016, 19:18
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
26th January 2016, 19:53
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
26th January 2016, 21:57
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
27th January 2016, 02:47
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
27th January 2016, 05:40
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
27th January 2016, 10:25
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
27th January 2016, 11:48
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
27th January 2016, 16:27
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
29th January 2016, 05:19
Is there VS support in VirtualDub yet?
sneaker_ger
29th January 2016, 07:11
VapourSynth has had a VfW module to enable support for software like VirtualDub for years.
LigH
29th January 2016, 09:00
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
30th January 2016, 23:09
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
2nd February 2016, 14:00
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
2nd February 2016, 17:36
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
3rd February 2016, 13:28
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
3rd February 2016, 18:14
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()
Myrsloik
3rd February 2016, 18:41
I released R31 (http://www.vapoursynth.com/2016/02/r31-boring-maintenance/)!
It mostly just fixes the that some format conversions were erroneously rejected. Changelog in the first post and all that...
Boulder
3rd February 2016, 18:52
Regarding the performance related changes made in R30 affecting source filters, is it just that the performance improvements require new versions of source filters or will they stop working altogether (or have some weird behaviour)?
Myrsloik
3rd February 2016, 18:58
Regarding the performance related changes made in R30 affecting source filters, is it just that the performance improvements require new versions of source filters or will they stop working altogether (or have some weird behaviour)?
All old filters will continue working exactly the way they always have. The only change is that filters now can request that a different cache strategy is used that minimizes the number of "out of order" frame requests.
speedyrazor
4th February 2016, 07:23
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_cmd.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()
Thanks for the code, it works well, with a small tweak. One question though is do you know how I would send a SIGINT signal to terminate this process?
splinter98
4th February 2016, 11:22
Thanks for the code, it works well, with a small tweak. One question though is do you know how I would send a SIGINT signal to terminate this process?
Try:
from signal import SIGINT
vspipe_process.send_signal(SIGINT)
or if you just want to kill the process you can also use one of the following:
#Both of these are the same on Windows
vspipe_process.terminate() #Sends SIGTERM on POSIX
vspipe_process.kill() #Sends SIGKILL on POSIX
speedyrazor
6th February 2016, 22:07
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()
This works, but it doesn't print in realtime on my Windows 7 system, the sdterr is blocked whilst the transcode is running. Is there anyway to get the VSPipe stderr out in realtime whilst it happening?
LigH
6th February 2016, 22:14
No clue about python; but other programming languages may need an output flush, possibly even a cooperative cycle to process messages.
LoRd_MuldeR
6th February 2016, 23:43
No clue about python; but other programming languages may need an output flush, possibly even a cooperative cycle to process messages.
That's right. However, the explicit fflush() is required inside the child process that writes something to stdout/stderr, not in the parent process that tries to read from the child's stdout/stderr.
So, this might be a problem in VSPipe - which is written in C++, by the way:
https://github.com/vapoursynth/vapoursynth/blob/master/src/vspipe/vspipe.cpp
If the child process is missing the required fflush()'s, there is nothing you can do on the parent's side! You have to fix the child process. And, indeed, after a quick look, it seems like VSPipe does not explicitly flush its stderr after the fprintf()'s.
(AFAIK, this is a Windows-only quirk)
speedyrazor
7th February 2016, 06:58
That's right. However, the explicit fflush() is required inside the child process that writes something to stdout/stderr, not in the parent process that tries to read from the child's stdout/stderr.
So, this might be a problem in VSPipe - which is written in C++, by the way:
https://github.com/vapoursynth/vapoursynth/blob/master/src/vspipe/vspipe.cpp
If the child process is missing the required fflush()'s, there is nothing you can do on the parent's side! You have to fix the child process. And, indeed, after a quick look, it seems like VSPipe does not explicitly flush its stderr after the fprintf()'s.
(AFAIK, this is a Windows-only quirk)
Thanks for looking into this. In that case, is there a way to get VSPipe to write to a 'realtime' log, I can then read from that?
speedyrazor
7th February 2016, 13:46
Thanks for looking into this. In that case, is there a way to get VSPipe to write to a 'realtime' log, I can then read from that?
What I am trying to do is get the sdterr out from VSPipe in realtime so I can see when L-SMASH source gives me an error (when encountering a bad file), currently it just continues to process and ffmpeg encodes a stuck frame for the duration of the file.
Myrsloik
10th February 2016, 18:18
Here's a vspipe you can test. (https://dl.dropboxusercontent.com/u/73468194/VSPipe64_fflush.exe) It calls fflush on stderr after every frame.
Selur
16th February 2016, 20:26
Is there something similar to 'LoadDll(...)' in Vapoursynth.
Using the portable version and for example DFTTest I have to put libfftw3f-3 next to the DFTTest.dll, but I would prefer to keep it inside a separate folder and load it explicitly, is something like that possible?
Myrsloik
16th February 2016, 20:30
I really don't recommend doing this. I think it's very wrong.
But calling the windows api loadlibrary using ctypes directly from python should do what you want.
Selur
16th February 2016, 20:39
Can you be a bit more specific?
atm. my script looks like this:
# Imports
import vapoursynth as vs
import sys
core = vs.get_core()
# Loading Plugins
core.std.LoadPlugin(path="G:/Hybrid/Vapoursynth/vapoursynth64/plugins/DenoiseFilter/DFTTest/DFTTest.dll")
core.std.LoadPlugin(path="G:/Hybrid/Vapoursynth/vapoursynth64/plugins/SourceFilter/FFMS2/ffms2.dll")
# Loading Source: F:/TestClips&Co/test.avi
clip = core.ffms2.Source(source="F:/TESTCL~1/test.avi",cachefile="H:/Temp/avi_0197468a3716844ade54f3f30f60eeda_491.ffindex",fpsnum=25)
# Denoising
clip = core.dfttest.DFTTest(clip=clip)
# Output
clip.output(sys.stdout, y4m=1)
and I would like to place libfftw3f-3 at
G:/Hybrid/Vapoursynth/vapoursynth64/plugins/libfftw/libfftw3f-3.dll
looking at https://docs.python.org/2/library/ctypes.html#module-ctypes I don't see how to load the dll in a way that Vapoursynth can use it for in example DFTTest or other filters.
Myrsloik
16th February 2016, 20:51
The key here is that if a library with a certain filename, regardless of path, has been loaded into a process then loading the dll again without specifying an absolute path will simply return a handle to the already loaded copy.
This is of course advanced windows and insane python but I suspect this is the same thing loaddll does.
This actually has nothing to do with vapoursynth. You're just messing with the dll loading of the process.
My guess. Don't forget to assign it to a global variable to ensure it stays loaded. I guess.
import ctypes
Dllref = ctypes.windll.LoadLibrary(path)
Selur
16th February 2016, 20:54
Will do. Thanks! :)
Selur
20th February 2016, 18:47
std.Levels(clip clip[, int min_in=0, int max_in, float gamma=1.0, int min_out=0, int max_out, int[] planes=[0, 1, 2]])
source: http://www.vapoursynth.com/doc/functions/levels.html
What are the defaults for max_in/max_out or are there really none? 255? (seems strange to not have no defaults for parameters that are followed by parameters which have defaults)
jackoneill
20th February 2016, 19:34
source: http://www.vapoursynth.com/doc/functions/levels.html
What are the defaults for max_in/max_out or are there really none? 255? (seems strange to not have no defaults for parameters that are followed by parameters which have defaults)
The default value of max_in and max_out is the format’s maximum allowed value.
Source: http://www.vapoursynth.com/doc/functions/levels.html
Selur
20th February 2016, 19:36
Missed that, but still unsure what the 'the format’s maximum allowed value' is,...
feisty2
20th February 2016, 19:58
Missed that, but still unsure what the 'the format’s maximum allowed value' is,...
255 uint8_t
65535 uint16_t
1.0 float
Selur
20th February 2016, 20:01
Thanks!
mawen1250
21st February 2016, 03:49
There's actually no limitation for float format.
As for the conversion between float and 8-bit int:
0.0~1.0 corresponds to 16~235/0~255 for Y/R/G/B.
-0.5~0.5 corresponds to 16~240/0.5~255.5 for U/V.
jackoneill
21st February 2016, 12:24
There's actually no limitation for float format.
As for the conversion between float and 8-bit int:
0.0~1.0 corresponds to 16~235/0~255 for Y/R/G/B.
-0.5~0.5 corresponds to 16~240/0.5~255.5 for U/V.
How are you going to have 0.5 and 255.5 in 8 bit int?
mawen1250
22nd February 2016, 13:44
How are you going to have 0.5 and 255.5 in 8 bit int?
You won't have it as a single pixel value though.
It's the definition of full range UV where 128±(255/2) corresponds to 0±0.5.
2-perf
25th February 2016, 22:21
Hi,
I'm a total newbie to video encoding. A friend at work heard me saying that I was using Handbrake to encode some Quicktime files to Blu-ray and told me I should be using a frame server... WTF? I replied to him!
Anyway he came to my place, set me up with:
- python-3.5.1-amd64.exe
- ffms2-2.22-msvc (I'm using the x64 flavor)
- vapoursynth-r29.exe (x64 flavor I guess)
- x264_launcher.2016-02-06.exe
He wrote me a VapourSynth script whish looks like this:
import vapoursynth as vs
# get the core instance
core = vs.get_core()
# load a native vapoursynth plugin, you can also use the auto-loading
# you should use absolute paths as the working directory may not be what you think it is
core.std.LoadPlugin(r'S:\Dropbox\softwares\portableapps\codec_encoder\ffms2-2.22-msvc\x64\ffms2.dll')
# open a video file; ret is now a clip object
path = r'D:\restauration\projet\tropico\deliveries\master\tropico.mov'
ret = core.ffms2.Source( source = path )
# flip the video a bit
#ret = core.std.Transpose( ret )
# set the clip to be output
ret.set_output()
The things is it fails 9 times out of 10 when trying to start the second pass.
Here's the .log (Well, I hope). Sorry I'm a digital colorist not a computer geek. :p
Simple x264 Launcher (Build #1012), built 2016-02-06
Job started at 2016-02-18, 22:19:28.
Source file : D:\encodage\projet\tropico\script.vpy
Output file : D:\encodage\projet\tropico\output\script.264
--- SYSTEMINFO ---
Binary Path : C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2
Avisynth : No
VapourSynth : Yes
--- SETTINGS ---
Encoder : x264 (H.264/AVC), x64, 8-Bit
Source : VapourSynth (vpy)
RC Mode : 2-Pass
Preset : slower
Tuning : Film
Profile : High
Custom : --level 4.1 --ref 4 --subme 10 --psy-rd 1.00:0.15 --merange 24 --deadzone-inter 21 --deadzone-intra 11 --no-fast-pskip --cqm flat --chroma-qp-offset 3 --threads 12 --lookahead-threads 1 --slices 4 --no-dct-decimate --bluray-compat --vbv-maxrate 38000 --vbv-bufsize 30000 --bframes 3 --b-pyramid 1 --weightb --open-gop --weightp 1 --keyint 24 --min-keyint 1 --rc-lookahead 24 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --qcomp 0.00 --qpmin 0
--- CHECK VERSION ---
Detect video encoder version:
Creating process:
"C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2\toolset\x64\x264_8bit_x64.exe" --version
x264 0.148.2665 a01e339
(libswscale 4.0.100)
(libavformat 57.21.101)
(ffmpegsource 2.22.0.1)
built by Komisar on Jan 18 2016, gcc: 4.8.4 (multilib.generic.Komisar)
x264 configuration: --bit-depth=8 --chroma-format=all
libx264 configuration: --bit-depth=8 --chroma-format=all
x264 license: GPL version 2 or later
libswscale/libavformat/ffmpegsource license: GPL version 2 or later
Detect video source version:
Creating process:
"C:\Program Files (x86)\VapourSynth\core64\vspipe.exe" --version
VapourSynth Video Processing Library
Copyright (c) 2012-2015 Fredrik Mellbin
Core R29
API R3.2
Options: -
> x264 revision: 2665 (core #148)
>
VapourSynth version: r29 (API r3)
--- GET SOURCE INFO ---
Creating process:
"C:\Program Files (x86)\VapourSynth\core64\vspipe.exe" --info D:\encodage\projet\tropico\script.vpy -
Width: 1920
Height: 1080
Frames: 7491
FPS: 24000/1001 (23.976 fps)
Format Name: YUV422P10
Color Family: YUV
Bits: 10
SubSampling W: 1
SubSampling H: 0
Resolution: 1920x1080
Frame Rate: 24000/1001
No. Frames: 7491
--- ENCODING PASS #1 ---
Creating input process:
"C:\Program Files (x86)\VapourSynth\core64\vspipe.exe" --y4m D:\encodage\projet\tropico\script.vpy -
Creating encoder process:
"C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2\toolset\x64\x264_8bit_x64.exe" --bitrate 35000 --pass 1 --stats D:\encodage\projet\tropico\output\script.stats --preset slower --tune film --profile high --level 4.1 --ref 4 --subme 10 --psy-rd 1.00:0.15 --merange 24 --deadzone-inter 21 --deadzone-intra 11 --no-fast-pskip --cqm flat --chroma-qp-offset 3 --threads 12 --lookahead-threads 1 --slices 4 --no-dct-decimate --bluray-compat --vbv-maxrate 38000 --vbv-bufsize 30000 --bframes 3 --b-pyramid 1 --weightb --open-gop --weightp 1 --keyint 24 --min-keyint 1 --rc-lookahead 24 --colorprim bt709 --transfer bt709 --colormatrix bt709 --qcomp 0.00 --qpmin 0 --output D:\encodage\projet\tropico\output\script.264 --frames 7491 --demuxer y4m --stdin y4m -
y4m [info]: 1920x1080p 0:0 @ 24000/1001 fps (cfr)
resize [warning]: converting from yuv422p16le to yuv420p16le
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x264 [info]: profile Main, level 4.1
x264 [info]: frame I:339 Avg QP:10.89 size:467818
x264 [info]: frame P:2145 Avg QP:13.96 size:277862
x264 [info]: frame B:5007 Avg QP:18.17 size:120544
x264 [info]: consecutive B-frames: 5.1% 5.4% 35.4% 54.0%
x264 [info]: mb I I16..4: 41.5% 0.0% 58.5%
x264 [info]: mb P I16..4: 43.0% 0.0% 0.0% P16..4: 35.5% 0.0% 0.0% 0.0% 0.0% skip:21.5%
x264 [info]: mb B I16..4: 12.5% 0.0% 0.0% B16..8: 26.5% 0.0% 0.0% direct:26.8% skip:34.2% L0:10.4% L1:14.9% BI:74.8%
x264 [info]: direct mvs spatial:99.7% temporal:0.3%
x264 [info]: coded y,uvDC,uvAC intra: 94.9% 39.3% 19.9% inter: 47.8% 11.9% 5.6%
x264 [info]: i16 v,h,dc,p: 14% 9% 65% 12%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 12% 9% 20% 10% 11% 11% 9% 10% 10%
x264 [info]: i8c dc,h,v,p: 65% 16% 16% 4%
x264 [info]: Weighted P-Frames: Y:3.0% UV:0.8%
x264 [info]: kb/s:34776.07
encoded 7491 frames, 25.61 fps, 34776.07 kb/s
vpyp [info]: Output 7491 frames in 292.32 seconds (25.63 fps)
Final file size is 1.26 GB bytes.
--- ENCODING PASS #2 ---
Creating input process:
"C:\Program Files (x86)\VapourSynth\core64\vspipe.exe" --y4m D:\encodage\projet\tropico\script.vpy -
Creating encoder process:
"C:\Program Files (x86)\MuldeR\Simple x264 Launcher v2\toolset\x64\x264_8bit_x64.exe" --bitrate 35000 --pass 2 --stats D:\encodage\projet\tropico\output\script.stats --preset slower --tune film --profile high --level 4.1 --ref 4 --subme 10 --psy-rd 1.00:0.15 --merange 24 --deadzone-inter 21 --deadzone-intra 11 --no-fast-pskip --cqm flat --chroma-qp-offset 3 --threads 12 --lookahead-threads 1 --slices 4 --no-dct-decimate --bluray-compat --vbv-maxrate 38000 --vbv-bufsize 30000 --bframes 3 --b-pyramid 1 --weightb --open-gop --weightp 1 --keyint 24 --min-keyint 1 --rc-lookahead 24 --colorprim bt709 --transfer bt709 --colormatrix bt709 --qcomp 0.00 --qpmin 0 --output D:\encodage\projet\tropico\output\script.264 --frames 7491 --demuxer y4m --stdin y4m -
y4m [error]: bad sequence header magic
x264 [error]: could not open input file `-'
WARNING: Input process exited with error (code: -1073741819), your encode might be *incomplete* !!!
IMPORTANT: The Vapoursynth process terminated abnormally. This means Vapoursynth or one of your Vapoursynth-Plugin's just crashed.
PROCESS EXITED WITH ERROR CODE: -1
Thanks for your patience.
jackoneill
26th February 2016, 11:57
Hi,
I'm a total newbie to video encoding. A friend at work heard me saying that I was using Handbrake to encode some Quicktime files to Blu-ray and told me I should be using a frame server... WTF? I replied to him!
Anyway he came to my place, set me up with:
- python-3.5.1-amd64.exe
- ffms2-2.22-msvc (I'm using the x64 flavor)
- vapoursynth-r29.exe (x64 flavor I guess)
- x264_launcher.2016-02-06.exe
He wrote me a VapourSynth script whish looks like this:
...
The things is it fails 9 times out of 10 when trying to start the second pass.
Here's the .log (Well, I hope). Sorry I'm a digital colorist not a computer geek. :p
...
Thanks for your patience.
If that's all you do in the VapourSynth script you don't need VapourSynth at all. Your copy of x264 can probably open tropico.mov directly (depends on how it was compiled).
Anyhow, the log you provided doesn't contain anything to indicate why vspipe fails. You should run vspipe directly a few times, until it prints something other than "Output N frames in M seconds": "vspipe.exe script.vpy NUL"
stax76
29th February 2016, 14:31
I have a problem updating StaxRip to latest VS and vslsmashsource, code below works using ffms2 but not using vslsmashsource, with old versions it has worked fine.
import vapoursynth as vs
core = vs.get_core()
core.std.LoadPlugin(r'D:\Projekte\GitHub\staxrip\bin\Apps\Plugins\vs\vslsmashsource\vslsmashsource.dll')
clip = core.lsmas.LibavSMASHSource(source = r'D:\Temp\Video\Clips\test.mp4')
clip = clip.resize.Bicubic(format=vs.COMPATBGR32)
clip.set_output()
Myrsloik
29th February 2016, 14:33
I have a problem updating StaxRip to latest VS and vslsmashsource, code below works using ffms2 but not using vslsmashsource, with old versions it has worked fine.
import vapoursynth as vs
core = vs.get_core()
core.std.LoadPlugin(r'D:\Projekte\GitHub\staxrip\bin\Apps\Plugins\vs\vslsmashsource\vslsmashsource.dll')
clip = core.lsmas.LibavSMASHSource(source = r'D:\Temp\Video\Clips\test.mp4')
clip = clip.resize.Bicubic(format=vs.COMPATBGR32)
clip.set_output()
Now describe how it doesn't work
stax76
29th February 2016, 14:36
that was quick :), returns blackness it seems, culprit is 'format=vs.COMPATBGR32', without that it's fine but StaxRip uses VFW...
stax76
29th February 2016, 14:44
vslsmashsource version I use is x64 r875
http://www.dropbox.com/sh/3i81ttxf028m1eh/AAABkQn4Y5w1k-toVhYLasmwa?dl=0
Myrsloik
29th February 2016, 14:46
vslsmashsource version I use is x64 r875
http://www.dropbox.com/sh/3i81ttxf028m1eh/AAABkQn4Y5w1k-toVhYLasmwa?dl=0
What if you update VS but not lsmashsource? That should work properly too.
stax76
29th February 2016, 15:01
What if you update VS but not lsmashsource? That should work properly too.
neither works with VS R31
stax76
29th February 2016, 20:10
Can it be fixed or is there a workaround?
Myrsloik
29th February 2016, 21:34
Can it be fixed or is there a workaround?
Your script works perfectly here when testing in 64bit versions of things. Unless your test.mp4 is magical or something I don't see any problem.
stax76
29th February 2016, 21:45
Your script works perfectly here when testing in 64bit versions of things. Unless your test.mp4 is magical or something I don't see any problem.
I've tried also LWLibavSource and another mp4 and one vob, always blackness, which OS are you using?
Myrsloik
29th February 2016, 21:50
I've tried also LWLibavSource and another mp4 and one vob, always blackness, which OS are you using?
Win10 with all updates. Can you cut a piece of one of the failing files?
stax76
29th February 2016, 22:13
really strange, can you try to open the preview window of the latest StaxRip build? Here it's totally black.
latest build: http://1drv.ms/1OqPDOe
Myrsloik
29th February 2016, 22:30
really strange, can you try to open the preview window of the latest StaxRip build? Here it's totally black.
latest build: http://1drv.ms/1OqPDOe
The preview works just as expected but I did notice some odd things:
Says python is version 3.5.0 when it's 3.5.1. Should check for msvcp120.dll and not msvcr120.dll for symmetry and to be more certain all of the runtime is actually installed. (some applications only install the C runtime and not the C++ part)
I have to install avisynth+ BEFORE I can get far enough to select to preview with lsmash in vapoursynth. Makes no sense to me.
stax76
29th February 2016, 23:43
Thanks for trying and reporting. I updated to Python 3.5.1 and msvcp120.dll. Regarding VS integration the hard part is done, a few small issues are left to do. I've no idea about the blackness issue at the moment but I keep looking.
jackoneill
1st March 2016, 08:33
Maybe put core.text.FrameNum(clip) before you convert to RGB, to see if the blackness comes from the source filter or somewhere else.
clip = clip.resize.Bicubic(format=vs.COMPATBGR32)
I hope you're passing a clip there, in your local copy of the script.
stax76
1st March 2016, 12:23
With adding core.text.FrameNum it shows blackness without framenumbers.
import vapoursynth as vs
core = vs.get_core()
core.std.LoadPlugin(r'D:\Projekte\GitHub\staxrip\bin\Apps\Plugins\vs\vslsmashsource\vslsmashsource.dll')
clip = core.lsmas.LibavSMASHSource(source = r'D:\Temp\Video\Clips\test.mp4')
clip = core.text.FrameNum(clip)
clip = clip.resize.Bicubic(format=vs.COMPATBGR32)
clip.set_output()
I'll ask StaxRip users to provide log files to narrow it down, if all fails I have to get rid of VFW which will cost 1-2 days.
LigH
1st March 2016, 12:31
If you export the resulting clip into a video file, instead of trying to display it directly in StaxRip, and then watch it in a different program (or use the script as input for VirtualDub, with disabled display speedups), does it contain useful content?
stax76
1st March 2016, 12:46
If you export the resulting clip into a video file, instead of trying to display it directly in StaxRip, and then watch it in a different program (or use the script as input for VirtualDub, with disabled display speedups), does it contain useful content?
D:\>"C:\Program Files (x86)\VapourSynth\core64\vspipe.exe" "D:\Temp\Video\Clips\sabo temp files\sabo_Preview.vpy" - --y4m | "D:\Projekte\GitHub\staxrip\bin\Apps\x265\x265_ml.exe" --crf 22 --preset ultrafast --frames 5062 --y4m --output "D:\Temp\Video\Clips\sabo temp files\sabo_out.hevc" -
Error: Can only apply y4m headers to YUV and Gray format clips
Output 0 frames in 0.04 seconds (0.00 fps)
x265 [error]: unable to open input file <->
If I open the vpy with VirtualDub sometimes my nvidia driver crashes so maybe the issue happens only on nvidia systems...
edit:
you mean disabling DirectX in VirtualDub's prefs dialog? Doesn't make a difference.
LigH
1st March 2016, 13:25
I did not think of using x265 to "save it as video", instead imagined a rather basic process, maybe some raw video in AVI. VSPipe being limited to YUV or Y8 is an additional unexpected limit here.
It looks like your script is supposed to output RGBA (or BGRA?); is that the only kind of video source you could display in StaxRip's preview window? Do you still use DIB functions?
At least it seems that the reason is related rather to displaying the result, less to handling it. Especially VirtualDub killing the display driver is highly suspicious.
__
P.S.: I can confirm "blackness" on W7 SP1 with Nvidia and some compression errors now and then. VirtualDub-AMD64 opens it, it is rather stable, the reported FourCC is more or less empty (I would assume 0x00000000). That may be the reason for the problems. Any more specific FourCC would be useful. I see no reason why your script shall not output e.g. YV12 ~ YUV422P8 (or at least YUY2 ~ COMPATYUY2), as long as your preview window uses a technology which can handle such video frames (okay - VapourSynth prefers planar YUV formats, which are not always supported by Windows easily and natively, that will certainly be a point where StaxRip64 will need an enhancement).
I'd like to point at sdk\include\vapoursynth\VapourSynth.h to emphasize:
typedef enum VSPresetFormat {
/* ... */
/* special for compatibility, if you implement these in any filter I'll personally kill you */
/* I'll also change their ids around to break your stuff regularly */
pfCompatBGR32 = cmCompat + 10,
pfCompatYUY2
} VSPresetFormat;
Wouldn't be surprised if this will be expanded to "filter or tool". :D
__
P.P.S.:
VirtualDub-AMD64 can display (format=vs.COMPATYUY2). More or less... it's vertically flipped (upside down). Reported decompressor is "Microsoft YUV (YUY2)".
jackoneill
1st March 2016, 14:31
And what if you pass matrix_in_s="709" to the resizer?
LigH
1st March 2016, 14:39
Ah, this does indeed display something useful in VD64 using COMPATBGR32 as output format.
So the reason was just some lack of initialization of attributes?
stax76
1st March 2016, 14:58
And what if you pass matrix_in_s="709" to the resizer?
my headache got better :)
but what if it's a SD source?
LigH
1st March 2016, 15:07
Then probably "601" instead of "709".
stax76
1st March 2016, 15:09
I've tried all documented options with a VOB source without success, 601 gives an error, 709 works with HD sources but gives blackness with a SD source.
http://www.vapoursynth.com/doc/functions/resize.html
Myrsloik
1st March 2016, 15:12
I've tried all documented options with a VOB source without success, 601 gives an error, 709 works with HD sources but gives blackness with a SD source.
http://www.vapoursynth.com/doc/functions/resize.html
470bg
You really should do this experimentation in a separate script with vspipe. Then it will tell you what the error is.
stax76
1st March 2016, 15:26
470bg
You really should do this experimentation in a separate script with vspipe. Then it will tell you what the error is.
gives also blackness
D:\>"C:\Program Files (x86)\VapourSynth\core64\vspipe.exe" "D:\Video\Samples\DVD\Pulp Fiction\VTS_01_1 temp files\VTS_01_1_Preview.vpy" - --y4m | "D:\Projekte\GitHub\staxrip\bin\Apps\x265\x265_ml.exe" --crf 22 --preset ultrafast --frames 2970 --y4m --sar 16:11 --output "D:\Video\Samples\DVD\Pulp Fiction\VTS_01_1 temp files\VTS_01_1_out.hevc" -
Error: Can only apply y4m headers to YUV and Gray format clips
Output 0 frames in 0.03 seconds (0.00 fps)
x265 [error]: unable to open input file <->
import vapoursynth as vs
core = vs.get_core()
core.std.LoadPlugin(r'D:\Projekte\GitHub\staxrip\bin\Apps\Plugins\vs\vslsmashsource\vslsmashsource.dll')
clip = core.lsmas.LWLibavSource(source = r'D:\Video\Samples\DVD\Pulp Fiction\VTS_01_1 temp files\VTS_01_1.m2v')
clip = clip.resize.Bicubic(matrix_in_s = '470bg', format = vs.COMPATBGR32)
clip.set_output()
Are_
1st March 2016, 15:40
Just curious, does "matrix_in_s" exists at all? It is listed like that in the documentation in one example but not anywhere else.
It should be "matrix_in"? If that is the case, it makes me think you are still not using a proper console to debug vapoursynth scripts. If you are using a simple "vspipe script.vpy NUL" then I don't know why it does not output the error.
LigH
1st March 2016, 15:42
Are you really a programmer, stax76? ;) Read the error message, try to understand it. Then avoid provoking it, and continue to the next layer. — Try the simplest of all cases:
vspipe VTS_01_1_Preview.vpy > NUL
And hope that STDERR will contain something related to the content of the script, not to the (in this case, due to the output attributes) unsupported parameter of the command line.
Myrsloik
1st March 2016, 15:42
Just curious, does "matrix_in_s" exists at all? It is listed like that in the documentation in one example but not anywhere else.
It should be "matrix_in"?
There are two versions of many arguments. The matrix_in version with takes an integer. But remembering the ITU assigned number for your favorite matrix is hard. So you can also specify it with a string using the matrix_in_s version which is usually easier to remember.
stax76
1st March 2016, 15:43
Just curious, does "matrix_in_s" exists at all? It is listed like that in the documentation in one example but not anywhere else.
It should be "matrix_in"?
------
Arguments denoted as type enum may be specified by numerical index (see ITU-T H.265 Annex E.3) or by name. Enums specified by name have their argument name suffixed with “_s”. For example, a destination matrix of BT 709 can be specified either with matrix=1 or with matrix_s="709".
Are_
1st March 2016, 15:51
My fault, I was thinking the initial call of functions in the help was auto-generated from the source code with all possible valid values for the variables.
stax76
1st March 2016, 16:38
The problem is also with Intel GPU, at least HD works now.
Myrsloik
1st March 2016, 17:21
I made this build (https://dl.dropboxusercontent.com/u/73468194/vapoursynth-r32-test1.exe) just for you. Have fun.
r32:
now has a slightly more informative error message when the wrong type is passed as an argument in python
vsvfw now prints per frame errors on the corresponding frame
splicing two incompatible clips could sometimes give a confusing error message
removed planeaverage
stax76
1st March 2016, 18:02
my preview shows now: Resize error: Resize: field-based video not supported
import vapoursynth as vs
core = vs.get_core()
core.std.LoadPlugin(r'D:\Projekte\GitHub\staxrip\bin\Apps\Plugins\vs\vslsmashsource\vslsmashsource.dll')
clip = core.lsmas.LWLibavSource(source = r'D:\Video\Samples\DVD\Pulp Fiction\VTS_01_1 temp files\VTS_01_1.m2v')
clip = clip.resize.Bicubic(matrix_in_s = '470bg', format = vs.COMPATBGR32)
clip.set_output()
Video
Format : MPEG Video
Format version : Version 2
Format profile : Main@Main
Format settings, BVOP : Yes
Format settings, Matrix : Custom
Format settings, GOP : M=3, N=12
Format settings, picture structure: Frame
Duration : 1mn 58s
Bit rate mode : Variable
Bit rate : 4 527 Kbps
Width : 720 pixels
Height : 576 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 fps
Standard : PAL
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.437
Time code of first frame : 00:00:00:00
GOP, Open/Closed : Open
Stream size : 64.1 MiB (100%)
stax76
1st March 2016, 18:24
the source looks progressive in DGIndex though MediaInfo says interlaced
if I load a source where MediaInfo says progressive then it works fine
thanks everybody for the help!
Myrsloik
1st March 2016, 18:42
It is encoded as interlaced which unfortunately is used for a lot of progressive content too. The built in resizer doesn't support interlaced because it's evil and a lot of extra effort. You can script your own interlaced resizer or simply remove the _fieldbased property which will make all video be treated as progressive.
LigH
1st March 2016, 18:45
MediaInfo says interlaced
Means, the MPEG2 encoder had been set up for interlaced encoding mode (regardless of the content; usually a safety measure in DVD studios).
Unfortunately, no idea how different VapourSynth behaves here, but for me, "field based" sounds as if you would apply SeparateFields() right after MPEG2Source() in AviSynth, in comparison (maybe MPEG2Source() even supports decoding to separate fields directly?). Sorry for wild guessing here.
stax76
2nd March 2016, 00:21
this works:
clip = mvsfunc.AssumeFrame(clip)
https://github.com/HomeOfVapourSynthEvolution/mvsfunc/blob/master/mvsfunc.py#L1942
foxyshadis
4th March 2016, 11:50
this works:
clip = mvsfunc.AssumeFrame(clip)
https://github.com/HomeOfVapourSynthEvolution/mvsfunc/blob/master/mvsfunc.py#L1942
If this is going to be part of Staxrip, then you'll want to make sure it's actually fake-interlaced progressive and not actually interlaced first!
stax76
4th March 2016, 15:21
If this is going to be part of Staxrip, then you'll want to make sure it's actually fake-interlaced progressive and not actually interlaced first!
It's added whenever MediaInfo says interlaced, why is it a big problem adding it for real interlaced?
@Myrsloik
Latest release works without AviSynth installed and vice versa, the cut feature depends on AviSynth though, it just generates a 16x16 pixel avi without audio using BlankClip and ffmpeg because mkvmerge can only cut if there is a video stream present. I should be able to code a VS version, after that both scripting engines are both absolutely on par and first class citizens in StaxRip.
edit:
Next built supports cutting without AviSynth being installed, ffmpeg can do the job alone without any scripting engine, also for video cutting the cool slicing syntax is now used.
dipje
5th March 2016, 22:47
Because if it is really interlaced (so weaved) and you're telling vapoursynth and all the filters that it is NOT interlaced, none of the filters and resizers will do 'interlaced-correct' stuff, and probably make a mess of it.
If you want to mark a clip as progressive when it is _wrongly_ flagged as interlaced, the Vapoursynth way (that I use anyway) is:
c = core.std.SetFrameProp(c, "_FieldBased", intval = 0)
(c being the clip)
It basically means set the '_FieldBased' property of all the frames to '0' (meaning progressive).
But like how I opened: This is only for _wrongly_ tagged interlaced-but-really-progressive material. Real interlaced should be tagged as interlaced so filters and scripts know it is interlaced and handle it accordingly.
Knowing when it is wrongly tagged as interlaced is the trick, and not something I'm interested in. I'm not spending energy on fixing wrong metadata in source material. The source is in error then, there, done. (Or in your case it might be the source plugin, who knows).
That being said, MeGUI has a 'detector' where it tries to see what the source really is, no matter how it is tagged in metadata or properties. How it works and what it really does, no clue.
Myrsloik
10th March 2016, 22:07
R32 test2 (https://dl.dropboxusercontent.com/u/73468194/vapoursynth-r32-test2.exe)
Consider it RC quality. I plan to make another maintenance release soon since I haven't had time to actually make any bigger changes.
r32:
extended avisynth mvtools compatibility hack to work for 64bit version as well
fixed regression from r29 that would make compatyuy2 conversions vertically flipped
vspipe now outputs planar rgb in gbr plane order to better match what other software expects as input
now has a slightly more informative error message when the wrong type is passed as an argument in python
vsvfw now prints per frame errors on the corresponding frame
splicing two incompatible clips could sometimes give a confusing error message
removed planeaverage
rakan
15th March 2016, 01:44
Hi there,
I was trying to compile vapoursynth on Ubuntu 14.04 and I got this error...
CXX src/core/libvapoursynth_la-cachefilter.lo
CC src/core/libvapoursynth_la-cpufeatures.lo
CXX src/core/libvapoursynth_la-exprfilter.lo
In file included from src/core/exprfilter.cpp:37:0:
src/core/jitasm.h: In constructor 'jitasm::detail::ResultT<float, 4>::ResultT(float)':
src/core/jitasm.h:8533:52: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
ResultT(const float imm) : val_(Imm32(*(uint32*)&imm)) {}
^
src/core/jitasm.h: In member function 'void jitasm::detail::ResultT<double, 8>::StoreResult(jitasm::Frontend&, const jitasm::detail::ResultDest&)':
src/core/jitasm.h:8608:67: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
f.mov(f.dword_ptr[f.rsp - 8], *reinterpret_cast<uint32*>(&imm_));
^
In file included from /usr/include/string.h:640:0,
from ./include/VSHelper.h:17,
from src/core/exprfilter.cpp:32:
In function 'void* memset(void*, int, size_t)',
inlined from 'jitasm::Backend::Backend()' at src/core/jitasm.h:1030:32,
inlined from 'void jitasm::Frontend::ResolveJump()' at src/core/jitasm.h:1739:12:
/usr/include/x86_64-linux-gnu/bits/string3.h:81:32: warning: call to '__warn_memset_zero_len' declared with attribute warning: memset used with constant zero length parameter; this could be due to transposed parameters [enabled by default]
__warn_memset_zero_len ();
^
In function 'void* memset(void*, int, size_t)',
inlined from 'jitasm::Backend::Backend()' at src/core/jitasm.h:1030:32,
inlined from 'void jitasm::Frontend::Assemble()' at src/core/jitasm.h:1807:11:
/usr/include/x86_64-linux-gnu/bits/string3.h:81:32: warning: call to '__warn_memset_zero_len' declared with attribute warning: memset used with constant zero length parameter; this could be due to transposed parameters [enabled by default]
__warn_memset_zero_len ();
^
CXX src/core/libvapoursynth_la-genericfilters.lo
CXX src/core/libvapoursynth_la-lutfilters.lo
CC src/core/libvapoursynth_la-mergefilters.lo
CC src/core/libvapoursynth_la-reorderfilters.lo
CXX src/core/libvapoursynth_la-settings.lo
CC src/core/libvapoursynth_la-simplefilters.lo
src/core/simplefilters.c: In function 'separateFieldsGetframe':
src/core/simplefilters.c:659:13: error: too few arguments to function 'vsapi->setFilterError'
vsapi->setFilterError("SeparateFields: no field order provided");
^
make: *** [src/core/libvapoursynth_la-simplefilters.lo] Error 1
I just pulled the latest from git. Git log starts with...
commit 109ce5968eeaea0f7e503f3a3d2265fdb32dbd5d
Author: myrsloik <fredrik.mellbin@gmail.com>
Date: Mon Mar 14 20:18:59 2016 +0100
Make tff argument optional for separatefields
I rolled back git by one commit and got a little bit farther...
CXX src/core/libvapoursynth_la-cachefilter.lo
CC src/core/libvapoursynth_la-cpufeatures.lo
CXX src/core/libvapoursynth_la-exprfilter.lo
In file included from src/core/exprfilter.cpp:37:0:
src/core/jitasm.h: In constructor 'jitasm::detail::ResultT<float, 4>::ResultT(float)':
src/core/jitasm.h:8533:52: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
ResultT(const float imm) : val_(Imm32(*(uint32*)&imm)) {}
^
src/core/jitasm.h: In member function 'void jitasm::detail::ResultT<double, 8>::StoreResult(jitasm::Frontend&, const jitasm::detail::ResultDest&)':
src/core/jitasm.h:8608:67: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
f.mov(f.dword_ptr[f.rsp - 8], *reinterpret_cast<uint32*>(&imm_));
^
In file included from /usr/include/string.h:640:0,
from ./include/VSHelper.h:17,
from src/core/exprfilter.cpp:32:
In function 'void* memset(void*, int, size_t)',
inlined from 'jitasm::Backend::Backend()' at src/core/jitasm.h:1030:32,
inlined from 'void jitasm::Frontend::ResolveJump()' at src/core/jitasm.h:1739:12:
/usr/include/x86_64-linux-gnu/bits/string3.h:81:32: warning: call to '__warn_memset_zero_len' declared with attribute warning: memset used with constant zero length parameter; this could be due to transposed parameters [enabled by default]
__warn_memset_zero_len ();
^
In function 'void* memset(void*, int, size_t)',
inlined from 'jitasm::Backend::Backend()' at src/core/jitasm.h:1030:32,
inlined from 'void jitasm::Frontend::Assemble()' at src/core/jitasm.h:1807:11:
/usr/include/x86_64-linux-gnu/bits/string3.h:81:32: warning: call to '__warn_memset_zero_len' declared with attribute warning: memset used with constant zero length parameter; this could be due to transposed parameters [enabled by default]
__warn_memset_zero_len ();
^
CXX src/core/libvapoursynth_la-genericfilters.lo
CXX src/core/libvapoursynth_la-lutfilters.lo
CC src/core/libvapoursynth_la-mergefilters.lo
CC src/core/libvapoursynth_la-reorderfilters.lo
CXX src/core/libvapoursynth_la-settings.lo
CC src/core/libvapoursynth_la-simplefilters.lo
CXX src/core/libvapoursynth_la-textfilter.lo
CXX src/core/libvapoursynth_la-vsapi.lo
CXX src/core/libvapoursynth_la-vscore.lo
CXX src/core/libvapoursynth_la-vslog.lo
CXX src/core/libvapoursynth_la-vsresize.lo
src/core/vsresize.cpp: In member function 'std::shared_ptr<{anonymous}::vszimg::graph_data> {anonymous}::vszimg::get_graph_data(const zimg_image_format&, const zimg_image_format&)':
src/core/vsresize.cpp:759:48: error: 'atomic_load' is not a member of 'std'
std::shared_ptr<graph_data> data = std::atomic_load(data_ptr);
^
src/core/vsresize.cpp:762:17: error: 'atomic_store' is not a member of 'std'
std::atomic_store(data_ptr, data);
^
make: *** [src/core/libvapoursynth_la-vsresize.lo] Error 1
TalasNetrag
19th March 2016, 17:50
R30 Blogpost
For those of you who still can’t live without certain Avisynth filters there are great news. Avisynth 2.6 plugins are now supported in both 32 and 64 bit builds. Note that 64 bit builds can’t use 2.5 plugins. Which isn’t a real problem since almost none exist anyway.
Is it possible to use .avsi skripts by putting then into the plugins folder? I am trying to use WarpDeRing (http://avisynth.nl/index.php/WarpDeRing_source).
Trying to use a path with a dash in it ("H:\01 - Encoding\01.mkv") results in the error:
vapoursynth.Error: Index: Can't open "H:\ - Encoding\01.mkv"
Are_
19th March 2016, 18:09
As far as I know, no, you can't, but that script has not any logic on it, so porting it is almost a copy past exercise.
About your error with the path try with an "r" before the path, like this:
(r"H:\01 - Encoding\01.mkv")
feisty2
24th March 2016, 17:19
the simple plugin I wrote runs pretty slooow
is it like, inline simd is a must or like, my programming skill blows considering my major is theoretical physics not computer science..
Mystery Keeper
24th March 2016, 18:11
the simple plugin I wrote runs pretty slooow
is it like, inline simd is a must or like, my programming skill blows considering my major is theoretical physics not computer science..
The key to make filters run fast is to branch the code ("if" and "switch" statements) as little as possible. Writing several very similar routines is better (perfomance-wise) than branching inside loops.
MonoS
28th March 2016, 18:47
the simple plugin I wrote runs pretty slooow
is it like, inline simd is a must or like, my programming skill blows considering my major is theoretical physics not computer science..
In my test with MVTools, GCC autovectorization works pretty well, try activating -O3 -march=native and see what you get performance wise, don't know if template will make autovectorization impossible.
Regarding Mystery Keeper comment, you can avoid branching using SSE, for example an abs function may be convertent branchless using
value = _mm_set_ps1(value_address);
value_abs = _mm_and_ps(pixel, mask of all 1 except MSB);
_mm_store1_ps(value_abs, value address);
A similar thing whit clamp
A branch like the one at line 87, 114, 126, etc, will not affect performance because they execute always the same path, and the processor is pretty good at knowing this.
In the end, as Myrsloik in the other thread, don't use the STL when writing the kernel, C++ is not zero-cost abstraction https://gist.github.com/rygorous/c6831e60f5366569d2e9
Mystery Keeper
28th March 2016, 19:24
I'd correct that to "STL is not zero-cost abstraction". C++ templates can be used for the said "very similar routines" and have no runtime overhead. And even <vector> can be used for safe memory allocation/deallocation. You can create it once and then work with raw memory (vector::data() / &vector[0]).
LoRd_MuldeR
28th March 2016, 21:19
I want to add that you should define _SECURE_SCL to 0 in your project settings when using STL with the Microsoft compiler - at least in Release builds.
AFAIK, the latest versions of Visual Studio do this automatically (for Release builds) now, but older versions definitely did not. And this can make a HUGE speed difference, in my experience!
So, if you think STL is slow in your project (and you use MSVC), then _SECURE_SCL should be one of the first things to check...
asarian
1st April 2016, 08:29
At the risk of sounding rude (which really isn't my intention), what's the point of VapourSynth to begin with?! Will I be able to use scripts like QTGMC with it? Or MCTemporalDenoise? I mean, I get it's Python and all; and that is pretty cool; but, so far, it just looks like a very rudimentary emulation of AviSynth, that will likely never be able to handle complex scripts like the above.
Just trying to figure out what the added value of VapourSynth is, really. 64-bit? From what I gather, looks like even Seth (MT) has given up on 64-bit. Can't say I blame him either, as getting all those complex stuff (with all third-party dll's) to 64-bit is just a humongeous endeavour that seems unlikely to ever fully happen.
Been off the video world for a spell, so I may be wrong on many things; if so, feel free to correct me. :)
Boulder
1st April 2016, 08:34
At least it doesn't crash like Avisynth MT and 64-bit environment is a big bonus. Why wouldn't it be able to handle such functions? QTGMC has been ported quite a while ago and it works well (and utilizes the CPU completely on my i7).
It takes a little to get used to but it's worth it.
LigH
1st April 2016, 08:47
@ asarian:
Your question proves that you took very little time to try to answer it for yourself. VapourSynth is not an emulation. It is a separate framework, not just a frameserver. It may support many features similar to what you are used to from AviSynth, but it has a different base. It was designed not to be restricted by the limits of AviSynth known from its origins when BenRG made it. One factor is the support of 64-bit memory addressing and multi-threading from the base. Another factor is support of different color spaces, also with higher component precisions than just 8 bit. A third is a possible integration in separately running applications. Reading about its history, you may find a few more...
asarian
1st April 2016, 08:51
At least it doesn't crash like Avisynth MT and 64-bit environment is a big bonus. Why wouldn't it be able to handle such functions? QTGMC has been ported quite a while ago and it works well (and utilizes the CPU completely on my i7).
It takes a little to get used to but it's worth it.
This is all good news! I knew there *had* to be a good reason for someone to start a project like this. :) Thank you for your clarification!
I shall look into this more, as 64-bit truly is a *major* thing for me. Currently, with 1080p material, I can manage barely (with the avs2yuv process separation trick); and some things (like very complex upscaling) just runs out of memory in the 32-bit environment.
asarian
1st April 2016, 08:55
@ asarian:
Your question proves that you took very little time to try to answer it for yourself. VapourSynth is not an emulation. It is a separate framework, not just a frameserver. It may support many features similar to what you are used to from AviSynth, but it has a different base. It was designed not to be restricted by the limits of AviSynth known from its origins when BenRG made it. One factor is the support of 64-bit memory addressing and multi-threading from the base. Another factor is support of different color spaces, also with higher component precisions than just 8 bit. A third is a possible integration in separately running applications. Reading about its history, you may find a few more...
Why, like I said, I didn't mind being corrected if I was wrong. :) Looks like I really need to try and give VapourSynth a chance. And, apart from 64-bit, native (stable) multi-threading will be welcomed too!
stax76
1st April 2016, 09:12
@asarian
Maybe have a look at StaxRip.
https://github.com/stax76/staxrip/wiki/Test-Build
asarian
1st April 2016, 16:16
At least it doesn't crash like Avisynth MT and 64-bit environment is a big bonus. Why wouldn't it be able to handle such functions? QTGMC has been ported quite a while ago and it works well (and utilizes the CPU completely on my i7).
It takes a little to get used to but it's worth it.
Am I right in not seeing 64-bit installers for it? Only a portable 64-bit, it seems. Will that work with the Pismo File Mount Audit Package too?
And yes, I just found the full port of QTGMC. :) This looks promising. Now only MCTemporalDenoise, at some point, and I'm all set.
Myrsloik
1st April 2016, 16:17
Am I right in not seeing 64-bit installers for it? Only a portable 64-bit, it seems. Will that work with the Pismo File Mount Audit Package too?
And yes, I just found the full port of QTGMC. :) This looks promising. Now only MCTemporalDenoise, at some point, and I'm all set.
The installer has both versions. You need to have x64 python installed first too.
asarian
1st April 2016, 16:19
The installer has both versions. You need to have x64 python installed first too.
Okay, cool. :) Thx.
Efenstor
1st April 2016, 21:24
Hi guys. Is it possible to make VapourSynth read source from a pipe? I want something like
ffmpeg -f rawvideo - | vspipe --y4m proc_vs.py - | ffmpeg -i pipe: output.mkv
The reason for this is that the pullup filter from ffmpeg works so much better than VIVTC on the footage I want to process. In fact, VIVTC doesn't seem to work at all - I dunno if it is bug or not, but I do everything right and my footage is nothing special, just a telecined 24p AVCHD video shot with a Canon camcorder.
Here is the VIVTC code that does not work
import vapoursynth as vs
core = vs.get_core()
# Source
video = core.ffms2.Source('00066.MTS')
video = video.std.AssumeFPS(fpsnum=30000, fpsden=1001)
# Process
video = core.vivtc.VFM(clip=video, order=1)
video = core.vivtc.VDecimate(video)
# Output
video.set_output()
The output is still combed. Anyway I remember that when I tried the AviSynth's IVTC plugin a few years ago it occasionally been leaving combing behind as well as some duplicate frames, which ffmpeg's pullup never does. At least for my case ffmpeg performs absolutely perfectly with no parameter fiddling at all. Any chance of porting it to VS? )))
Myrsloik
1st April 2016, 22:22
Hi guys. Is it possible to make VapourSynth read source from a pipe? I want something like
ffmpeg -f rawvideo - | vspipe --y4m proc_vs.py - | ffmpeg -i pipe: output.mkv
The reason for this is that the pullup filter from ffmpeg works so much better than VIVTC on the footage I want to process. In fact, VIVTC doesn't seem to work at all - I dunno if it is bug or not, but I do everything right and my footage is nothing special, just a telecined 24p AVCHD video shot with a Canon camcorder.
Here is the VIVTC code that does not work
import vapoursynth as vs
core = vs.get_core()
# Source
video = core.ffms2.Source('00066.MTS')
video = video.std.AssumeFPS(fpsnum=30000, fpsden=1001)
# Process
video = core.vivtc.VFM(clip=video, order=1)
video = core.vivtc.VDecimate(video)
# Output
video.set_output()
The output is still combed. Anyway I remember that when I tried the AviSynth's IVTC plugin a few years ago it occasionally been leaving combing behind as well as some duplicate frames, which ffmpeg's pullup never does. At least for my case ffmpeg performs absolutely perfectly with no parameter fiddling at all. Any chance of porting it to VS? )))
You should probably use d2vsource, ffms2 with mts is bad luck. It could be bad decoding that makes ivtc fail.
Modified raw source with pipe input (http://forum.doom9.org/showthread.php?p=1755073#post1755073)
LigH
2nd April 2016, 08:56
L-SMASH Source for AviSynth used to be quite reliable in this case. Still, it may in general be a good idea to rip your Blu-ray's main movie to MKV first (e.g. using MakeMKV) before converting it further: Matroska has less container overhead than M2TS, and the fine granularity makes TS parsing quite slow.
Efenstor
2nd April 2016, 14:16
You should probably use d2vsource, ffms2 with mts is bad luck. It could be bad decoding that makes ivtc fail.
Modified raw source with pipe input (http://forum.doom9.org/showthread.php?p=1755073#post1755073)
Thanks Myrsloik! You should've put the link to vsrawsource mod before everything else. :) I just tried d2vsource but cannot produce the d2v file, as D2VWitch freezes on startup and I can't use DGIndex as I'm on Linux.
In fact, would I be on Windows I would be pretty happy with AviSynth but as I am a Linux-man, I've been waiting for something like AvxSynth but with a lot of plugins for quite a time. Of course, I've tried to run AviSynth under Wine but it's too... too incorrect you know, when it's Linux. Also too much CPU power gets lost in the translation.
Efenstor
2nd April 2016, 14:19
L-SMASH Source for AviSynth used to be quite reliable in this case. Still, it may in general be a good idea to rip your Blu-ray's main movie to MKV first (e.g. using MakeMKV) before converting it further: Matroska has less container overhead than M2TS, and the fine granularity makes TS parsing quite slow.
Thanks LigH, I'll try it. By the way, I think ffmpeg will do that as well:
ffmpeg -i input.mts -scodec copy -acodec copy -vcodec copy -f matroska input.mkv
Efenstor
3rd April 2016, 09:45
L-SMASH Source for AviSynth used to be quite reliable in this case. Still, it may in general be a good idea to rip your Blu-ray's main movie to MKV first (e.g. using MakeMKV) before converting it further: Matroska has less container overhead than M2TS, and the fine granularity makes TS parsing quite slow.
Turned out it was one really good idea, and the only one which helped me through to the VIVTC. Now it works, although it required me some toil with compilation. I know it's unavoidable as VapourSynth and its plugins are all in the alpha stage.
For the newbies who are interested how to process AVCHD .MTS files on Linux with VapourSynth here are a few tricks.
1. Compiling plugins: there are no binaries yet at all, learn how compile from sources. Always clone everything from GitHub, outdated stable releases may not compile successfully. Don't forget about -Ofast (or -O3 if you get errors), otherwise you won't get the full speed.
2. Compiling L-Smash: configure with ./configure --enable-shared
3. Compiling the V.C.Mohan's vcmove (as suggested by _Are):
mv ReformHelper.cpp reformHelper.cpp
gcc -fPIC -shared -std=c++11 -Ofast vcmove.cpp -o libvcmove.so
I guess vcmod, vcfreq and the others are compiled in the same manner, although I did not yet tried.
4. Basic bash script for processing a single file. Input file name is specified as an argument, the rest is in the user definitions.
#!/bin/bash
# User defines
vspath=/usr/local/lib/python3.4/site-packages
ffmpeg_options_out="-vcodec ffvhuff -acodec pcm_s16le"
dst_dir="."
dst_ext="avi"
# Prepare some vars
filename=$(basename "$1")
filename_out="$dst_dir/${filename%.*}.$dst_ext"
# Remove the output file if already exists
if [ -e $filename_out ]; then
rm $filename_out
fi
# Process
env PYTHONPATH=$vspath vspipe -a filename="$1" -y proc.py - | \
ffmpeg -i pipe: $ffmpeg_options_out $filename_out
5. Basic batch processing. No arguments, edit the user definitions.
#!/bin/bash
# User defines
vspath=/usr/local/lib/python3.4/site-packages
src_dir="."
src_ext="mts"
ffmpeg_options_out="-vcodec ffvhuff -acodec pcm_s16le"
dst_dir="proc"
dst_ext="avi"
# Do processing
files=$(find "$src_dir" -maxdepth 1 -iname "*.$src_ext" | sort -n)
for i in $files ; do
# Prepare some vars
filename=$(basename "$i")
filename_out="$dst_dir/${filename%.*}.$dst_ext"
# Remove the output file if already exists
if [ -e $filename_out ]; then
rm $filename_out
fi
# Process
env PYTHONPATH=$vspath vspipe -a filename="$i" -y proc.py - | \
ffmpeg -i pipe: $ffmpeg_options_out $filename_out
if [ $? -ne 0 ]; then
exit $?
fi
done
6. Basic proc.py:
import vapoursynth as vs
core = vs.get_core()
clip = core.lsmas.LWLibavSource(filename)
#Processing goes here
clip.set_output()
asarian
3rd April 2016, 15:08
The installer has both versions. You need to have x64 python installed first too.
Have 64-bit Python installed; the "vapoursynth-r31.exe" installer still wants to install to C:\Program Files (x86), though. So it may not be the 64-bit version after all?!
Myrsloik
3rd April 2016, 15:32
Have 64-bit Python installed; the "vapoursynth-r31.exe" installer still wants to install to C:\Program Files (x86), though. So it may not be the 64-bit version after all?!
Look atcthe component selection, not the path. You'll ser it say 64bit.
asarian
4th April 2016, 07:00
Look atcthe component selection, not the path. You'll ser it say 64bit.
Yeah, my bad. LOL. That was only 1 sceen further in! :P
asarian
4th April 2016, 11:41
So, dumb question probably, but how does VSFS work? (As opposed to AVFS) Got AVFS working just fine now.
'vsfs' is not recognized as an internal or external command,
asarian
4th April 2016, 16:13
So, dumb question probably, but how does VSFS work? (As opposed to AVFS) Got AVFS working just fine now.
'vsfs' is not recognized as an internal or external command,
Anyone?! I can understand 'VSPipe -' doesn't output to a file; but shouldn't an output file otherwise show up in the VSFS somewhere?!
poisondeathray
4th April 2016, 18:34
So, dumb question probably, but how does VSFS work? (As opposed to AVFS) Got AVFS working just fine now.
'vsfs' is not recognized as an internal or external command,
Anyone?! I can understand 'VSPipe -' doesn't output to a file; but shouldn't an output file otherwise show up in the VSFS somewhere?!
You need to register VSFS first, it's described in the instructions under "installation of VSFS"
http://www.vapoursynth.com/doc/installation.html
Otherwise it's analgous to AVFS - a "virtual" AVI will appear in the c:\volumes folder
asarian
4th April 2016, 22:29
You need to register VSFS first, it's described in the instructions under "installation of VSFS"
http://www.vapoursynth.com/doc/installation.html
Otherwise it's analgous to AVFS - a "virtual" AVI will appear in the c:\volumes folder
Thanks for replying. The doumentation said
"By default VSFS will be registered if the Pismo File Mount Audit Package was installed before VapourSynth."
Hence, I hadn't registered it manually. So I did
pfm register "C:\Program Files (x86)\VapourSynth\core64\vsvfw.dll"
It registers okay, but still not seeing anything appear in c:\volumes when I run a job.
poisondeathray
5th April 2016, 00:20
Hence, I hadn't registered it manually. So I did
pfm register "C:\Program Files (x86)\VapourSynth\core64\vsvfw.dll"
It registers okay, but still not seeing anything appear in c:\volumes when I run a job.
How are you "running" the job ?
The newer versions use the commandline
eg.
vsfs input.vpy
or
start vsfs input.vpy
I'm using an older version, that runs from the context menu, and you right click, mount
asarian
5th April 2016, 00:32
How are you "running" the job ?
The newer versions use the commandline
eg.
vsfs input.vpy
or
start vsfs input.vpy
I'm using an older version, that runs from the context menu, and you right click, mount
The problem, for me, is that 'vsfs' doesn't seem to exist, anywhere (unlike avfs). Like:
F:\jobs>start vsfs neela.vpy
The system cannot find the file vsfs.
F:\jobs>vsfs neela.vpy
'vsfs' is not recognized as an internal or external command,
operable program or batch file.
'vsfs' (other than the dll) is nowhere to be found on my system.
poisondeathray
5th April 2016, 00:36
pfm register "C:\Program Files (x86)\VapourSynth\core64\vsvfw.dll"
Is that the correct .dll or a typo ?
In the older version I'm using it's vsfs.dll , not vsvfw.dll
Things might have changed, if it's vsvfw.dll, try calling it with vsvfw neela.vpy
Also there might some differences with portable vs installed version. I'm using an old installed version
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.