DV Info Net

DV Info Net (https://www.dvinfo.net/forum/)
-   What Happens in Vegas... (https://www.dvinfo.net/forum/what-happens-vegas/)
-   -   Help. Pro 10 (32 bit) + MB Looks + 32-bit Color --> crash (https://www.dvinfo.net/forum/what-happens-vegas/487532-help-pro-10-32-bit-mb-looks-32-bit-color-crash.html)

Steven Reid November 15th, 2010 01:40 PM

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

Jeff Harper November 15th, 2010 01:46 PM

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.

Steven Reid November 15th, 2010 02:01 PM

Quote:

Originally Posted by Jeff Harper (Post 1588289)
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.

Well, Jeff, thanks for the quick reply. My RAM preview already is at 0 and rendering threads set to 1 as I stated. No joy.

Quote:

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.
I've generally had success with 8-bit projects. I'm not doing a lot of heavy compositing, where I understand that 32-bit color can help, but in those instances where I have cool diffusion or light effects, 8-bit looks not quite right. <sigh>

Quote:

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.
That is strange. I've tried both ways with the same result: render fresh and re-render over (incomplete) original.

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?

Jeff Harper November 15th, 2010 02:07 PM

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?

Craig Longman November 15th, 2010 02:32 PM

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.

Steven Reid November 15th, 2010 02:37 PM

Quote:

Originally Posted by Jeff Harper (Post 1588299)
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?

Thanks for chiming in again! To continue our conversation: Yeah, it's frustrating, even for my typical project lengths of 10-15 min. I just have to wonder what folks do for long form (1-2h) projects. Yikes! I even went so far as to look at NewBlue FX, but, man, after shelling out for MB Looks and then having to buy a boatload of NB stuff to get even remotely close to what I have with MB Looks...more yike$.

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.

Steven Reid November 15th, 2010 02:57 PM

Quote:

Originally Posted by Craig Longman (Post 1588309)
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.

Good idea, if I understand you to mean "change just one variable at a time and see what happens." I applied MBL event-by-event, as I tweaked the settings to taste based upon shooting conditions for each event, but I think one can apply MBL at track level (and perhaps others, too). Unfortunately, I don't think I have an easy way of simply toggling one FX for the entire project with a single click. If I misunderstood you, however, please elaborate.

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.

Craig Longman November 15th, 2010 04:47 PM

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.

Dylan Morgan November 15th, 2010 05:07 PM

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?

Craig Longman November 15th, 2010 05:30 PM

Quote:

Originally Posted by Dylan Morgan (Post 1588363)
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?

32 bit floating point numbers are (relatively) huge. The can store 30 or so digits of precision. So for each colour of each pixel, 30 digits are being used for all the calculations, as opposed to 8bit integer mode when only (at most) 0-255 are used to track each colour of each pixel. This means that the FXes can not only use a Red as 64, but 64.25 or 64.98, or 64.01, and anything inbetween. It just allows much less information to be lost during processing where potentially many calculations are applied to each pixel.

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.

Gerald Webb November 15th, 2010 07:39 PM

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.

Steven Reid November 15th, 2010 08:45 PM

Quote:

Originally Posted by Gerald Webb (Post 1588397)
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.

Since I'm a lowly hobbyist, Gerald, I had only glanced at First Light as an expensive frivolity for me (but useful for a serious videographer), but I'm aware that many others, like you, absolutely rave about it. Now I can begin to see why.

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

Steven Reid November 15th, 2010 09:39 PM

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

Mike Kujbida November 16th, 2010 03:41 AM

Quote:

Originally Posted by Steven Reid (Post 1588414)
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.

Do you mean the SMLuminance plug-in from http://www.endor.demon.co.uk/ or a different one?

Steven Reid November 16th, 2010 06:48 AM

Quote:

Originally Posted by Mike Kujbida (Post 1588479)
Do you mean the SMLuminance plug-in from http://www.endor.demon.co.uk/ or a different one?

Yes, that is exactly the one I had in mind, even though when I posted I couldn't remember the full name. Thanks for the link!

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


All times are GMT -6. The time now is 01:54 AM.

DV Info Net -- Real Names, Real People, Real Info!
1998-2024 The Digital Video Information Network