Current version

v1.10.4 (stable)


Main page
Archived news
Plugin SDK
Knowledge base
Contact info
Other projects



01 Dec - 31 Dec 2013
01 Oct - 31 Oct 2013
01 Aug - 31 Aug 2013
01 May - 31 May 2013
01 Mar - 31 Mar 2013
01 Feb - 29 Feb 2013
01 Dec - 31 Dec 2012
01 Nov - 30 Nov 2012
01 Oct - 31 Oct 2012
01 Sep - 30 Sep 2012
01 Aug - 31 Aug 2012
01 June - 30 June 2012
01 May - 31 May 2012
01 Apr - 30 Apr 2012
01 Dec - 31 Dec 2011
01 Nov - 30 Nov 2011
01 Oct - 31 Oct 2011
01 Sep - 30 Sep 2011
01 Aug - 31 Aug 2011
01 Jul - 31 Jul 2011
01 June - 30 June 2011
01 May - 31 May 2011
01 Apr - 30 Apr 2011
01 Mar - 31 Mar 2011
01 Feb - 29 Feb 2011
01 Jan - 31 Jan 2011
01 Dec - 31 Dec 2010
01 Nov - 30 Nov 2010
01 Oct - 31 Oct 2010
01 Sep - 30 Sep 2010
01 Aug - 31 Aug 2010
01 Jul - 31 Jul 2010
01 June - 30 June 2010
01 May - 31 May 2010
01 Apr - 30 Apr 2010
01 Mar - 31 Mar 2010
01 Feb - 29 Feb 2010
01 Jan - 31 Jan 2010
01 Dec - 31 Dec 2009
01 Nov - 30 Nov 2009
01 Oct - 31 Oct 2009
01 Sep - 30 Sep 2009
01 Aug - 31 Aug 2009
01 Jul - 31 Jul 2009
01 June - 30 June 2009
01 May - 31 May 2009
01 Apr - 30 Apr 2009
01 Mar - 31 Mar 2009
01 Feb - 29 Feb 2009
01 Jan - 31 Jan 2009
01 Dec - 31 Dec 2008
01 Nov - 30 Nov 2008
01 Oct - 31 Oct 2008
01 Sep - 30 Sep 2008
01 Aug - 31 Aug 2008
01 Jul - 31 Jul 2008
01 June - 30 June 2008
01 May - 31 May 2008
01 Apr - 30 Apr 2008
01 Mar - 31 Mar 2008
01 Feb - 29 Feb 2008
01 Jan - 31 Jan 2008
01 Dec - 31 Dec 2007
01 Nov - 30 Nov 2007
01 Oct - 31 Oct 2007
01 Sep - 30 Sep 2007
01 Aug - 31 Aug 2007
01 Jul - 31 Jul 2007
01 June - 30 June 2007
01 May - 31 May 2007
01 Apr - 30 Apr 2007
01 Mar - 31 Mar 2007
01 Feb - 29 Feb 2007
01 Jan - 31 Jan 2007
01 Dec - 31 Dec 2006
01 Nov - 30 Nov 2006
01 Oct - 31 Oct 2006
01 Sep - 30 Sep 2006
01 Aug - 31 Aug 2006
01 Jul - 31 Jul 2006
01 June - 30 June 2006
01 May - 31 May 2006
01 Apr - 30 Apr 2006
01 Mar - 31 Mar 2006
01 Feb - 29 Feb 2006
01 Jan - 31 Jan 2006
01 Dec - 31 Dec 2005
01 Nov - 30 Nov 2005
01 Oct - 31 Oct 2005
01 Sep - 30 Sep 2005
01 Aug - 31 Aug 2005
01 Jul - 31 Jul 2005
01 June - 30 June 2005
01 May - 31 May 2005
01 Apr - 30 Apr 2005
01 Mar - 31 Mar 2005
01 Feb - 29 Feb 2005
01 Jan - 31 Jan 2005
01 Dec - 31 Dec 2004
01 Nov - 30 Nov 2004
01 Oct - 31 Oct 2004
01 Sep - 30 Sep 2004
01 Aug - 31 Aug 2004


Powered by Pivot  
XML: RSS feed 
XML: Atom feed 

§ VirtualDub's video panes

Seems like a lot of people haven't discovered this yet, given that I haven't updated the help files for 1.6.

