¶VirtualDub 1.6.6 released; multithreading 1.7.0
It's been a while, but 1.6.6 is now out the door. This release is solely a bug-fix release; the one option that was added addresses a compatibility issue with some hardware-based playback devices. Assuming that no major issues crop up this version will be promoted to stable in the next release with few or no changes; otherwise, I'll try again.
Part of the reason for the delay was that I was also working on a 1.7.0 branch at the same time. Some of the changes that I did not want to put in 1.6.6 and probably won't put in 1.6.7 will go into this branch instead. The primary change that I am working on at the moment is rewriting the rendering engine; it's a monolithic mess right now and I'm trying to break it apart into stages so that it is more finely grained. Among the benefits of doing this are that it could be further multithreaded for better performance on 2-way and 4-way SMP machines, and also able to cover the latency of IPC between 32-bit and 64-bit processes, which is how I plan to have the 64-bit version use 32-bit filters and codecs. It will also make handling multiple sources and possibly multiple outputs easier, if I go down that route.
Possible performance issues with Symantec AntiVirus Corporate Edition
One of the changes that was made to 1.6.6 was a rework of the way that VirtualDub opens files for write. For performance reasons, VirtualDub opens the output AVI twice, once in non-buffered I/O mode and again in buffered mode. Both open calls are done with the WRITE flag for access and for sharing permissions. I received some reports that 1.6.5 could not write files when certain versions of Symantec AntiVirus Corporate Edition were active and scanning AVI files. Basically, Symantec AntiVirus is apparently able to violate Win32 sharing conventions by opening newly created files and denying write access even though there is already a Win32 file handle open with write access. This causes VirtualDub's second file open to fail with an access denied error.
In 1.6.6, I fixed the open code so that it would once again work if only the buffered file handle open succeeded. However, in this mode you will see degraded file I/O performance if you are writing out a high-bandwidth video file, such as an uncompressed or Huffyuv-packed file. In addition, the file cache will also be more polluted so that other programs may page to disk after a prolonged save operation. If you are experiencing these kinds of problems with an antivirus product I first recommend trying to update to the vendor's latest version, and if that doesn't resolve the problem, try adding the output folder to the exclude list for scanning.
YCbCr issues
There were some minor accuracy bugs in the MMX versions of a few of the YCbCr conversion routines. Occasionally, the conversion resulted in values that were +/- 2/255 or +/- 3/255 off ideal; this has now been generally reduced to +/- 1/255. The differences were not visible.
Conversion from UYVY and YUY2 to RGB now interpolate chroma properly. This bug didn't affect the planar formats, though.
If you had a YCbCr-encoded AVI (YUY2, UYVY, YV16, YV12, I420, IYUV, or YVU9) that had a width that wasn't divisible by 4, 1.6.5 could report errors about incorrect frame sizes while scrubbing on the timeline. This was due to a bad scanline pitch computation that has been fixed in 1.6.6.
Sector alignment of large, uncompressed video frames
During 1.6.6's development I received a report from a hardware vendor that modifications were required to VirtualDub to play back its AVI files on their hardware devices, due to additional alignment restrictions in the hardware for DMA transfers from the hard disk. An option is now present in Options > Preferences > AVI to force sector alignment for large, uncompressed video frames. You should not enable this unless you are experiencing incompatibility problems as it will result in additional padding chunks being placed in the output file.
Change log
Build 23486 (1.6.6, experimental): [May 29, 2005]
[features added]
* Added an option in Options > Preferences > AVI to force sector alignment
for large uncompressed frames. This can resolve compatibility problems
with some uncompressed hardware video playback units.
[bugs fixed]
* Capture: Video/audio format and compression and video frame rate now
autosave on disconnect.
* Capture: Fixed some cases where the Raw Audio Format dialog didn't
highlight the currently selected PCM format.
* Capture: Noise reduction threshold was not restored properly.
* Capture: Renamed Peak Meter back to Volume Meter and restored V
accelerator.
* Frame byte size was being computed improperly for YCbCr AVIs.
* Fixed broken MJPEG video decoding at bottom-right corner on streams that
have restart markers.
* Reworked MJPEG field ordering detection to be consistent with DirectShow
MJPEG decoder. If this is reversed for your files, enable "swap fields"
in AVI extended open options.
* Scene detection was busted for 16-bit RGB (very rare case).
* Minor status updating features, such as the current position nub moving
during input preview, were broken after running a job that ended in an
error.
* (AMD64 only) Scene detection is now implemented.
* (AMD64 only) Enabled some video filters that had scalar implementations:
flipv, fliph, deinterlace, rotate, and HSV.
* Save Image Sequence dialog didn't show the "add as job" button as checked,
even if it was saved as such from the last time.
* Fixed minor bugs in various image converters and improved accuracy of a
few YCbCr-to-RGB converters.
* Fixed UYVY/YUY2-to-RGB converters not interpolating chroma properly.
* Fixed YVU9 chroma planes being swapped on write to disk and enabled YVU9
for direct input.
[regressions fixed]
* App would sometimes exit after stopping frameserver.
* Frameserver sent garbage data if the video filter chain changed the frame
size.
* Fixed a regression in video codec negotiation for MS MPEG-4 V3 variants
where a different but compatible codec was not properly detected.
* Doing a paste with no selection caused one frame to be deleted before
doing the paste.
* Write open failures were being reported again when the target file
couldn't be opened a second time in fast I/O mode, which happens
sometimes with emulators or remote drives. The slower fallback has been
reinstated.
* Running out of disk space at the very end of a render operation was
sometimes reported as an I/O error rather than a write error.
* Sampling in filter preview could fail if the timeline had been edited.