VirtualDub documentation: Capture

Video capture in Windows is hardly a walk in the park, so here's a few tips to keep you going.  As usual, corrections are welcome.

How fast of a CPU do I need?

This is a hard question to answer, but I can tell you what I've been able to do:

Celeron 300 @ 450, Hauppauge WinTV, 44KHz 16-bit stereo PCM, 640x480 YUY2 at 29.97 fps compressed with PicVideo at quality 18, on-screen display disabled.

Pentium III 733, Hauppauge WinTV, 44KHz 16-bit stereo PCM, 640x480 YUY2 at 29.97 fps compressed with Huffyuv in Predict Median, Preview on.

Note that these are with a 16-bit desktop.  You will take a sizeable hit with a 24-bit or 32-bit desktop if you have Preview on.

VirtualDub says I don't have a capture device, but I know I have one.

VirtualDub needs a Video for Windows capture driver to capture. Most Firewire (DV) devices do not provide a VFW driver, and thus cannot be used by VirtualDub at all. Also, ATI appears to be shipping their current devices with a WDM (Windows Driver Model) driver only; this can be used indirectly by VirtualDub through a Microsoft wrapper, but it is crippled in functionality and it also appears that the wrapper is buggy.

The wrapper will show up as "Microsoft WDM Image Capture (Win32)." If it works for you, great.

I can capture DV through VirtualDub, but I get the audio out of my sound card instead.

Video for Windows only captures audio through a sound device; with DV, the audio is interleaved with the video itself. I don't have any DV specs, so I can't make VirtualDub extract the audio.

I get no sound.

First, check that you aren't missing the pass-through.  Most video capture cards don't have on-board sound capture and instead use your sound card, so if you don't connect the cable from the capture board to the sound input, you won't get any sound.

Next, bring up Volume Control (sndvol32.exe), go up to the menu and choose Properties, then switch to Recording controls.  Make sure Line-in, Aux, or whatever input you are using is selected.  Voice chat programs are notorious for automatically switching inputs for you, and some video capture drivers are known to reset volume levels as well.

