Aaron Wiesen
Forum Replies Created
-
Windows 7
Sony Vegas 9.0c (32-bit)
Magic Bullet Looks for Sony Vegas (32-bit plug-in only, and the reason 64-bit Vegas was not being used)Hit this error dozens of times rendering out to every Avi and Quicktime format Vegas could throw out.
Stumbled on this CFF explorer solution and had a working render thirty minutes later.
“Thanks” doesn’t even begin to cover the headache you’ve saved me. Should I ever happen to meet you on the street somewhere, I owe you a drink. ^_^
-
Well, time to smack myself in the head…during reinstallation, I loaded on the 64-bit version of Vegas. Went back, installed the 32-bit version, and everything popped up just fine.
Thanks for the help. I’m surprised about huffyuv being 32-bit only though. Anyone happen to know of a good 64-bit equivalent?
-
The problem could be coming from your project and preview settings. If these don’t match your output settings, then what Vegas thinks it’s going to be rendering and what it actually finishes will look different.
File –> Properties
Create a custom template for the 640 x 480 Apple .mp4 using identical settings (Pixel aspect, frame rate, and the like). Don’t forget to set the “Full-resolution rendering quality” to “Best”, and you might even want to play with toggling on the “Adjust source media to better match project or render settings” option (though to be honest, I’m not sure what this will do).
Also, make sure that you try looking at the “Preview (Full)” and “Best (Full)” previews (drop-down located above the preview window) as opposed to the default “Preview (Auto)” setting, just in case.
If that doesn’t work, you can always try compensating before rendering by adding an effect such as Sony Levels, but I realize that isn’t the ideal solution.
-
I’m sure there are probably better ways of doing this, but one option I like is to use AutoGK. This is a free XviD/DivX utility (found easily via google search).
Simply select your input file, choose an output file location/name, set “step 3” to “Target quality” at “100”, click “Add Job”, and click “Start”.
Without changing any other settings, your file should be significantly compressed with relatively little quality loss. (The most significant difference at “100 target quality” is a loss in pure blacks with some artifacting. My guess is that for webcam footage, this shouldn’t be a big deal.)
For example: I have a fully uncompressed huffyuv .avi file (15 seconds) that takes up 202MB. After using the settings I described, it dropped in filesize to 5.27MB.
Here’s a screenshot of the original:
And the AutoGK render:
These screenshots probably make it look as though no quality was lost at all, but trust me, the blacks have deteriorated (it just happens that the original video was 1080, so it looks great this small).
Best of all, you should then be able to drop the AutoGK file right into Vegas and start editing. (Not sure if you actually need other codecs to do this…I downloaded the k-lite mega codec pack and thus have everything under the sun.)
As for getting back out of Vegas small, it sounds like these are headed for the internet, so “.mp4” is probably your best bet here. (Render as –> Save as type: MainConcept AVC/AAC (*.mp4) –> Template: Apple iPod 640×480 video). This WILL add to any interlacing issues you may have with the footage, but since you said most of it is stationary, I don’t think it’ll be a problem.
Hope this is what you’re looking for,
Aaron
Vegas Pro 9.0c
Intel Core2Quad Q9550 @ 2.83GHz
8.00GB RAM -
I’ll keep GearShift in mind should this happen again (and meanwhile, I’ll continue to try and get the rest of my mac oriented group to make files that ‘play nice’ with windows and vegas). Thanks for all the info guys.
-
I’m inclined to agree with that thought. However, as I wasn’t the one who had control over the initial render settings (and as the person who did no longer has access to the original files), I was hoping for a solution other than, “re-encode en masse.”
Well, I’m already more than halfway through converting the files, so that’ll have to do for now. But I am still curious: should something like this happen again, is there any other way to address this problem?
-
Without being 100% sure, if your optimization concerns come from the fact that ony 4GB of your RAM was being used during the render of your video, chances are you have nothing to worry about.
The process of rendering falls almost exclusively on your processor. RAM is, in fact, not that critical to the process. And I believe the RAM setting you increased was under the category of “Dynamic RAM Preview Max”, a setting that ONLY monitors the amount of RAM usage for playing a real-time preview out of your timeline.
For reference, you do want to keep this at a reasonable amount, or you may experience your computer slowing down if you’re multitasking other programs (or even worse, Vegas itself will start responding poorly). However, with 12GB, I’m guessing you’d be quite safe setting this around half (6144) or even a bit more.
One thing that would be worth checking is the setting underneath this, “Maximum number of rendering threads”. This directly correlates to how many separate things your computer is rendering at once. As I’m assuming you’re using the 64-bit version of Vegas on a 64-bit version of windows (with an i7 920 at that), feel free to push this setting up as high as it can go. (The assumed risk is speed over stability, but I’ve never had a problem with my Core 2 Quad.)
Finally, 8 hours for a 2 hour video isn’t actually all that uncommon when you’re talking about HD footage on consumer level machines. The time factor really tends to rely upon how you’re encoding the finished product (i.e. a relatively uncompressed format has little done to it and will render much faster than, say a heavily compressed two-pass/multi-pass render), and if you’ve added complicated effects/plug-in chains (i.e. if you had crossfades and color correction done to every clip, it would take MUCH longer to finish).
Hopefully this clears a few things up.
-
Perfect, thanks a lot.