Huffyuv is a very fast, lossless Win32 video codec. "Lossless" means that the output from the decompressor is bit-for-bit identical with the original input to the compressor. "Fast" means a compression throughput of up to 38 megabytes per second on my 416 MHz Celeron.
Huffyuv is intended to replace uncompressed YUV as a video capture format. It is fast enough to compress full-resolution CCIR 601 video (720 x 480 x 30fps) in real time as it's captured on my machine. Huffyuv also supports lossless compression of RGB data, so it can be used for the output of programs like VirtualDub.
Huffyuv is free software. Full C++ source code (~32K) is available, or you can download a pre-built DLL (~15K). Read about what's new in version 2.1.1.
Here are some older versions in case you have problems with version 2.1.1. Note that 1.x versions cannot decompress 2.x files.
If you like Huffyuv, you may also be interested in Avisynth.
Please note that the "free" in "free software" is different from the "free" in "freeware." See What is Free Software? at the FSF's web site for more information.
I am now asking for donations to support my work on Huffyuv and other programs.
You'll need Windows 95, 98, Me, NT, or 2000 to run Huffyuv.
YUY2->RGB colorspace conversion and all of the compression methods except "predict left" require a processor with MMX. All Pentium II, Pentium III, and Athlon processors have MMX. Some original Pentiums have MMX. Pentium Pros do not have MMX.
If you want to use Huffyuv for video capture, your capture card must be able to capture in YUY2, UYVY, or RGB format. Most capture cards support one of these formats, but some, such as the Miro DC10 series, will only capture in Motion JPEG format. If your card only supports Motion JPEG, you can't use Huffyuv for capture (although you can still use it for editing).
YUY2 and UYVY will compress better and more quickly than RGB, so use them rather than RGB if you can. If you have a Matrox card, try "Flying Dutchman's YUY2 enabling utility," available at Desktop Video World.
To install Huffyuv just download the zip file above, uncompress the files to a temporary directory, right-click on the huffyuv.inf file and select "Install." You can delete the files in the temporary directory after the installation completes (which takes only a fraction of a second). There should be no need to reboot.
If you're asked to insert a disk named "Huffyuv AVI lossless video codec," just click OK and select the appropriate directory if necessary.
To uninstall Huffyuv, use Add/Remove Programs in the Control Panel.
How to tell your video capture program to use Huffyuv will depend on the program. In general, you should look for a "Video Format" dialog, and set the format to YUY2 or UYVY. Then you should look for a "Compression" dialog and choose Huffyuv from the list. (Do it in this order, because Huffyuv might not show up in the latter dialog unless you've already set the format in the former.)
Some capturing programs (including ATI's Multimedia Center) do not support external compressors and hence can't be used with Huffyuv. If you're using one of these, I recommend switching to Avery Lee's free, GPL'd VirtualDub. (Even if you're not using one of these you should probably switch anyway, since VirtualDub is a lot better than any bundled capture utility.)
Huffyuv has a configuration dialog which looks like this:
You can get to the dialog by clicking the "Configure" button when you select Huffyuv as your compressor, or via the "Settings" button which is right next to "Remove" in the Multimedia Control Panel.
The options are, as you can see, self-explanatory. However, I'll expand a little on the explanations here.
Here you can trade off compression speed against compression ratio. Generally speaking, the methods lower down on the list will give you better ratios, but this won't necessarily always be true. (In particular, if the benchmarks below are to be believed, "predict left" is better than "predict grad" for 720x480 video.)
Huffyuv ships configured for the highest compression. If you find you're dropping frames, try moving to a lower compression level. With a modern processor and a modern IDE hard drive, you should be able to capture CCIR 601 video at maximal ("predict median") compression without problems.
"Predict median" isn't currently available for RGB compression, not because it's inapplicable there but simply because I haven't implemented it yet.
For RGB input you also have the option of converting to YUY2 and then compressing that. (It's the last option in the drop-down list box.) This is not lossless, but often it doesn't matter because the same conversion is done anyway when you compress to MPEG or Indeo or any other lossy format.
When a program reads a Huffyuv-compressed AVI file, it can either ask Huffyuv to decompress the video to a specific format (like RGB), or it can ask for the "default format." Huffyuv's default format is the format the video was originally compressed from, either YUY2 or RGB.
There are a number of video-processing programs out there which ask the decompressor to produce its default format, but then malfunction when Huffyuv returns YUY2. Huffyuv autodetects several of these programs (Premiere, Ulead Media Studio's Video Editor, AVI2MPG2_VFW, and Bink), and reports RGB instead of YUY2 to them.
The "Always suggest RGB" option makes Huffyuv do this in every application, not just the four mentioned above. If an application needs this option checked, please let me know which one so that I can add it to the list in future versions of Huffyuv, and save everyone some aggravation.
Huffyuv can compress RGBA (RGB with alpha) images along with RGB and YUY2. The problem is that the format that applications like Adobe After Effects use for RGBA happens to be exactly the same as ordinary 32-bit RGB. I'm afraid that if RGBA compression is enabled by default, an innocent application might pass 32-bit RGB to Huffyuv, in which case Huffyuv would waste a bunch of space compressing the unused alpha channel. Most people don't need RGBA compression, so I took the safe route and made it an option.
Some capture drivers are broken and get the field order backwards. If you're stuck with one of these, you can compensate by checking this option--proving once again that two wrongs make a right.
If you check this, Huffyuv will open a console window whenever it's used and display various diagnostic messages. This makes it easier for me to troubleshoot problems via email.
If your system is configured to make it possible, "Email author" will open a blank email message addressed to me, and "Visit home page" will open this page in your browser.
I ran a whole bunch of benchmarks on Huffyuv and the competition, and the results are shown below. Keep in mind that you shouldn't trust a study sponsored by one of its participants; in fact, I don't know how far I'd trust these numbers myself. However, I hope they'll be useful at least for gauging ballpark performance.
Some of the compression methods in the table below are lossy. (A comparison of lossless compression only wouldn't have been very interesting because, as you'll see, Huffyuv's competition in that category is--how do you say--pathetic.) I've indicated lossy compression by writing the compression ratio in italics. I didn't measure the degree of loss, but keep in mind that Huffyuv's only lossy transformation is conversion between RGB and YUY2, while PICVideo does that conversion and also has additional lossy steps.
The tables are sorted in decreasing order of compression ratio, with the exception of the anomalous "Predict gradient" and "Predict left" values for the 720x480 clip. I don't know why these values are reversed, but it makes me wonder if there's a bug in my benchmarking program. (Or, heaven forbid, in Huffyuv.)
The video clip I used was the overture from "Giant Robo," which I chose because it has a lot of variety in a short amount of time. I ran each test five times and chose the best time of the five.
If you want to try one of these codecs, here are their home pages:
|YUY2 COMPRESSION RESULTS||320x240, 30fps||720x480, 30fps|
|Compression method||Compression speed (fps)||Decompression speed (fps)||Compression ratio||Compression speed (fps)||Decompression speed (fps)||Compression ratio|
|PICVideo MJPEG / Q19||170.1||186.6||7.01:1||42.2||44.1||8.14:1|
|Huffyuv / Predict median||183.4||60.1||2.80:1||40.5||13.3||2.77:1|
|Huffyuv / Predict gradient||229.7||94.2||2.66:1||47.6||20.5||2.53:1|
|Huffyuv / Predict left||248.1||99.2||2.33:1||58.0||22.2||2.71:1|
|PICVideo MJPEG / Q20||95.2||100.3||2.28:1||22.3||23.7||2.50:1|
|RGB24 COMPRESSION RESULTS||320x240, 30fps||720x480, 30fps|
|Compression method||Compression speed (fps)||Decompression speed (fps)||Compression ratio||Compression speed (fps)||Decompression speed (fps)||Compression ratio|
|PICVideo MJPEG / Q19, 4:2:2||129.7||163.0||9.79:1||30.8||37.4||10.14:1|
|Huffyuv / -> YUY2, Predict median||82.8||50.4||4.28:1||18.6||4.45:1|
|Huffyuv / -> YUY2, Predict gradient||94.9||72.4||4.07:1||20.4||4.14:1|
|Huffyuv / -> YUY2, Predict left||95.2||75.3||3.56:1||21.0||4.21:1|
|PICVideo MJPEG / Q20, 4:2:2||81.4||92.4||3.29:1||18.9||21.3||3.40:1|
|Huffyuv / Predict gradient||126.3||60.6||2.39:1||27.1||13.4||2.30:1|
|Huffyuv / Predict left||150.4||65.0||2.23:1||34.3||14.5||2.47:1|
|PICVideo lossless JPEG / "pseudo YCbCr"||34.3||43.8||2.10:1||8.2||10.7||2.35:1|
|Huffyuv / Predict left, no decorrelation||166.9||67.7||1.82:1||35.8||15.1||2.10:1|
|PICVideo lossless JPEG / default||50.8||43.1||1.68:1||13.4||10.8||1.98:1|
|AVIzlib / best||5.8||53.8||1.51:1||1.1||12.8||1.69:1|
|AVIzlib / fastest||9.7||51.2||1.47:1||2.4||12.0||1.62:1|
If you capture video in order to edit it and output it back to tape, then Motion JPEG is probably perfectly adequate. It's also a good archival format. However, if you're producing MPEG video (or any lossy format), you should avoid using MJPEG (or any lossy format) in your intermediate files if you can. The reason is that JPEG was designed for viewing, not image processing. JPEG achieves its compression by exploiting known weaknesses in the human perceptual system, but computers don't see images the way people do: an MJPEG clip which looks fine to you may not look so good to an MPEG encoder. As a rule, MPEG encoders are very sensitive to noise, and MJPEG is basically an avoidable source of noise.
None of the bugs in Huffyuv are known to me at this time.
Huffyuv assumes that your video has a horizontal resolution which is a multiple of four. I may remove this limitation in the future.
I used Microsoft's MSYUV sample codec as a skeleton for Huffyuv. The parts that I wrote are copyrighted by me and distributed under the terms of the GNU General Public License, version 2 or later. The parts Microsoft wrote (of which not many are left) are covered by Microsoft's copyright.
Huffyuv 2.0 and 2.1 crashed when used with Premiere because Premiere sometimes calls ICDecompress without first calling ICDecompressBegin, in blatant violation of the spec. (At least, I think it's in violation of the spec; the spec is not wonderfully clear.) Version 2.1.1 now makes the missing call on Premiere's behalf.
If MSP6 tells you that you should "convert your clip to 24-bit," try recompressing it with Huffyuv 2.1.1. Since YUY2 uses 16 bits per pixel, Huffyuv-compressed YUY2 used to use a value of 16 in the biBitCount field. But both Premiere and MSP6 seem to think this has something to do with 16-bit RGB. As of version 2.1.1 Huffyuv puts 24 in this field to make them happy, and stores the actual value elsewhere.
This version has a new .INF file which supports uninstalling, courtesy of Ondrej Zary / Rainbow Software.
Finally, an acknowledgement which I inexcusably forgot to include in the 2.0 and 2.1 release notes. I would like to extend special thanks to Karel Suhajda, whose suggestions and test results played a large role in spurring me to write the improved compression methods in Huffyuv 2.0 (and possibly some further-improved methods yet to come).
It seems as though every major change to Huffyuv is followed within a few days by a bugfix release. Oh well. This version should fix the problems with the "swap fields on decompress" option and with Huffyuv's not appearing as an output format in Premiere and MSP6.
In order to fix the latter problem I had to change the way Huffyuv's compression method is stored, with two user-visible consequences. First, if you used Huffyuv 2.0, your choices of YUV and RGB compression methods will be screwed up when you install 2.1, so please reselect them from the configuration dialog.
Second, I still support 2.0-compressed files in 2.1, but if you have 2.0-compressed files that you want to store permanently, please recompress them with version 2.1. Version 2.0 was only in release for three days, and this way I don't have to keep the ugly 2.0-support code in all future versions of Huffyuv. You can recompress the files by using VirtualDub with the video compression set to Huffyuv, the video dub mode set to "fast recompress," and the audio dub mode set to "direct stream copy." The file size will not change if you use the same compression method as before.
In other news, I also rewrote the YUY2->RGB conversion code in MMX, which makes decompression of compressed YUY2 to RGB (a very common case) significantly faster. (That's why this is version 2.1 and not 2.0.1.) I updated the benchmarks to reflect this. A few 720x480 compression numbers are gone now because they're obsolete and I stupidly deleted the clip I'd used to make them.
There are now multiple selectable compression methods, most of which offer significantly better compression than version 1.x's algorithm, at the cost of some speed. The compression method from version 1.x is no longer available, although version 2.0 can still decompress version 1.x's files. All of the compression methods except for "predict left" require a processor with MMX. (I hope no one is still editing digital video on a pre-MMX machine.)
I may drop support for decompressing Huffyuv 1.x files in the future. Please let me know if this would cause you undue hardship (for example, if you have 1.x files archived on non-rewritable CD-R).
The Huffman tables used for compression are now stored in the AVI file along with the compressed data. This is an important change because it means I can distribute improved Huffman tables in the future without breaking backward compatibility. It also makes it easier for end users to play around with custom Huffman tables. The extra space required in the AVI file is negligible: usually around 150 bytes, and that's per file, not per frame.
All of the core compression and decompression code (except for colorspace conversion) is now written in assembly language. Decompression is still a lot slower than compression, though. The assembly language code has been moved to its own ASM file, so you'll now need MASM or a clone in order to compile Huffyuv. Jon Kirwan has a page explaining how to get MASM for free.
That damned RGB compression bug is finally truly fixed. (I think.)
There's a new "swap fields on decompress" option for people with broken capture drivers.
RGBA compression can now be enabled in any application. Don't enable it unless you plan to use it.
"avi2mpg2_vfw.exe" and "bink.exe" have been added to the list of apps that need RGB output.
are now on the Huffyuv change history page. (Which now actually exists. :-P )
Huffyuv's algorithm is roughly the same as lossless JPEG: it predicts each sample and Huffman-encodes the error. The predictor functions are "left" (predicts the previous sample from the same channel), "gradient" (predicts Left+Above-AboveLeft), and "median" (predicts the median of Left, Above, and the gradient predictor). Channels are compressed separately, but in RGB mode the channels used are actually R-G, G, and B-G. This yields much better compression than R, G, B.
The error signal in each channel is encoded with its own Huffman table. On compression Huffyuv picks appropriate tables from its built-in collection. These tables are then stored in the output file and used when decompressing. This way future versions of Huffyuv can decompress old files without my having to explicitly support old tables. A Huffyuv-savvy application can also specify the Huffman tables to be used for compression instead of accepting the defaults.
Huffyuv's fourcc is HFYU. I haven't registered this, but I don't anticipate any problems.
If you have trouble installing Huffyuv using huffyuv.inf, you can do it manually as follows: First move the huffyuv.dll file to your windows\system directory. Then, if you're running Win95/98, add the line VIDC.HFYU=huffyuv.dll to the [drivers32] section of system.ini. If you're running WinNT/2000, use regedit to add the following values to the registry:
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\MediaResources\icm\VIDC.HFYU] "Description"="Huffyuv lossless codec [HFYU]" "Driver"="huffyuv.dll" "FriendlyName"="Huffyuv lossless codec [HFYU]"