¶Beware of Huffyuv's "Predict median" Mode
Ben Rudiak-Gould's Huffyuv is a fairly common lossless video codec on Windows. Its main advantages are fast compression speeds, lossless support for both YCbCr and RGB video, and of course, it's free. Because it's lossless, the compression ratios that can be obtained are limited, but generally you can get around 1.6:1 to 2.2:1 on average, and that's a big help when you can use it during real-time video capture.
There is, however, a bear trap in its settings.
If you bring up the configuration dialog for the video codec (Video > Compression > Huffyuv, Configure in VirtualDub), there are two combo boxes at the top of the dialog which set the prediction modes for YUY2 and RGB video. The prediction mode changes the way that Huffyuv attempts to detect patterns in the video and thus the speed and effectiveness of the compression. Most of the modes are fast for both compression and decompression, but you should be aware of the Predict Median mode on the YUY2 side. I've made the mistake of picking this mode before, and while it's fast for compression, it's unexpectedly slow for decompression. The reason it's so slow is that the Predict Median predictor goes through a non-vectorized scalar code path on the decompression side and is thus very slow. This won't affect your video, of course, but if this turns out to be too slow for your post-processing work, you can always recompress it again with another Huffyuv predictor thanks to the lossless nature of the codec.
I should note that I only have experience with the last official version of Huffyuv, 2.1.1. There have been some unofficial updates to Huffyuv to add workarounds for compatibility issues with applications and to add YV12 support, but I don't know if those have any speed improvements to the predictor. I looked into trying to speed up the median predictor in it at one point but was unable to do so, and I'm guessing that it's a hard problem because it shares a lot in common with the Paeth predictor in PNG, which is also inherently serial and hard to parallelize. I also looked into rewriting the bitstream parser into C++, but I tried using compiler intrinsics and of course ended up hanging both the VC8 and VC9 compilers.
The MultimediaWiki has a description of the Huffyuv compression algorithm: http://wiki.multimedia.cx/index.php?title=HuffYUV. Unfortunately, it seems to be missing a few critical details, most notably the exact nature of the VLC bitstream: 32-bit words in little endian format, codewords placed starting from the MSB, Huffman codes allocated longest codeword first, and with a maximum codeword length of 31 bits.
Incidentally, just like with Avisynth, I've noticed that people like to butcher the name of this codec for some reason. It's Huffyuv, first letter capitalized, rest in lowercase. It's been that way since 1.0.0 and appears that way in the documentation, dialogs, and source code. Yet, for some reason, people keep misnaming this codec HuffYUV.