VirtualDub 1.6.14
Posted by: Newsfactory on: 03/13/2006 11:24 PM [ Print | 0 comment(s) ] · 3738 views
VirtualDub is a video capture/processing utility for 32-bit Windows platforms (95/98/ME/NT4/2000/XP), licensed under the GNU General Public License (GPL). It lacks the editing power of a general-purpose editor such as Adobe Premiere, but is streamlined for fast linear operations over video. It has batch-processing capabilities for processing large numbers of files and can be extended with third-party video filters. VirtualDub is mainly geared toward processing AVI files, although it can read (not write) MPEG-1 and also handle sets of BMP images.
New stable version is out, 1.6.14, which is just 1.6.13 with a few minor fixes and changes. For the most part creating this version was uneventful, except for the part where I coded a genetic algorithm to produce a Huffyuv frame that had a value encoded on the last DWORD of a frame that was exactly (multiple of 16K) - 32 bytes in size. I had to do this in order to replicate and verify a workaround for the random Huffyuv crash, which is caused by VLC decoding reading four bytes beyond the end of the frame.
Also, after another report, I tracked down the cause of the "vidc.draw" crash, where VirtualDub crashes trying to open an AVI file or bring up the video compression dialog on a codec with FOURCC "draw." Well, rather, I found a page on the Adobe Premiere Elements technical support site through Google that explains the problem. Basically, the crash is caused by the addition of a video codec entry in the Registry that has a space at the beginning of the filename. The behavior of the OS in this regard is rather strange ? an attempt to open such entry with ICOpen() succeeds with a valid HIC, even though the codec filename is invalid, but any calls using that HIC crash in ICSendMessage(). I didn't put in a workaround for this, because it's unclear how to safely to do, but deleting the errant entry resolves the problem, and doing so can't make the problem any worse since whatever registered the bad entry obviously isn't using the codec that was supposed to be registered.
Changelog
VirtualDub 1.6.14 (32-bit) release build (VirtualDub-1.6.14.zip) VirtualDub 1.6.14 (AMD 64-bit) release build (VirtualDub-1.6.14-AMD64.zip)
New stable version is out, 1.6.14, which is just 1.6.13 with a few minor fixes and changes. For the most part creating this version was uneventful, except for the part where I coded a genetic algorithm to produce a Huffyuv frame that had a value encoded on the last DWORD of a frame that was exactly (multiple of 16K) - 32 bytes in size. I had to do this in order to replicate and verify a workaround for the random Huffyuv crash, which is caused by VLC decoding reading four bytes beyond the end of the frame.
Also, after another report, I tracked down the cause of the "vidc.draw" crash, where VirtualDub crashes trying to open an AVI file or bring up the video compression dialog on a codec with FOURCC "draw." Well, rather, I found a page on the Adobe Premiere Elements technical support site through Google that explains the problem. Basically, the crash is caused by the addition of a video codec entry in the Registry that has a space at the beginning of the filename. The behavior of the OS in this regard is rather strange ? an attempt to open such entry with ICOpen() succeeds with a valid HIC, even though the codec filename is invalid, but any calls using that HIC crash in ICSendMessage(). I didn't put in a workaround for this, because it's unclear how to safely to do, but deleting the errant entry resolves the problem, and doing so can't make the problem any worse since whatever registered the bad entry obviously isn't using the codec that was supposed to be registered.
Changelog
VirtualDub 1.6.14 (32-bit) release build (VirtualDub-1.6.14.zip) VirtualDub 1.6.14 (AMD 64-bit) release build (VirtualDub-1.6.14-AMD64.zip)
« ForceWare 87.43 For Laptop and Desktop GPUs · VirtualDub 1.6.14
· 50×BIOS and 148×Firmware Update »