The right and bottom borders of the video panes in VirtualDub are draggable. You can choose arbitrary zooms as well as aspect ratios, even those that may be different from the underlying file. This means that you can correctly view video clips that may have an aspect ratio greatly different than 1:1, such as a clip whose frames have been split into sequential fields. Right-clicking on the panes opens a context menu that allows selection of several predefined zooms and aspect ratios, along with an option to restore exact 1:1 pixel size.

Under Options > Preferences > Display, there are a number of options for choosing the rendering technology. If you are experiencing rendering issues, particularly with multiple monitors, turning off DirectX support entirely is recommended. This is required under current versions of WINE and under Windows XP Terminal Server (a.k.a. Remote Desktop) to work around DirectDraw blit clipping issues. VirtualDub automatically disables accelerated preview when it loses focus, in order to release system resources and to allow for reselection of a better mode when it is reactivated. It also disables it by default when Terminal Server is active this is usually faster over a remote link anyway.

Filtering and stretching

The non-DirectX path, which uses GDI, is never filtered and always uses point sampling. In this case each pixel in the source becomes a rectangle on screen, which results in generally poor perceptual quality. It is sometimes preferable when looking for image artifacts, however, as it results in the sharpest image. GDI is very slow when stretching, so when using this mode you will see a serious speedup by using exact 1:1 blits, unless your display driver accelerates StretchBlt(), which nearly none do.

The DirectDraw blit path, which is the default, may or may not bilinearly filter. Unfortunately, whether it does depends on your video driver, and VirtualDub cannot tell or control which is being used. Generally, 3D cards filter and 2D-only cards don't. Stretching is basically free in this mode due to hardware acceleration.

The DirectDraw overlay path is also usually filtered, even on cards that don't support 3D. You can tell when this mode is active by a telltale dark green border when dragging or resizing the pane this is the colorkey used to mask the video whenever VirtualDub's window is covered. Depending on the video card, and even the video format, the filtering may be better or worse than bilinear. It's not uncommon for chroma to not be filtered in some modes, or even luma unfiltered along a particular axis. This type of display is often subject to separate color controls in the video driver's configuration pages, so be aware of drivers shipping with off-unity settings NVIDIA drivers, in particular, like to install with saturation set above 100%. VirtualDub will attempt to use an overlay whenever possible, but usually overlays and blits don't conflict: it's usually the case that blits only support RGB and overlays only support YCbCr. There's also usually only one overlay, so if you attempt to do output preview with both input and output formats set to YCbCr, only one will be a true overlay and the other will be a software conversion followed by a blit.

Note that the overlay I talk about here is different than the overlay mode usually seen in capture programs. In this case, the overlay is a second display surface that is pasted on top of the regular desktop in the scanout hardware of the video chip; in the capture case, overlay is usually just the video capture hardware scribbling right onto the desktop window, which then gets displayed as usual.

The 3D minidrivers are the only ones which allow selection of the video filtering algorithm. The OpenGL minidriver supports only point and bilinear; the Direct3D 9 driver also supports bicubic, if you have DX7-class 3D hardware. These drivers are typically slower than the 2D drivers, due to overhead in texture conversion and feeding the hardware command list. I intend to improve the Direct3D 9 driver over time, as that seems to be the way that video display on Windows is headed; I actually prefer OpenGL, but I only have experience with basic OpenGL 1.1, and Direct3D is the evil that I know, so I'm more likely to do work on that front.

Windows Longhorn^H^H^H^HVista

Oddly, VirtualDub seems to mostly work fine under Windows Vista beta 1. I was hoping for a really spectacular fireworks display, like what you'd get on an Amiga with a busted copper list. However, if you have hardware powerful enough to run Aero Glass, you may still encounter some issues with VirtualDub's video displays and the Desktop Composition Engine. When I tried it with the alpha LDDM drivers from NVIDIA, the GDI minidriver stopped working, meaning that whenever you task switched from VirtualDub during preview, the panes would stop updating. It turns out that there is some strange issue with mixing GDI and DirectDraw rendering on the same window when VirtualDub deletes its DirectDraw objects and drops to GDI rendering, the results of the last DirectDraw blit stick around and cover the GDI output. I don't know whose fault this is, whether it be Microsoft, NVIDIA, or mine, but I've filed a bug on it just to see what Microsoft's reaction is at least.

Although the problem is minor, turning off DirectX acceleration will work around it. StretchBlt() performance seems to be seriously improved in Vista, which is an unexpected bonus.

