VirtualDub2

[v0lt]

Something is not quite working though.
Please use the new version of the plugin from the VirtualDub2 v2.2.0.755 release (https://forum.doom9.org/showthread.php?p=2014143#post2014143) or from the GitHub repository. (https://github.com/v0lt/scripted_vdplugin/releases)

[rgr]

1. Filter data file (default Deshaker.log).
2. Folder with .vdproject file.

I load the project to 44282 -- I can leave the field empty, the plugin uses the current folder.
I load the same project to 667 -- I have to fill in the field with the full path (I don't know where it looks for it then, but not in the project path)..

OK, I figured out where the problem is.

1. If I first run VDub, and then *load the project via File->Load Project*, everything is OK. The plugin sees the project path as "current".
2. If I first run VDub, and then *drag the project into it*, the plugin saves its data in the VDub directory -- it sees this as "current" (I also had this entered as the startup directory in the shortcut from which I run VDub). But after deleting this data, it still does not see the project folder as current, but I have not checked what the "current" folder is for the plugin.

I do not know if this is how it should be, so I am reporting the problem.

(In the vdproject file, the project path is entered as // $location if that matters)

[v0lt]

VirtualDub2_v2.2.0.803_unicode (https://disk.yandex.ru/d/R3Ob8yREy4ChvA)
Test build. The application has been rewritten to use CharacterSet=Unicode in the project properties.

PS: updated to 2.2.0.803.

[isidroco]

Will you consider changing /queryVersion reply to some # higher than older versions (ie: 45nnn )

[v0lt]

Will you consider changing /queryVersion reply to some # higher than older versions (ie: 45nnn )
I don't understand you.

[StainlessS]

I dont offhand know how to show the /queryVersion thingy that he mentions (CLI is rusty).
But this is I think what he's going on about.

vudb64 /?

VirtualDub CLI Video Processor Version (build 44282/release-AMD64) for AMD64
/autorecover Scan for auto-recover files
/capture Switch to capture mode
/capaudiorec [on|off] Enable/disable capture audio recording
/capaudioplay [on|off] Enable/disable capture audio playback
/capchannel <ch> [<freq>] Set capture channel (opt. frequency in MHz), use antenna:<n> or cable:<n> to force mode
/capdevice <devname> Set capture device
/capfile <filename> Set capture filename
/capfileinc <filename> Set capture filename and bump until clear
/capfilealloc <size> Preallocate capture file in megabytes
/capstart [<time>[s]] Capture with optional time limit (default is minutes, use 's' for seconds)
/F <filter> Load filter
/edit <instance> Open video filter configure dialog
/h Disable exception filter
/hexedit [<filename>] Open hex editor
/hexview [<filename>] Open hex editor (read-only mode)
/resetall Reset all settings to defaults
/s <script> Run a script
/i <script> [<args...>] Invoke script with arguments
/cmd <command> Run quick script command
/c Clear job list
/b <src-dir> <dst-dir> Add batch entries for a directory
/p <src> <dst> Add a batch entry for a file (SaveAVI)
/SaveAVI <src> <dst>
/ExportViaEncoderSet <src> <dst> <set>
/RunNullVideoPass <src>
/SaveAVI * <dst> (* to use source loaded with other commands)
/RunNullVideoPass *
/ExportViaEncoderSet * <dst> <set>

/r Run job queue
/master <file> Join shared job queue in non-autostart mode
/slave <file> Join shared job queue in autostart mode
/portable Switch to portable settings mode
/priority <pri> Start in low, belowNormal, normal, aboveNormal, high, or realtime priority
/queryVersion Return build number
/safecpu Do not use CPU extensions on startup
/min Start minimized
/max Start maximized
/topmost Create window as always-on-top
/x Exit when complete


Maybe it dont properly return [EDIT: set errorlevel] the build number.

EDIT: from post #1539

set oldVDub= & REM space: Enable newer VDub2 commands: use color matrix, hide i/o video in status window
set xCompr=I& REM *I* default h264 vDub internal for new Vdub
IF not "%PARAM:ch264v=%" == "%PARAM%" set xCompr=H& REM *H* h264 vfw
IF exist "%vdloc%%vDubCli%" ( rem Check if old vdub version
"%vdloc%%vDubCli%" /queryVersion >nul
if not errorlevel 42475 ( REM if ver<42475 old version of virtualDub
set noWavHeader= & REM don't use in new vdub versions
set oldVDub=// & REM bars "// " comments out newer commands
set xCompr=H& REM *H* default h264 vfw compressor for old Vdub
)
)


EDIT: Is this correct for cli logic ??? [maybe something like "if not errorlevel < 42475"

if not errorlevel 42475 ( REM if ver<42475 old version of virtualDub

[v0lt]

I think it is wrong to use the build number to compare executables of different projects with different executable file names.

If you want to know the version number, you can do it like this:
@ECHO OFF
SET FILE_NAME="VirtualDub2.exe"
FOR /F "USEBACKQ" %%F IN (`powershell -NoLogo -NoProfile -Command ^(Get-Item %FILE_NAME%^).VersionInfo.FileVersion`) DO (SET FILE_VERSION=%%F)
ECHO %FILE_NAME% %FILE_VERSION%
PAUSE

I will fix the "/queryVersion" command for the next release. But it will not give a number greater than the build number of the original VirtualDub 1.10.4.

[wonkey_monkey]

This is only a teeny tiny thing, but when a video is 100% of the window width, but doesn't exceed the window height, it still has a raised border to the left and right.

Could that border be shifted off the edges of the window in such a case?

[LigH]

EDIT: Is this correct for cli logic ???

Yes, ERRORLEVEL comparison is implicitly "greater than or equal", but there are 3-letter verbose operators (e.g. "EQU").

https://ss64.com/nt/errorlevel.html

[StainlessS]

Ta LigH :)

[v0lt]

Test build VirtualDub2_v2.3.0.819 (https://disk.yandex.ru/d/R3Ob8yREy4ChvA)
VirtualDub2 is now a Unicode application.
Improved support for file paths with Unicode characters.
Removed obsolete "Disk I/O write mode" setting.

PS: updated to 2.3.0.819.

[isidroco]

I don't understand you.

My script takes in account WHICH version of VirtualDub is installed and changes it's behaviour accordingly. For that basically I use something like:


vDub64.exe /queryVersion >nul
if not errorlevel 42475 ( REM if ver<42475 old version of virtualDub
set noWavHeader= & REM don't use in new vdub versions
set oldVDub=// & REM bars "// " comments out newer commands
set xCompr=H& REM *H* default h264 vfw compressor for old Vdub
)


In a batch, "IF ERRORLEVEL 100" gives true if error is Less or Equal than 100.
As you can see in my example, if the errorlevel returned by /queryVersion is LESS than 42475, implies that is an OLD version of VirtualDub and some workarounds are SET for it.
Your NEW version of VirtualDub breaks natural ascending version order. And ALSO breaks program name (it has ALWAYS been VirtualDub.exe / VirtualDub64.exe ). Whats worst, now both x32 and x64 versions have SAME NAME: VirtualDub2.exe

All those breaking things breaks consistency, and makes your program unusable for me: My script decides to use VirtualDub x32 if certain filters that only exist on x32 are used, or else uses faster x64 platform (h264/h265 are at least twice as fast) under x64. But my script must work on ANY virtualDub version, and your unneeded and unjustified changing both, VirtualDub names and version number lower than before breaks everything and makes a nightmare of exceptions.

I'm dissapointed that instead of improving we have all these problems. And I can't see any advantage in changing an already established naming and versioning convention that you are refusing to follow. VirtualDub x32/x64 has always been on same folder...

[v0lt]

And ALSO breaks program name (it has ALWAYS been VirtualDub.exe / VirtualDub64.exe ).
No. You often forget about "Veedub64.exe".

I'm dissapointed that instead of improving we have all these problems. And I can't see any advantage in changing an already established naming and versioning convention that you are refusing to follow.
I suggested you earlier suggested checking the name of the folder name and the executable file. I also showed how to get the version of the executable file. You don't want this - that's your right. My right to make my version of VirtualDub2 as I like.

VirtualDub x32/x64 has always been on same folder...
You are writing a lie.
Avery Lee released 32 and 64 bit versions of VirtualDub in two different archives (https://virtualdub.sourceforge.net/). I don't remember him recommending unpacking the two versions into the same folder.

[isidroco]

No. You often forget about "Veedub64.exe".....
You are writing a lie.
Avery Lee released 32 and 64 bit versions of VirtualDub in two different archives (https://virtualdub.sourceforge.net/). I don't remember him recommending unpacking the two versions into the same folder.

What I meant is that it was always possible to put everything on one folder.
Agreed about Veedub64.exe. But it has never had the SAME name, almost no x86/x64 utility has the same name (ie: PSTOOLS has 64 appended to each utility). If VirtualDub folders are on PATH, it's impossible to know which version will be called when you write VirtualDub2.exe on command prompt. It only creates possible misunderstanding and errors. I would understand if there's an advantage of doing that, but I can't see any. Using same name for two different programs is a mistake. Choose the name that you want, but please use different naming for x86/x64.

You didn't answer about breaking natural version ascending order.

[v0lt]

What I meant is that it was always possible to put everything on one folder.
There is VirtualDub2 v2.1.3.667 x64 and win32 (https://github.com/v0lt/VirtualDub2/releases/tag/2.1.3), in which the EXE files are named as you want. But it seems you did not even try to write everything in one folder. Otherwise you would have realized that one of the versions would not work properly.

You didn't answer about breaking natural version ascending order.
I answered (https://forum.doom9.org/showthread.php?p=2015240#post2015240). The full version number increases monotonically.

I think your approach to defining the VirtualDub type is wrong. I will not support it.

I would make two variables.
The first variable defines the VirtualDub type: original VirtualDub, VirtualDubMod or VirtualDub2.
The second variable defines the architecture: win32 or x64.

[isidroco]

Otherwise you would have realized that one of the versions would not work properly.
...
The first variable defines the VirtualDub type: original VirtualDub, VirtualDubMod or VirtualDub2.
The second variable defines the architecture: win32 or x64.

I didn't realize that, as I didn't put it on use because of the Versioning issue.
Either you should use version numbers starting from 45000 or rename this project to VirtualDub3, as there already is this one with same name: https://sourceforge.net/projects/vdfiltermod/ and version of that one is 44282.
Even on different folders, having same name for both versions will make mistakes possible when launching without specifying full path.

I can't understand why you refuse to return a version number higher than previous VirtualDub versions.

[v0lt]

In version 2.3.0.819, the "/queryVersion" command has been deprecated and now always returns 50000.

[isidroco]

In version 2.3.0.819, the "/queryVersion" command has been deprecated and now always returns 50000.
Thanks, I'm really sorry of being so insistant and bothering you, when I'm grateful of all your work to continue improving this. I would appreciate /queryVersion not being deprecated, but just be used like you did before but starting in 50xxx ie: 50819, etc
And also I would be greatful, if you can consider having different names for x32/x64 versions. As my script is given with vdub name and must figure out which version (by calling /queryVersion) and platform (x32/x64) based on it's name. As a workaround I could check if "64" is on it's path, but it's a weak solution, as it may be altered if user decides to use another folder name.

[Hellboy.]

isidroco
Stop trying to obligate v0lt to change his VirtualDub because you don't want to change your script.
You haven't mentioned a real reason why you can't change your script.
All the excuses you mentioned don't make any sense.
The only conclusion i can see is that you didn't write that script and you don't know how to change it.

[blob2500]

Hi. If I set the VirtualDub.ini file, I found that Virtualdub2 is not completely portable; for example regarding the parameters of the integrated x264 codec, it releases the values ​​in the windows registry. I think this should not happen, or am I wrong?

https://i.postimg.cc/BXBC2t1R/vd-reg-x264.jpg (https://postimg.cc/BXBC2t1R)

[shekh]

blob2500

It works that way. VirtualDub.ini holds settings of the main app only, any plugin is on its own. (I still consider this behaviour of codec portable since it does not require installation and registry settings do little harm if any).

[blob2500]

I understand, but with other internal codecs, even plugins, it doesn't happen. Examples: Lagarith, FFmpeg x264...

If they were user-added plugins it would make sense, but since they are internal, provided with the basic package, they should all behave the same way.

[isidroco]

isidroco
Stop trying to obligate v0lt to change his VirtualDub because you don't want to change your script.
You haven't mentioned a real reason why you can't change your script.
All the excuses you mentioned don't make any sense.
The only conclusion i can see is that you didn't write that script and you don't know how to change it.

You are extremely disrespectful. I'm not forcing anyone, and explained the lack of logic in having a NEW version of a program with a value less than previous. Also explained that I use BOTH x32 and x64 virtualDubs, and it's difficult to tell which one you are using if they have the SAME name, and I can't predict which folder name user will use. I can change my script, but I also want to mantain compatibility with previous versions as I always did.
Now I'm adding a whole avisynth Noise reduction and preparing an installer because it's getting difficult for a regular user to install and use.

[Leo 69]

v0lt,

Do you know why I get artifacts every time I try to play any H.265 10-bit video in VirtualDub? The issue is very easy to reproduce with basically any 10-bit video encoded with H.265 codec. When played back, about 50% of video is shown normally and 50% is filled with artifacts like this. What can be done? Also, when I try to convert any such video into any other format from within VirtualDub, these artifacts will be in the resulting file as well. So could there be anything wrong with the built-in decoder?

https://i.postimg.cc/6ppkSqfz/2025-03-21-002410.png

[v0lt]

The issue is very easy to reproduce with basically any 10-bit video encoded with H.265 codec.
I don't have your "any video".
I have "LG Colors of Journey HDR UHD 4K Demo.mkv" and it plays without artifacts in VirtualDub2 x64 v2.3.0.829 (https://disk.yandex.ru/d/R3Ob8yREy4ChvA).

So could there be anything wrong with the built-in decoder?
The 64-bit build 2.3.0.829 uses FFmpeg 7.1.1 (official build). I don't know what could be wrong there.

[Leo 69]

I don't have your "any video".
I have "LG Colors of Journey HDR UHD 4K Demo.mkv" and it plays without artifacts in VirtualDub2 x64 v2.3.0.829 (https://disk.yandex.ru/d/R3Ob8yREy4ChvA).


The 64-bit build 2.3.0.829 uses FFmpeg 7.1.1 (official build). I don't know what could be wrong there.

Thanks for replying. Upon inspection, I found that 8-bit H.265 videos also have the same issue. Could you please try playing back this sample on your end?

https://app.filen.io/#/d/022ef330-5369-4ae7-b7a0-562f43839e47%23znUBKaMTjewwQfduQXjgBv8dGiwdMQmi

I also tried the LG : Colors Of Journey HDR video and can confirm that it doesn't have this issue. I also have several other 60 FPS demos and they don't have this issue, but videos with more regular framerates (23.976, 25 and 29.97) have.

[SeeMoreDigital]

v0lt,

Do you know why I get artifacts every time I try to play any H.265 10-bit video in VirtualDub?
All fine at my end when feeding VirtualDub2 v2.1.3.667 with HEVC streams extracted from 4K UHD discs.

[Leo 69]

All fine at my end when feeding VirtualDub2 v2.1.3.667 with HEVC streams extracted from 4K UHD discs.

Have you tried the sample I posted?

[LigH]

Could you please try playing back this sample on your end?

https://app.filen.io/#/d/022ef330-5369-4ae7-b7a0-562f43839e47%23znUBKaMTjewwQfduQXjgBv8dGiwdMQmi

VirtualDub2 r44282 (release): OK
VirtualDub2 r44282 + avlib 0.7.1.220: broken
VirtualDub2 v2.2.0.755: broken
VirtualDub2 v2.3.0.829: broken

[v0lt]

The "avlib_vdplugin" log when playing "sample.mkv" looks like this:
FFLog: Could not find ref with POC 14
FFLog: Could not find ref with POC 14
FFLog: Could not find ref with POC 14
...
FFLog: Could not find ref with POC 17
FFLog: Could not find ref with POC 17
FFLog: Could not find ref with POC 17
I found a similar issue: https://github.com/mpv-player/mpv/issues/3440

[SeeMoreDigital]

VirtualDub2 r44282 (release): OK
I can confirm this release does indeed fix Leo 69's issue ;)

Edit: Having a 'variable frame rate' doesn't help. But re-muxing the hevc elementary stream to have a constant frame didn't help either.

[LigH]

I found a similar issue: https://github.com/mpv-player/mpv/issues/3440

There I read that there are reasons (e.g. VFR, but also High Bit Depths) which may cause wrong seeking. Issue got closed only because "wrong muxing" was blamed. But if an older version works without issues, there seems to be a more compatible fallback technique to determine a valid reference frame?

[Leo 69]

I just wanted to add that variable frame rate doesn't really play a role, I have plenty of videos with CFR which VirtualDub has same issues with (but not with all videos).

[v0lt]

I found this ticket - https://trac.ffmpeg.org/ticket/9805.
There is a problem with ffplay, but ffplay works fine for me.
There are links in the ticket, but they do not explain how to solve the problem in applications using ffmpeg.

[qyot27]

There I read that there are reasons (e.g. VFR, but also High Bit Depths) which may cause wrong seeking. Issue got closed only because "wrong muxing" was blamed. But if an older version works without issues, there seems to be a more compatible fallback technique to determine a valid reference frame?
If it's the sort of 'wrong muxing' I'm thinking of (or at least in the same ballpark), then remuxing yourself using MKVToolNix and then checking if the new file is broken would confirm that.

[LigH]

Original sample.mkv was (according to metadata) multiplexed with mkvmerge v90.0.

Remultiplexed with mkvmerge v91.0 (https://www.mediafire.com/file/aws4t7697los6sk/sample2.mkv/file): same result (works in r44282, fails with any newer avlib).

Remultiplexed with Box4 v3 to MP4 (https://www.mediafire.com/file/vcof2shusj46u2d/sample.mp4/file): same result (works in r44282, fails with any newer avlib).

[v0lt]

Test build VirtualDub2 v2.3.0.838 (https://disk.yandex.ru/d/R3Ob8yREy4ChvA).
I tried to fix the problem with some HEVC streams.
Hopefully nothing else was broken.

[jay123210599]

Say I want to zoom in on this specific part of the video (meaning only show that specific selection). How do I do that?

https://imgur.com/Sucpw45

[poisondeathray]

Say I want to zoom in on this specific part of the video (meaning only show that specific selection). How do I do that?

https://imgur.com/Sucpw45

If you mean the frame selection in the screenshot , edit=>crop to selection

If you mean spatially, to some elements of the picture such as eyes etc.., apply the crop filter and resize filter

[SeeMoreDigital]

Out of interest...

If I wanted to use the 'x264 8-bit codec' to encode a Blu-ray disc compatible video stream, what additional command lines would I need to put in the 'Extra command line' box?

Cheers

[nji]

Say I want to zoom in on this specific part of the video (meaning only show that specific selection). How do I do that?

https://imgur.com/Sucpw45

Try this (https://www.rationalqm.us/motion/motion.html)

[LigH]

@SeeMoreDigital

Possibly among others, most probably: --bluray-compat (I guess).

Calling Selur with more experience for support...

[Selur]

See https://forum.doom9.org/showthread.php?t=154533 under '2.1 Mandatory parameters', the mandatory options are really needed and to be compatible with most authoring software, make sure to use "--slices 4" when using level 4.1, also I would add every option under '2.2 Optional parameters' if possible.

Cu Selur

[LigH]

:thanks:

And I guess exporting raw AVC video from the x264 codec, without a container, is an own issue to be thought through thoroughly.

[SeeMoreDigital]

Hello again,

So far I've added --bluray-compat --slices 4 into the command line area but at the end of the encoding process I received the following 'warning' message: -

https://i.ibb.co/JRr4tx0B/Screenshot-2025-03-31-102205.png

What do I need to do to resolve this?

[LigH]

Add also VBV parameters related to the Profile@Level, resolution, and frame rate of the material, based on the Blu-ray compatibility table.

[SeeMoreDigital]

Add also VBV parameters related to the Profile@Level, resolution, and frame rate of the material, based on the Blu-ray compatibility table.I'm encoding (what is essentially) a still image into an 1920x1080 AVC video stream at 1000kbps ARB at 24.000fps. Would the following work:

--vbv-bufsize 1000 --vbv-maxrate 3000 is allowed

[v0lt]

VirtualDub2 v2.3.0.845 (https://github.com/v0lt/VirtualDub2/releases/tag/2.3.0)

Changes:
VirtualDub2 is now a Unicode application.
Improved support for file paths with Unicode characters.
Removed obsolete "Disk I/O write mode" setting.
The "/queryVersion" parameter has been deprecated.
Updated zlib 1.3.1.

Updated avlib-1.vdplugin to version 0.7.1.264.
- FFmpeg 7.1.1 is now supported.
- Fixed crash on problematic AAC audio.
- Fixed missing sound for some MP4 files with AAC audio.
- Fixed a crash when playing video files with changing video frame size.
- Ignore m3u playlist files.
- Fixed frame retrieval for some HEVC streams.
- Added video encoder SVT-AV1.
- Minor optimizations.

Updated scripted.vdplugin to version 0.2.2.100.
- Scintilla 5.5.6 updated.
- Lexilla 5.4.4 updated.

Also available is old VirtualDub2 44282 with updated avlib.vdplugin (https://github.com/v0lt/avlib_vdplugin/releases/tag/0.7.1.264).

[rgr]

Since changing the program version, folder, etc. VirtualDub doesn't want to show up in the "Open With" list (I mean the context menu, not the window with "more" applications).
I used to have VirtualDub there, then I changed the folder, new version etc. and since then it doesn't want to show up in this menu, even when I make it the default application for e.g. avs.

The only thing I've googled is that others also have this problem with VirtualDub.
How do I fix this?

https://www.sevenforums.com/attachments/tutorials/167647d1486576054t-open-add-program-open_with.jpg

[v0lt]

Since changing the program version, folder, etc. VirtualDub doesn't want to show up in the "Open With" list (I mean the context menu, not the window with "more" applications).
I used to have VirtualDub there, then I changed the folder, new version etc. and since then it doesn't want to show up in this menu, even when I make it the default application for e.g. avs
What you write is not a VirtualDub problem. It is an old Windows bug.
https://superuser.com/questions/91655/open-with-dialog-ignores-my-selection