View Full Version : VapourSynth Editor 2
lansing
15th August 2020, 05:08
it is useful for some very careful frame-by-frame video restoration, and sometimes you only need to select a static region across all frames, like the LogoAnalysis virtualdub plugin.
feisty2, what should be the output format of the selection rectangle? There are the starting position + width + height, or the four points of the rectangle. What do you need?
(10, 0), width=30, height=20
or
(10, 0) (30, 0) (10,20) (30, 20)
_Al_
15th August 2020, 07:24
vapoursynth uses: width, height, left, top for rectangle
numpy uses: img[y1:y2, x1:x2] for rectangle
feisty2
15th August 2020, 07:52
feisty2, what should be the output format of the selection rectangle? There are the starting position + width + height, or the four points of the rectangle. What do you need?
(10, 0), width=30, height=20
or
(10, 0) (30, 0) (10,20) (30, 20)
the 4 points (actually you only need 2 for rectangular selection, the top left and the bottom right) would be better.
lansing
17th August 2020, 06:56
New version up, now with a new selection tool window to select a part of the frame and return its control points. The returned format is "min_x, min_y, max_x, max_y". Mouse scroll to zoom in and out.
This took me a few tries before finally getting it to work. Zoom will get less responsive as the image gets bigger, most of the time had been spent searching for workaround on this but then I realized that this also happened to photoshop, lol.
_Al_
17th August 2020, 16:34
Zoom will get less responsive as the image gets bigger
This was a major reason to look for some other preview so images after zoom are fast or even behave faster , investigating HD, UHD images on a regular machine even laptops, not having beefed up PC with tons of RAM. This does not increase RAM at all or CPU usage. Using zoom 2x,..., 10x to compare clips. The way is to store three lists with clips:
-original clips passed to viewer (for seeking original values YUV),
-converted rgb clips with original resolution and
-current rgb clips , zoomed etc.
Current rgb clips are those to preview on screen. Every zoom, crop is actually done in absolute scale (https://github.com/UniversalAl/view/blob/master/view.py#L1552) from converted rgb clip from original. This can be done really easy, once you realize that you just need to keep reference data for zooming,cropping (width, height, x(left), y(top) and if zooming from already zoomed image you just add x,y relative coordinates to absolute x,y and do a new zoom from original. This way you can return back to previous zoom (https://github.com/UniversalAl/view/blob/master/view.py#L1516) or just reset image to original (https://github.com/UniversalAl/view/blob/master/view.py#L1569), all pressing a single button.
It looks harsh at first , for example loading 5 clips and zooming in a clip actaully zooms in all remaining rgb clips to same zoom/crop , so clip comparisons is always ready using hot keys, but it is fast because those frames are actually not requested yet, only frames for that actually previewing clip is requested.
lansing
17th August 2020, 17:46
This was a major reason to look for some other preview so images after zoom are fast or even behave faster , investigating HD, UHD images on a regular machine even laptops, not having beefed up PC with tons of RAM. This does not increase RAM at all or CPU usage. Using zoom 2x,..., 10x to compare clips. The way is to store three lists with clips:
-original clips passed to viewer (for seeking original values YUV),
-converted rgb clips with original resolution and
-current rgb clips , zoomed etc.
Current rgb clips are those to preview on screen. Every zoom, crop is actually done in absolute scale (https://github.com/UniversalAl/view/blob/master/view.py#L1552) from converted rgb clip from original. This can be done really easy, once you realize that you just need to keep reference data for zooming,cropping (width, height, x(left), y(top) and if zooming from already zoomed image you just add x,y relative coordinates to absolute x,y and do a new zoom from original. This way you can return back to previous zoom (https://github.com/UniversalAl/view/blob/master/view.py#L1516) or just reset image to original (https://github.com/UniversalAl/view/blob/master/view.py#L1569), all pressing a single button.
It looks harsh at first , for example loading 5 clips and zooming in a clip actaully zooms in all remaining rgb clips to same zoom/crop , so clip comparisons is always ready using hot keys, but it is fast because those frames are actually not requested yet, only frames for that actually previewing clip is requested.
There are more technical things to consider for drawing lines on the image than just zooming. In Qt, in order to draw something, you have to take a pixmap(image) and draw on top of that. Usually we just make a copy of the input image and treated it as the drawing board.
And since lines became part of the image, if you scale the image, the lines will get bigger and become ugly. To prevent this, the process order has to be scale-->draw, not draw-->scale. And this is where it couldn't get optimize, the whole scaled image has to be presented first before the drawing.
Looking at the wider picture, if even Photoshop is having this same problem, there's nothing more I can do about it.
_Al_
17th August 2020, 18:13
In Qt, in order to draw something, you have to take a pixmap(image) and draw on top of that.
opencv works the same , there is no overlay or something (or I cannot use it), lines are one pixel wide and they become thick if zoomed in enough.
But that has nothing to do with that zoom in strategy. I attempted to do it like that in Qt as well. But using QThread for creating a pixmap and also QTimer to time it, it became difficult to apply it (for more clips). I was thinking to start a QThread with all rgb clips loaded but it looked difficult I gave up, also having working an alternative. But you guys are better programmers. Mystery Keeper might have started it with a mind to preview one clip only. You start something else, based on that code, so things might need some regrouping.
Also, those crop lines are added into image just before previewing (whatever it is opencv, Ot, draw into numpy image (https://github.com/UniversalAl/view/blob/master/view.py#L970) or just before creating a pixmap in Qt), they are not part of those rgb arrays.
Also, that line could be one pixel thick, it does not matter, because it has no meaning to be smaller, smaller than a pixel in video.
So draw (into whatever on screen) -->scale (new rgb --> for pixmap) is fine, not sure why to avoid it?
Looking at Qt codes now. I cannot find a process of Qt upscaling automatically to preview window size (point resize) , so that might be done manually controlling aspect ratio as well. This is done automatically in opencv, hence zooming in is faster, because reference w x h gets smaller. This is the core of the problem? This should not be done with Bicubic resize etc., preview would be not real.
lansing
18th August 2020, 03:14
opencv works the same , there is no overlay or something (or I cannot use it), lines are one pixel wide and they become thick if zoomed in enough.
But that has nothing to do with that zoom in strategy. I attempted to do it like that in Qt as well. But using QThread for creating a pixmap and also QTimer to time it, it became difficult to apply it (for more clips). I was thinking to start a QThread with all rgb clips loaded but it looked difficult I gave up, also having working an alternative. But you guys are better programmers. Mystery Keeper might have started it with a mind to preview one clip only. You start something else, based on that code, so things might need some regrouping.
Also, those crop lines are added into image just before previewing (whatever it is opencv, Ot, draw into numpy image (https://github.com/UniversalAl/view/blob/master/view.py#L970) or just before creating a pixmap in Qt), they are not part of those rgb arrays.
Also, that line could be one pixel thick, it does not matter, because it has no meaning to be smaller, smaller than a pixel in video.
So draw (into whatever on screen) -->scale (new rgb --> for pixmap) is fine, not sure why to avoid it?
Looking at Qt codes now. I cannot find a process of Qt upscaling automatically to preview window size (point resize) , so that might be done manually controlling aspect ratio as well. This is done automatically in opencv, hence zooming in is faster, because reference w x h gets smaller. This is the core of the problem? This should not be done with Bicubic resize etc., preview would be not real.
Zooming is not cropping, I think this is where you have fundamentally mistaken it. The image needs to be able to move around while zoomed in, therefore it cannot be cropped, the whole scaled image has to be there first. And then limitation occurs as the image gets bigger.
_Al_
18th August 2020, 04:49
Yes, it is not the same. It is a decision to make it the same. You are always one key press away to return to previous zoom (to zoom out to previous zoom) as described above or reset (whole resolution). That brings in video world instant advantage to handle things on slow PC's , or not enough RAM (which 8GB easily is) even if manipulating with UHD. It is the same handling as in every NLE. Left hand is on keyboard, right on the mouse.
lansing
23rd August 2020, 17:12
I didn't even look there! Some examples or guide from MK would be nice but I'll try to figure it out
Do you manage to figure out how the drop template works?
poisondeathray
23rd August 2020, 17:19
Do you manage to figure out how the drop template works?
Not yet; busy with other stuff
I have time to play with it today , and will post details if I figure it out
poisondeathray
23rd August 2020, 17:48
Do you manage to figure out how the drop template works?
I got it figured out. Don't forget to push "save all" to commit changes. I didn't need to exit/restart the program
"category" is just description for user
"file name mask list" is the actual wild card entry such as "*.mkv" (without the quotes)
When you click on the row, enter what you want in the text box below, with tokens. All that I needed in Windows for tokens was {f}, it filled in the extension, filename
clip = core.lsmas.LWLibavSource(r'{f}')
For example, I like using "LibavSMASHSource" for MP4 (no indexing)
So I would make an entry for category = mp4
filename mask list = *.mp4
and clicking on the row I would enter:
clip = core.lsmas.LibavSMASHSource(r'{f}')
It fills in everything including clip = core.lsmash.LibavSMASHSource(r'PATH\NAME.mp4)
If you don't like using clip = whatever, you can change it
It's pretty easy to figure out, if someone needs screenshots or more help just ask
lansing
23rd August 2020, 18:49
Thanks I got it working. I was using ".mp4" for the wildcard and it didn't work. I didn't know that we have to put a * in front.
lansing
28th August 2020, 21:59
Updated version to R3. Many code refactoring and clean up while waiting for VSAPI 4.0. And fixed a bug where the frame cache didn't get release on tab close.
changelog
R3: [2020-08-28]
- Fixed a bug where frame cache didn't get released when tab was closed
- Added a button in settings to open the config file folder
- Fixed missing includes in repo so the project can be rebuild by others
- A new selection tool to make area selection on a single frame. The selected rectangle can be returned with its control points (coordinates)
- Finished transferring the frame discarded rollback function
- Cosmetic adjustment for timeline and bookmark manager
- Refactored codes and cleaned up some obsolete codes
I tried to look for the memory leak in vapoursynth but still don't know where it is. I narrowed the problem down to the creation of a VSCore. Every time I created a vscore and deleted it, some 9MB of RAM leaked.
VSCore *pCore = cpVSAPI->createCore(1);
cpVSAPI->freeCore(pCore);
While at it, I found another memory hogging problem on playback. If we set play speed to anything other than "no limit", memory usage will be doubled. For my dvd, the memory usage playing with "no limit" is 150 MB while playing it without "no limit" jumped to 300 MB. I'm still investigating the problem and looking from the change log, I'm suspecting that it could be originated all the way back from r9 of the original version.
However I couldn't find download for r8 anymore, MS's page only has r17 as the oldest release. If anyone has the older version, please share it.
ChaosKing
28th August 2020, 23:20
You got lucky https://web.archive.org/web/20160604054704/https://bitbucket.org/mystery_keeper/vapoursynth-editor/downloads/
Direct link https://web.archive.org/web/20160607212315/https://bitbucket.org/mystery_keeper/vapoursynth-editor/downloads/VapourSynthEditor-r8-64bit.7z
lansing
29th August 2020, 00:16
You got lucky https://web.archive.org/web/20160604054704/https://bitbucket.org/mystery_keeper/vapoursynth-editor/downloads/
Direct link https://web.archive.org/web/20160607212315/https://bitbucket.org/mystery_keeper/vapoursynth-editor/downloads/VapourSynthEditor-r8-64bit.7z
Oh no, the playback feature wasn't implemented in r8 yet, need to look for r9 now.
Update: I was able to rebuild r9 from source.
In r9, RAM usage will only go double on playback and go back down when stopped. So this mechanism was broken somewhere in between the updates in the years. Right now the RAM will not go back down when stopped. Will fix.
l33tmeatwad
30th August 2020, 02:11
Took me a while to get around to compiling and testing this. One thing I don't like is the fact that you cannot load videos without the full path added even if the script is in the same folder. Was this an intentional change?
lansing
30th August 2020, 04:53
Took me a while to get around to compiling and testing this. One thing I don't like is the fact that you cannot load videos without the full path added even if the script is in the same folder. Was this an intentional change?
I never knew it was there lol, I always load video by drag and drop. I'll look into it.
Cary Knoop
30th August 2020, 04:59
Question about this new VS Editor, can I install this without negatively impacting the original VS Editor, in other words can both be installed and used?
poisondeathray
30th August 2020, 05:31
Question about this new VS Editor, can I install this without negatively impacting the original VS Editor, in other words can both be installed and used?
Yes, no problem
But they share the same config file. If you edit the preferences on one, it affects the other
In Windows:
It is in C:\Users\USERNAME\AppData\Local\vsedit.config
Most programs have their own folder, vsedit does not have one.
ChaosKing
30th August 2020, 06:16
Yes, no problem
But they share the same config file. If you edit the preferences on one, it affects the other
In Windows:
There is also a portable mode! You can find it in settings.
lansing
30th August 2020, 10:38
In r9, RAM usage will only go double on playback and go back down when stopped. So this mechanism was broken somewhere in between the updates in the years. Right now the RAM will not go back down when stopped. Will fix.
More update on this, this looks to be a lot bigger issue than I thought. The RAM usage came from the frame cache. The program is caching two copies of a frame at a time. One copy would be convert to RGB for preview and the other copy for process like running benchmark and retrieving frame info. This led to unnecessary doubling of RAM usage during preview playback. As a result, a supposedly 600 MB of frame cache for a 1080 video was doubled to 1600 MB.
In comparison, the same 1080 video on Avspmod only uses 270 MB of RAM...there's a lot of improvement to be done...
ChaosKing
31st August 2020, 07:37
So that is why after a while + multiple previews vsedit just chrashed for me.
lansing
31st August 2020, 23:17
I put up a R3.1 test build (https://bitbucket.org/gundamftw/vapoursynth-editor-2/downloads/) for testing. This probably breaks benchmark and encoding.
This build I removed one of the frame copy in the frame cache, that only saved about 10% of memory usage. What really reduced the memory are changing the frame requesting queue from using max number of threads to 2 and setting frame cache from 100 to 1. The result is:
720 x 480:
before: 310 MB
after: 120 MB
1920 x 1080:
before: 1600 MB
after: 476 MB
From my observation I don't see any negative impact but I have a fast machine, so please test on your machine and give feedback on the change.
poisondeathray
1st September 2020, 05:22
R3.1 test seems ok so far. But you're right - benchmark crashes it
lansing
1st September 2020, 06:44
R3.1 test seems ok so far. But you're right - benchmark crashes it
What is your RAM usage on playback compare to R3?
poisondeathray
1st September 2020, 16:13
What is your RAM usage on playback compare to R3?
1280x720p23.976
R3 634 MB
R3.1 149 MB
V1 R19 636 MB
poisondeathray
1st September 2020, 16:15
request:
1) ability to drag tabs to reorder them
2) can you add right click > copy to to new tab in the tab context menu ?
shph
1st September 2020, 17:28
request for mouse middle click to zoom (similar to "classic" vseditor preview window)
lansing
1st September 2020, 22:26
Does anyone know how to use the "preview advance setting"? I have no idea what it does, I changed the matrix coeff but nothing happen to my image?
lansing
1st September 2020, 22:51
request for mouse middle click to zoom (similar to "classic" vseditor preview window)
No that's not a good way to zoom. When zooming, you will want to go with something like 100%->150%->200%->250%, little by little, but this along will require 3 clicks if you're to do it with middle click. This should be handle by wheel scroll.
l33tmeatwad
4th September 2020, 20:29
Just tested out the latest from the repository. Everything seems to be working fine, however it always crashes when closing on macOS. Not sure what's going on, haven't had a chance to run a debug, but I figured I'd mention that in case I don't get around to it anytime soon.
ChaosKing
7th September 2020, 10:53
One thing that is a bit annoying in vseditor2 is when your script has an error. With vs1 the log windows was always visible and I could immediately spot the problem. In vs2 you always need to explicitly open the log window (on every program start) to see if there is an error.
Maybe the last status of the log window could also be saved (opened/closed)
OR
a small icon indicates if there an error is present
OR
the log opens automatically if the script contains an error (on F6 / F7 pressed)
lansing
14th September 2020, 15:07
Updating my status, I've been busy playing Xenoblade Chronicle for the past week, update on the project will continue after I finished it.
Tohno_Neil
15th September 2020, 20:22
I tried the R3 X64 version,popup a window and program closed.
:confused:
https://forum.doom9.org/attachment.php?attachmentid=17486&stc=1&d=1600197787
Unable to locate the program input point _ZNSt3pmr20get_default_resourceEv in the dynamic link library Qt5Core.dll
Any debug mode?
l00t
25th September 2020, 09:00
Dear lansing, I really appreciete your work on improving VSEditor. I have a small question regarding when are you planning to put back the Crop Editor? Also Zoom functions bound to 1, 2, 3 was very useful.
Tima
6th October 2020, 13:51
I can't make VSEditor 2 to become default editor for vpy files on Windows:
- I can associate it, but when I click on the script, VSEditor opens with a blank tab instead of the target script.
(VSEditor doesn't even pick up script argument when called via CLI)
- In addidion, I get theme_presets.txt file created in the folder where my script is located.
Both items seem to be regressions compared to v1.
poisondeathray
28th October 2020, 16:15
R3.1 issue with the FI color picker - >8bit seem to read as 8bit values, and sometimes values are off
Works ok in R3.0 or R19 original
sl1pkn07
1st November 2020, 18:35
Hi
i have this when close the app
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
Abortado (`core' generado)
builded with GCC 10.2.0 and QT 5.15.1
and also, anyone can review this?
is for add support for use XDG paths ('/home/$USER/.config' and '/home/$USER/.local/share' ) as directory path defaults for themes and bookmarks in linux
diff --git a/vsedit/src/main_window.cpp b/vsedit/src/main_window.cpp
index 5f068d1..3156207 100644
--- a/vsedit/src/main_window.cpp
+++ b/vsedit/src/main_window.cpp
@@ -2266,11 +2266,24 @@ void MainWindow::slotSaveBookmarksToFile()
{
QFileInfo fileInfo(scriptName);
//get file path and fileName without extension
+#ifdef Q_OS_LINUX
+ QString xdgDataHome = QFile::decodeName(qgetenv("XDG_CONFIG_HOME"));
+ if (xdgDataHome.isEmpty())
+ xdgDataHome = QDir::homePath() + "/.local/share/vsedit";
+ QDir xdgDataHome_path;
+ if (!xdgDataHome_path.exists(xdgDataHome))
+ xdgDataHome_path.mkpath(xdgDataHome);
+#else
QString filePath = fileInfo.absolutePath();
+#endif
QString scriptFileName = fileInfo.baseName();
QString fileName = QFileDialog::getSaveFileName(this,
+#ifdef Q_OS_LINUX
+ tr("Save bookmark"), xdgDataHome + QDir::separator() + scriptFileName,
+#else
tr("Save bookmark"), filePath + QDir::separator() + scriptFileName,
+#endif
tr("Text file (*.txt)"));
if (fileName.isEmpty())
diff --git a/vsedit/src/script_editor/script_editor.cpp b/vsedit/src/script_editor/script_editor.cpp
index 238b6e4..4af581b 100644
--- a/vsedit/src/script_editor/script_editor.cpp
+++ b/vsedit/src/script_editor/script_editor.cpp
@@ -941,7 +941,17 @@ void ScriptEditor::loadThemeSettings()
{
QString savedThemeName = m_pSettingsManager->getThemeName();
- QFile file("theme_presets.txt");
+#ifdef Q_OS_LINUX
+ QString xdgConfigHome = QFile::decodeName(qgetenv("XDG_CONFIG_HOME"));
+ if (xdgConfigHome.isEmpty())
+ xdgConfigHome = QDir::homePath() + "/.config/vsedit";
+ QDir xdgConfigHome_path;
+ if (!xdgConfigHome_path.exists(xdgConfigHome))
+ xdgConfigHome_path.mkpath(xdgConfigHome);
+ QFile file(xdgConfigHome + "/theme_presets.txt");
+#else
+ QFile file("theme_presets.txt");
+#endif
if (!file.open(QIODevice::ReadOnly | QIODevice::Text)){
file.open(QIODevice::WriteOnly); // create file if it doesn't exist
file.open(QIODevice::ReadOnly | QIODevice::Text);
diff --git a/vsedit/src/settings/settings_dialog.cpp b/vsedit/src/settings/settings_dialog.cpp
index e71b833..59c0c20 100644
--- a/vsedit/src/settings/settings_dialog.cpp
+++ b/vsedit/src/settings/settings_dialog.cpp
@@ -285,7 +285,17 @@ void SettingsDialog::loadThemePresets()
* load from temp string and add preset names to theme list model
* the list model will then update combobox automatically
*/
- QFile file("theme_presets.txt");
+#ifdef Q_OS_LINUX
+ QString xdgConfigHome = QFile::decodeName(qgetenv("XDG_CONFIG_HOME"));
+ if (xdgConfigHome.isEmpty())
+ xdgConfigHome = QDir::homePath() + "/.config/vsedit";
+ QDir xdgConfigHome_path;
+ if (!xdgConfigHome_path.exists(xdgConfigHome))
+ xdgConfigHome_path.mkpath(xdgConfigHome);
+ QFile file(xdgConfigHome + "/theme_presets.txt");
+#else
+ QFile file("theme_presets.txt");
+#endif
if (!file.open(QIODevice::ReadOnly | QIODevice::Text)){
file.open(QIODevice::WriteOnly); // create file if it doesn't exist
file.open(QIODevice::ReadOnly | QIODevice::Text);
@@ -375,7 +381,17 @@ void SettingsDialog::saveThemeSettings()
m_pSettingsManager->setThemeName(
m_ui.themePresetSelectionComboBox->currentText());
- QFile file("theme_presets.txt");
+#ifdef Q_OS_LINUX
+ QString xdgConfigHome = QFile::decodeName(qgetenv("XDG_CONFIG_HOME"));
+ if (xdgConfigHome.isEmpty())
+ xdgConfigHome = QDir::homePath() + "/.config/vsedit";
+ QDir xdgConfigHome_path;
+ if (!xdgConfigHome_path.exists(xdgConfigHome))
+ xdgConfigHome_path.mkpath(xdgConfigHome);
+ QFile file(xdgConfigHome + "/theme_presets.txt");
+#else
+ QFile file("theme_presets.txt");
+#endif
if (!file.open(QFile::WriteOnly | QFile::Truncate | QIODevice::Text )) {
QMessageBox::information(this, tr("Unable to write to file"),
file.errorString());
@@ -933,9 +945,19 @@ void SettingsDialog::slotHandleThemeExport()
void SettingsDialog::slotExportSelectedThemePresets(QStringList &a_selectedThemePresets)
{
+ QString xdgConfigHome = QFile::decodeName(qgetenv("XDG_CONFIG_HOME"));
+ if (xdgConfigHome.isEmpty())
+ xdgConfigHome = QDir::homePath() + "/.config/vsedit";
+ QDir xdgConfigHome_path;
+ if (!xdgConfigHome_path.exists(xdgConfigHome))
+ xdgConfigHome_path.mkpath(xdgConfigHome);
QString defaultDir = QStandardPaths::writableLocation(QStandardPaths::DesktopLocation);
QString fileName = QFileDialog::getSaveFileName(this,
- tr("Export theme preset"), defaultDir + QDir::separator() + tr("theme"),
+#ifdef Q_OS_LINUX
+ tr("Export theme preset"), xdgConfigHome + QDir::separator() + tr("theme"),
+#else
+ tr("Export theme preset"), defaultDir + QDir::separator() + tr("theme"),
+#endif
tr("Theme file (*.txt)"));
if (fileName.isEmpty())
greetings
lansing
1st November 2020, 22:14
Sorry for the late response, I have finished all my games now and will be back on the project tomorrow. Looks like VSAPI 4.0 is still not ready yet, so I guess I haven't miss anything much.
Jukus
2nd November 2020, 15:43
I installed VSE 2 from https://aur.archlinux.org/packages/vapoursynth-editor-git/ and nothing works, F5 doesn't work, F6 doesn't work, when I open the script from the file manager then a blank document opens instead of the script.
lansing
2nd November 2020, 20:47
I installed VSE 2 from https://aur.archlinux.org/packages/vapoursynth-editor-git/ and nothing works, F5 doesn't work, F6 doesn't work, when I open the script from the file manager then a blank document opens instead of the script.
R3.1 was a test version, try R3
sl1pkn07
4th November 2020, 22:08
R3.1 (R3 tag, 1 commit ahead, not ver "3.1") is only one commit ahead R3
https://bitbucket.org/gundamftw/vapoursynth-editor-2/commits/
outhud
8th November 2020, 12:20
Can someone point to what Qt I should install to get this to compile on Ubuntu 20.04 LTS?
It seems it needs Qt 5.13 at least, but not clear how I should install this. Using the offline installer, and enabling "Sources" in the installer, says it will take over 4.01GB HDD space?
PRAGMA
23rd November 2020, 18:30
Great work so far. Love the little UX improvements here and there, just I have some suggestions (some might be bugs on my end?).
- when opening VS Edit, remember what scripts/tabs were open (this one is driving me mad)
- maybe add a setting that attempts to preview the script automatically when you open the script/tab, if it errors out, then don't retry automatically.
- in the log under the script editor, add support for this to show prints (stdout) not just stderr (this one drove me absolutely mad with the original VS Edit, my only solution is to raise exceptions rather than print or use core.text, both aren't ideal)
- on Linux, kde plasma 5, the UI for the log under the script editor annoyingly has a white border around it if you're on a dark theme.
https://i.imgur.com/p0D8xo7.png
- Also forgive me if I'm missing something obvious, but why is the seek bar so insanely huge height wise?
https://i.imgur.com/MC515si.png
- Maybe a way to pin the Tools' windows next to the preview window so its no longer floating would be nice too.
- Also a way to change the preview to be Bilinear would be nice. Seems the dropdown for the kernel was removed and the hotkey for it doesn't seem to do anything.
:thanks::thanks:
PRAGMA
23rd November 2020, 18:47
R3.1 (R3 tag, 1 commit ahead, not ver "3.1") is only one commit ahead R3
https://bitbucket.org/gundamftw/vapoursynth-editor-2/commits/
I could be wrong but doesn't look like this aur package should be versioned R3.1, since the git itself doesn't have any of the R3.1 changes committed to it yet. The only R3.1 available is a Windows X64 build in Deployments
Jukus
4th December 2020, 13:36
Is the Point resizer used for zoom and there is no way to change it?
Jukus
4th December 2020, 17:46
Just stopped working after restarting
Failed to evaluate the script:
Python exception: D2V cannot be opened.
Traceback (most recent call last):
File "src/cython/vapoursynth.pyx", line 2244, in vapoursynth.vpy_evaluateScript
File "src/cython/vapoursynth.pyx", line 2245, in vapoursynth.vpy_evaluateScript
File "script_9777", line 8, in
File "src/cython/vapoursynth.pyx", line 2069, in vapoursynth.Function.__call__
vapoursynth.Error: D2V cannot be opened.
sl1pkn07
7th December 2020, 21:39
I could be wrong but doesn't look like this aur package should be versioned R3.1, since the git itself doesn't have any of the R3.1 changes committed to it yet. The only R3.1 available is a Windows X64 build in Deployments
┌─┤[$]|[sl1pkn07]|[sL1pKn07]|[~/aplicaciones/vapoursynth-editor-git/vapoursynth-editor]|
└───╼ echo $(git describe --long --tags | tr - .)
R3.1.gf38042a
┌─┤[$]|[sl1pkn07]|[sL1pKn07]|[~/aplicaciones/vapoursynth-editor-git/vapoursynth-editor]|
└───╼ echo $(git describe --long --tags)
R3-1-gf38042a
is a git thing. because makepkg (part of pacman, the archlinux package manager) dont like the "-" in the version
greetings
lansing
17th December 2020, 08:28
Finally back, R3.2 updated.
changelog
Capping frame cache and frame ticket queue sizes, greatly reducing memory usage
I have tested for the last couple of days, the memory issue should be resolved now on my part. The original version had the frame ticket queue and frame cache size set too big, I pretty much disabled them now. Though the memory usage is still a lot higher than Avspmod. For example, my 720x480 dvd source is using 48 MB on playback in avspmod while vseditor is using 105 MB. The original loading of the video is only 62 MB but then it raise as more frames were loaded and were capped at 105 MB. After going through all the codes looking for the cap, I finally realized that the frame caching actually came from vapoursynth, as running benchmark through vspipe results in about the same amount of memory usage.
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.