VapourSynth Editor

[dontrythisathome]

with m_m_pActionFrameToClipboard generates this output

../src/preview/previewdialog.cpp: In member function ‘void PreviewDialog::createActionsAndMenus()’:
../src/preview/previewdialog.cpp:869:35: error: ‘m_m_pActionFrameToClipboard’ was not declared in this scope
m_pPreviewContextMenu->addAction(m_m_pActionFrameToClipboard);

[jackoneill]

Sorry, could check again only at this time of day.

The output was too long for Doom9's text box.

Here's the link on pastebin: link (http://pastebin.com/kymA4Kyr)

I see. It crashes while autoloading the plugins. Does the same thing happen if you use vspipe?

Did you create ~/.config/vapoursynth/vapoursynth.conf ? If yes, what does it contain? What did you pass to the configure script when you compiled VapourSynth?

Maybe you should compile VapourSynth with --enable-debug and repeat this experiment.

foxyshadis probably added an extra "m_" at the beginning of that name.

[foxyshadis]

Well, that was dumb. Edited my post to edit out the extraneous m_

[Mystery Keeper]

Ouch. What a stupid mistake. Sorry for not working on the viewer. I've been rather busy. I'll fix this bug and make new fix release as soon as I can.

[dontrythisathome]

This morning, a few minutes ago, I recompiled vapoursynth with

./configure --prefix=/usr --enable-debug

and recompiled vapoursynth editor again and seems to work now with no errors at all.

( Changing the variabile name and recompiling vapoursynth should solve the problem I think )

I'll keep you update if anything bad comes up.

[Mystery Keeper]

Released r5 with fixes to VS r27 compatibility and the action bug. Please test if distributions work properly. Virtual machines are not working for me right now.

[dontrythisathome]

Both debug and release build work for me with no problem at all.

[Mystery Keeper]

Because Myrsloik compiled with Visual Studio and I with MinGW. Those warning mean that someone forgot a certain assembler call after using MMX instructions in their plugin.

[Mystery Keeper]

Maybe Myrsloik forgot to put that call into some of the core functions? It is probable.

[Myrsloik]

Maybe Myrsloik forgot to put that call into some of the core functions? It is probable.

No. Different compilers default to different control register flags. Gcc for some inexplicable reason defaults to something different sometimes.

It's the host application that sets it on startup and that's it. Vapoursynth only checks if it's sane.

The warning is printed before anything else is done by VS.

Btw, VS simply need the windows default fpu state when threads and processes are created.

[Mystery Keeper]

So, what do I do about it?

[Myrsloik]

So, what do I do about it?

Set the fpu state to the default before loading VS. There are intrinsics for that.

Or simply join the dark visual studio side for the windows builds. Maybe mingw has an option for it too. No idea.

[Boulder]

While trying to convert the HD mod of contrasharpening to VS-compatible code, I found out that this code crashes the preview:

import vapoursynth as vs

core = vs.get_core()

clp = core.ffms2.Source('c:/x265/hotfuzz.vc1')

superclip = core.mv.Super(clp,pel=2,rfilter=4)

bv1 = core.mv.Analyse(superclip, blksize=16, overlap=8, search=5, searchparam=4, pelsearch=3, isb=True, delta=1)
fv1 = core.mv.Analyse(superclip, blksize=16, overlap=8, search=5, searchparam=4, pelsearch=3, isb=False, delta=1)

original = core.std.ShufflePlanes(clp, planes=[0], colorfamily=vs.GRAY)

cb1 = core.mv.Compensate(original,superclip,bv1,thscd1=300,thscd2=80)

cb1.set_output()If "clp" is fed into mv.Compensate, there's no problem. Also the clip "original" can be opened in the preview window. Using "Check script" doesn't crash.

[Boulder]

I'd expect "Check script" to shout out loud :) Or does it just check the syntax and doesn't check the actual output?

[Mystery Keeper]

I'd expect "Check script" to shout out loud :) Or does it just check the syntax and doesn't check the actual output?
It checks if the graphs is successfully built, but requests no frames.

[lansing]

Any update on working with R30 portable?

[Myrsloik]

Any update on working with R30 portable?

What is there to update about? R5 already works with it if you stuff everything in the same directory.

[Mystery Keeper]

Probably can make it work with the portable version from anywhere. When I get to it >_>

[lansing]

What is there to update about? R5 already works with it if you stuff everything in the same directory.

That's the one thing I don't want to do. I wanted Vapoursynth and the editor to have their own folder instead of stuffing 30 files into one. It would be one big mess if you're to update/remove any one of them after.

[Tormaid]

First, I want to thank you for developing this program; it's made transitioning to Vapoursynth much easier for me.

I wanted to inquire, if I may, about your future plans for the VS Editor. Specifically, I'm interested in macro support like that found in AvsPmod. This makes a huge difference in efficiency when I have to scene-filter something. For example, I can use something like this to re-create static fades to black when they are corrupted with compression artifacts at the press of a key:


