VirtualDub

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.

I basically started VirtualDub in college to do some quick capture-and-encoding that I wanted done; from there it's basically grown into a more general utility that can trim and clean up video before exporting to tape or processing with another program. I released it on the web and others found it useful, so I've been tinkering around with its code ever since. If you have the time, please download and enjoy.

§ ¶Altirra 1.1 released

I finally have some time lately to flush out some of the stuff I've had going on lately, and since all my latest VirtualDub work went out with 1.9.2, it's time for something else. A while ago I posted the first version of Altirra, my Atari 8-bit computer emulator. Due to some encouragement from some friendly people on AtariAge, I went back and fixed a whole bunch of emulation bugs in the emulator, and the result is version 1.1:

http://www.virtualdub.org/beta/Altirra-1.1.zip
http://www.virtualdub.org/beta/Altirra-1.1-src.zip

As proof of its worthiness of release, I present my in-emulator triumph over evil in The Last Starfighter:

The primary improvements are a lot of undocumented features implemented in GTIA, a couple of fixes to POKEY, and several tricky but important timing fixes in ANTIC. The display code now also does aspect ratio locking (a feature that I need to integrate back to VirtualDub).

Working on an emulator for an old computer system is basically working to an inflexible, and unfortunately incomplete, spec. I have access to the official Atari Hardware and OS reference manuals, which describe all hardware registers and kernel calls in the system. You can write an emulator that exactly conforms to those specifications and the result is that you will be able to run maybe half of the software that was released. The other half won't work because it depends on undocumented behavior such as when the display list interrupt bit resets (scan line 248) and the exact number of clock cycles it takes to enter the vertical blank routine (47-53 for XL OS). The spec is unrelenting and frozen -- unless you have a time machine, there is no way to change it. Therefore, you will implement exactly what the hardware does, period, and anything less is a bug. It gives you some appreciation for when you do have leeway to get specs changed to ease implementation.

There is one feature that I wanted to get into this version that I couldn't, which is artifacting. Artifacting is a phenomenon of composite video where unfiltered high frequencies in luminance are misinterpreted by the TV as colors. In NTSC Ataris, the high-resolution modes output pixels at a rate exactly twice the color subcarrier, which means that alternating luminance values produce colors instead of patterns. NTSC is designed with frequency interleaving to mitigate this somewhat, but the Atari produces non-interlaced video with a constant color subcarrier phase, defeating this. The way I tried to simulate this was brute-force, simply converting the video screen to a virtual 13.5MHz (4*Fsc) signal and then separating it out to Y/I/Q with FIR low pass and high pass filters. Well, the result kind of sucked, with an exceptionally blurry luma output and visible rippling in artifacted areas. The result on a real Atari with my LCD monitor's composite input looks significantly better, which leads me to believe there's something I'm missing, possibly a non-linear separation algorithm.

Changelist after the jump.

(Read more....)

No comments | May 12, 2009 at 21:14 | default

§ ¶UI rendering in Windows 7

I spent some time downloading and Windows 7 RC today. I installed the beta a while ago, but didn't do too much with it since I had only installed it on a VM, which invalidated any comparisons in graphics performance and prevented any access to 3D acceleration. Well, this time I took advantage of the uber-cool install to VHD feature to install and run Windows 7 without having to repartition my hard drive, so that I could run it directly on real hardware. I get the feeling that I'm pretty far behind in noticing some of the improvements in Windows 7, but hey... better late than never.

Now, to understand where I'm coming from, I've had both 32-bit XP and 64-bit Vista installed on dual-boot for some time, but I almost never boot into Vista 64 unless I need to test some 64-bit code. The reason is that Vista 64 runs like complete crap. CPU and memory aren't a problem, because I have a 2.5GHz Core 2 and 2GB of RAM. The problem is my somewhat mediocre NVIDIA Quadro NVS 140M, which is 8400GS based, compounded by my 1920x1200 display. It runs like a slug with Aero Glass enabled, and is still laggy and runs at low frame rates with it off. The result is that Visual Studio 2005 is noticeably more sluggish on Vista 64 than in XP, and thus I spend all my time in XP instead.

The main reason that Vista performs worse is that, despite all the hype about the new desktop hardware acceleration, the WDDM 1.0 display driver model introduced in Vista actually forces all GDI and DirectDraw rendering to occur in software on the CPU. Since most UI in Windows is based off one of those two APIs -- including Win32 UI and .NET's GDI+ based UI -- this results in significantly slower UI performance. Well, unfortunately, it doesn't seem that Windows 7 runs Aero Glass any better, and in fact on this system VirtualDub has trouble breaking around 25 fps due to the low desktop composition frame rate. It runs noticeably better with composition disabled however: stretching video to 1920x1200 through DirectDraw now takes about 0-2% of the CPU instead of 6-10%.

The reason for this, as it turns out, is that the new WDDM 1.1 DDI in Windows 7 reintroduces support for adds several GDI optimizations, including reducing lock contention and reintroducing some hardware acceleration. The DDI documentation for GDI hardware acceleration reveals seven primitive operations that are supported for acceleration: alpha blend, BitBlt, ClearType blend (text rendering), solid color rect fill, StretchBlt, and transparent blit (color key). That covers a lot, but the one notable omission is line draw. In theory it would be possible to accelerate those by rasterizing the line to spans, and it'd be trivial to do so for the common cases of horizontal and vertical lines, but I don't know if Windows 7 actually does this. In any case, reintroduction of basic GDI acceleration is welcome. This also appears to extend to DirectDraw blits, although those are still not bilinearly filtered as they usually are with XP drivers.

Another interesting change is that WDDM 1.1 reintroduces support for DirectDraw hardware video overlays. In Vista, attempting to use a hardware overlay either resulted in the overlay calls silently failing or desktop composition being forced off. It appears that overlays work again on Windows 7. You can't test this with current versions of VirtualDub since I added code to force them off on Windows Vista or later due to the poor OS behavior, but you can see them in action if you get an old version of VirtualDub like 1.6.0. They don't work quite like on XP, though, because for some reason they don't update except when a GDI repaint occurs. I'm not sure if it's worth investigating this since any video card that supports WDDM 1.1 supports DirectX 9, and at that point it's better just to use Direct3D.

I have noticed a couple of occasional weirdnesses in the USER layer in Windows 7 that I haven't pinned down yet. In the beta at high DPI, one specific item in VirtualDub's display pane context menu bizarrely shows up in a different font. Altirra also occasionally shows a vertically displaced window caption in one of its tool windows after a full-screen mode switch. I suppose it's possible that these are video driver related, as the WDDM 1.1 drivers are still very new.

In any case, since I don't intend to buy a new computer any time soon, it's looking like I might be leapfrogging Vista to Windows 7 as my main OS, now that some of the 2D performance gaffes are getting addressed.

(Read more....)