VirtualDub2

[isidroco]

I found the cause. If I leave the default path in the Deshaker filter ("C:\Users\Właściciel\AppData\Local\Deshaker"), VDub crashes when saving the project. Until I save the project, VDub (or rather the filter) saves everything correctly to that path.

Maybe it's caused by non ascii user: "Właściciel" had problems before with Paths/names including spanish: áéíóúñ in both AVIsynth and deshaker... Now I avoid using those.

[v0lt]

Maybe it's caused by non ascii user: "Właściciel" had problems before with Paths/names including spanish: áéíóúñ in both AVIsynth and deshaker... Now I avoid using those.
I think in VirtualDub2 v2.5.0.1005+ this problem may no longer exist.

[jay123210599]

How do I add subtext (https://github.com/vapoursynth/subtext) and assrender (https://github.com/AmusementClub/assrender) as plugins for VirtualDub2?

[LigH]

Not at all. They are for VapourSynth, which is a Python based scripting engine. You can load a VPY script in VirtualDub2, but the VapourSynth script will have to load the source file and handle all the filtering outside, and VirtualDub2 will only pass the result through to the encoders and save the result.

[rgr]

I think in VirtualDub2 v2.5.0.1005+ this problem may no longer exist.

This problem has been gone for a long time, I don't even remember which version it was.

[jpsdr]

In fact, the "plugins32" and "plugins64" folders were never needed.
But for me it's pratical, it gives some kind of order, not putting every files in haphazardly.

[blob2500]

Test build VirtualDub2 v2.5.0.1005 (https://disk.yandex.ru/d/R3Ob8yREy4ChvA)


Hi,
is it possible that one day you will also update the integrated x264 codec (vdplugin) ?

x264 - Core 157 r2935 is quite dated (feb. 2019).

Thanks

An updated plugin has been posted in the VideoHelp forum (https://forum.videohelp.com/threads/414223-VirtualDub2-Fork-By-v0lt#post2740481), did not test yet...
I tested this plugin update (core 164 r3191) it works well, but the encoding is slightly slower; approximately around 3-4%.

[Washka]

I also using x264, x265 have a little too smooth image for vhs even on higher bitrate.

[v0lt]

Hi,
is it possible that one day you will also update the integrated x264 codec (vdplugin) ?

x264 - Core 157 r2935 is quite dated (feb. 2019).
The source code is here - https://sourceforge.net/p/vdfiltermod/x264/ci/master/tree/

Need:
1. Rework the old project file for Visual Studio 2019 or 2022.
2. Automate the x264 library build.
3. Merge codec_8 and codec_10 (I think this separation is no longer necessary, and the bit depth could be selected in the x264.vdplugin settings).
4. Make the updated project publicly available.

[blob2500]

If I'm not mistaken, the version of the plugin currently present in virtualdub2 is based on the latest "official" vfw version (2017):

https://sourceforge.net/projects/x264vfw/files/


To avoid too much work, wouldn't it be possible to build directly on this?

https://sourceforge.net/projects/mpxplay/files/x264vfw/

It's updated to 2025, and I think many things are already ready, such as the 8/10-bit color depth unification.

(there is also the x265vfw version on the same author's site)

[LigH]

The VDub2 codec plugin is not a VfW codec. It is not to be installed in Windows. And I guess it has a more flexible interface to integrate into VDub2 better.

[blob2500]

Yes, I know that. But it's irrelevant. Maybe I didn't explain myself well, sorry.

I meant to base the plugin version on the most recent vfw version of x264. The plugin version, including the current one (core 157 r2935), is derived from vfw r2851, then updated by the previous VirtualDub2 author to r2935.
If I replace the vfw's .dll extension with .vdplugin and place it in the plugins folder, it works like a normal VirtualDub2 codec plugin. However, some superfluous features remain available that should be removed from the plugin version, such as the vfw/external file drop-down menu, typical of the vfw interface.

https://forum.doom9.org/showpost.php?p=1777059&postcount=89

What is x264 plugin (actually 2 plugins for each bitdepth): this is basically x264vfw from https://sourceforge.net/projects/x264vfw/ with some cosmetic changes:
VFW API is extended to support format negotiation etc.
File output is removed.
Decode support is removed.
Format conversion is disabled (handled by VD).

In fact some arbitrary vfw codec can be simply renamed as vdplugin, this may be useful to have many portable versions of same codec.

[LigH]

I guess I should notify autodidact in the VideoHelp forum (https://forum.videohelp.com/threads/414223-VirtualDub2-Fork-By-v0lt#post2786346) if he may be able to participate here.

[blob2500]

Thank you very much for your interest, LigH :)

[v0lt]

https://forum.doom9.org/showpost.php?p=1777059&postcount=89
...
In fact some arbitrary vfw codec can be simply renamed as vdplugin, this may be useful to have many portable versions of same codec.
It works, but only as an encoder (decoding does not work).
https://github.com/shekh/VirtualDub2/issues/7

[blob2500]

xvid, however, is an encoder that can already be used as a plugin by placing it in the virtualdub2 plugins folder. Of course, the decoder code remains inside, and as you mentioned, it doesn't work.

Moreover, the x264-8.vdplugin / x264-10.vdplugin plugins also don't work as decoders. For that, we can use the other libraries already present in virtualdub2;but it is not possible to make cuts without recoding :(

The new x264vfw by mpxplay can already be used as a plugin, but unlike Xvid, there are still some ambiguous entries in the user interface that should be removed and can cause problems, such as those related to "virtualdub hack," which shekh had removed to derive the plugin from the original vfw version.

"virtualdub hack" should always be enabled with virtualdub's native avi output, but should certainly be disabled in other cases if I remember correctly (certainly if you choose "output file" from the vfw interface) otherwise you get an incorrect frame order. Options removed; rightly so, for a codec that is intended to be "integrated" into virtualdub2, a second output file in encoder interface makes no sense.

[v0lt]

Test build VirtualDub2 v2.5.0.1026 (https://disk.yandex.ru/d/R3Ob8yREy4ChvA)
Improved Unicode support.
Updated avlib_vdplugin 1.1.0.426
- Fixed a crash when opening AviSynth+ scripts in some rare situations.

[LigH]

At least, autodidact published an April 2025 build of x264 plugins (https://forum.videohelp.com/threads/414223-VirtualDub2-Fork-By-v0lt#post2786398) (0.165.3215 32c3b80).

[rgr]

Test build VirtualDub2 v2.5.0.1005 (https://disk.yandex.ru/d/R3Ob8yREy4ChvA)
Set "activeCodePage=UTF-8" in the application manifest. This will add support for AviSynth+ scripts with Unicode character paths.


Unfortunately, I don't know if a complete transition to UTF-8 is premature.
I see some Avisynth plugins don't accept UTF8 filenames, such as TimeCodeFPS. Such a script loads correctly in VDub, but "ffmpeg -i script.avs" throws an error when the plugin reads the file.
So far I have been using code page 1250 and there was no problem (apart from the lack of national characters in the VDub editor).


I'll add the "ProductVersion" field, but I doubt this will fix the Windows bug for VirtualDub2. Perhaps the very fact of changing the executable file had an impact.

Well, it didn't help. But I'll check after restarting the computer.

[v0lt]

At least, autodidact published an April 2025 build of x264 plugins (https://forum.videohelp.com/threads/414223-VirtualDub2-Fork-By-v0lt#post2786398) (0.165.3215 32c3b80).
Have you tested these encoders?
I can add them to the next VD2 build...

Unfortunately, I don't know if a complete transition to UTF-8 is premature.
I see some Avisynth plugins don't accept UTF8 filenames, such as TimeCodeFPS. Such a script loads correctly in VDub, but "ffmpeg -i script.avs" throws an error when the plugin reads the file.
Your observation shows that "activeCodePage=UTF-8" works well for VD2 and should be applied to ffmpeg.exe as well (perhaps this can be done via an external manifest file).

[LigH]

Did just a very quick test (slow preset CRF, custom option "--nr"). Encoded well, result comparable to a previous encode with same options, open in VDub2 again, play in MPC-BE.

Just like the previous encode with the shipped x264-8b, both encodes also had the same error: Premature abort during playback in VDub2, "requested frame not found; next valid frame = 484" near the end (but all frames are displayed when going forward frame by frame). May not be the fault of the encoder but of the playback system or multiplexers, same error with MP4 +faststart (https://www.ligh.de/test/Beinahe-Unfall_8.mp4), MOV +faststart (https://www.ligh.de/test/Beinahe-Unfall_8.mov), and MKV (https://www.ligh.de/test/Beinahe-Unfall_8.mkv). / x264-10b, MP4 +faststart (https://www.ligh.de/test/Beinahe-Unfall_10.mp4)

[v0lt]

@LigH
Thank you.

Test build VirtualDub2 v2.5.0.1057 (https://disk.yandex.ru/d/R3Ob8yREy4ChvA)
Improved Unicode support.
Updated x264 video encoders (libx264 core 165 r3215 32c3b80). Thanks to autodidact from https://forum.videohelp.com/.
Updated avlib_vdplugin 1.1.0.428.
Updated scripted_vdplugin 0.3.2.133:
- Fixed a crash when opening AviSynth+ scripts in some rare situations.

PS: Updated to v2.5.0.1057.

[rgr]

xxxxx

[v0lt]

Test build VirtualDub2 v2.5.0.1064 (https://disk.yandex.ru/d/R3Ob8yREy4ChvA)
Fixed display of video window in capture mode.
Updated avlib_vdplugin 1.1.0.430:
- Updated FFmpeg 8.0.1.

[rgr]

Test build VirtualDub2 v2.5.0.1064 (https://disk.yandex.ru/d/R3Ob8yREy4ChvA)
Fixed display of video window in capture mode.
Updated avlib_vdplugin 1.1.0.430:
- Updated FFmpeg 8.0.1.

I don't know if this has already been corrected, but I'm sending the discussion for you to read:
https://code.ffmpeg.org/FFmpeg/FFmpeg/issues/20709
Source file: MP4 H265 lossless from VDub.

[v0lt]

Test build VirtualDub2 v2.5.0.1075 (https://disk.yandex.ru/d/R3Ob8yREy4ChvA)
Added remembering of video and audio file formats in save dialogs.

[rgr]

Has anyone noticed that when opening an AviSynth script using Caching I.Dr., the first frames of the audio are cut off (not always)? (v1005)

Caching I.D.:

https://gcdnb.pbrd.co/images/jnEOXP9bnUmX.png?o=1

AviFile:

https://gcdnb.pbrd.co/images/Moqnx7zDMDNw.png?o=1

[v0lt]

VirtualDub2 v2.5.1.1095 (https://github.com/v0lt/VirtualDub2/releases/tag/2.5.1)

Changes:
Improved Unicode support.
Script, job, project and settings files are now saved in UTF-8 encoding.
Set "activeCodePage=UTF-8" in the application manifest. This will add support for AviSynth+ scripts with Unicode character paths for Windows 10 v1903 or later.
API change: The VDXAudioEncDefinition structure has been replaced with VDXAudioEncDefinition2, whose mpDriverTagName field points to a wide string.
Added the ability to load processing setting files (.vdscript) using drag-and-drop.
Updated x264 video encoders (libx264 core 165 r3215 32c3b80). Thanks to autodidact from https://forum.videohelp.com/.
Fixed display of video window in capture mode.
Added remembering of video and audio file formats in save dialogs.
Fixed opening of ACM codec settings.
Minor optimizations and cosmetic changes.

Updated avlib-1.vdplugin to version 1.1.1.438.
- Updated FFmpeg 8.0.1.
- Closed GOPs is used for the "x265 - HEVC lossless" encoder.
- API change: The mpDriverTagName field for audio encoders now contains a wide string (see VDXAudioEncDefinition2 in VirtualDub2 v2.5).
- Added "Rate control" parameter for ProRes video encoder.
- Fixed a crash when opening AviSynth+ scripts in some rare situations.
- Added "Load defaults" button for audio encoders.
- Fixed muting of the first audio samples for some media files.

Updated scripted.vdplugin to version 0.3.3.136.
- Fixed a crash when opening AviSynth+ scripts in some rare situations.

[SupermanTV]

v0lt, thank you for the new stable release.

Unfortunately, that ProRes 'Default' setting we discussed here weeks ago is still unusable for me.. (Mb/s capped at 233 / flawed/jumpy frames in output, looks like sync issue)
I do Capturing in ProRes HQ (Camera YUY2 input) and this new setup is awkward.. I have to remember to switch from Default to 'qs slider control'..
Why was it changed in the first place?
Hopefully you can retake/revise the issue... Thanks.

[v0lt]

I have to remember to switch from Default to 'qs slider control'..
You only need to set the encoder once and your choice setting will be saved.

[tebasuna51]

VirtualDub2 v2.5.1.1095 (https://github.com/v0lt/VirtualDub2/releases/tag/2.5.1)

Don't work in my old W10 (last test version v2.5.0.1075 work fine), the file avcodec-62.dll is present in the folder:

[v0lt]

Don't work in my old W10 (last test version v2.5.0.1075 work fine), the file avcodec-62.dll is present in the folder:
I have VirtualDub2 running and working without any problems.
Windows 10 22H2 x64, VirtualDub2 x 64 v2.5.1.1095, avcodec-62.dll n8.0.1-28-g9c93070155-20251211

PS: The SetThreadDescription function (https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-setthreaddescription) is available starting with Windows 10 v1607. It looks like something is wrong with your Windows.

PPS: You can also try the Win32 version. It has fewer external dependencies.
Or use dll from older version of FFmpeg - ffmpeg-n8.0.1-24-g0cc8bfa50f-win64-gpl-shared-8.0.zip (https://github.com/BtbN/FFmpeg-Builds/releases/download/autobuild-2025-12-10-12-57/ffmpeg-n8.0.1-24-g0cc8bfa50f-win64-gpl-shared-8.0.zip)

[rgr]

v0lt, thank you for the new stable release.

Unfortunately, that ProRes 'Default' setting we discussed here weeks ago is still unusable for me.. (Mb/s capped at 233 / flawed/jumpy frames in output, looks like sync issue)
I do Capturing in ProRes HQ (Camera YUY2 input) and this new setup is awkward.. I have to remember to switch from Default to 'qs slider control'..
Why was it changed in the first place?
Hopefully you can retake/revise the issue... Thanks.

Does this also happen with other codecs (UTVideo, others)?

[tebasuna51]

PPS: You can also try the Win32 version. It has fewer external dependencies.
Thanks.
Win32 version works fine

Or use dll from older version of FFmpeg
Also with these dll's.

[rgr]

Is VDub freezing for anyone else using DirectX9? I didn't have this problem before, but now it freezes when switching to another window while playing a VDub file. I switched to DirectX11 and the problem disappeared. Switching back to DirectX9, the problem persists.
v1005

[v0lt]

Is VDub freezing for anyone else using DirectX9? I didn't have this problem before, but now it freezes when switching to another window while playing a VDub file...
v1005
I don't care about bugs in older versions when a newer release has been released.
I have no issues with Direct3D 9. VirtualDub2 x64 v2.5.1.1095 (https://github.com/v0lt/VirtualDub2/releases/tag/2.5.1), Windows 10 22H2, Intel UHD 750.

PS:
Test buildVirtualDub2 v2.5.2.1105 (https://disk.yandex.ru/d/R3Ob8yREy4ChvA)
Fixed display of the duration of the selected range in the status.
Potential memory leaks have been fixed.

[rgr]

I don't upgrade as long as I have some program windows open.

However, in the latest version, "Source frame rate adjustment" -> "Change so video and audio durations match" doesn't work.

After selecting this option, nothing happens. However, after entering the value in parentheses in the "Change frame rate to:" field, the timeline is corrected.

Edit: however, I can confirm that the latest versions solve the problem of bad audio timeline using Caching input driver+AVS script.

[v0lt]

However, in the latest version, "Source frame rate adjustment" -> "Change so video and audio durations match" doesn't work.
I would remove this feature altogether. It always worked incorrectly.

[rgr]

I would remove this feature altogether. It always worked incorrectly.

I suggest not. At least it shows the correct value (I think). And I'd like to point out that entering this value in the field causes the correct behavior (I think).

[v0lt]

I think I understand why you think "Change so video and audio durations match" isn't working. That's because the "Cashing input driver" reports the same duration for both video and audio.
But if you use the built-in "AVI input driver," it will show you something like this.
https://i.ibb.co/0j7msr3z/VD-frame-rate.jpg (https://ibb.co/0j7msr3z)
Current: 23.976 fps. This is the correct value for the video.
"Change so video and audio durations match": 23.982 fps.
This estimated fps value may not be accurate for various reasons:
1. The actual video and audio durations often differ slightly. This is not a reason to change the video frame rate.
2. The audio bitrate specified in the AVI file header may be incorrect. This often happens when 44100 Hz audio is encoded into MP3 using a Fraunhofer encoder. In this case, the header states 128000 bps, but the actual bitrate is approximately 127704 bps. In this case, you need to adjust the audio bitrate, and leave the video frame rate alone.

[rgr]

I don't care about bugs in older versions when a newer release has been released.
I have no issues with Direct3D 9.

I can confirm that the latest VDub (test) also hangs with DirectX9, and the only way to fix it is to kill it from the task manager.
Switching to DirectX11 solves the problem.
The hang seems to always occur in one specific instance: when I switch from VDub to another program/window while a video is playing (+AVS loaded via CID as usual).
I don't know which version this has been happening since, as I was previously working with OpenGL.

[wonkey_monkey]

I don't know if anyone will care, but:

With Display options set to Use OpenGL, scale at 75%, and filter as Bicubic, the image comes out somewhat aliased. I haven't seen it happen with any other combination yet.

https://i.ibb.co/CdWbNS0/image.png

Bicubic on left, bilinear on right.

[tormento]

With Display options set to Use OpenGL, scale at 75%, and filter as Bicubic, the image comes out somewhat aliased.
Any kernel introduces some artifacts.

When zooming to see the REAL quality of a video or an applied filter, I prefer to use the least invasive kernel possible.

Otherwise, what you are watching are the filter artifacts, not the video itself.

[wonkey_monkey]

Bicubic shouldn't introduce these artefacts. It looks fine under DirectX 9, for example, so there's something wrong somewhere under OpenGL.

Actually I think it's just not implemented and is reverting to Nearest Neighbour.

[jay123210599]

I put this in a Vapoursynth script:
clip = clip.std.SetFrameProps(_Matrix=1, _Primaries=1, _Transfer=1)
But when I put the script in VirtualDub2 with the code, the actual format was YUV420 instead of YUV420-709. How do I change that?

[rgr]

Use Caching Input Driver, not AVIFile.

[v0lt]

... or configure the Decode Format settings (https://forum.doom9.org/showthread.php?p=2005175#post2005175).

[jay123210599]

Use Caching Input Driver, not AVIFile.

How would that help with my problem?

[rgr]

AVIFile does not detect the format, it uses the one you set in Decoder Format.

[jay123210599]

AVIFile does not detect the format, it uses the one you set in Decoder Format.

How do I use Caching Input Driver?