frame = avsp.GetFrameNumber()
count = avsp.GetVideoFramecount()
avsp.InsertText('\nReplaceFramesSimple(Overlay(last, last.trim(0, %i)++last.FreezeFrame(%i,%i,%i) \
.trim(%i, %i).FadeOut2(%i, color=$000000, fps=23.976)++last.trim(%i, %i)), mappings="[%i %i]")' \
% (x-1, x, frame, x, x, frame, frame-x, frame+1, count, x, frame))
avsp.ShowVideoFrame(forceRefresh=True)


This is especially useful when combined with the ability to bookmark frames and import scene-change metrics as bookmarks, so you can easily jump from one affected section to the next.

I'm interested in hearing your thoughts on this. Thank you in advance for your time.

[Mystery Keeper]

I'm working on it very slowly right now. Next release will have theme settings. I'm also aiming for better portable VS support soon.

[littlepox]

Has anyone requested the feature of displaying YUV/RGB info? If not, I'd like to request for it:

When you preview the video, the information bar shall automatically display the YUV/RGB info (in 8bit scale) for the pixel your cursor is on.

This is featured in the AVSpMod. I hope there is the same one in VS which shall simplify our life a lot.

Kindly excuse me and get me informed if this feature is already there, just not turned on by default.

[shader]

Does anybody know how to print to log window. I just want to show some statistics. When using vspipe stderr works well.

I already check stdout and stderr, both of them don't work.

[Mystery Keeper]

Might add a logging feautre someday.

[jackoneill]

Does anybody know how to print to log window. I just want to show some statistics. When using vspipe stderr works well.

I already check stdout and stderr, both of them don't work.

VapourSynth R30 introduced VSAPI::logMessage (http://www.vapoursynth.com/doc/api/vapoursynth.h.html#logmessage). I believe messages sent through that are displayed in vsedit's log window. If you want to call it from Python, maybe you can figure something out with ctypes. You can get the VSAPI pointer from vsscript (again, ctypes).

[lansing]

I would like to request a feature to quick switch to show all separate plane, like RGB and YUV. I'm using the BM3D for denoising and I wanted to adjust the denoise strength of each plane, so I need a quick way to actually see the plane.

[Mystery Keeper]

No. Do that with VS functions.

[lansing]

No. Do that with VS functions.

That's not going to help when you're to repeat the same process 20/30 times

[LexSfX]

I feel like I might be missing something. I can preview still frames and this is cool and all, but I can't seem to actually play the clip in the "Preview" mode, so that it animates and plays sound. I'm looking for a "playback" type of thingy. Is this feature missing or am I failing to find it?

[Mystery Keeper]

You can playback by holding right or left keys while preview window is focused. I believe it is quite enough for fast scripts, and you wouldn't want to "play" a slow script. There will be no sound because VapourSynth isn't supposed to work with sound in the first place.

[jackoneill]

If you want to play a video, use a video player. mpv (mpv.io) can even filter the video using a VapourSynth script.

[LexSfX]

You can playback by holding right or left keys while preview window is focused. I believe it is quite enough for fast scripts, and you wouldn't want to "play" a slow script. There will be no sound because VapourSynth isn't supposed to work with sound in the first place.

Oh, so VapourSynth can't manipulate sound, is super slow (due to Python or due to reassigning the clip every step?), and doesn't have a DirectShow source function to avoid ffms2 bugs such as incorrect color channel order in RGB H264 (LAV Video Decoder and VLC load the video properly). I guess it's not a viable AVISynth replacement yet for me.

For comparison, I wrote this script which simply loads the video and works around the ffms2 H264 RGB color bug:

import vapoursynth as vs
core = vs.get_core()
clip = core.std.ShufflePlanes(clips=core.ffms2.Source(source='B:\\media\\video\\capture\\ystas-lossless-rgb.mkv'), planes=[2, 0, 1], colorfamily=vs.RGB)
clip.set_output()

and it still can't play at anywhere near 60 fps while holding the right arrowkey despite my 4GHz Sandy Bridge CPU. AVISynth has no problem playing it back at full speed with sound and plenty of modifications I throw at it.

I am just interested in a quick edit->play at full speed with sound to test my changes->edit cycle, like I can do with AVISynth already, so I'll be dropping VapourSynth for now and keeping tabs on whether its performance improves in the future. Thank you for your cool script editor program and both of you for the info.

[sl1pkn07]

why not report the bug in the ffms2 bugtracker?

[Mystery Keeper]

LexSfx, the editor doesn't play fast because there are many things going on internally in it. The processing is actually much faster. Try running the encoding with vspipe.

[LexSfX]

LexSfx, the editor doesn't play fast because there are many things going on internally in it. The processing is actually much faster. Try running the encoding with vspipe.

Oh, that's interesting, but the lack of sound manipulation still makes it a no-go for me for now. I need to be able to add audio cross-fades timed programmatically and suchlike, like I've done in AVISynth. I'm sorry to bother you in your editor thread. I have only the utmost respect for the work you've done, especially since this was the most convenient program I could easily use to try VapourSynth after its time-consuming problematic installation (long story).

[LexSfX]

why not report the bug in the ffms2 bugtracker?I have done so in the past and it was fixed in some special build of ffms2 in 2011 when RGB in H264 was bleeding edge, but that fix wasn't pushed into the main branch or something, then I asked the ffms2 people a bit more in IRC about a year later and they told me they weren't interested in fixing it (or something to that effect), so I gave up. It was fixed in mainline ffmpeg and libav, so I figured it would eventually show up fixed in ffms2, but it's still not. I just don't want to deal with all that drama too much. I would fix it myself and I've looked at the source to try to figure out what to do, but it was way over my head.

Edit: It turns out that the ffms2 that comes with VapourSynth is outdated in some way and that downloading the ffms2 release from github and overwriting ffms2.dll, ffms2.lib, and ffmsindex.exe with those fixes the problem. It seems there was a regression and it was fixed in this change:

"vapoursource: Fix swapped RGB channels bug introduced in 2.21 (Myrsloik)"

I have the utmost respect for all these devs! :) Thanks to Myrsloik in particular!

