VapourSynth Editor 2

[Zarxrax]

Okay so I have run into this same problem numerous times now. I will try to open vsedit, and it just wont open, giving an error that it can't open another vpy file (different file than the one I am trying to open). I am thinking this is because its trying to open files that I have previously worked on, but instead of opening the application without opening the file, it simply just stops altogether.

I had previously had this happen after deleting a file, and I was able to recover by bringing the file back. But now its giving this error for a file that still exists. I'm not sure what the issue is, and I can't find anything sort of settings file that I can delete which might reset it.

[videoh]

Workaround:

Locate vsedit.config
Edit it and wipe out the history by changing to this line (delete stuff after the =):

recent_files_list=

It should be fixed in vsedit of course but this should get you going. Until it is fixed you may want to disable
'Automatically load the last script' in settings. Then use File/Recent scripts as needed; the last one will be at the
top of the list.

[Zarxrax]

Workaround:

Locate vsedit.config
Edit it and wipe out the history by changing to this line (delete stuff after the =):

recent_files_list=

It should be fixed in vsedit of course but this should get you going. Until it is fixed you may want to disable
'Automatically load the last script' in settings. Then use File/Recent scripts as needed; the last one will be at the
top of the list.

Thank you! I was able to find vsedit2.config in my "AppData\Local" folder. Removing the recent files didn't help, so I ended up deleting the file, and that let me back in to start using the application again!

[videoh]

Thank you! I was able to find vsedit2.config in my "AppData\Local" folder. Removing the recent files didn't help, so I ended up deleting the file, and that let me back in to start using the application again! Good to hear. I investigated it using vsedit under linux, which accounts for the differences.

[lansing]

