What is 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.
§ ¶It's good to know I'm not crazy
Going through my weekly backlog of email, I found a crash report on this assembly code:
004e19f3: 0f73d430 psrlq mm4, 30h
004e19f7: 0f7ee0 movd eax, mm4
004e19fa: 0fe504c5d89f5c pmulhw mm0, [eax*8+005c9fd8] <-- FAULT
00
This is the division approximation code for the temporal smoother filter in VirtualDub. It essentially computes:
result.rgb = color.rgb * div_table[sum >> 48];
The crash was an access violation, indicating a bad pointer. Problem number one is that, the way the code's structured, the table index never exceeds 128. Problem number two:
EAX = 00800000
Extracting the top 16 bits of a 64-bit unsigned quantity gave a value bigger than 0x10000. That's... not possible.
I couldn't figure out how this could happen, so I wrote back the user asking if the crash was reproducible. As it turned out, he'd already diagnosed the problem: bad RAM. My guess is that the OS had done a context switch in the middle of these instructions, giving the opportunity for EAX to be dumped to memory and be corrupted. Sometimes the impossible does actually happen... well, at least when hardware failure is involved.
(Read more....)
§ ¶Field order confusion in VirtualDub
Why are the "even field first" and "odd field first" labels in VirtualDub reversed?
Well, actually, they're not, depending on how you label scan lines.
The even field in VirtualDub corresponds to the field that has the upper set of scan lines, and the odd field is the one with the lower set. The reason is that internally VirtualDub numbers scan lines so that the top scan line is scan line 0. That means the even field consists of 0, 2, 4... and the odd field is 1, 3, 5..., meaning that the even field is positioned higher than the odd field. If you consider scan lines to be numbered starting from 1, then this would be backwards and thus confusing. When this issue was raised, I did some searching around and didn't see a clear consensus on scan line numbering, so the plan is to abandon even/odd terminology in UI and just use top/bottom instead across the board.
If you're confused about the field order of a clip, the best way to check it is to use bob deinterlacing to double it to field rate and then check if you get motion juddering. The mode that gives you the smooth output is the correct one. You can do this in VirtualDub via the "bob doubler" filter in 1.8.0+, or the "deinterlace" filter in 1.9.2+. Unfortunately, there are a few places where I've goofed the field order settings at times; the bob doubler had this backwards until 1.8.2, and I've just been informed that it's currently backwards in the new IVTC filter in 1.9.x. I'm working on making sure everything's correct for 1.9.3.
(Read more....)
