View Full Version : Vapoursynth
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!
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.