VirtualDub2

[isidroco]

Originally Posted by rgr

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]

Originally Posted by isidroco

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 and 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]

Originally Posted by v0lt

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]

Originally Posted by v0lt

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]

Originally Posted by v0lt

Test build VirtualDub2 v2.5.0.1005

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

Originally Posted by LigH

An updated plugin has been posted in the VideoHelp forum, 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]

Originally Posted by blob2500

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/vdfiltermo...i/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...9&postcount=89

Originally Posted by shekh

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 if he may be able to participate here.

[blob2500]

Thank you very much for your interest, LigH

[v0lt]

Originally Posted by blob2500

https://forum.doom9.org/showpost.php...9&postcount=89

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
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 (0.165.3215 32c3b80).

[rgr]

Originally Posted by v0lt

Test build VirtualDub2 v2.5.0.1005
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]

Originally Posted by LigH

At least, autodidact published an April 2025 build of x264 plugins (0.165.3215 32c3b80).

Have you tested these encoders?
I can add them to the next VD2 build...

Originally Posted by rgr

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).