Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
21st November 2015, 23:12 | #1781 | Link |
Professional Code Monkey
Join Date: Jun 2003
Location: Kinnarps Chair
Posts: 2,548
|
Here's R29 test 2.
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.
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet Last edited by Myrsloik; 21st November 2015 at 23:15. |
22nd November 2015, 14:25 | #1783 | Link |
Professional Code Monkey
Join Date: Jun 2003
Location: Kinnarps Chair
Posts: 2,548
|
Yes, it will be a normal library dependency.
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet Last edited by Myrsloik; 22nd November 2015 at 21:24. Reason: changed my mind |
22nd November 2015, 23:57 | #1784 | Link |
Registered User
Join Date: Oct 2014
Posts: 268
|
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. |
23rd November 2015, 00:18 | #1785 | Link | |
Professional Code Monkey
Join Date: Jun 2003
Location: Kinnarps Chair
Posts: 2,548
|
Quote:
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.
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet |
|
27th November 2015, 16:37 | #1787 | Link |
Professional Code Monkey
Join Date: Jun 2003
Location: Kinnarps Chair
Posts: 2,548
|
Yes. All you have to do is install both versions of python before installing VS.
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet |
4th December 2015, 00:30 | #1793 | Link |
Professional Code Monkey
Join Date: Jun 2003
Location: Kinnarps Chair
Posts: 2,548
|
Here's R29 RC4. 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. Code:
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
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet Last edited by Myrsloik; 8th December 2015 at 00:23. Reason: Sneakily updated link to RC5 |
8th December 2015, 18:24 | #1794 | Link |
Professional Code Monkey
Join Date: Jun 2003
Location: Kinnarps Chair
Posts: 2,548
|
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 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.
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet |
9th December 2015, 14:22 | #1796 | Link | |
Registered User
Join Date: Apr 2015
Posts: 163
|
Quote:
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 |
|
9th December 2015, 14:29 | #1797 | Link |
Professional Code Monkey
Join Date: Jun 2003
Location: Kinnarps Chair
Posts: 2,548
|
How many threads?
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet |
9th December 2015, 18:33 | #1799 | Link | |
Professional Code Monkey
Join Date: Jun 2003
Location: Kinnarps Chair
Posts: 2,548
|
Quote:
The work on making things even more consistent will continue in R30.
__________________
VapourSynth - proving that scripting languages and video processing isn't dead yet |
|
18th December 2015, 19:30 | #1800 | Link |
Registered User
Join Date: Apr 2009
Posts: 478
|
Hi, I have a simple question here.
I found a script to convert framerates, like so: Code:
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() Code:
vapoursynth.Error: AssumeFPS: argument fpsnum was passed an unsupported type |
Tags |
speed, vaporware, vapoursynth |
Thread Tools | Search this Thread |
Display Modes | |
|
|