Finally, if you have a Hauppauge WinTV, check for an AUDIOSEL.EXE application on your hard disk or driver CD.  It can be used to force the audio pass-through on for those cards.  (Note: If you are using an external source with

I get sound, but it has cracks and pops in it.
My video has greenish lines in it.
Occasionally, I see thin horizontal strips in the captured video that looks like they came from the last frame???

No one has a rock-solid answer for why these problems occur, but it appears to be caused by contention on the PCI bus, which then prevents the sound card and video capture devices from emptying their buffers in time.  This problem is reported more frequently on motherboards that have a VIA chipset, or in systems that have a SoundBlaster Live! sound card.  In the former case, try upgrading your VIA 4-in-1 drivers first, and if that is not sufficient, check for a motherboard BIOS update that specifically addresses your problem.  As for the Live!, the Creative driver is known to cause problems by lowering the latency timer of the PCI bus.  (The result is similar that of making the red lights appear every ten seconds at a four-way intersection.)  In that case, try installing the Microsoft drivers instead.

Also, check the websites for the hardware manufacturers to see if they have utilities which may help.  For instance, Pinnacle has a PCI adjustment utility for some of their cards.

If you are using RGB24 for your raw capture format, switch to YUY2 to drop your raw datarate by 33% (see below), which may be enough to lower PCI bus load to workable levels.

I see a greyish, wavering line at the bottom of my capture. It looks sort of like the picture, but distorted.

If it's only a few lines at the bottom, it's likely VHS head switching noise. Ignore it or crop it out afterward.

I see a lot of thin lines in my image, like a comb.

That's interlacing -- what you're seeing is two fields, taken at slightly different times, and combined together to form a single frame. You'll see it whenever you capture with a height more than 240 lines (NTSC) or 288 lines (PAL). Interlacing is not a defect in the video and cannot be "fixed" -- it's a fundamental aspect of the way video is encoded.

Which capture format should I choose if I'm going to use video compression?

Ultimately, you will need to choose a format which is compatible with the codec, but if you have a choice, always choose YUY2, UYVY, or YVYU over RGB24.  Here's why:

TV cards generally use one of two chips, either the Zoran ZR36120 (FlyVideo-derived devices), or the Brooktree/Conexant BT8x8 series (everyone else).  If you look at the datasheets for these chips you will find that they either accept YUV 4:2:2 data from the decoder or produce it internally.  Guess how they produce RGB24 data when you ask for it?  You guessed it, the YUV 4:2:2 data is upsampled to RGB24.  This means that the extra color resolution that RGB24 gives is entirely fabricated.

Choosing YUY2/UYVY/YVYU over RGB24 typically gives you a sizable speed increase, and gives you better compression with Huffyuv.

RGB16 introduces horrible banding and signal loss, while RGB32 just adds an extra 8-bits of junk to RGB24.  There is no point in using either.

Why do I get errors when I try to capture with a height above 240 (288 for PAL/SECAM)?

This following only applies to devices based on the BT848(A) or BT878(A).

NTSC video is composed of alternating fields of 240 scanlines, and PAL/SECAM of 288.  If you specify a height equal to or lower than that, the capture driver only snags one field.  If you specify a taller image, both fields are grabbed.  In either case when you specify a size smaller than the height of the field(s) captured, the result is then scaled down.

The BT8x8(A) can only DMA to one destination at a time, and the output pixel format can only be set on a per-field basis.  If you specify Overlay mode, then the capture driver will instruct the chip to DMA one field to memory for capture, and the other field to the video card.  The catch is that if you are capturing both fields, both DMA lists have to point to main memory.  This means that overlay mode is impossible when both fields are captured, and depending on your exact driver, you will either have overlay disabled when the capture starts, or, as is more often the case, get a cryptic error about being out of memory.  Note that this is not a bandwidth issue -- you can capture 640x240 in overlay mode, but not 80x480.

To "fix" the problem, specify Preview mode; this unfortunately is slower since the CPU is now doing a blit from the captured frame to the video card.  It may be that your system is not fast enough to handle this, in which case you will need to disable the video preview entirely and capture blind.  A secondary consequence of all of this is that you see exactly what is being captured in Preview mode, while you are actually seeing the other field in Overlay.  If you have a strange source where one field is much cleaner than the other, it is possible with an Overlay display that you will see a clean display on screen and end up capturing crap.  (I have had this happen.)

This may not apply to you if you have such a chip built onto your video card, since in that case the chip can DMA into video memory, and then other video hardware can transfer from there into main memory for capture.

Other people can capture 768x576, but my card doesn't do more than 640x480.

It's likely that the other people are dealing with a PAL (Phase Alternating Line) standard, while you are dealing with the NTSC (National Television System Committee) standard.  PAL has fields of 625 scanlines at 50Hz while NTSC is 525 scanlines at 59.94 Hz.  In addition to the resolution difference, PAL people should capture at 25 fps while NTSC people at 29.97.

I have lots of codecs in the normal video compression dialog, but some disappear when I go to capture!

You can only use codecs which are compatible with the current capture format, so try changing the capture format in the Video Settings or Video Format dialogs. RGB formats will give you the widest selection; YCrCb (YUV) formats will whittle the list down, and exotic formats such as VCR2 or MJPG will usually clear the list. This restriction is necessary because the for 424m1212e mat may require hardware assist to decode, and it may be impossible for VirtualDub to decompress the video during capture in order to transcode to another format.

What's the difference between compatibility mode and normal (internal) capture?

Compatibility capture mode (F5 key) is a no-frills, straight Video for Windows capture -- it lets Video for Windows do as much work as possible and is the failsafe mode you should use to diagnose problems when regular capture mode doesn't work. It has a number of disadvantages:

Timing correction is disabled, so audio on long captures may be out of sync.

The capture file will be invalid if it exceeds 2GB.

Only one capture file is allowed -- no multisegment captures.

VirtualDub won't be able to display the compressed video frame size.

Video filtering options that change the size of the frame aren't allowed.

Disk I/O is buffered, so you may encounter problems when pushing the limits of your hard disk bandwidth.

It's basically like Vidcap32.

Use normal capture mode (F6) when possible. If you find that you can't capture even in compatibility mode, chances are something is seriously wrong with your system configuration.

The audio isn't in sync in the capture file.

It's what we get for putting audio and video capture on separate clocks.

If you are running VirtualDub 1.4c or earlier, check the Knowledge Base for a possible workaround if your sound card isn't very accurate. (This problem will be fixed in V1.4d.) Also, if you're using compatibility mode, to capture, don't -- for VirtualDub to resync the audio during capture, you must not be using compatibility mode, and timing correction must also be active (it's in the capture menu).

The "lock video stream to audio stream" option in settings only works for compatibility mode; it sets the frame rate of the video stream so that it's the same length in time as the audio one. This is a nasty way to get audio in sync, because it will make editing harder -- to coerce the clips to a single frame rate for rendering, frames will have to be dropped or duplicated.  It also doesn't work well if the timing relationship between audio and video drifts over the course of the capture.