I also noticed that DirectDraw blits weren't filtered. This might be my fault since I don't bother to set the ARITHSTRETCH bits, given that I couldn't find any hardware on the planet that heeded them. This is another reason I intend to eventually evolve the Direct3D-based display code, as in that case I definitely have control over video filtering. Aero Glass does seem to suck quite a bit of GPU power already, however, as I noticed it taxing the NVIDIA GeForce FX 5600 a bit. I've heard that the DCE renders windows in 16-bit floating-point and does gamma-correction, which seems a bit extreme to me, especially since that hardware doesn't support alpha blending with FP16 render targets. Then again, Vista is only at beta 1, so it's not performance optimized.

If you have Vista beta 1 and try VirtualDub on it, I'd be interested in hearing if you do or don't see the above behavior. Ctrl+Shift+F9 seems to toggle Aero Glass, although oddly I can't find any documentation verifying that.

Incidentally, on an unrelated note, Vista supports symlinks. Unlike the junctions you can create on Windows 2000/XP, these work on files as well as directories, and if you delete a symlink with Explorer it doesn't delete the target. Finally!


Comments posted:

Who wants an OS that needs one cpu/gpu only to draw windows and fx?
Who needs these fx anyway?
Well, at least microsoft stated that systems with onboard gfx probably won't work with windows vista (or vice versa).
I already have enough problems with my good old visual basic 5 under windows xp sp2.
It keeps crashing in debug-mode like no other (DEP already disabled).
Might be the OS is too 'modern' for the good old vb5.
If I try it under Vista I will shurely get a message box stating:
'This program has too few fx for windows vista - please buy something like .Njet 2003.'

Murmel - 01 09 05 - 12:40

Murmel, I think you missed something :)
Our current OS (Win2k/xp) requires one cpu just to draw windows and fx.
Windows Vista requires one gpu just to draw windows and fx, so guess what the cpu will do instead?

On topic though, I did notice the panes. I have wondered though, can VirtualDub detect aspect ratio automatically? I dont think so, but I could be wrong. Oh, and is it possible to save avi files with another aspect ratio than 1:1?

Cybermaze - 01 09 05 - 16:50

At first I was anti-gpu in Vista, until I realized the cards were much more optimized for the job, and that it can be tweaked or turned off. Maybe they'll detect and disable Aero for integrated intel and sis crapboards.

One thing I noticed before is that I get two pixels of black border when I use D3D. I blow it up to 400 and it's gone, but not any other resolution. Works great with opengl, though. (ATI Mobility 9000, latest omega drivers. Could well be its fault.) Oh, only when I save the setting and reopen it does the error show. Either way it's slightly faster and cleaner looking; I just have to remember to disable that for quality-checking, I'm used to thinking of vdub as my no-filtering viewer. =D

foxyshadis (link) - 05 09 05 - 03:40

Aspect ratio detection would be possible for MPEG-1 and DV files, but probably not for AVI. There are a couple of fields in AVI that can indicate aspect ratio (biXPelsPerMeter/biYPelsPerMeter and one in the OpenDML analog video header), but I'd be skeptical of software writing or interpolating those fields correctly. I currently don't know of any, although I haven't really looked. And with the biX/Y headers, you're actually specifying a physical size instead of an aspect ratio, which is more than you actually want to indicate.

I think Aero Glass's system requirements are too high to run at all on most integrated hardware just requiring pixel shader 2.0 alone would rule out most of them.

Both the Direct3D and OpenGL minidrivers in VirtualDub pad to powers of two when allocating their textures but don't fill the boundary data on the blit, which is why you get the junk on the bottom and right edges. The OpenGL driver is also capable of tiling across textures, but that shouldn't happen on any modern hardware. It's weird that you're not seeing the problem there. Eventually I'll get around to fixing the problem by supporting rectangular textures. I think this is slightly more annoying on OpenGL, though, where the NVIDIA extension for doing so requires a different texture target and non-normalized texture coordinates, whereas in Direct3D they're always 0-1. It's also possible to clamp the coordinates in a pixel shader since there are no mipmaps, but that complicates and slows down the shader, especially in the bicubic case.

Phaeron - 06 09 05 - 02:15

It's actually the left border only, a 2-pix black strip. It overwrites them, rather than moving everything right. OpenGL I've noticed sometimes flickers in the lower right changing frames, especially if I have two instances open in 2x zoom, and doesn't display anything in dub mode. I'll just go back to DDraw for the moment.

foxyshadis (link) - 07 09 05 - 02:35

Avery, Just a suggestion:
It would be great if (in some future) you could add the Script Editor (for Avisynth) VdubMod (now dead) used to have.Just think about it.It was of great help and a nice feature.
Thank you as always, you've given me many years of happy video processing ( I guess I started with 1.2 version or the like ) :)

