Current version

v1.10.4 (stable)

Navigation

Main page
Archived news
Downloads
Documentation
   Capture
   Compiling
   Processing
   Crashes
Features
Filters
Plugin SDK
Knowledge base
Contact info
 
Other projects
   Altirra

Archives

Blog Archive

VirtualDub 1.9.9 released

It's been so long since I released a new version of VirtualDub that I almost forgot my SourceForge password. Ugh.

Version 1.9.9 is now up, and is a stable release with queued up bug fixes; several of them are in the core filtering engine and a couple are in the AVI and Huffyuv handling code. As usual for a stable release, there are no new features other than a small diagnostic one (log specific errors when plugins fail to load on startup).

I don't normally disclose much specifics about what I have in progress, but since I've been slow lately working on VirtualDub (mainly due to time and motivational constraints) and because I have published some working test code already, I'll mention some of my long term plans here. As many of you know, one of the big issues with VirtualDub right now is lack of support for more advanced video formats. VirtualDub's development model depends on an abstraction between specific video formats and the core program for various reasons, relating to legal, maintenance, and simple complexity problems. The short answer is that I cannot and will not take a dependency on an external library to handle formats, nor can I implement them directly. Therefore, the current long-term plan is to beef up the input and output plugin support -- which includes adding command-line encoder support and bringing the DirectShow input plugin internal to the program. The command-line encoder support is still rough, but I've been posting test releases in the forum, and it's starting to look good as a way to export to formats such as H.264, as well as any bizarro homegrown format you can encode to with a simple CLI program. The DirectShow input plugin mostly works, although it needs work on the file type mapping side.

Another frequently requested feature is multicore support. There is a strong misconception that not taking advantage of multiple cores is a bug that requires a ten minute fix, and this notion really needs to be dispelled: writing correctly multithreaded software is hard with standard programming paradigms and that's a major problem that the software industry is currently facing. This is further complicated when dealing with APIs that have threading affinity or are difficult to run in a concurrent manner. The problem with VirtualDub is that the video and audio codecs are typically the main bottleneck, and I can't force those to be multithreaded from my end. I do have a couple of plans, though. First, video codecs that produce only key frames can be parallelized; this is not currently implemented in even test releases, but I don't see any blocking issue there. Second, I do have more control over video filters, and while I can't run a single video filter on multiple threads, as I've written before it is possible to run different video filters in the same chain concurrently. The test releases in the beta forum can already do this to some extent, and I'm seeing some promising gains on a dual-core machine.

Now, the bad part: I have no timeline whatsoever for this. Sorry, but that's reality. I have a full-time job, I have other interests, and therefore I only work on VirtualDub occasionally. I get a lot of requests for various features, some of which are well-written, and some of which are frankly abusive, but regardless I can only take on a few of them at a time, and I generally have to avoid chasing the frontier, whether it be in compilers, OS features, algorithms, formats, etc. If you've sent me an email and haven't gotten a response, or are still waiting for a feature to arrive -- I apologize, and please believe me when I say I keep a master list of requests. Thanks for your support and your continued patience, and if you've got some time, feel free to try some of the test releases I put out in the forums.

Change log:

Build 32817 (1.9.9, stable): [April 9, 2010]
   [features added]
   * The log now indicates which plugins failed to load on startup.
   [bugs fixed]
   * UI: Fixed a case where the output pane could change aspect ratio when
     auto pane sizing was enabled and the main frame window was resized.
   * UI: The output pane now has the correct pixel aspect ratio when an input
     plugin indicates non-square pixels and no filters are used.
   * UI: 6% zoom menu items didn't display checkmarks properly.
   * AVI: Fixed incorrect decoding of paletted video files when biClrUsed=0 in
     the header and the input color mode is set to Autoselect.
   * AMD64: Fixed incorrect disassembler module in crash handler.
   * Render: Fixed sporadic hang when using smart rendering with fast
     recompress mode.
   * Render: Audio is no longer cut off when "cut off when video ends" option
     is disabled and IVTC filter is used.
   * Filters: Fixed duplicate frame fetches when using lagged filters (ex:
     temporal smoother) at the very end of the source video stream.
   * Filters: Fixed frame fetch errors when using filters with a frame window
     (ex: interpolate) at the end of an MPEG-1 video.
   * Filters: Source length was not set during renders.
   * Filters: Fixed garbage line at bottom of frame when using IVTC filter
     with an odd height.
   * Filters: Fixed bug where filter preview stopped displaying frames past a
     certain point when edits had occurred on the timeline.
   * Batch: Timeline had wrong frame counts when creating batch jobs via
     Process Directory or Batch Wizard with a frame rate changing filter (ex:
     IVTC).
   * Decoders: Fixed decoding of Huffyuv files using median prediction and
     4:2:0 encoding.
   * Decoders: Fixed incorrect chroma DC handling with restart markers in
     MJPEG decoder.
 

Comments

This blog was originally open for comments when this entry was first posted, but was later closed and then removed due to spam and after a migration away from the original blog software. Unfortunately, it would have been a lot of work to reformat the comments to republish them. The author thanks everyone who posted comments and added to the discussion.