Why am I dropping frames?

Perhaps one of:

Insufficient CPU power. If you're running near the limits (>90% CPU), then you can sporadically drop frames when busy scenes pass by.

Slow hard disk. Note that most hard disks cannot handle capturing full frame, uncompressed video; that requires 18MB/sec for 16-bit RGB/YUY2 and 27MB/sec for 24-bit RGB, not counting filesystem and seek overhead. Also, if you don't have DMA set on an IDE disk, you'll get slower performance than usual and additionally will load the CPU significantly during disk access, often by 40% extra or more.

Bus bottleneck.

Bad source, such as VHS video tape, or a signal interruption such as changing the channel.

Timing correction necessary to keep the audio synchronized. Most sound cards will deviate a small fraction from the video capture device, requiring that a few frames be dropped to keep the audio in sync. Another possibility is that the source is outputting a slightly slow or fast frame rate; old videotape can do this, as well as game consoles.

The key to remember is that one dropped frame per thousand is nearly indescernable, but ten dropped frames at a single point is.

Why does my video capture stop at 1 hour, 11 minutes, but I still get audio?

This is a bug in many video capture drivers. The exact limit is actually 2³² microseconds, or 1 hour, 11 minutes, 34 seconds. Many TV tuner devices are susceptable to this bug, as are the miro/Pinnacle DCxx devices; you may be able to fix the problem simply by upgrading to the latest capture drivers. There are two incarnations of this problem. In the non-fatal version, video frames are still sent to the application, but the timestamp on the video stream starts over from zero. VirtualDub will correct for this problem automatically, allowing you to capture beyond 71 minutes. The other possibility is that the driver stops sending data altogether. VirtualDub will notify you if this occurs, but will not be able to capture past 71 minutes in this case.

Vanilla capture devices based on the Conexant/Brooktree BT848/878 reference drivers are usually either immune to the problem or have the non-fatal form of it. I'm told that the bug in Pinnacle's DC30(+) drivers still exists but is nonfatal as of the 1.41a drivers. As of this writing, the bug in the DC10/10+/20/20+ drivers is fatal and cannot be worked around.

There are apparently a few drivers that are even susceptable to half this limit (35 min.) due to using signed 32-bit arithmetic.  VirtualDub does not yet detect or attempt to bypass the 35 minute limit that results.

I'm getting an error when I try to capture an AVI file bigger than 4GB.

You'll get this problem if you either (a) are running Windows 95/98/98SE/ME, or are saving to a FAT32-formatted partition. Either limits you to 4GB. If you want to capture a single file bigger than 4GB, you must have your capture partition formatted as NTFS and you must be running Windows NT/2000. The error message itself is caused by Windows, and not by the limitations of the AVI file format.

So how do I capture more than 4GB?

You must do all of the following:

Use normal capture (F6 key) and not compatibility mode capture (F5 key).

Check Capture/Enable multisegmented capture.

Add one or more drives to Capture/Spill drives. Set the thresholds to 50MB, and make sure you use a full path (i.e. E:\ and not E:). Also, set priority of all drives to 0 to avoid a bug in V1.4c.

VirtualDub will then capture in segments to a bunch of 2GB files.

How do I change the channel or capture in MPEG-1/2?

You can't -- this functionality isn't available through the Video for Windows capture interface. The application that comes with your capture device can do it because it uses a proprietary interface that other programs can't use.

VirtualDub documentation: compiling

It seems you can never compile someone else's application without a lot of hair pulling!

What do I need to compile VirtualDub?

You need Visual C++ 6.0 SP5 + Processor Pack and Microsoft Macro Assembler (MASM) 6.15.  The Processor Pack is a free download from Microsoft's website, although you will need to patch to SP5 first (this is mandatory anyway since some pre-SP3 bugs will cause VirtualDub to miscompile).  It also includes MASM (ml.exe) as well.  If you don't have the Processor Pack installed, the SSE instruction sfence will not compile.

What are the verinc and mapconv tools?

verinc is my automatic build number incrementer, and mapconv generates the .dbg files used to generate stack dumps on a crash. mapconv can be safely removed from the VirtualDub.exe post-build step without problems, but verstub.asm still needs to be compiled.

Download source code for mapconv and verinc from virtualdub.org (HTTP).

How should I lay out the directory structure when I unzip the archives?

The source and auxsrc distributions can go into any directory, although VirtualDub just might be a good name for it. NekoAmp should go into amplib_new and Sylia should go into sylia, with both directories at the same level as the VirtualDub directory.

What's INVALID_SET_FILE_POINTER

