!kouze-kun wrote: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
Qyot27 wrote:!kouze-kun wrote: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.
Qyot27 wrote: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).
Scintilla wrote: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?
Qyot27 wrote: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 wrote:Scintilla wrote: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.
Qyot27 wrote: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.
Qyot27 wrote: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).
!kouze-kun wrote:hows premiere? i have pro cs4 on my desktop but never really used it much. think switching over would b a good idea? i use after effects also so the compatibility would b a plus. and hows the whole editing with 23.967 footage thing? i heard theres a problem with that.
Scintilla wrote:It looks like Adobe has finally gotten 23.976fps editing right as of Premiere Pro CS4 (though I never tried CS3). I've seen it in action -- importing, editing, exporting -- without any problems. However, I don't know why they don't have a 24fps "drop-frame" timebase if they're going to allow 23.976fps editing.
Users browsing this forum: No registered users and 2 guests