Morsa - 07 09 05 - 07:13

Not sure where the best place to say this, but I've found a minor sorta-bug in VirtualDub 1.6.10: the log window claims it's actually "VirtualDub CLI Video Processor Version *1.6.9* (build 23648/release) for 80x86"

I also managed to crash VirtualDub, but I'm not quite sure how (triggered the crash after spending some time fiddling with filters on a large avi and fiddling with rendering options). If you want I'll send the bug report, but I think the cause is "my computer hates me".

BoggyB (link) - 18 09 05 - 15:19

Re:symlinks on Vista
I haven't tried Vista yet, but yeah, even though symlinks and junction points
have been around since at least Win2K, explorer was never updated to take them
into account (I guess the file system and shell teams at Microsoft never talk to each other).
My biggest pet peeve is that even if you manage to create a junction point, if you try
to delete it from within explorer, explorer will delete all the files contained in the junction point, rather than deleting the junction point itself.

If you do want to use JPs/HLs in Win2K/WinXP/Win2003, I strongly recommend installing "NTFS Link"
(google for it), which extends explorer to deal with HLs/JPs the way they should be.
Despite being freeware, the implementation seems to be very thorough and professional
(for example, correcting the explorer bug I mentioned with deleting JPs).
The only "bug" I've found is that if you don't reboot between installing
and configuring it, the configuration settings don't seem to take
(which means installing and configuring it normally takes two reboots).

Bob Ludwig - 29 10 05 - 01:22

Junction points do indeed fulfill some of need created by a lack of symlinks, but they're not a replacement. One problem is that they can't be deleted with the regular DeleteFile() API; another is that you can't junction a file. Still, I do find them very handy. I use the Sysinternals junction tool to manipulate them.

Hard links are also not symlinks, primarily since they're not directional. If you delete the target and create a new file at the same name, it's an independent file rather than a replacement for the old target.

I should note, also, that Vista's DIR command displays the target of a symlink. Windows 2000/XP doesn't display the target of an NTFS junction.

Phaeron - 29 10 05 - 01:36

I could need a "permanent GL" switch.

I too want to use virtualdub as a viewer. My boards overlay is not bilinear,
so virtualdub is the best viewer. Also GL doesn't alloc the one-and-only
overlay which then is still free for another app, such as virtualdub.capture .

When I put another window to front, GL is not used and machine is too
slow (sound stutter).
When I then put virtualdub to front, it doesn't go back GL again. I got to
press stop and then play, and the area gets black for a couple of frames.
startstop vs window deactivation seem to have different GL create/shutdown code.
When this happens too often , my GL freaks out and goes softwarerendering.
I usually got no problems with "1.1" functionality, but thats permanent
and fixed window width demos.

Skip frames instead soundstutter would also be nice. It's ironic that huffyuff decoding is slower than encoding. As we're into it a sound volume slider would also be nice ;)

For me v1.6 was a quantum leap vs 1.4 which didn't save settings so going capture required clicking a lot.

Juergen - 12 12 05 - 02:09

Start/stop and window activate do use the same code, but it may have something to do with panes being reinitialized one-by-one rather than all at once. Also, VirtualDub's use of OpenGL is somewhat unorthodox; most apps only use one GL context, and I've seen weird driver bugs that don't occur in other apps. The nastiest was a full ten-second delay on 100% CPU with old NVIDIA drivers, although I've heard people reporting black screen problems on ATI cards too.

What video card do you have? The D3D9 minidriver is a bit more advanced than the OGL driver, so you might try that instead if you have D3D7+ drivers. Hopefully you have at least a TNT2, because going back beyond that is returning to driver bugfest land....

Phaeron - 12 12 05 - 02:22


I have installed virtual dub ver 1.9.8 for preparing some images of microcrustaceans, but as soon as i click CAPTURE AVI, it doesn't capture any image. I am using Vista version on my laptop can any one give me suggestion on this.


pranay - 02 04 10 - 16:48

Comment form

Please keep comments on-topic for this entry. If you have unrelated comments about VirtualDub, the forum is a better place to post them.
Remember personal info?

Email (Optional):
Your email address is only revealed to the blog owner and is not shown to the public.
URL (Optional):
Comment: /

An authentication dialog may appear when you click Post Comment. Simply type in "post" as the user and "now" as the password. I have had to do this to stop automated comment spam.

Small print: All html tags except <b> and <i> will be removed from your comment. You can make links by just typing the url or mail-address.