A macro constant included in recent versions of Microsoft's Platform SDK, which has newer Win32 includes than the original Visual C++ 6.0 distribution.  Install the PSDK includes or use:

#define INVALID_SET_FILE_POINTER ((DWORD)-1)

VC++ says it can't find IAMPDecoder.h

You need to install the NekoAmp source code and headers. By mistake, some of VirtualDub's modules refer to an amplib directory in their preprocessor settings; they should all be pointing to amplib_new

VC++ says it can't find IScriptInterpreter.h

Install the source code and headers for the Sylia scripting language in ../sylia

When I recompile VirtualDub, the executable is over a megabyte, instead of the 380K yours is!

Don't release Debug mode builds; change the build target to "VirtualDub - Win32 Release."  (You're not supposed to ship debug executables anyway, as the Visual C++ debug RTL isn't redistributable.)

I'm building a Release build now, but it's still over 800K.

I cheated -- the release VirtualDub.exe is compacted with UPX

Isn't assembly language dead with modern compilers?

void add_pairs(float *dst, const float *src, int count) while(--count);
}


F:\test>cl /c /O2ax /G6s fpu.cpp && dumpbin /disasm fpu.obj
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.

fpu.cpp
Microsoft (R) COFF Binary File Dumper Version 6.00.8447
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.


Dump of file fpu.obj

File Type: COFF OBJECT

?add_pairs@@YAXPAMPBMH@Z (void __cdecl add_pairs(float *,float const *,int)):
00000000: 8B 54 24 0C mov edx,dword ptr [esp+0Ch]
00000004: 85 D2 test edx,edx
00000006: 74 1F je 00000027
00000008: 8B 44 24 08 mov eax,dword ptr [esp+8]
0000000C: 8B 4C 24 04 mov ecx,dword ptr [esp+4]
00000010: D9 00 fld dword ptr [eax]
00000012: 83 C0 04 add eax,4
00000015: D9 00 fld dword ptr [eax]
00000017: 83 C0 04 add eax,4
0000001A: D8 C1 fadd st,st(1)
0000001C: 83 C1 04 add ecx,4
0000001F: 4A dec edx
00000020: D9 59 FC fstp dword ptr [ecx-4]
00000023: DD D8 fstp st(0)
00000025: 75 E9 jne 00000010
00000027: C3 ret
00000028: 90 nop
00000029: 90 nop
0000002A: 90 nop
0000002B: 90 nop
0000002C: 90 nop
0000002D: 90 nop
0000002E: 90 nop
0000002F: 90 nop

What was that again?

VirtualDub documentation: Processing

There are a few areas of VirtualDub that are rougher than they should be. The least I can do is document it.

How do I crop a video?

VirtualDub allows you to crop at the beginning of any video filter; you can do it by clicking on a video filter and then "cropping." This option is called "clipping" in versions prior to 1.4. If you don't have any video filters you want to run, add a "null transform" filter and then add cropping to that.

The reason you can crop before any filter is that filters that are spatial (area-based) tend to exhibit artifacts at the edge of the image, where the area filters are poorly defined. You can sometimes get more natural results by applying the blur/sharpen/etc. first and then cropping afterward.

You cannot crop in direct stream copy mode -- the cropped video must be recompressed. That's life.

Why does the sound stutter during playback?

This will occur if your CPU isn't fast enough to handle real-time preview. When checking the results of filtering, it's better to be able to see all frames in slow-motion rather than to see a sync'ed, 1 FPS slideslow. You can enable the "drop frames when behind" option in the menu, but it's not very effective in most cases and can simply lead to a 1 FPS, stuttering slideshow. If you must see the results in real-time, using frame rate decimation is usually far more effective.

Short answer: VirtualDub is not a player.

I tried to cut out some frames in direct stream copy mode, and VirtualDub put them back in!?

You deleted a frame, but didn't delete the non-keyframes after it.

A keyframe is a frame that can be decoded on its own; a non-keyframe, or delta frame, is a difference from the previous frame and cannot be decoded if the frame before it is missing. VirtualDub always plays it safe and makes sure that all frames that you don't delete are decodable. This means that any non-keyframe that you include will force inclusion of any frames before it, back to and including the previous keyframe.

Below the position slider and to the right of the motion buttons, there is a timestamp counter that shows the current position:

Notice the [K] at the end -- this is the current frame type. K indicates a keyframe; nothing indicates a delta frame; [D] indicates a dropped frame, which is another type of non-keyframe. Basically, all you have to do is ensure that when you delete a segment, you end the delete right before the next keyframe. You can seek between keyframes by holding SHIFT when dragging the nub or clicking on the forward and backward buttons with the yellow key icon.

