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.
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.
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.
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.)
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.
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.
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.
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 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).
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.
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.
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]"