[TheFluff]

if you want to say something is shit, you can say it's shit
no need to pussyfoot around with the utmost respect here and thankyous there

[LexSfX]

I don't think it's shit though, and saying "it's shit" is not productive. I'm not "pussyfooting" around. I clearly made a mistake. I was using a previous version of ffms2 that had a regression and I didn't realize VapourSynth was much faster elsewhere than in VapourSynth Editor.

[foxyshadis]

You can playback by holding right or left keys while preview window is focused. I believe it is quite enough for fast scripts, and you wouldn't want to "play" a slow script. There will be no sound because VapourSynth isn't supposed to work with sound in the first place.

VSEdit uses the standard windows key-repeat, the same as when you hold down a letter in this text box, which defaults to about 20/sec and goes up to about 30/sec. That's obviously not possible to use anywhere near real-time for 60fps, and even if you maxed it out, that's changing a global setting to solve a local problem. I think asking for a play/pause button is a perfectly good enhancement request.

[Mystery Keeper]

VSEdit uses the standard windows key-repeat, the same as when you hold down a letter in this text box, which defaults to about 20/sec and goes up to about 30/sec.Didn't know that. Shall consider.

[Mystery Keeper]

R6 is here with few overdue changes:
-Added some theme settings.
-Switched preview to use the internal resizer instead of zimg. Requires VapourSynth R29+.
-Support for building under MacOS X (not tested).

[l33tmeatwad]

R6 is here with few overdue changes:
-Added some theme settings.
-Switched preview to use the internal resizer instead of zimg. Requires VapourSynth R29+.
-Support for building under MacOS X (not tested).
Just tested R6 in OSX and it compiles and runs great! Thanks for the update!

[Boulder]

Thanks a lot!

[l33tmeatwad]

Just tried r6 on Ubuntu and Fedora today, both give the "Failed to initialize VapourSynth" error, both still work with r5 and process scripts fine.

[Mystery Keeper]

There are problems with Win32 build too. And it is working too. Trying to figure it out.

[Boulder]

I installed the new version yesterday, and tested the ResampleHQ port from here:

https://gist.github.com/4re/64642122e359c37543fe

It's giving me a washed out picture compared to a standard Vapoursynth resize. R4 doesn't have this issue.

[Mystery Keeper]

I installed the new version yesterday, and tested the ResampleHQ port from here:

https://gist.github.com/4re/64642122e359c37543fe

It's giving me a washed out picture compared to a standard Vapoursynth resize. R4 doesn't have this issue.

R5 used earlier version or zimg library for chroma resampling and had internal (likely wrong) colorspace conversion. R6 uses the resize plugin bundled with VapourSynth. Try playing with the preview settings. Also try encoding and see if the picture is different from the editor's preview.

[Boulder]

It doesn't seem to affect encoding at all so it's preview only. The funny thing is that you can use ResampleHQ and the internal resampling methods in the same script and interleave them, and the RHQ version of the frame is washed out. I've managed to find out that the part which causes the issue is the call of fmtc.transfer.

[Mystery Keeper]

Can you make screenshots for comparison? To see how exactly it is "washed out".

[Boulder]

Sure, here they are:

https://drive.google.com/open?id=0BzeF_1syecQwdjZvclBPM0lVYTA (ResampleHQ)
https://drive.google.com/open?id=0BzeF_1syecQwRDRfcVdVYTdtd1k (internal resampler)

To me it looks like the difference between a full and limited range.