How come VirtualDub doesn't let me compress into MPEG layer III audio, or only up to 56Kbps?

Audio compression is handled by third-party Windows ACM drivers, not by VirtualDub itself. The MP3 compression driver comes from Fraunhofer-IIS and has a few incarnations, with the filenames L3CODECX.ACM L3CODECA.ACM, and L3CODECP.ACM. If you don't have any MP3 options, you either don't have the L3 codec installed at all, or have the standard version (L3CODECX). A 56Kbps limit means you have the Advanced version; 128Kbps means you have Professional; 320Kbps means you're using the warez Radium hack.

I can't tell you where to find these codecs, unfortunately, and I suspect they aren't redistributable in any case.

VirtualDub documentation: crashes

Listed below are a few common VirtualDub crashes that are related to third-party drivers.  If you get a crash in VirtualDub, one of the entries below may help you track down the problem.  The "symbol containing EIP" will appear as the top entry in the estimated call stack, in the form of dll name ! export.  If the top entry contains only a name rather than a DLL name and an export name, it's probably a crash in VirtualDub itself and you should reference the Knowledge Base instead.

As usual, the information you get out of a crash dump may be suspect, so a crash in a particular DLL does not mean that that DLL is bad.  However, the DLL implicated in the crash dump may give you a clue as to what's going on.

VirtualDub features

Have you ever worked with desktop video?

Sure, you've probably played a few video clips on your monitor.  But have you ever made one yourself?  Used a video capture device?  Wrestled with the software that comes with it?  Felt like the software is a few leagues above or below your level?  Time to try something else.

VirtualDub helps you get video into your computer.

If your capture device is Video for Windows compatible, then VirtualDub can capture video with it.  But VirtualDub isn't your average capture program:

• Fractional frame rates.  Don't settle for 29 or 30 when you want 29.97.
• Optimized disk access for more consistent hard disk usage.
• Create AVI2 (OpenDML) files to break the AVI 2GB barrier and multiple files to break the FAT32 4GB limit.
• Integrated volume meter and histogram for input level monitoring.
• Real-time downsizing, noise reduction, and field swapping.
• Verbose monitoring, including compression levels, CPU usage, and free disk space.
• Access hidden video formats your capture card may support but not have a setting for, such as 352x480.
• Keyboard and mouse shortcuts for faster operation.  To capture, just hit F6.
• Clean interface layout: caption, menu bar, info panel, status bar.

VirtualDub lets you clean up video on your computer.

There are lots of programs that let you "edit" video.  And yet, they're frustratingly complex for some of the simplest tasks.  VirtualDub isn't an editor application; it's a pre- and post-processor that works as a valuable companion to one:

• Reads and writes AVI2 (OpenDML) and multi-segment AVI clips.
• Integrated MPEG-1 and Motion-JPEG decoders.
• Remove and replace audio tracks without touching the video.
• Extensive video filter set, including blur, sharpen, emboss, smooth, 3x3 convolution, flip, resize rotate, brightness/contrast, levels, deinterlace, and threshold.
• Bilinear and bicubic resampling -- no blocky resizes or rotates here.
• Decompress and recompress both audio and video.
• Remove segments of a video clip and save the rest, without recompressing.
• Adjust frame rate, decimate frames, and 3:2 pulldown removal.
• Preview the results, with live audio.

You can take a captured clip, trim the ends, clean up some of the noise, convert it to the proper frame size, and write out a better one.  Don't see a video filter you want?  Write your own, with the filter SDK.

VirtualDub is fast.

The author of VirtualDub is very impatient.  That means his program is designed for speed, both in the interface and in the processing pipeline.  Converting a compressed, 320x240 MPEG-1 file to an uncompressed, 24-bit AVI requires only these two steps in VirtualDub:

• Open video file (Ctrl-O).
• Save AVI (F7).

How fast is this operation?  On a C450, 40 frames per second (1.3x real-time speed).  With a little tweaking, the speed rises to 55 fps (1.8x), with the CPU hardly breaking a sweat at 40%.

VirtualDub is cheap.

To be exact, it costs nothing.  VirtualDub is licensed under the GNU General Public License, meaning you can use it for free.  No risk involved, and the whole source code is available if you want it.

VirtualDub filters

I've decided that I don't have the time or energy to hunt down and maintain a list of all the current video filters available for VirtualDub, so I've appointed Donald Graft as honorary filter website maintainer.  You can find his own filters, and a comprehensive list of other third-party filters, at:

