View Full Version : VirtualDub2


Pages : 1 2 [3]

levicki
17th July 2026, 11:58
Hi, I just tested on win 10 64bit. RTX 4080 Driver:596.49 , scaling working, but when i click play i got error: Cannot initialize rendering parameters: Cannot start filter: `NVRTX` : RTX Video api initialization failed. I copy that 3 files in plugins64 folder.

If scaling is working and you can seek then you should also be able to play.

Make sure you have enough free video RAM (i.e. don't use ComfyUI or Ollama at the same time, and do not use RTX video features elsewhere like in player or browser when processing in VirtualDub).

levicki
17th July 2026, 14:27
NVRTX plugin has been updated.

Changes:
- Normalized passthrough output from 10-bit to 16-bit using more accurate math than VirtualDub2 internal normalization
- Repositioned radio buttons, reduced groupbox size, moved and aligned buttons, reduced dialog vertical size, centered vertically in monitor workarea -- should no longer get clipped when preview is enabled

rgr
30th July 2026, 11:48
VDub always sets me to "PAR 1:1 (Source)" for CID, while the actual source PAR is 12:11.
(When using ffmpeg, use -avisynth_flags all).

By the way, it would be possible to add the most common PARs for SD material, i.e. 12:11 and 16:15.
For SD PAL DV Wide is also strange because it should be more like 64:45.
https://en.wikipedia.org/wiki/Pixel_aspect_ratio

SeeMoreDigital
30th July 2026, 13:09
VDub always sets me to "PAR 1:1 (Source)" for CID, while the actual source PAR is 12:11.
(When using ffmpeg, use -avisynth_flags all).

By the way, it would be possible to add the most common PARs for SD material, i.e. 12:11 and 16:15.
For SD PAL DV Wide is also strange because it should be more like 64:45.
Yes the settings should be 8:9 or 16:15 for 4:3 NTSC @720x480 and 4:3 PAL @720x576 respectively.

And 32:27 or 64:45 for 16:9 NTSC @720x480 and 16:9 PAL @720x576 respectively.

wonkey_monkey
31st July 2026, 23:25
Yes the settings should be 8:9 or 16:15 for 4:3 NTSC @720x480 and 4:3 PAL @720x576 respectively.

Shouldn't it really be 10:11 and 128:117? You're supposed to account for nominal analogue blanking (https://en.wikipedia.org/wiki/Nominal_analogue_blanking) but it seems to be one of those things that everyone ignores to the point where it ends up being a case-by-case basis.

Even Doctor Who blu-rays end up in the wrong ratio :(

levicki
1st August 2026, 12:13
For target DAR 4:3 SAR should be:
- For PAL 12:11 (ITU, 704x576) or 16:15 (non-ITU, 720x576)
- For NTSC 10:11 (ITU, 704x480) or 8:9 (non-ITU, 720x480)

For target DAR 16:9 SAR should be:
- For PAL 16:11 (ITU, 704x576) or 64:45 (non-ITU, 720x576)
- For NTSC 40:33 (ITU, 704x480) or 32:27 (non-ITU, 720x480)

In case it's not clear, those ratios are applied to source with respective width -- if you have a full 720 pixels wide image (no black bars) you use non-ITU SAR, if you have 720 pixels wide image with 8 pixels black bar on each side you crop it and apply ITU SAR.

hello_hello
9th August 2026, 08:52
My understanding is the ITU pixel aspect ratios are derived from the rate at which analogue scan lines are sampled. The ITU PARs aren't easy to remember, and possibly only apply to video that was sampled from an analogue source.
Then there's the official MPEG4 PARs used for Bluray and probably many DVDs. They're very close to being the same as the ITU PARs but the numbers are more user friendly.
Finally there's the generic PARs that result in an exact 4:3 or 16:9 display aspect ratio (for a width of 720).

I tend to use an MPEG4 PAR for 4:3 DVDs, and for 16:9 DVDs if it was shot on video or there's substantial black each side, I'd assume it's MPEG4, otherwise it's more likely to use a generic PAR.

From this old doom9 post:
https://forum.doom9.org/showthread.php?p=1058927#post1058927

Exact PAR according to ITU-R BT.601
PAL NTSC
4:3 1150/1053 38800/42651
16:9 4600/3159 155200/127953

Almost exact and commonly used ITU-PAR according to Jukka Aho’s well-known article. However he did not account for the fact that the top and bottom half-lines of the analog image are only half-height.
PAL NTSC
4:3 128/117 4320/4739
16:9 512/351 5760/4739


MPEG-4 PAR taken directly from the MPEG-4 standard documents.
Very similar to exact ITU figures and usually used for MPEG-4 encodings.
PAL NTSC
4:3 12/11 10/11
16:9 16/11 40/33


Generic PAR (i.e. ignoring ITU)
This leads to an exact 16:9 DAR for an uncropped 16:9 PAL frame.
PAL NTSC
4:3 16/15 8/9
16:9 64/45 32/27

hello_hello
9th August 2026, 09:00
Even Doctor Who blu-rays end up in the wrong ratio :(

I've noticed that sort of thing before.
I'm fairly certain the Fawlty Towers PAL DVDs use an ITU/MPEG4 PAR, given it was shot on video, but when it was upscaled for bluray it was obviously resized under the assumption it used a generic PAR, so the width ended up a bit squished.

SeeMoreDigital
9th August 2026, 09:09
Shouldn't it really be 10:11 and 128:117? You're supposed to account for nominal analogue blanking (https://en.wikipedia.org/wiki/Nominal_analogue_blanking) but it seems to be one of those things that everyone ignores to the point where it ends up being a case-by-case basis.I guess when the majority of people had CRT displays, yes you needed to account for analogue blanking. But thankfully we only have to cater for digital displays now ;)

v0lt
11th August 2026, 19:24
Test build VirtualDub2 v2.5.2.1164 (https://disk.yandex.ru/d/R3Ob8yREy4ChvA)
Added VSFilterBE 2.47.1 plugin, which provides TextSub and VobSub video filters.
Added the ability to temporarily register native VfW codecs from the "vfwcodecs" folder.
Added the Xvid VfW encoder.

mts1
11th August 2026, 20:09
PAL, 4:3
702x575 -> 1150/1053 (for "diagonal" CRT lines, not sure if one can really make it)
702x576 -> 128/117 (for "horizontal" lines, like from CCD)
704x576 -> 12/11 (MPEG-2 compatible with "macroblocks" of 16x16 pixels)
720x576 -> 16/15 (for digital sources authored after circa year 2000)

mts1
11th August 2026, 20:37
Test build VirtualDub2 v2.5.2.1164 (https://disk.yandex.ru/d/R3Ob8yREy4ChvA)
Added VSFilterBE 2.47.1 plugin, which provides TextSub and VobSub video filters.
Added the ability to temporarily register native VfW codecs from the "vfwcodecs" folder.
Added the Xvid VfW encoder.

I see this is a second build after I brought up the issue with 10-bit video.
I just wonder if you have plans to address it in the future, because I've noticed that if I use any filters during the capture, even as simple as crop, I get just a fully pink video.
Thanks

levicki
12th August 2026, 15:54
Generic PAR (i.e. ignoring ITU)
This leads to an exact 16:9 DAR for an uncropped 16:9 PAL frame.
PAL NTSC
4:3 16/15 8/9
16:9 64/45 32/27

Just be mindful when you say "uncropped" that you actually mean full width frame (720px). Because if you have a 704px frame padded to 720px with 8px black bars and you apply those ratios you will screw the aspect ratio.

EDIT: Added a table.

mts1
12th August 2026, 21:51
Just be mindful when you say "uncropped" that you actually mean full width frame (720px). Because if you have a 704px frame padded to 720px with 8px black bars and you apply those ratios you will screw the aspect ratio.

EDIT: Added a table.

If you apply the ratio to pixels, then then the size doesn't matter. :)

Washka
13th August 2026, 01:22
Please can someone check with some SD video (1 hours or more) who have newer cpu. (My cpu i7 13700k)
When i`m using benchmark in analyze pass VHS sample video i have ~1430 FPS in benchhmark and after 40 min fps drop to 390-400 and don`t go up. Test file is on NVME, cpu do not drop in frequency.
When i encoding i have around 720 fps with ffdshow/NVENC HEVC and same thing, after ~40 min encoding speed drop to 390-400.
I change sliders in Options > Performance options but can not get more than 40 min to go in full speed.
I did not enable any plugin in filters and NO audio.
Sometimes i did not touch anything and fps is locked to 125 fps. I save project, just close VirtualDub than open and have 1430 fps again in benchmark.
Maybe old Pc`s don`t have this problems.

I tested this in VirtualDub2_v2.5.2.1164 64bit.

edit:
I try some randowm version from net "VirtualDub2_v2.2.0.755 x64" and this version can reach max 1034 fps in benchmark but no slow down.

v0lt
13th August 2026, 04:08
I see this is a second build after I brought up the issue with 10-bit video.
I just wonder if you have plans to address it in the future, because I've noticed that if I use any filters during the capture, even as simple as crop, I get just a fully pink video.
There are no such plans. However, those with the appropriate equipment, skills, and interest can try to solve the problem themselves and submit a pull request.

I try some randowm version from net "VirtualDub2_v2.2.0.755 x64" and this version can reach max 1034 fps in benchmark but no slow down.
Try replacing FFmpeg DDLs:
avcodec-62.dll
avformat-62.dll
avutil-60.dll
swresample-6.dll
swscale-9.dll

Emulgator
13th August 2026, 19:24
NVMe: I suggest to use HWinfo and watch/graph SSD temperature.
Mine throttled at +68°C.
It took hours of filing 4 proper heatpipe heatsinks until they snug-fit side by side into my chassis
plus guided airflow until the system sustained larger uncompressed transfers
(Vegas 6hr project 4K60p fileswapping at rendering end etc.)

Washka
14th August 2026, 23:55
Now I tested it, and the conclusion is: it was a huge file, ~70 GB.

Since I have 64 GB of RAM and the file I tested is ~70 GB, about 70% of the file was cached in RAM (because of multiple runs), and that ran at 1400 FPS, then, when the file started being read from disk, it slowed down.

So who would think that disk read speed was too slow for encoding?

The input file was a lossless AVI with Lagarith compression.

edit:
I also make one copy of "VirtualDub2_v2.4.0.930 32Bit" and put all plugins i have: That is 332 *.vdf plugins installed. Many are soo old and found 2 of them: Xlogo05.vdf and Condition.vdf. They both crash VirtualDub2 32bit when trying to Save video when i want to press Video Compression CHANGE button. I don`t use that plugins but want to report so other ppl who have same problem can avoid this 2 plugins. They are from 2003.

v0lt
25th August 2026, 06:27
VirtualDub2 v2.5.3.1197 (https://github.com/v0lt/VirtualDub2/releases/tag/2.5.3)

Changes:
Fixed display of the duration of the selected range in the status.
Potential memory leaks have been fixed.
32-bit "PICVideo Lossles JPEG Codec" (pvljpg20.dll) is not supported because it crashes.
64-bit "MLC lossless codec" (mlc.dll), "Proxy Codec64" (pxc0.dll) are not supported because it crashes.
Fixed video capture with compression in the "FFmpeg FFV1" and "x264 8 bit" codecs.
Fixed loading of processing settings (script files).
Added VSFilterBE 2.47.1 plugin, which provides TextSub and VobSub video filters.
Added the ability to temporarily register native VfW codecs from the "vfwcodecs" folder.
Added the Xvid VfW encoder.
Cosmetic changes.

Updated avlib-1.vdplugin to version 1.1.3.490.
- The FFmpeg 8.1.2 x64 build from BtbN is used.
- The FFmpeg 8.1.2 win32 build from Defisym is used.
- Fixed enumeration of video encoders when some video encoders were not available in the used FFmpeg build.
- Video encoders that cannot be used due to missing hardware or an unsupported driver will not be available for selection and configuration.
- Added QSV VP9 encoder.
- Added VBR mode for most video encoders.
- Cosmetic changes.

levicki
25th August 2026, 16:03
@v0lt: what are the chances of supporting AV1 mp4 video files?

v0lt
25th August 2026, 17:01
@v0lt: what are the chances of supporting AV1 mp4 video files?
It's been supported for a long time. You could just try opening such a file.
https://i128.fastpic.org/thumb/2026/0825/58/_7cd97f5f07779d0e13ccb5ebfdda8358.jpeg (https://fastpic.org/view/128/2026/0825/_7cd97f5f07779d0e13ccb5ebfdda8358.png.html)

wonkey_monkey
25th August 2026, 20:58
Could you upload your images to a site that doesn't try to open sneaky tabs with porn on them?

mts1
25th August 2026, 21:59
Could you upload your images to a site that doesn't try to open sneaky tabs with porn on them?

Based on the crumbs of cookies I found I think it opens more than just one website...