View Full Version : Huffyuv Capture Issue
EpheMeroN
14th October 2004, 08:28
I used to use Huffyuv v2.1.1 CCESP Patch v0.2.3 as my codec of choice for my NTSC analog captures using a "Field Threshold" of 480.
As I recently upgraded to Huffyuv v2.1.1 CCESP Patch v0.25, I realized that using a "Field Threshold" of 240 was the proper setting for NTSC material.
That brings up a problem now. All Huffyuv captures I have that were captured w/ the 480 threshold play back garbled, with rainbowy colors and are not visible whatsoever, but the 240 threshold captures playback perfectly.
I know a workaround is to switch the threshold back and forth from 240 to 480 depending on what video I'm working with, but with my situation it is not possible.
I edit videos and have nearly 1,000 clips now that were captured using the Field Thresholds of 240 and 480 mixed. Is there a solution to getting flawless playback from both of these types of captures? Possibly a setting within the new Huffyuv version?
EpheMeroN
18th October 2004, 05:04
Still no ideas? -bump-
Arachnotron
19th October 2004, 11:40
Maybe there is a clever avisynth script to detect this, but if not the only thing I could think of is this (warning: farfetched idea, have no idea if this works)
I assume you know by the file date which file has which setting
- find a util that let's you change the fourcc code in batch mode. Set de fourcc of the 480 treshhold files to a bogus value
- recompile huffyuv after changing the name of the settings ini file in the source
- rename the dll file and install it, but adapt the .inf file to link it to the bogus fourcc code used above and give it a different display name
- change the settings of the bogus huffyuf to the 480 treshold
I *think* after this you should be able to open everything .
bastel
2nd November 2004, 12:08
Originally posted by EpheMeroN
I used to use Huffyuv v2.1.1 CCESP Patch v0.2.3 as my codec of choice for my NTSC analog captures using a "Field Threshold" of 480.
As I recently upgraded to Huffyuv v2.1.1 CCESP Patch v0.25, I realized that using a "Field Threshold" of 240 was the proper setting for NTSC material.
That brings up a problem now. All Huffyuv captures I have that were captured w/ the 480 threshold play back garbled, with rainbowy colors and are not visible whatsoever, but the 240 threshold captures playback perfectly.
I know a workaround is to switch the threshold back and forth from 240 to 480 depending on what video I'm working with, but with my situation it is not possible.
I edit videos and have nearly 1,000 clips now that were captured using the Field Thresholds of 240 and 480 mixed. Is there a solution to getting flawless playback from both of these types of captures? Possibly a setting within the new Huffyuv version?
I can write a tool that adds the flags to the file, it's just a byte set in the header. Yeah I could do that. I just need constant nagging to move my lazy a**. Even tho it's kind of easy to do.
Of course I could look into the idea of an autodetection for files that miss the flag. the wrong setting for those results in quite visible distortion, maybe it's easily detectable... would make a nice extension.
bas
ps: i seldomly go into doom9 forums and even then i don't check all threads (i simply search for huffyuv and look what results i get).
If there are requests and other important stuff, just priv msg me, ok?
FlimsyFeet
2nd November 2004, 20:58
What's the difference between these "CCESP patch versions"?
The version I have is Huffyuv v2.1.1 CCESP Patch v0.2.2, do I need to update?
bastel
3rd November 2004, 10:20
Originally posted by FlimsyFeet
What's the difference between these "CCESP patch versions"?
The version I have is Huffyuv v2.1.1 CCESP Patch v0.2.2, do I need to update?
Yes you need to do. v0.2.5 of the patch.
Hmm some version of the patch come with the html describing the changes (i.e. the html of the hidden huffyuv ccesp patch webpage ;)
So lets copy&paste:
-------------------------
- I removed version 0.2.4 because it introduced a interlaced handling different than version 2.2.0 (the new huffyuv) does it. Even though version 2.2.0 seems to be buggy and I did my interlaced handling first, I changed it because how I did it in 0.2.4 was a bit braindead (the garbage argument). Please use version 0.2.5 instead. Thank you.
- Version 0.2.4 finally stores if the file has been created interlaced or not. Due to rare circumstances with garbage bytes where the flag is stored in files created with versions 0.2.2 and below, there is also a switch to ignore the flag.
- Cleared up some confusion about the pc and tv color range in Huffyu and CCE. See some paragraph below.
- Version 0.2.3 changes the initialization of the BITMAPINFOHEADER structure, removing random bytes that were otherwise left depending on the application you are using. Old versions copied the input structure to the output one before setting certain values. This version sets all bytes in the structure to zero before it sets those values. The benefit of this is that merging should now work in virtualdub regardless of the avi's origin. See this thread for the the problems you might have without this version. Since the new version is copying values and discards all those that were troublesome, it might break compatibility in some rare cases (I doubt it but hey...), so the old 0.2.2 will stay online for now.
- Version 0.2.2 allows you to set the output buffer size. Might fix crashing. See VirtualDub Knowledge Base - PRB: Access violation when capturing with Huffyuv video codec.
bastel
4th November 2004, 00:34
Originally posted by bastel
I can write a tool that adds the flags to the file, it's just a byte set in the header. Yeah I could do that. I just need constant nagging to move my lazy a**. Even tho it's kind of easy to do.
If you need a fix real quick, then open the avi file in question with a hex editor and modify the byte at offset 0xd6.
The byte in front must either be 0x18, 0x10 or 0x20.
And a few bytes up (at 0xbc - 0xbf) should be the 4cc code "HYUV".
If yes, then set 0xd6 to 0x20 for a progressive file, 0x10 for interlaced. Actually only change the upper nibble, the lower 4 bits are reserved (but should be 0 anyway)
That's basically the information necessary to write a small patch tool that even does some checking before patching.
A more sophisticated version could clean up the junk that 0.2.2 and below don't clear, which disables vdub from joining those files even if it is possible to do so.
good night. bas.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.