https://neuron2.net/

You'll find my own subtitler filter below, if you scroll down.

VirtualDub filters can be loaded manually by clicking on the Load button that appears in the Add Filters dialog box.  They can also be automatically loaded at startup if you copy the .vdf file into a plugins subdirectory under the VirtualDub program directory.  It is possible, although unusual, for filters to conflict with each other, so if you have problems with a particular filter chain you might want to try testing each filter individually to narrow the scope of the problem.

Download subtitler-2_4.zip from virtualdub.org
Download subtitler-2_4-src.zip from virtualdub.org
Download subtitler-2_3.zip from virtualdub.org
Download subtitler-2_3-src.zip from virtualdub.org
Download subtitler-2_2.zip from virtualdub.org
Download subtitler-2_2-src.zip from virtualdub.org
Download subtitler-2_1.zip from virtualdub.org
Download subtitler-2_1-src.zip from virtualdub.org
Description: Applies Sub Station Alpha v2.x/4.x scripts to video.
Supports batch operation: Yes
Updated: (V2.4) Fix for another crash.

Pretty self-explanatory; handles most of the common features in SSA scripts.  It has text antialiasing, so your subtitles look good at small sizes.

Download warpsharp-1_1.zip from virtualdub.org Download warpsharp-1_1-src.zip from virtualdub.org
Description: Sharpens images by warping pixels toward edges.
Supports batch operation: Yes
Updated: (V1.1) Adds bicubic filtering and performance optimizations.

Sharpens images through warping rather than convolution.  Most effective on cartoon-style animation.

Note: This filter won't work in Avisynth because it uses the BitBlt() function from VirtualDub -- Donald Graft has a version on his site which will work.

Filter SDK

VirtualDub has the capability to load third-party DLLs that include their own video filters.  The filters that are built into VirtualDub use the same interface that is exported to DLLs, so you can write filters similar to or better than the included ones.  You can sample some of these at the third-party filters page; these range from corrective filters, such as noise reducers, to synthesis filters, such as the subtitler.  The basic interface is simple to work with: VirtualDub gives you a 32-bit ARGB bitmap to modify.

Requirements for the filter SDK:

• A 32-bit Windows C++ compiler.  Microsoft Visual C++ 6.0 Service Pack 5 recommended; it is possible to write filters in Borland C++ Builder but I cannot help you with this.  Microsoft Visual Studio .NET has not been tested with this SDK and is not recommended.
• VirtualDub 1.2 or newer (viable V1.4.11 build tree recommended to build debug builds).

Download filter SDK 1.05 (filtsdk-1.05.zip, 66K zip file)

Knowledge base

Open bugs

• BUG: MPEG layer I audio not decoded properly in MPEG-1 files
• BUG: Fields dropped when decoding Motion-JPEG video from Pinnacle MJPEG-capable device
• BUG: Crash when decoding MPEG-1 file with odd macroblock width on Pentium 4
• PRB: MPEG-1 file longer than twelve hours has audio stream truncated

Closed bugs

• BUG: Audio desynchronized after deleting segments
• BUG: Horizontal interlacing in output
• BUG: Precise bilinear and precise bicubic modes show purple stripe along right border
• BUG: Filter copy construction does not work
• BUG: Save Image Sequence command saves to wrong directory
• BUG: Playback locks up intermittently on multi-CPU or hyperthreaded system
• BUG: Compressed WAV files are missing the FACT chunk
• BUG: Job system munges last bytes of codec configuration structure
• PRB: Internal error: MMX state left on during video scan
• BUG: Frameserver libraries fail to load due to missing MSVCR70.DLL
• BUG: Temporal smoother introduces flashing pixel in bottom left corner
• BUG: OpenDML files written with bad duration values in index
• BUG: Video frames dropped when reindexing video
• BUG: Out of memory while importing uncompressed RGB video

Open bug list

BUG: MPEG layer I audio not decoded properly in MPEG-1 files symptoms Audio extracted from an MPEG-1 file sounds very distorted. cause Occasionally, an MPEG-1 file surfaces whose audio is encoded in layer I, instead of the more common and more efficient layer II format. The layer I decoder in NekoAmp accidentally uses the layer II dequantization table, which causes the distortion because layer I does not have sample grouping. workaround No direct workaround. Use external tools to demultiplex and decompress the audio (TMPGEnc and WinAmp can do this for you). File | File Information in VirtualDub will tell you if the MPEG-1 file has layer I, II, or III audio.

