Vegas 4 and "corrupt" Huffyuv AVI

MJPollard wrote on 3/18/2003, 10:19 AM
Every time I attempt to import an AVI file captured with the Huffyuv codec, the data appears corrupted (image is upside down, and blotches of green, red, and blue make up the image), even though the AVI loads and displays fine in every other video editor and player at my disposal. By searching the forum, I have discovered that this is a known issue, and that checking the "always suggest RGB" option in the codec's configuration dialog will allow Vegas 4 to import the video correctly. Being at work makes trying this a bit difficult :-), so I'll do that when I get home.

My question is, will this issue be addressed in a future release of Vegas? When every other app handles the AVI correctly without using this option, and Vegas is the only one that can't, well, one can't help having the opinion that Vegas is the app that needs fixing. (If there are facts that say otherwise, I'm all ears. My thinking is not so rigid that it can't change.) Since this apparently is an issue that dates back to Vegas Video 3, it's strange that it wasn't addressed in Vegas 4. I'm sure that enabling Huffyuv's "always suggest RGB" option will do the trick, but my point is that it shouldn't *have* to be necessary if most other apps handle the AVI without problems. For now, Vegas 4's (seeming) inability to handle Huffyuv AVIs means that this powerful application is gathering bit-dust on my hard drive, and since I shelled out quite a few pennies for Vegas+DVD...

Any thoughts? Opinions? Urges to tell me to go pound salt? :-)

Comments

discdude wrote on 3/18/2003, 12:04 PM
Not only does this bug crap out HuffYUV, but it craps out older versions of DivX and XviD.

From what I understand, Vegas just accepts whatever the default colorspace of the codec is. However, Vegas only understands RGB. So if the codec outputs a YUV as the default colorspace, Vegas can't handle it.

That's why "Always suggest RGB for output" works for HuffYUV. Never versions of XviD work because it returns RGB24 now instead of YUY2. DivX is closed source so I don't know how they fixed the problem in version 5.0.3, but I assume a similar approach was taken.

The only saving grace it that other apps like Adobe Premiere have the same problem. If you look at the source code of HuffYUV, it actually detects Premiere and returns RBG by default. Of course, if I were SF, I'd fix this problem ASAP, because having the same reputation of reliabilty as Premiere is not a good thing.
Spot|DSE wrote on 3/19/2003, 1:55 AM
You are right about why Vegas won't read the Huffy, but why use it anyway? Just to prove yourself the point, render a test pattern 10 times with Huffy, changing each render by just one pixel. Now do the same with Vegas. Huffy's 'lossless' sure as heck isn't.
Try it for yourself before yelling at me. I've done it, time and again. In fact, look around and somewhere you'll find the codec comparison I did last year on SOFO, Canopus, Sony, Matrox, Huffy, and MSDV.
I'd MUCH rather SOFO work on things like XYZ in track motion/Pan-crop, High Def, 24P, surround, AC3, video buses, 10 bit, hardware, 232 control, filters, tools, DVDA, etc that are more relevant to Vegas than working to 'fix' how third party tools, particularly those that are lesser quality, function in Vegas.
Just my nickel's worth.
MJPollard wrote on 3/19/2003, 8:24 AM
Yell at you? Never. Disagree with you? That's another story. :-)

You may have valid points when it comes to the Huffyuv codec, but in all honesty, what does that have to do with it? The fact remains that Vegas 4 does not "play well" with Huffyuv without a kludge, whereas other apps work just fine without needing the kludge. In my opinion, this puts the onus of fixing the problem squarely on the shoulders of Sonic Foundry, and since I'm reasonably certain that I'm far from the only person to use Huffyuv, investing the time and resources needed to fix the problem would seem to be the reasonable thing to do (especially since the fix should be a trivial one). That's *my* nickel's worth. :-)
discdude wrote on 3/19/2003, 2:47 PM
Spot, I have to agree with MJPollard on this.

Things like XYZ in track motion/Pan-crop, High Def, 24P, surround, AC3, video buses, 10 bit, hardware, 232 control, filters, tools, DVDA are all very nice. But they seem like Vegas 5 features, while the HuffYUV "fix" seems like a Vegas 4.0a feature if you know what I mean.

I'll try to dig up that comparison you did between codecs. I find it hard to believe that Huffyuv fails so badly compared to the "Vegas" codec (I'm assuming the DV codec here). The only loss should be some slight color information loss due to the RGB -> YUV conversion. But the Vegas codec should suffer from the same loss (plus those incurred by the DCT alogrithms).
TheHappyFriar wrote on 3/20/2003, 7:16 AM
I use the Huffy codec for capturing on my analog capture card with iuVCR from www.iulabs.com. I have no complaintes. I did have to check the "always output to RGB" box, but I captured a short clip with each setting BEFORE I started capturing the video I needed (read the manual on the wbsite first). I have no reason to uncheck the box eigther as every other program I try to use (Premiere, Fractal Painter) doesn't seem to have a problem with it. I don't use premiere anymore, and my capture card would only capture uncompressed AVI's before I got this codec. Then I hooked up a DVCPro from work and captured on that and the stuff I captured looked as crisp as on the DVCPro tape itself.
Of course I don't do my final renderes to Huffy. Playback is very choppy. That stinks.
DDogg wrote on 3/20/2003, 1:10 PM
@MJPollard, couple of thoughts for you. As said, you just need to setup Huffy correctly to work perfectly with Vegas. That takes two seconds and you will never have another problem. The second question is just a curious one, why involve an intermediate format anyway? Just frameserve with avisynth to get untouched video from your source and say bye, bye to all those huge intermediate files that take quite a lot of TIME to create. Isn't time money? VFAPI wrapped avisynth video is always rgb24 so Vegas loves it, and if you desire, you can do intermediate filtering (and trying different filters on the fly in seconds) without rendering to Huffy. I just don't understand why somebody still uses Huffy. Maybe I am the one that is missing something. It would certainly not be my first time.

If Vegas does ever support the native AVS format of avisynth then sure you would need a "ConvertToRGB24" statement at the end of the script, but until then VFAPI does it automatically for you and Vegas is happy. I frankly hope SoFO NEVER puts in a format check and convert on load routine, which I think is what you are asking for. That would just add more chances for conversion degradation. Convertion of color space is never lossless. Hope you don't mind the comments.

Cheers, DD