§ ¶VirtualDub 1.6.18 and 1.7.2 released
Two new releases of VirtualDub today.
1.6.18 (stable) has a couple of fixes from the 1.7.x series backported to it, one being a fix for AVI compatibility issues when alignment is enabled (mostly capture mode), and another being a crash related to the Cancel button in the video filter list dialog.
1.7.2 (experimental) has a slew of fixes, and a couple of changes. One is that throttling is now supported, so you can force VirtualDub to use less than 100% of the CPU during processing. Another change is that this is the first version with an input driver plugin API. This allows new container formats to be added for import, much like video filters can be added with new .vdf files. The API is still very experimental at this point, but if anyone wants to experiment with it: [VirtualDub plugin SDK 0.5]. Please send any comments on the API. Again, this API is still experimental and is subject to breaking changes.
Full change lists after the jump.
Build 27700 (1.7.2, experimental): [May 19, 2007]
* Added minor frame lines to the parameter curve editor.
* Input driver plugin support.
* The threshold, sharpen, and brightness/contrast filters now support
* The DV type-1 audio source can now be set to conceal errors.
* Rendering operations can be throttled or paused.
* Capture: Screencap driver can now capture the mouse cursor.
* AVI parser now handles files with a significant amount of garbage prior to
the first video or audio chunk.
* Curve editor opens to current frame instead of frame 0.
* Smart rendering didn't check the right locations in filter opacity curves
if edits had been applied.
* Animated GIF decoder didn't handle the "erase" and "restore" disposal
* Animated GIF decoder could display a one-frame glitch at start of
* Time-based filters and filter curves weren't reflected in output preview
when applied to a repeating frame.
* Fixed interlaced field DirectDraw display with planar YCbCr formats.
* The "smart rendering" option could cause a missing codec error even if
the video mode was set to Direct.
* Added workaround for BlackMagic MJPEG codec not producing key frames.
* Added workaround for update problems with the Direct3D and OpenGL display
modes in Windows Vista.
* Capture: Fixed crash when attempting to use "remove duplicate frames"
feature of screencap driver on a 3D card that didn't support occlusion
* Capture: Fixed crash in screencap driver on 3D cards that don't support
* Capture: Fixed bugs in screencap driver's rescale function.
* Fixed inaccurate length field in WAV header.
* D3D: Fixed memory leak.
* AMD64: MPEG video decoder now works.
Build 24473 (1.6.18, stable): [May 19, 2007]
* Improved compatibility of AVI files written in capture mode or with the
"sector alignment" option. (NOTE: Affected files can be fixed by re-
running them through VirtualDub in Direct mode.)
* Fixed crash when selecting Cancel after removing certain video filters
from the video filter chain.
Just to clarify, with this new API, does this mean file formats such as MP4 and MKV could be added without meaning significant changes to the core of VirtualDub?
Inventive Software - 20 05 07 - 10:31
I own two multimedia players (Unibrain – iZAK, & Pinnacle ShowCenter 200), where I try to reproduce DivX videos captured from PLEXTOR – PX-TV402U hardware encode card, using VirtualDub. I have noticed that VirtualDub produces an OpenDML Multi part AVI file.
Although the files are reproduced very well, when the file enters the second part of the multi part portion, then you can not use the fast-forward or fast-rewind in both multimedia players. It seems that multi part AVI files cause problems in the FR & FF modes. Do we get any benefits from multi part AVI files? Is there a way to avoid producing such a file with VirtualDub?
P. Drosos - 22 05 07 - 02:39
the resize filter crop function acts a bit weird in this version, as far as setting the crops. pulling the crop lines out used to very fluid, now it's jumpy.
bdub - 22 05 07 - 12:39
Three letter: YAY
Michael - 22 05 07 - 20:55
I'd like to know if there is any possibility to make a virtualdub that open and save those new formats know as ISO formats (or raw encoded, for those who don't know this, it's generaly called non-vfw videos). AVI formats do not suport that, but mkv and mp4 does.
I think that put this on virtualdub will be great because those formats can do a lot like real variable frame rate and some other things
id - 23 05 07 - 11:53
The new version (1.6.18) shows a new behaviour that I didn't spot previously. When I run some processing that displays the processed video in the preview pane, and let the tooltip window (the one that describes what [K], [D] etc means) pop up so that it partially overlaps the preview pane, then let it vanish, the preview pane stops updating except for the small part that was overlapped by the tool tip. It can be fixed by switching to another application and back, so it isn't a major problem, it's just strange.
Karel - 25 05 07 - 06:42
I found that the experimental version of VirtualDub displays parts of the status windows incorrectly when the display is set to 120 dpi. The "video", "perf" and "log" property pages are affected. The status windows in the stable version of VirtualDub displays correctly.
derJörg - 25 05 07 - 09:58
Okay, let's see if I can get through these:
Haven't heard anyone try it, but in theory it's possible. I did test the API enough to confirm that it's possible to expose a custom B-frame video format. The input API lets you do almost anything that the internal API can, with the notable exception being that currently you can't open an info dialog.
Yes, if you capture a multi-part file with compression you can end up with segments that aren't valid AVI files by themselves, because they don't start with key frames. This was intentional in order to avoid having another layer of buffering during capture. You can rejoin the segments in VirtualDub and rewrite new segments in Direct mode to produce proper divisions (in that case it does enforce key frame splits), but if your other programs can accept large AVI files, and you're capturing to an NTFS-formatted drive, you're better off just turning off multi-part capture entirely in the Options menu.
1.7.2 moved the display code into a separate thread in order to improve vsync timing, which is critical for stable field (50/60Hz) display. Unfortunately, Windows has some issues with this and the slow update of the cropping dialog is an example. I'm looking for ways to fix this.
The main problems with regard to the new formats are flexibility and codec availability. Flexibility is an issue because the more that a format supports, the harder it is to say "we support format X." I call this the TIFF Problem — TIFF is easy to write because it's infinitely flexible, but it's a PITA to read because it's infinitely flexible. Codecs are a problem because most of the modern formats either require linking against a static lib (to which I have a lot of objections) or using DirectShow (which is very hard to integrate with, particularly if you can't link against the filter static lib).
Are you sure this is new since 1.6.17? I would be very surprised if it was, since there are intentionally VERY few changes in 1.6.18, and none are near the display code. There is a known issue with the display panes partially updating as you describe if Direct3D display is enabled in Options > Preferences > Display, though, which AFAICT is due to a quirk in IDirect3DDevice9::Present() that I haven't been able to work around. Something's funny with the way that Direct3D handles the update region in a child window. The Direct3D option is disabled by default, though.
Haven't tested high DPI in a while, so yeah, I can see that. Dunno why it'd be different between 1.6.18 and 1.7.2, though, since the status window code hasn't changed much.
Phaeron - 27 05 07 - 15:15
Karel's problem exists in 1.6.17 as well
Carter - 29 05 07 - 02:54
Thank you for answering my question. However, are you considering multi-segment capture option? If that is the case, I must tell you that this option is already turned-off in the capture menu of the capture mode. But still, when I run Gspot, a video codec identification utility (a freeware program that identifies which video codec and audio compression method is used on .avi files) it tells me that the avi file is an OpenDML multi-part file (so many frames have been captured in the first part, and the rest in the second part of the avi file). I use PLEXTOR PX-TV402U capture card, which in fact is a hardware DivX encoding card. VirtualDub actually does not perform any further compression, since the avi file is already hardware encoded, but the final avi file produced (DX50 codec) by VirtualDub, according to Gspot utility, is an OpenDML multi-part file, which actually causes problems when try to use fast-forward or fast-rewind functions of the multimedia players.
P.Drosos - 29 05 07 - 03:22
The addition of an input driver api is the best news I've heard regarding VirtualDub in a long time! I only wish I were a good enough programmer to make plugins for it myself.
Now for that DirectShow codec support... (only joking!)
TechMage89 - 30 05 07 - 20:01
As far as I know, multi-segment capture would require a secondary buffer because with codecs such as DivX, you can have as much as 300 frames between each keyframe - or none at all. To make multi-segment capture efficient, you'd need to either:
- force the codec into creating a key frame at the beginning of the new segment, or
- force the split at the latest keyframe once you've reached the required segment size.
As far as I know, the only way to force a codec to create a keyframe is to stop encoding and resume it for the next segment. It is resources consuming, and may introduce frameskips. The second solution would yeld better results and would look like Virtualdub's current behaviour, however it would require a hefty amount of RAM and a nimble hard disk to make it work well.
Well, at least I think so.
Mitch 74 - 01 06 07 - 05:17
thanks yet again for keeping VDub alive !
what would we do without it ...
enkidu - 03 06 07 - 16:24
on 1.7.2, the new brightness/contrast filter works so far as the preview is seen correctly when setting up the filter, but after hitting "ok" the line shows the brightness and contrast has not changed, it's still at "bright +0, cont %100". so it doesn't apply the change.
bdub - 03 06 07 - 22:27
I don't really know if Vdub 1.7.2 has some kind of memory leak, but I just noticed that everytime I use that version+Avisynth long renders just make Vdub exit at around 80% completion.This doesn't happen using version 1.7.1. Pentium 4 HT, onboard Intel Video.
Morsa - 28 06 07 - 19:12
There is something that has been puzzling me in the 1.7 branch. If I run a video file through ver 1.7.2 (or 1.7.0 for that matter) set at "direct stream copy", I end up with a slightly bigger file than the original. With earlier versions I get an exact copy. I'm asking this because all files processed with ver 1.7.x are unplayable with my hardware dvd/xvid/divx player.
JR - 02 07 07 - 02:34