BUG: Fields dropped when decoding Motion-JPEG video from Pinnacle MJPEG-capable device symptoms VirtualDub does not appear to be decoding MJPEG video correctly -- sometimes fields are left behind from previous frames. cause If you have no VFW MJPEG decoder installed on your system, VirtualDub will use its own internal MJPEG decoder. This decoder does not properly handle padding before markers (FF FF xx) in some cases, resulting in the second field not being decoded. It appears that recent DC10plus drivers from Pinnacle Systems are now producing frames which trigger this bug. (This is most definitely my bug -- the MJPEG data is fine.) workaround Install a third-party, Video For Windows MJPEG codec to avoid using the internal decoder.

BUG: Crash when decoding MPEG-1 file with odd macroblock width on Pentium 4 symptoms A crash occurs when attempting to decode MPEG-1 files of certain widths, e.g. 720x480. You have a Pentium 4 CPU. cause The SSE2 macroblock prediction code assumes alignment that is not correctly guaranteed by the decoder initialization, and thus the code crashes if the pixel width of the source, rounded up to the nearest 16 pixels, is not a multiple of 32 pixels. This bug affects all SSE2-capable CPUs on both the P4-optimized and general builds, since the bug is in shared code. workaround Disable SSE2 optimization in Options|Preferences|CPU.

PRB: MPEG-1 file longer than twelve hours has audio stream truncated symptoms Attempting to load an MPEG-1 file that is longer than 12 hours results in little or no audio coming up. cause Unlike compressed audio in an AVI, the MPEG import filter reports uncompressed sample counts to VirtualDub's engine rather than compressed sample counts. Since MPEG-1 has highly compressed audio, it is possible to create an MPEG-1 file on regular computers whose audio track decompresses to more than 2,147,483,647 samples, the limit of VirtualDub's internal sample handlers. The worst case is with 48KHz audio, in which it occurs after 12 hours, 26 minutes. A bug in VirtualDub causes the large audio stream to come up in the editor with very little, if any, of the audio. This problem is not related to the 4GB limit or 32-bit file addressing. VirtualDub's MPEG-1 handler will handle files larger than 4GB without problems, assuming the audio sample limit is not reached, and the problem can occur with files smaller than 4GB, although it is unlikely due to the extreme compression required in that case. In any case, it is not recommended that you attempt to process MPEG-1 files this large. workaround Use an MPEG-savvy tool to slice the MPEG file apart and process the chunks separately. As a hack, use VirtualDub's hex editor to whack off the end of a copy of the file, then open the whacked file with "accept partial streams" checked in the open options.

Closed bug list

BUG: Audio desynchronized after deleting segments symptoms Video becomes desynchronized from audio when saving after deleting portions of the clip, or no audio is included at all in the output file. cause There is a bug in the way VirtualDub computes audio offsets when the following conditions occur: Source audio is compressed. Audio mode is "direct stream copy." You have deleted portions of the clip. A non-zero start offset is specified. The processing operation then starts with an audio start offset that is far larger than it should be. If the computed offset is beyond the end of the source, no audio is included at all. workaround Do not use both a start offset and segment deletion. fixed

BUG: Horizontal interlacing in output symptoms 24-bit video is compressed or output with horizontal black stripes. cause 1.4.12's 24-bit color conversion routine has an error in the way it processes odd-width bitmaps that causes it to punch out every other pixel. It only occurs with odd-width video and it is a regression only in 1.4.12. workaround Turn off integer SSE support. fixed

BUG: Precise bilinear and precise bicubic modes show purple stripe along right border symptoms The Precise modes of the resize filter add a purple stripe along the right side of the video. cause This is due to an assembly mistake in 1.4.12 -- it is a regression only in that version and does not occur in 1.4.11. workaround No workaround. fixed

BUG: Filter copy construction does not work symptoms The copyProc feature of the 1.4.11 video filter API, which is supposed to allow copy construction of filters as true C++ objects, receives the same addresses for source and destination. cause Oops. workaround No workaround. The API version has been bumped to v9 in 1.4.12 to reflect the fixed copy construction procedure, and filters using that feature should decline to run on a v8 API host. fixed

BUG: Save Image Sequence command saves to wrong directory symptoms Attempting to save an image sequence results in the files going to the wrong directory. cause The "directory" field in the dialog is ignored by mistake. This is a regression in 1.4.11 that does not occur in 1.4.10. Also, the corresponding script command is unaffected. workaround Place the directory in the "Prefix" field. fixed

