Contents:
Direct YUY2 handling with CinemaCraft Encoder
Field Threshold
Full Size Output Buffer
New Configuration Dialog
Installation

Download huffyuv_ccesp-patch_0.2.2.dll
Download huffyuv_ccesp-patch_0.2.2.source.zip

This is a patched DLL that will work with CinemaCraft Encoder and utilize direct YUY2 bitmap transfer.

New

Benefits

What Is New

Direct YUY2 handling with CinemaCraft Encoder

CCE is expensive and buggy. Period.
To explain the problem with YUY2 and Huffyuv you need some windows-basics:
In Windows, bitmaps are always bottom-up. That means the first line in memory is actually the last line you see on the screen. This is true for the frame handling between video codec and application, too. If an application wants top-down frames it has to use a negative height in the request structure.

Now CCE did two things wrong with Huffyuv: It called a unimplemented function to check if Huffyuv could handle the YUY2 output format. And it gave a negative height in the info structure.

Wanton (thanks guy!) implemented the missing function and did some quick hack to return success on the query, regardless of the wanted output format. This way the whole thing worked with CCE but stopped working with almost any other application.

I used this hack and started to fire up the debugger. After a while it was clear that CCE wanted a bottom-up bitmap - not a top-down bitmap as given in the request info!

I followed the original Huffyuv development scheme and added a 3rd application flag. The "ignore-top-down-request" flag is activated when Huffyuv encounters an application called ccesp.exe or ccespt.exe. If enabled, Huffyuv will convert any negative height to its absolute value and use it througout the whole decompression. Enable the debug output window to see this.

If the "always suggest rgb output format" switch is disabled, Huffyuv and CCE will now use YUY2 encoded frames, thus avoiding the YUY2->RGB conversion in Huffyuv and the opposite RGB->YUY2 step in CCE. This should speedup encoding by 10 percent. Use the logging function of cce to verify this!

Note: CCE is so buggy (or smart?) that it requests YUY2 for the advanced configuration and the cut/add avi dialog, too. Of course it gets what it wants but is then unable to display it. So if you need to use these, please enable the "always suggest rgb output format" checkbox. Of couse you should disable it again when you are going to do your 9-pass encode ;)

UPDATE: You can leave the "always suggest rgb output format" checkbox enabled! If you do, CCE will still use YUY2 for encoding but RGB for all the dialogs, thus making everthing perfect!
(You have to disable YUV decoding in CCE - under Options -> Misc to use RGB instead of YUY2 for encoding with Huffyuv from now on. I wonder who could possibly think about disabling that ;).

Lemme say this again: It does not matter if you enable or disable the "always suggest rgb output format" checkbox in the Huffyuv configuration dialog! Huffyuv and CCE will always use YUY2 for encoding but fall back to RGB for CCE dialogs that display video if the "always rgb output format" checkbox is on!

NOTE:I thought I might add a warning at this point: don't use YUV encoded AVI files in tv color-range and CCE (affected: v2.62, untested: 2.50). Even if you set 0-255 for lumiance level it will squeeze it to 16-235. You will notice that in your final encode anyway. Please use pc color-range in your AVI-file and 16-235 "squeeze" in CCE.

Field Threshold

When I added the YUY2 stuff described above, I discovered a hardcoded threshold that will trigger progressive or field based compression. Something that was not acceptable, as
  • NTSC has a threshold of 240,
  • Progressive Frames have none at all.

    I simply added another entry in huffyu.ini and added a way to edit it in the configuration dialog.
    You can change the value to any number between 1 and 16384.

    If you're processing NTSC video, you should set it to 240, so that material with more than 240 lines will use interlaced compression. For PAL the original value of 288 is right.

    If you are doing progressive material, setting it to 480 or 576 lines will compress even video at this resolution progressive. This should result in better compression.

    Warning: There is only this global setting, Huffyuv does not store this setting in the individual avi-files!
    Decoding a video with 480 lines, compressed interlaced with a 288 threshold after setting a new threshold of 480 lines will fail and vice versa!

    Full Size Output Buffer

    Original Huffyuv has a fatal flaw that might lead to crashes due to buffer overflows.
    I knew this before but I always have been to tired to actually understand the code segment. Until lately when I had a bright day ;)

    See VirtualDub Knowledge Base - PRB: Access violation when capturing with Huffyuv video codec for further information.

    I added another entry to huffyuv.ini and a checkbox in the config dialog.
    If you experience the error described in the VirtualDub Knowledge Base, enable this option.

    The default is enabled (at least until I find out if it impacts performance somehow).

    UPDATE: This is a quote from stuff I found on the net:

    "Oh, BTW, I just uncovered a bug with AVI_IO. It seems that Markus has coded AVI_IO to initially create 0 size files that maximize the amount of free disk space (eg. if you set your AVI_IO max file size to 1GB and you have 30GB of free disk space, 30 zero size files will be created when you start the capture). When he fills up the last file and the capture is still going, he reports a disk full error. However, it looks like he uses the Huffyuv reported buffer size to keep track of the amount he is writing to the file, but he actually only writes the true content of the buffer which is less than the reported size. This became very apparent after our patch since we increased the reported buffer size significantly. My 1GB files were only half full and the capture stopped (with a 'disk full') error when the last file was 'filled'. I've emailed Markus about this and hopefully he will fix it."
    So there might be problems when you capture with avi_io and the switch enabled.
    (As I own a license of that program, I could try it myself, but as usual I am a lazy ass. ;)

    New Configuration Dialog

    With the added setting the old way of using static text to explain it made the dialog a bit too crowded.
    I removed all static text and added tooltips to handle the job. The implementation is not 100 percent correct but hopefully does its job fine.

    Installation

    Copy huffyuv_ccesp-patch_0.2.2.dll over the existing huffyuv.dll in your Win9x\System or WinNT\System32 directory.

    That's it.

    Version 0.2.2, 2001-12-08, doc update: 2002-01-14