Updated to R5.9 (https://bitbucket.org/gundamftw/vapoursynth-editor-2/downloads/)


changelog

- Bug fixed: log window not showing indentation correctly
- Removed the implicit warning message logger as it did basically nothing to improve user experience. The only warning message Vapoursynth produces is deprecation warning, which no typical user needed it.
- Rewrote the preview filters chain implementation, now preview filters runs programmatically on processed video node instead of being part of the script. Resulting in faster loading time when switching between preview filters and less memory consumption
- Moved the matrix coefficient setting from the "Preview Advanced Settings" to the preview filter dialog
- Removed Preview Advanced Settings dialog as it was replaced by Preview Filters dialog
- The script processor request only preview frame during playback instead of both output and preview frame. This should give a little speed up on playback
- Bug fixed: manual entering frame number in the navigation box will not trigger on every key press


I removed the warning message logger as stated in the changelog. The Preview Advanced Setting dialog has also been removed, as most of the options are useless. It had been a long time that I have no idea what they do because none of them seems to do anything to the image. The matrix coefficient setting has been fixed now and moved to the Preview Filter Dialog. Before it would not work if the input clip has the Matrix value.

I also rewrote the preview filters chain implementation. Before it was done by appending python script like "main_script + filter1_script + filter2_script". But with this, every little change in the preview filter will result in the reloading of the whole script. Now the filters will run on the resulting node of the main script, so it's faster now.

Another optimized update is a change in the request frame process. Originally the program will request two frames every time, the output frame for retrieving frame properties and a RGB frame for display. But during playback, nobody is going to check for frame info anyway, so I make it only to retrieve the RGB frames instead of both. And from my test playing a 4K 60 fps iphone video, the change gives a little 5% boost in speed. Well it still ran under 60 fps, don't know why. This is probably the next thing I would need to investigate.

Please test for bug.

And ignore the crop editor dialog, it is not done yet.

[ChaosKing]

In case you need help with the upcoming ApiV4 changes, here's a repo which implemented the necessary changes for v4:https://github.com/YomikoR/VapourSynth-Editor

An alternative could be this plugin https://github.com/DJATOM/LibP2P-Vapoursynth

[lansing]

In case you need help with the upcoming ApiV4 changes, here's a repo which implemented the necessary changes for v4:https://github.com/YomikoR/VapourSynth-Editor

An alternative could be this plugin https://github.com/DJATOM/LibP2P-Vapoursynth

Thanks, I was just looking for info about packing RGB to image.

[ChaosKing]

+ Discussion here https://github.com/YomikoR/VapourSynth-Editor/commit/78ddeea46d7835837c929992e6c333916d5419da#comments

[lansing]

+ Discussion here https://github.com/YomikoR/VapourSynth-Editor/commit/78ddeea46d7835837c929992e6c333916d5419da#comments

I read them. I think using DJATOM's LibP2P library is the way to go. Just plug in the arguments and it will spit out the image. They mentioned about the playback going around 130 fps, I wonder what it would be with 4K video. I'll see how it goes.

[DJATOM]

With that fix (https://github.com/vapoursynth/vapoursynth/commit/7b1d45d50cf2555be23c52042fde258e3d48816c) I'm now getting ~290 fps with DGSource, vapoursynth-preview and libp2p.

[DJATOM]

> boy
> ~31 y.o.
:sly:

[lansing]

I tried YomikoR's packing and got like 3 fps playback on my 4K video with DGSource, the gpu's video decoder is running at 1%. Reverting it back to api 3 has no improvement...what is the problem

[DJATOM]

Probably your VS somehow lacks the fix. Here's my latest build: installer (https://mega.nz/file/jtFlxK7J#2bEfs0bFVl1xO_Yz5GYEvD20trR1sejjxIinKLPf6A8) | portable (https://mega.nz/file/m9t2RK4Z#PhVWanFhuXCkL7b6areVKvEw2dFzDURwSgxGfoP6voA)

[lansing]

Probably your VS somehow lacks the fix. Here's my latest build: installer (https://mega.nz/file/jtFlxK7J#2bEfs0bFVl1xO_Yz5GYEvD20trR1sejjxIinKLPf6A8) | portable (https://mega.nz/file/m9t2RK4Z#PhVWanFhuXCkL7b6areVKvEw2dFzDURwSgxGfoP6voA)

Didn't work. I also tried the new api4 RC1 but it's the same. When I revert back to api3 with compatBGR32 output and the video played smooth again.

I'll try invoking it as a plugin to see how it goes.

[DJATOM]

In API4 you can also create plugin on-the-fly. Example (https://github.com/vapoursynth/vapoursynth/blob/doodle1/src/avisynth/avisynth_compat.cpp#L299).

[lansing]

The libP2P plugin returns a Gray32 frame, which is a API4 format. So that means I'll probably have to update most of the function syntax before I can test it out lol.

[DJATOM]

Indeed. Gray32 is convenient for packed formats. Maybe it also can fit into Gray8 and x4 width, I haven't tried.

[Yomiko]

In API4 you can also create plugin on-the-fly. Example (https://github.com/vapoursynth/vapoursynth/blob/doodle1/src/avisynth/avisynth_compat.cpp#L299).

Indeed that's where I'm stuck with v3 API. Invoking an existing plugin is the convenient way in v3. Invoking a compiled plugin with LoadPlugin is not too horrible. But createFilter and fetching the node from the out VSMap seems doubtful.

As for the Gray32 format, since only bit operations are involved in packing, most formats should work, at least if not further touched by other filters.

Edit:
createFilter and fetching the node from the out VSMap is okay. My code has a bug in packing to Gray8 with 4x width.

Edit:
Now both are done.

[Yomiko]

I tried YomikoR's packing and got like 3 fps playback on my 4K video with DGSource, the gpu's video decoder is running at 1%. Reverting it back to api 3 has no improvement...what is the problem

Probably the reason mentioned in #209.

[lansing]

Vapoursynth's newest commit just included LibP2P as dependency, which mean I can invoke the RGB pack/unpack filters without worrying about having an extra dependency for vsedit2, yay. I also finished updating all vsapi4 syntax I can find for the program, now I'm just waiting for the next VS RC build for test.

[DJATOM]

I don't see an interface for this (pack/unpack), but sure if you managed to invoke p2p from your end, it's nice.

[Yomiko]

For your reference, in my mod I ended up keeping each preview frame until the next one comes in this commit (https://github.com/YomikoR/VapourSynth-Editor/commit/fa533a77785b7a2c6ec0cae5e298dd32990376eb). It seems this is not necessary for working with V3 API provided the preview QImage is constructed by reference (I don't know why and why it breaks with V4), but it brings some acceleration.

[lansing]

I got the preview working now with invoking the libp2p plugin in the program, that's with the latest VS R55 RC3. The playback speed did go back to normal again like vsapi3. So doing the packing through the vapoursynth end did resolved the turtle speed issue.

I also tested both libp2p R1 and R2, with R2 just a tiny bit faster, maybe the new acceleration in R2 is not for my use case?

I don't have the problem Yomiko has with the need on keeping the preview frame reference.

---------------------------------------------------------------

I'm still investigating the sub-realtime playback problem for my 4K 60 fps clip. Here's a speed comparison using vsedit2 and vsedit mod2 so far:


vsedit2

fps mode fps gpu usage
60 ~30 16%
unlimited ~50 22%


vsedit mod2

60 ~50 19%-29%
unlimited >60 47%


My computer can go as high as over 60 fps but somehow when I set the fps mode to 60, it was playing at much less than 60 fps. Why?

As a side note, I should also create a playback fps counter like avspmod because I'm just guessing by looking at the time counter right now.

[Yomiko]

Just curious. Did you also take benchmarks with BlankClip?

[lansing]

Updated to R6 (https://bitbucket.org/gundamftw/vapoursynth-editor-2/downloads/), now with VSAPI 4 implemented.

changelog

- Implemented VSAPI 4, program now requires Vapoursynth R55+ to run
- libP2P Vapoursynth plugin will be required for previewing frame
- refactored the preview filter in the filter chain into separate functions
- cosmetic on frame properties matrix display
- bug fixed: color picker producing wrong color that was introduced in commit
- Bug fixed: manual entering frame number in the navigation box will not trigger on every key press
- The script processor request only preview frame during playback instead of both output and preview frame.
This should give a little speed up on playback
- Rewrote the preview filters chain implementation, now preview filters runs programmatically on
processed video node instead of being part of the script. Resulting in faster loading time when
switching between preview filters and less memory consumption
- Moved the matrix coefficient setting from the "Preview Advanced Settings" to the preview filter dialog.
- Removed Preview Advanced Settings dialog as it was replaced by Preview Filters dialog
- Bug fixed: log window not showing indentation correctly
- Bug fixed: defined an absolute path for the theme_presets file so that opening the program through
vpy would not generate a new one on the current directory
- Single instance implementation using the KDSingleApplication library
- File association for vpy file option on Windows platform, opening vpy will load as new tab in the program


You'll need the LibP2P plugin to work:
https://github.com/DJATOM/LibP2P-Vapoursynth

As for the preview, I don't know what is the universal RGB format to convert to. Right now I just convert everything to RGB24.

[Myrsloik]

Updated to R6 (https://bitbucket.org/gundamftw/vapoursynth-editor-2/downloads/), now with VSAPI 4 implemented.

...

You'll need the LibP2P plugin to work:
https://github.com/DJATOM/LibP2P-Vapoursynth

As for the preview, I don't know what is the universal RGB format to convert to. Right now I just convert everything to RGB24.

Why don't you integrate the plugin into your program? It's easy to do and then user won't have to muck about with a separate dependency.

See the packrgb32 bit, that's all you need.
https://github.com/vapoursynth/vapoursynth/blob/master/src/avisynth/avisynth_compat.cpp#L256

[lansing]

Why don't you integrate the plugin into your program? It's easy to do and then user won't have to muck about with a separate dependency.

See the packrgb32 bit, that's all you need.
https://github.com/vapoursynth/vapoursynth/blob/master/src/avisynth/avisynth_compat.cpp#L256

I was expecting VS to include it as a core plugin in the future.

[Myrsloik]

I was expecting VS to include it as a core plugin in the future.

Trivial packing is not a core feature.

[lansing]

I'm still investigating the sub-realtime playback problem for my 4K 60 fps clip. Here's a speed comparison using vsedit2 and vsedit mod2 so far:

My computer can go as high as over 60 fps but somehow when I set the fps mode to 60, it was playing at much less than 60 fps. Why?


More update on this, I narrowed down the problem to Qt's QImage to QPixmap conversion speed being too slow. The conversion from packed RGB to QImage also took some processing time but the video can still be played in real time. It's the QImage->QPixmap conversion that cut the speed in half.

QImage frameImage(pData, width, height, QImage::Format_ARGB32);
QPixmap framePixmap = QPixmap::fromImage(frameImage);

[_Al_]

I experienced similar constructing QT preview using QImage.Format_RGB888 from vapoursynths RGB24, it was quite slow, then looking into Mystery Keeper code, he used packed RGB and . Did that (though in Python's pyqt5) and it just visibly sped up preview.
something:
img = dstack( [array(rgb24.get_frame(f).get_read_array(i), copy=False) for i in range(3)])
img = QImage(img, img.shape[1], img.shape[0], QImage.Format_RGB888)
pixmap = QPixmap.fromImage(img)
versus packed RGB:
img = QImage(compatBGR32.get_frame(f).get_read_array(0), w, h, stride, QImage.Format_RGB32).mirrored()
pixmap = QPixmap.fromImage(img).scaled(scale_w, scale_h, **modes)

[lansing]

I experienced similar constructing QT preview using QImage.Format_RGB888 from vapoursynths RGB24, it was quite slow, then looking into Mystery Keeper code, he used packed RGB and . Did that (though in Python's pyqt5) and it just visibly sped up preview.
something:
img = dstack( [array(rgb24.get_frame(f).get_read_array(i), copy=False) for i in range(3)])
img = QImage(img, img.shape[1], img.shape[0], QImage.Format_RGB888)
pixmap = QPixmap.fromImage(img)
versus packed RGB:
img = QImage(compatBGR32.get_frame(f).get_read_array(0), w, h, stride, QImage.Format_RGB32).mirrored()
pixmap = QPixmap.fromImage(img).scaled(scale_w, scale_h, **modes)

The frame data was already packed RGB through libp2p. I tried turning off the QImage->QPixmap conversion and I was getting around 100 fps with "unlimited fps mode". Turned in on again and it was cut to 30 fps.

[_Al_]

Yes but what about us, poor python developers, shadowing real developers, how should we approach this in code if using pyqt5 for example? :-)

[lansing]

Yes but what about us, poor python developers, shadowing real developers, how should we approach this in code if using pyqt5 for example? :-)

You can pack it with libP2P plugin in the script


clip = core.resize.Point(clip, format=vs.RGB24)
clip = core.libp2p.Pack(clip)


And then it should be the same thing as C++

[Yomiko]

It's the QImage->QPixmap conversion that cut the speed in half.


QPixmap framePixmap = QPixmap::fromImage(frameImage, Qt::NoFormatConversion);

irrc (at least in pyqt5) the default flag could lead to a conversion in certain cases.
The old .mirrored() method for COMPAT format at least copied the frame, too, but I don't know why I didn't hear lots of complain about the performance.

[_Al_]

oh wow, thanks lansing and DJATOM
cannot test it now though, I'm running API4 portable so far

[lansing]

More update on this, I narrowed down the problem to Qt's QImage to QPixmap conversion speed being too slow. The conversion from packed RGB to QImage also took some processing time but the video can still be played in real time. It's the QImage->QPixmap conversion that cut the speed in half.


Some more non-preview benchmarks on the plugins. With a 4K video, decode with DGSource:

R55 R54
no conversion: 159 fps 196 fps
convert to RGB24: 107 fps 179 fps
convert to RGB24 + libP2P pack: 77 fps


It turned out that another big bottleneck is the resize filter in R55??


clip = core.resize.Point(clip, format=vs.RGBS)
# 58 fps

clip = core.resize.Point(clip, format=vs.RGB30)
# 85 fps

clip = core.resize.Point(clip, format=vs.RGB48)
# 86 fps

[Selur]

Argh,... those benchmarks are kind of the opposite of what I expected when I read:
It also performs better on most scripts and computers for those of you who don't care about audio. source: https://forum.doom9.org/showpost.php?p=1951233&postcount=4400

[Myrsloik]

Some more non-preview benchmarks on the plugins. With a 4K video, decode with DGSource:

R55 R54
no conversion: 159 fps 196 fps
convert to RGB24: 107 fps 179 fps
convert to RGB24 + libP2P pack: 77 fps


It turned out that another big bottleneck is the resize filter in R55??


clip = core.resize.Point(clip, format=vs.RGBS)
# 58 fps

clip = core.resize.Point(clip, format=vs.RGB30)
# 85 fps

clip = core.resize.Point(clip, format=vs.RGB48)
# 86 fps


Exactly where in the source do you do the requests? I want to look at it myself.

[lansing]

Exactly where in the source do you do the requests? I want to look at it myself.

this (https://bitbucket.org/gundamftw/vapoursynth-editor-2/src/a3405bd2fa31221ca68662d704694a3514094003/common-src/vapoursynth/vapoursynth_script_processor.cpp#lines-484)

[lansing]

More update on this, I narrowed down the problem to Qt's QImage to QPixmap conversion speed being too slow. The conversion from packed RGB to QImage also took some processing time but the video can still be played in real time. It's the QImage->QPixmap conversion that cut the speed in half.

QImage frameImage(pData, width, height, QImage::Format_ARGB32);
QPixmap framePixmap = QPixmap::fromImage(frameImage);


More update, for testing, I want to see how the speed goes if I don't output any image. So I took out the QImage conversion step and let the playback runs with no preview. The speed did went up a lot but still it didn't come close to the one from benchmark. My GPU was running about 90% on benchmark but only 55% from the test. So I was losing about half the speed just by entering the play queue before doing anything.

[MysteryX]

I double-click on vsedit.exe and nothing happens. I did install libp2p. Is there some other dependency? On Windows 10 x64.

[lansing]

I double-click on vsedit.exe and nothing happens. I did install libp2p. Is there some other dependency? On Windows 10 x64.

The program should be able to start even without libp2p. This should be caused by another problem. My guess is the vsedit2.config file? Try rename the vsedit2.config and let the program create a new one and see how it goes.

[MysteryX]

The program should be able to start even without libp2p. This should be caused by another problem. My guess is the vsedit2.config file? Try rename the vsedit2.config and let the program create a new one and see how it goes.

No such file.

[lansing]

More update, for testing, I want to see how the speed goes if I don't output any image. So I took out the QImage conversion step and let the playback runs with no preview. The speed did went up a lot but still it didn't come close to the one from benchmark. My GPU was running about 90% on benchmark but only 55% from the test. So I was losing about half the speed just by entering the play queue before doing anything.

Issue resolved. The problem was a mixed of the capping of frame request queue size that I committed back in R3 + QImage => QPimxap conversion + VS R55. The problem wasn't really noticeable until working with 4K contents.

Now on 4K video the preview is able to run at 160 fps in "unlimited fps" mode, which is surprisingly, a lot faster than Avspmod at 53 fps. Taking out QImage->QPixmap conversion like Yomiko did increased the speed from like 30 to 160 fps.

R6.1 (https://bitbucket.org/gundamftw/vapoursynth-editor-2/downloads/)

[Selur]

Nice, now it just needs to get Qt6 compatible. :) (main annoyance is that they changed how regular expression handling worked,..)

[lansing]

Nice, now it just needs to get Qt6 compatible. :) (main annoyance is that they changed how regular expression handling worked,..)

I haven't looked at Qt6, what it has to offer over Qt5?

[Selur]

Main point for me is that they fixed a few issues with MacOS, also c++17 is used.
(which is why I build all my code on macos against qt6 ;))
+ They just release Q6.2 which is an LTS version.

Cu Selur

[Selur]

btw. just tried to build your source in QCreator on Windows and the pro file lists a few files in src/crop_editor which do not seem to be part of the project (any more?), after removing those entries veditr builds,..

[lansing]

btw. just tried to build your source in QCreator on Windows and the pro file lists a few files in src/crop_editor which do not seem to be part of the project (any more?), after removing those entries veditr builds,..

I got similar report on my issue page. The crop editor was still in WIP but I got tire of commenting them out on every new releases, so a few commits ago I decided to just leave them there. But then I forgot to commit other related files so the project couldn't find them on build lol.

Anyway, I will have an update on it by like tomorrow.

[Selur]

no problem.