BUG: Playback locks up intermittently on multi-CPU or hyperthreaded system symptoms Playback freezes occasionally on a CPU with multiple logical processors and cannot be stopped except by killing the task. cause Thread synchronization code used in the blitter routines is not multi-CPU safe and only works properly on single CPU systems. workaround Turn on "synchronized blit." fixed

BUG: Compressed WAV files are missing the FACT chunk symptoms Compressed WAV files written by VirtualDub are missing the 'fact' chunk that indicates the number of uncompressed samples. cause Oops. workaround Write out an uncompressed WAV file and use Windows Sound Recorder to compress it. In practice, the 'fact' chunk is useless because it is computed from the length of the compressed stream and the format values in the header, so it conveys no additional information. (You can verify this by examining the output of sndrec32.) fixed

BUG: Job system munges last bytes of codec configuration structure symptoms Codecs may crash or use incorrect settings in batch jobs. cause The MIME BASE64 encoder that encodes the codec configuration structure squashes the last few bytes of the codec configuration structure due to incorrectly handling partial quanta. workaround There is no end-user workaround. Front-end programs that generate scripts should not be affected as only the BASE64 encoder is bugged. Codecs may work around the problem by allocating four unused bytes at the end of the codec block, if necessary. fixed

PRB: Internal error: MMX state left on during video scan symptoms You receive this error during a "scan for errors" command: Internal Error MMX state left on: T:\projects\VirtualDub_old\main\VideoSource.cpp:1101 cause 1.4.10 performs MMX state checks before and after certain calls to third-party codec drivers. Leaving MMX on results in floating-point computation failing; the check going in is designed to protect codecs against crashes that would be caused by VirtualDub, and the check going out traps potential crashes in VirtualDub caused by codecs. There is a bug in the video decompression code that causes the going-out check to be bypassed if a decompression error occurs. It appears that the Microsoft MPEG-4 V3 (a.k.a. DivX 3.11a) codec improperly leaves the MMX state on if it detects and reports a decompression error back to the client application. This error is then misreported by VirtualDub as an internal error instead of a codec failure. workaround None. The misleading error message will be fixed in the next release; a code workaround for the codec problem will be necessary since that codec is no longer being updated. fixed

BUG: Frameserver libraries fail to load due to missing MSVCR70.DLL symptoms Frameserving does not work in 1.4.10, because the requisite libraries fail to load. cause The 1.4.10 frameserver libraries were inadvertently shipped linked against the Visual Studio .NET (VC7) run-time library; this was a mistake. VirtualDub itself still runs because it was compiled with Visual C++ 6.0 as intended. Visual C++ 6.0 will continue to be the target compiler for the 1.4 series, and as such the MSVCR70.DLL libraries will not be provided. workaround Install the frameserver libraries from 1.4.9, which are properly linked with the VC6 CRT. There have been no changes to the frameserver libraries in 1.4.10 -- the code is exactly the same and will work fine with 1.4.10 acting as server. fixed

BUG: Temporal smoother introduces flashing pixel in bottom left corner symptoms Using the "temporal smoother" filter in 1.4.10 introduces a flashing pixel in the bottom left corner of the output video. cause The temporal smoother in 1.4.10 introduced a workaround for a ramp-up initialization issue; that fix is bad and actually introduced a regression not present in 1.4.9. workaround Back down to 1.4.9 if you need to use the temporal smoother filter. fixed

BUG: OpenDML files written with bad duration values in index symptoms You notice bad duration values in an AVI file larger than 2GB in a hex editor. cause VirtualDub writes the duration for the first sample into all hierarchical index entries. VirtualDub and current versions of DirectShow (Windows Media Player) ignore these values, but some other OpenDML applications may reject the file. workaround None. VirtualDub automatically disables the OpenDML index for files smaller for 2GB, so files used for large-scale distribution should not be affected (the legacy index does not have duration values). fixed

BUG: Video frames dropped when reindexing video symptoms Several video frames are missing from the beginning of video when reindexing a truncated AVI file. cause VirtualDub drops all samples from stream 0 until stream 1 or higher samples are hit in the AVI file. Typically, stream 0 is the video stream (but not always). This doesn't occur with VirtualDub's own AVI files since VirtualDub usually writes a preroll audio chunk first in the file. workaround None. fixed

BUG: Out of memory while importing uncompressed RGB video symptoms VirtualDub refuses to read frames from uncompressed RGB file with an out of memory error. cause Your uncompressed RGB file has been recorded using top-down (inverted) DIBs, which have a negative biHeight value.  VirtualDub currently does not support these. workaround Use the hex editor to edit the biHeight value to a positive value, then use the Flip Vertically filter to reinvert the video to its proper orientation during processing. fixed