question and a problem.

[Overture]

quick question... whats the difference between huff and uncompressed? huff has been giving me problems with my vegas since from what i hear, its because certain vegas'(newer versions, 8 and 9 pro) effects dont get along with certain codecs. so my huff has been giving me pixly crappy garbage(rainbow glitchy) frames when i mask or do opacities and other things. so i was wondering, ill just edit uncompressed from now on and completely ditch huff(ill miss it). but y do people prefer huff to uncompressed so much? does it have to do with colorspace changes or something? idk. just wondering:) or EVEN better IF ANYONE HAS A SOLUTION TO MY GARBAGE DATA PROBLEM THAT WOULD BE KEWL TOO!!! for now im just gonna buy a badass mazaingly awsomeness computer for now and hopefully that might help it a lil. its all i can think of at this point:(

[Kariudo]

huffyuv is a lossless codec, and although the files it gives are large they will be smaller than uncompressed (that is pretty much the reason why people prefer it over uncompressed)

not really sure what causes the garbage data, but if you don't have "always suggest rgb for output" checked in the huffyuv configuration dialog that may be worth a shot (might have to recompress your clips before it makes a difference)

Alternatively, lagarith might be worth a shot (another lossless codec, plays really well with Vegas from what I hear)

getting a better computer probably won't help (there is always a chance that a fresh reinstall could help).

[Overture]

thanx! well i tried "always suggest rgb" since i figured the problem mite be that vegas confuses the rgb/yuy2 properties of huffyuv and suggesting rgb would help but it didnt:( but then again i think i only tried it for my output amv, not on the actual footage yet. ill try it for the footage, maybe that will solve it. and if that doesnt work then ill try lagarith:) i heard lagarith is slower on slower cpu's then huff but im planning on upgrading asap anyways:), but if its good for vegas and solves the garbage data problem then its good enough for me:) thanx for the input!

one last question, is lagarith strictly yv12 or is it rgb also? never used it before so id like to kno. thanx

[Subtle Sorrow]

Sorry to hijack the thread haha. My question is are there any benifits of Lagerith over uncompressed? Except for the file sizes being much bigger for uncompressed?

[Qyot27]

thanx! well i tried "always suggest rgb" since i figured the problem mite be that vegas confuses the rgb/yuy2 properties of huffyuv and suggesting rgb would help but it didnt:( but then again i think i only tried it for my output amv, not on the actual footage yet. ill try it for the footage, maybe that will solve it. and if that doesnt work then ill try lagarith:) i heard lagarith is slower on slower cpu's then huff but im planning on upgrading asap anyways:), but if its good for vegas and solves the garbage data problem then its good enough for me:) thanx for the input!

I don't know Vegas, but is there something analogous to Premiere's 'Recompress' option? It forces Premiere to convert all footage to RGB prior to rendering - some of the problems associated with using YUY2-mode HuffYUV as footage can be resolved that way.

Also, my general recommendation is to always using RGB-mode HuffYUV while editing (although remember, I'm talking from Premiere land; however, I still think it's solid advice no matter what editing program is being used). This is done by choosing Full Processing mode in VirtualDub when you compress with HuffYUV or by having ConvertToRGB24() in your script and using Fast recompress mode (as Fast recompress mode keeps the video in the same colorspace as the input, unless the codec itself forces a conversion).

Lagarith does have the advantage of being multithreaded, so it has the potential to be faster than HuffYUV given you can use that functionality. But it does have its own pitfalls (the error frames it can give out at times are quite nasty, which is why I recommend feeding YV12-mode HuffYUV* to TMPGEnc, XviD, or x264 instead, even if Lagarith worked great in the editor).

*only available through ffdshow's VFW interface (and only decodable by ffdshow, due to non-backwards-compatibility), or other solutions that use ffmpeg directly, such as mencoder. YV12-mode HuffYUV sits between the original HuffYUV and Lagarith in terms of filesize, but it's faster on playback than either of them.

one last question, is lagarith strictly yv12 or is it rgb also? never used it before so id like to kno. thanx

Lagarith can encode in YV12, YUY2, RGB24, and RGBA. If it supports other more esoteric colorspaces they aren't listed in the configuration dialog. Note, however, that RGB (Default) will output whatever the source colorspace is - the other options are to force a standard conversion to YV12, YUY2, or to correctly store input in RGB+alpha.

[Scintilla]

