|
|||||||||
|
Thread Tools | Search this Thread |
November 15th, 2010, 01:40 PM | #1 |
Major Player
Join Date: Mar 2007
Location: Salem, Oregon
Posts: 435
|
Help. Pro 10 (32 bit) + MB Looks + 32-bit Color --> crash
The title pretty much sums up my problem, which I can reproduce reliably on a ~7 minute project. Here's a bullet point synopsis for ease of digestion and diagnosis:
Timeline: photo (PNG) and Cineform AVI (1440 x 1080), Sony color corrector, color curves, a few flash transitions, MB Looks on the avi's, plain vanilla audio wav's. Project: 1440 x 1080 progressive (1.33 pix ratio), 32-bit color (full range). Render: 1920 x 1080 (square pixel) Cineform avi, quality set to "best", interleave every 0.25s. Other tidbits: Pro 10 32-bit (because I want MB Looks), set rendering threads from "4" to "1," RAM preview to "0 MB", did the so-called 2GB hack on the Pro 10 executable using CFF Explorer. System: Win 7 x64 Ultimate, 8GB RAM. Task Manager indicates "0" GB free memory during a render, but ~3-4 GB available throughout. Vegas takes no more than 1.5-2 GB for itself, based upon the display for running processes. Problem: renders hang at a red preview screen less than 100% to completion, with a pop-up box stating that I've run out of memory. Hangs always occur during the video portion of the timeline, i.e., I can get the photo montage of PNG's to render separately just fine. Rendering the video portion of the timeline separately always produces a crash. I think I've read all memory-related threads here and on the Sony forums, so I'm really fresh out of ideas. Is MB Looks and 32-bit color just asking for trouble on ANY system? Before anyone asks, I selected 32-bit color because I have some diffusion effects and I like the optical cross-fade transition properties. So what I am doing wrong? Anything I should be doing differently? TIA, Steve |
November 15th, 2010, 01:46 PM | #2 |
Inner Circle
Join Date: Jun 2005
Location: Cincinnati, OH
Posts: 8,425
|
As a quick fix you might try reducing the ram preview to 0 or at least to a lower amount. And/or you might reducing the number of rendering threads to half. Rendering will obviously take much longer with the latter but at least you should get it done that way.
I've only rendered a 32bit project a couple of times, but recall it was troublesome on one occasion. In my work the 32 bit thing is of limited value, so I don't use those settings myself. If you are re-rendering over an old copy of the rendered project, try deleting the original, clearing from the recycle bin, then render. That has helped me on occasion also. There is no ryhme or reason why it works, but as a result of previous incidents, I am now in the habit of always deleting the original mpeg I rendered when re-rendering just to avoid issues.
__________________
"The horror of what I saw on the timeline cannot be described." |
November 15th, 2010, 02:01 PM | #3 | |||
Major Player
Join Date: Mar 2007
Location: Salem, Oregon
Posts: 435
|
Quote:
Quote:
Quote:
I've experienced this exact problem ever since 8.0, so maybe the things in my title just don't get along with each other for whatever reason. I'm OK with going to 8-bit land for those times when I use MB Looks. Any other ideas, criticisms, slaps upside my head? |
|||
November 15th, 2010, 02:07 PM | #4 |
Inner Circle
Join Date: Jun 2005
Location: Cincinnati, OH
Posts: 8,425
|
Ooops, sorry I missed your settings, my bad. Wow, I would've bet on one of those. Can't think of anything else....man, how frustrating for you.
For lack of any other ideas, have you tried rendering to a completely differenct hard drive, just for kicks?
__________________
"The horror of what I saw on the timeline cannot be described." |
November 15th, 2010, 02:32 PM | #5 |
Regular Crew
Join Date: Jul 2010
Location: London, ON
Posts: 175
|
If you remove MBL and then render, does it work OK? Just trying to narrow down the actual culprit.
If you've not done separate MBL settings per clip, perhaps you could render without (maybe even in 64bit) then re-render with MBL but nothing else going on? Using cineform, there shouldn't be a problem with a second render, no matter how unnecessary it should be. I've not used MBL, but from what I've seen it seems to be something applied to a project as a whole. If this isn't the case, then feel free to ignore me.
__________________
CraigL |
November 15th, 2010, 02:37 PM | #6 | |
Major Player
Join Date: Mar 2007
Location: Salem, Oregon
Posts: 435
|
Quote:
No, I haven't tried rendering to another drive. I will try that, but I can't fathom how that might bear upon Vegas' complaints about memory. My render drive actually is a 3x2TB RAID 5. My system is lean and mean and just screams...well, for my overclocked Q9550. |
|
November 15th, 2010, 02:57 PM | #7 | |
Major Player
Join Date: Mar 2007
Location: Salem, Oregon
Posts: 435
|
Quote:
Just for a sanity check, I can easily disable all event FX (though not MBL only) and render the project in 32 and 64-bit Pro 10 to see what happens. |
|
November 15th, 2010, 04:47 PM | #8 |
Regular Crew
Join Date: Jul 2010
Location: London, ON
Posts: 175
|
Taking one thing off at a time to see when it stopped breaking was exactly what I meant. Unfortunately, if you have MBL on each event, it might be hard.
The only way I can think to easily disable all the MBL for a test render would be to unregister the DLL so Vegas couldn't find it. Or uninstall it temporarily. But I'd make sure I had a back-up copy of the project just in case Vegas actually removes the FXes it can't find from all the places its referenced. And you should be able to put MBL on the track level. I had actually figured most people would simply colour correct on an event-by-event basis to get everything consistent, then apply something like MBL as an output filter to everything. And unfortunately, setting the LMA bit for the >2GB isn't always the answer. Some applications/DLLs might not be Large-Memory Aware and not handle using the full 32bits for memory access. Although it should be rare, it isn't impossible.
__________________
CraigL |
November 15th, 2010, 05:07 PM | #9 |
Regular Crew
Join Date: Feb 2009
Location: Portland OR
Posts: 70
|
Could anyone please explain to me the advantages to selecting 32bit? I heard it will smooth out gradients and other effects, but I honestly couldn't see a difference between 8 and 32. The gradient in Vegas had vertical lines that were very bothersome. Is 32 bit (video levels) better for color correction?
|
November 15th, 2010, 05:30 PM | #10 | |
Regular Crew
Join Date: Jul 2010
Location: London, ON
Posts: 175
|
Quote:
Also, using 32bit full-range gives you the option of using a Gamma of 1.000, which essentially means things will be composited together with a more 'film like' look. However, using a 1.000 gamma introduces other potential issues, so it should be used with caution. Now, you mention the gradient not looking any different. The little blue dot beside the plug-in indicates it does not support/handle floating point data, so it will only ever put out 8bit integer data. At least, on VMS they're not floating point capable, my demo copy of v10 Pro has expired, so I can't verify that this is.
__________________
CraigL |
|
November 15th, 2010, 07:39 PM | #11 |
Trustee
Join Date: Oct 2009
Location: Central Coast Australia
Posts: 1,046
|
Dont know if this helps,
I had one the other day, 90 sec, 1080p Neoscene with MB looks applied to most of the clip. No go, not even with all the fixs and tricks and combinations there of. But, Broke it up into 10sec bits, and got it done, loop region- render to new track etc.... then put it altogether and no-recompress render to one file. Its a massive pain, but it will save your backside if you need to deliver. On another note, Ive been using the trial of NeoHD which comes with First Light, Cineforms own color correcting and Looks software. It is amazing!!!! With this, you work on your clip/s in First Light, you do color correction, apply any looks you want, it comes with lots of great presets, then when you are done you save your project, NOT render, just save like you would a VEG. Then, you open up in Vegas and all your coloring and looks and framing, crops, zooms whatever, are there in Vegas.... NO RENDERING REQUIRED! It applies the info to the meta data of the clip via the codec, so Vegas is just looking at a clip which is (it thinks) in its native format. Realtime playback with all your Looks and coloring done. If you find a bit of the clip that you're not happy with, just open up First Light in another window, make changes, and they are reflected in Vegas instantly. again, no rendering required. This is the way of the future people.
__________________
http://vimeo.com/livewebvideo |
November 15th, 2010, 08:45 PM | #12 | |
Major Player
Join Date: Mar 2007
Location: Salem, Oregon
Posts: 435
|
Quote:
At the moment, I'm re-rendering my problem project. I observed two things. First, when I tried before and experienced crashes, my regularly scheduled backup (Acronis) had been running and sucking up memory and CPU. OK, that was a major no-no, I know-know. Second, within Vegas 32-bit, I shift-selected options to view the internal preferences and changed the amount of memory needed by Vegas from 328 (I think) to 1024 MB. Saved and closed. I read about this on another thread, so I thought I'd give it a shot. Now I'm rendering the project and I see that Vegas is consuming, at the moment, about 2.25 GB RAM, up from <1GB when I started the render. "Free" physical memory, as viewed in Task Manager, has steadily decreased from over 2GB to about 1.1GB. This contrasts with my last attempt when "free" memory was pegged essentially at 0MB. So far, so good. Steve |
|
November 15th, 2010, 09:39 PM | #13 |
Major Player
Join Date: Mar 2007
Location: Salem, Oregon
Posts: 435
|
Problem workaround
Crashed at 85% complete. Vegas reached a memory usage of about 2.5GB, IIRC.
OK, back to 8-bit color land. Because I felt adventurous, I kicked up the rendering threads to 4. The portion of my project with MB Looks rendered blazing fast (by comparison) to completion. I don't think Vegas used more than 1.5GB RAM. Now I'm rendering my ENTIRE project with the same settings. Lesson here? I guess I can't use MB Looks with 32-bit color. Visually, I don't notice much difference, except on the cross-fade transitions that lose the optical film-like characteristics. For that, I have a Luminance plug-in that should work just fine. Steve |
November 16th, 2010, 03:41 AM | #14 | |
Inner Circle
Join Date: May 2005
Location: Windsor, ON Canada
Posts: 2,770
|
Quote:
|
|
November 16th, 2010, 06:48 AM | #15 | |
Major Player
Join Date: Mar 2007
Location: Salem, Oregon
Posts: 435
|
Quote:
BTW, that site mentions compatibility of the FX up through Vegas 7. I had it working in 8.0, but I have yet to try it in Pro 10. Steve |
|
| ||||||
|
|