Tearing is a display artifact that occurs when images are presented to the screen without regard for the current status of the output circuitry. It occurs because pixels are sent to the screen gradually in book order rather than instantaneously. What happens is that the output DAC reads across the same area of the screen that is bring written to, so the monitor ends up showing a half-updated image. The result is a momentary frame that has half of an old frame and half of a new one, with a clean horizontal split across (the tear). Because the location of the tear varies according to timing, it usually jumps all over the place, which can be distracting.
I don't advertise VirtualDub as a player, but I've had several requests to add an option to fix this problem lately, so I decided to look into it. Tearing can be quite noticeable if you're previewing nearly full-screen 24 fps video. The most straightforward way to solve this problem is by synchronizing updates to the output scan, a technique known as vertical sync (vsync). This forces the tear to always occur off-screen so that it is not noticeable. Well, after doing some preliminary investigation, it's doable, but not as easy as I had hoped. As usual, DirectX is part of the reason why.(Read more....)
I see that one of the append dialogs from VirtualDub has been featured in The Daily WTF. Personally, I consider the presentation of this dialog as a WTF to be a grave disservice, since there are so many better WTFs in the program that could have been used. I feel insulted. I suppose I should explain the reasoning behind this dialog, though, and why it pops up annoyingly when it does.
To clear up a misconception: one of the comments noted that the error was caused by comparison in floating-point. This actually isn't the case, and if it were, it would actually make the dialog appear less frequently due to roundoff. (Remember, floating-point can be inaccurate, but consistently so.) Frame rates in AVI are not stored as floating-point or fixed-point, but in rational form as the ratio of two 32-bit unsigned numbers. This means that the sample rates of two streams can differ by up to the 10th significant digit, and more importantly, two streams can have different values in the header that correspond to the exact same frame rate. The submitter didn't indicate what version he was using, but versions prior to 1.4 have a bug in that they don't do a proper fraction check (they check numerator and denominator independently); this can cause error messages like the submitted, where the two frame rates are the same. One way to cause this is to process one of the segments with a version of VirtualDub that normalizes the frame rate fraction to lowest common denominator — the starting version of which I forget — so make sure you're using the newer versions of VirtualDub across the board when possible, to use the more liberal check.
And, yes, admittedly the error is not very informational, and I should look into clarifying it. However, it exists because of a sticky limitation with the way append is implemented, and I won't apologize for making an overly technical error message instead of one that says "I can't append."(Read more....)
Before I fall into the typical blog trap of talking about my random ire of the day (night?), I should say something related to VirtualDub. Generally, hard drive partitions that are formatted with NTFS have slightly slower write performance than partitions formatted with the FAT32 file system. If you are doing video capture, or similar manipulation of video files that requires high disk bandwidth, consider using FAT32 instead of NTFS, especially for temporary files for which it isn't a big deal if they are lost in a system failure (if your video capture is interrupted, you're not likely to need the partial file anyway).
Okay, now for ire.
It's fairly well known that the NT file system (NTFS) is very bad at avoiding fragmentation, partly due to its allocation strategy of intentionally placing tiny gaps between files — which is good if those files expand, but bad if they don't. Today, I see this in a fragmentation analysis report of my hard drive:
Fragments File Size Name 111 444KB WINDOWS\$NtServicePackUninstall$
The cluster size of the hard drive partition is 4K. This means that NTFS has successfully managed to create a huge directory in which not a single pair of clusters are sequential. I used to think that the Amiga standard file system was bad, but this takes the cake.(Read more....)
As I said in the previous blog entry, one of the new features in 1.6.11 is the ability to bind custom vertex and pixel shaders to a video display pane. GPUs are great for massive image manipulation (unless you happen to have one with "Extreme" in the name), and thus it's only natural that they'd be useful for video. More importantly, though, it is easier to quickly write an optimized shader than to write an optimized software filter. This makes GPU shaders attractive also for rapid prototyping, which I hope is what the new shader support in 1.6.11 will enable.
To activate custom video shader mode, select Options > Preferences from the menu, jump to Display, then enable DirectX, Direct3D, and effect support. Then enter the .fx filename — relative paths are from the program directory, absolute paths are used directly. Dismiss the dialog, then deselect and reselect VirtualDub for the change to take effect.(Read more....)
It looks like there are currently some issues with the mirror replication system on SourceForge which is making VirtualDub 1.6.11 a bit difficult to download at the moment. Looks like I'm not the only one affected, so just sit tight for a moment and give the SourceForge staff a day or so to iron things out. In the meantime, if you're really itching to get the new release, Henrik pointed out in the comments for the last entry that you can go through the 1.6.10 links:
...and after you've chosen a mirror, change the filename in the URL from 1.6.10 to 1.6.11 to access the new build.(Read more....)
VirtualDub 1.6.11 is out in the wild, and captures a couple of months of bug fixes. The major change in this version is that, as I noted last time, I've spent a good deal of time expanding the help file. In particular, a lot more of the new 1.6.x capture system is now documented. There are still some holes here and there, but I'm beginning to think that I should do another experimental drive in the 1.6.x series and revisit the capture system, especially since 1.7.x is a ways off anyway (there are some issues with latency that I need to work out).
I did sneak a new feature into this build, though: support for custom video display shaders. This doesn't add any new processing capabilities, but it does allow arbitrary vertex and pixel shaders to be used to control the video display panes. In particular, it permits experimentation with filtering techniques beyond the usual point/bilinear/bicubic set, if you have a powerful enough video card and are sufficiently adept with Direct3D shaders. The file format is the standard Microsoft effect file format (.fx), and the surrounding setup is documented in the help file.
I intend to go into more detail on issues with capture and video shaders, but there's too much to go into here, so those will have to be separate blog entries. In the meantime, click Read More... if you want to see the changelog.(Read more....)