thanx! well i tried "always suggest rgb" since i figured the problem mite be that vegas confuses the rgb/yuy2 properties of huffyuv and suggesting rgb would help but it didnt:( but then again i think i only tried it for my output amv, not on the actual footage yet. ill try it for the footage, maybe that will solve it. and if that doesnt work then ill try lagarith:) i heard lagarith is slower on slower cpu's then huff but im planning on upgrading asap anyways:), but if its good for vegas and solves the garbage data problem then its good enough for me:) thanx for the input!

I don't know Vegas, but is there something analogous to Premiere's 'Recompress' option? It forces Premiere to convert all footage to RGB prior to rendering - some of the problems associated with using YUY2-mode HuffYUV as footage can be resolved that way.

This may be nitpicking, but doesn't it merely force Premiere to render every frame anew instead of using existing preview files where it can?

Also, my general recommendation is to always using RGB-mode HuffYUV while editing (although remember, I'm talking from Premiere land; however, I still think it's solid advice no matter what editing program is being used). This is done by choosing Full Processing mode in VirtualDub when you compress with HuffYUV or by having ConvertToRGB24() in your script and using Fast recompress mode (as Fast recompress mode keeps the video in the same colorspace as the input, unless the codec itself forces a conversion).

Isn't ConvertToRGB32() actually faster? I was always under the impression that the only time you would want to put a script into RGB24 is if you were sending it to TMPGEnc.

[Qyot27]

This may be nitpicking, but doesn't it merely force Premiere to render every frame anew instead of using existing preview files where it can?

From what I'd seen repeated by others, it had more to do with attempting to pass footage that wasn't modified through to export unchanged if the option was unchecked - and if the source colorspace was in YUV, it would cause problems. Using the Recompress option was the suggested remedy. So it might be a combination of the colorspace issues and of opting not to reuse preview files.

Isn't ConvertToRGB32() actually faster? I was always under the impression that the only time you would want to put a script into RGB24 is if you were sending it to TMPGEnc.

I've never really used RGB32 because I didn't want to write excess junk data. That's really the only reason I said I prefer RGB24.

Honestly, I've never experienced TMPGEnc's problems with non-RGB24 data; all the times I ever gave it HuffYUV in YV12 format it encoded fine (not that I even use TMPGEnc anymore except for my own videos - for everything else I've switched to HCenc; the only reason I encode my own stuff with TMPGEnc still is because the MPEG Default matrix in TMPGEnc seems to produce better quality than HCenc's MPEG Default matrix*, given the same settings).

*However, I could use HCenc's FOX1 matrix to produce the same level of quality+higher SSIM value as TMPGEnc's MPEG Default matrix, once again given the same settings.

[Qyot27]

Isn't ConvertToRGB32() actually faster? I was always under the impression that the only time you would want to put a script into RGB24 is if you were sending it to TMPGEnc.

I've never really used RGB32 because I didn't want to write excess junk data. That's really the only reason I said I prefer RGB24.

Fixed. As nice as it is that the quote function is multi-layered now, sometimes it's a real pain.

[Overture]

I don't know Vegas, but is there something analogous to Premiere's 'Recompress' option? It forces Premiere to convert all footage to RGB prior to rendering - some of the problems associated with using YUY2-mode HuffYUV as footage can be resolved that way.

i thought the same thing too actually, but the only option in vegas that was close to that was to just uncheck the no recompression so it wouldnt smart recompress unchanged footage. that way everything should be compressed rgb rite? and as far as ive seen, everything should be being compressed. the most times i have all the garbage data is during certain effects, MOSTLY when i have excessive masking, so either way, the garbage data is present when smart recompression isnt on. but again, this was with footage i didnt use as only rgb huff. ill go try encoding some only RGB HUFFYUV footage now and do some silly masking on it and see how it turns out.

This is done by choosing Full Processing mode in VirtualDub when you compress with HuffYUV or by having ConvertToRGB24() in your script and using Fast recompress mode (as Fast recompress mode keeps the video in the same colorspace as the input, unless the codec itself forces a conversion).

if i just use fast recopress mode with the "always suggest rgb" option on, wont that change my footage to rgb also? ill try it your way for now. thanx:)

[Qyot27]

I don't really know. I always thought the 'Always suggest RGB' option was for the decoding routines - i.e. that HuffYUV would decode to RGB on playback instead of displaying in the original colorspace. But I could be wrong there - I've never used the option because I never had a need to.

Just make sure that the RGB compression method is set to something other than <--- Convert to YUY2. The other three options there (Predict left/no decorr., Predict left, and Predict gradient) only dictate the filesize and how fast it encodes, really - similar to how PNG and FLAC are both always lossless but have 8 or 9 different compression levels that are mainly a trade-off between encoding speed and filesize.