Dynamic RAM Preview max

michael-wildermuth wrote on 7/30/2014, 2:43 PM

I am posting this in case the information may prove useful to someone else.

I upgraded from Vegas Pro 11 to Vegas Pro 13 awhile back. I am pleased I did. I was surprised at how many little things were improved that have allowed me to work more efficiently. In addition, stability seems to have improved on my system.

Last week, after the notification of the release of Build 373 for Vegas Pro 13, I downloaded and upgraded. I had been working with NewBlueFX on bugs within Titler Pro 3.0 and received notification of a new release from them as well and so upgraded from Build 140610 to 140718 of Titler Pro 3.0

Last weekend, I ran several renders and began having crashes in rendering for the first time - an issue which greatly concerned me.

I did a system restore to set things back and tested a render, which completed successfully. I suspected Vegas Pro Build 373 might be the problem. I then reinstalled Titler Pro 3.0 Build 140718 and promptly obtained a crash which led me to suspect that Titler Pro 3.0 was the culprit. I replaced it with Build 140610 of Titler Pro 3.0 and got another crash!

I restored the system again and retested and this time got a crash again during a render even though I was back on Vegas Pro Build 310! I then noticed that I had changed “Dynamic Ram Preview max” to 3072 during an editing session and had failed to reset it to zero before performing renders as has been my habit since reading advice to do so in this forum quite some time ago.

I set “Dynamic Ram Preview max” to zero and my renders have all completed without a hitch.

I am currently testing with “Dynamic Ram Preview max” set to 200.

I will install Titler Pro 3.0 Build 140718 and test that and then go on to Vegas Pro Build 373 in separate steps and can report the results if anyone is interested.

I run with GPU Acceleration of video processing set to my graphics card.

I thought this information might help someone.

Comments

TeetimeNC wrote on 7/30/2014, 4:18 PM

It is surprising how poorly Vegas handles RAM preview situations like this. I think this, in general, has been a long running issue with Vegas.

/jerry

Lovelight wrote on 7/30/2014, 7:19 PM

I hear that and to top it all off access to this menu is buried making it so annoying to use. The cut to overlap conversion should be customizable for faster access, too.

Jerry K wrote on 7/30/2014, 10:14 PM

Forgetting to turn ram down or off before rendering well let's not forget we also need to turn off studio RGB to computer RGB before rendering and yes this is a longtime problem that needs to be addressed by Sony.

Jerry K

Marc S wrote on 7/30/2014, 10:48 PM

So does dynamic ram offer any benefits other than when doing a Shift+B?

Rob Franks wrote on 7/30/2014, 10:57 PM

No.

OldSmoke wrote on 7/30/2014, 11:10 PM

yes & no!

The thing is that it very much seems to depend on the system you have and when I say system I mean not only the CPU and GPU but last the RAM modules, motherboard and many more components. On my system, the default 200MB is the sweet spot, any more or less and the system performance is down and when I say down I mean preview and render performance. To say it only effects Shift-B is wrong.

Marc S wrote on 7/30/2014, 11:31 PM

Strange that a setting for a feature many of us probably do not use affects the system so much.

TeetimeNC wrote on 7/31/2014, 9:36 AM

This is just a semi-educated guess but it seems to me SCS needs to really take a critical look at the Vegas internal resource management service. There are too many situations where it doesn't gracefully handle dynamic resource allocation.

/jerry

Laurence wrote on 7/31/2014, 9:58 AM

Up to Vegas 10, preview RAM caches of several gigabytes were fine. I know this because I have 16GB and used 2GB for shift-B previews all the time. In Vegas 11, this was broken. I didn't realize this and left my usual 2GB preview in place. I believe that is why I never could get even through a single project in V11. It was just crazy unstable. When I upgraded to V12, I was getting the same sort of constant crashing until one day I read a post where one of us described how setting the preview RAM to zero improved his stability. I set mine to zero and it did improve my stability dramatically. Vegas would still crash multiple times each day, but that was far better than the crash every few seconds I would get with the preview RAM enabled. I was lucky to get through a stretch of a minute at a time. I suspect that had I known to set my preview memory to zero in V11, that that would have helped there as well, but V11 had come and gone before I realized this.

V13 is great. Crashes are rare for me and I can once again set aside preview RAM without it affecting stability. It really is a great feature and I'm glad to be able to use it again.

michael-wildermuth wrote on 7/31/2014, 10:02 AM

"Adjust levels from studio RGB to computer RGB" has been turned on during all my testing. I have never turned it off. In addition, the "Video Preview" and "Trimmer" windows have been shut down during all my tests. I am guessing that if your "Video Preview" window is shut down, "Adjust levels from studio RGB to computer RGB" becomes irrelevant.

Also, the test on the same project with "Dynamic RAM Preview max (MB):" set to 200 failed. I reset the value to zero, reran, and it finished successfully.

I have almost always set "Dynamic RAM Preview max (MB):" to zero after reading in this forum that it would speed rendering. During my troubles, I somehow overlooked this. I have wondered, however, why the software couldn't or shouldn't be modified to ignore this setting, effectively setting it to zero, during renders because I assume that setting aside memory during renders for a function that is not used during renders is counterproductive to producing renders swiftly and reliably. Just my musings...

I will be reinstalling the new Vegas and NewBlueFX Titler Pro 3.0 builds and continuing to test renders.

I take it that I do _not_ need to uninstall Vegas Pro 13 Build 310 before installing Build 373. Is that correct?

NormanPCN wrote on 7/31/2014, 11:15 AM

So does dynamic ram offer any benefits other than when doing a Shift+B?

Vegas caches frames during playback and uses unused preview RAM for this. So it you loop, you get the equivalent of a Shift+B. The size of the loop region where this works is of course dependent on the preview RAM size. Also, scrubbing back and forth Vegas can uses these cached frames.

Laurence wrote on 7/31/2014, 2:36 PM

I just bumped up from 1GB to 2GB on my preview file and it seems to be working fine with Vegas 13. With Vegas 11 or 12, you are best off setting the preview RAM to zero. This feature was broken in those versions.

Rob Franks wrote on 7/31/2014, 4:48 PM

"Vegas caches frames during playback and uses unused preview RAM for this."

I've tested that theory and I don't believe it's true.

While it is true Vegas caches frames during a loop, it doesn't change when you set preview ram to 0. At least not for me. Normal time line playback functions exactly the same for me regardless of the Preview ram setting (that includes setting it at 0)

(Tested both with GPU on and off)

Rob Franks wrote on 7/31/2014, 4:50 PM

"I just bumped up from 1GB to 2GB on my preview file and it seems to be working fine with Vegas 13. With Vegas 11 or 12, you are best off setting the preview RAM to zero. This feature was broken in those versions. "

Since the creation of vegas 64, I've set all my vegas versions at 3G and leave it there and I have never had any issues. (I have 16 gig ram and no page file.)

OldSmoke wrote on 7/31/2014, 5:17 PM

[I] I've tested that theory and I don't believe it's true.[/I]

I do believe it is true as I can see the difference on my system. I can pump it up to 4GB but all I get is smoother playback on the timeline after looping it several times. However, once I select a new loop region the timeline playback is down to a few fps ad render times increase too, significantly.

I also have no pagefile and 16GB RAM.

Rob Franks wrote on 7/31/2014, 5:39 PM

"I can pump it up to 4GB but all I get is smoother playback on the timeline after looping it several times"
I can get the same result with ram set to 0

Laurence wrote on 7/31/2014, 5:45 PM

[i]>Since the creation of vegas 64, I've set all my vegas versions at 3G and leave it there and I have never had any issues. (I have 16 gig ram and no page file.)[/ii]

Well I've been on Vegas since version 2. With the early versions it was a 32 bit version running on a 32 bit operating system. 32 bit Windows could address 4GB total, with a limit of 2GB per program. This was including any Windows page file that you might have been using. These were the theoretical limits that you never seemed to actually attain. RAM preview during this time was pretty limited

With 64 bit Windows and Vegas 64, you could start using several Gigabytes of RAM for previewing, and it worked quite well through V10. It was only V11 and V12 that gave me (and many other's here) problems. Check old forum posts and you'll see that I was not alone.

Rob Franks wrote on 7/31/2014, 7:54 PM

"Well I've been on Vegas since version 2. With the early versions it was a 32 bit version running on a 32 bit operating system. 32 bit Windows could address 4GB total, with a limit of 2GB per program."

Which is exactly why I said "since the creation of vegas 64....."
(I've been with vegas since version 4. I also know about the 4 gig limit because I was the one who came up with the resetting of the 2gig flag to eliminate crashing back in Vegas 8.... different screen name back then).

At any rate I can not say I have had the issues you (or others) have had. Ever since Vegas 64 I have set my ram at 3g and never had problems. Granted I don't use shiftB much anymore, the machine I have is pretty fast compared to what I had before but none the less... no problems. Now that's not to say I don't believe you. Vegas has worked well for some and not for others for what ever reason for many years now and I have never been sure why that is. Configuration? software conflicts? hardware types? Who knows.... but it works for me

Lovelight wrote on 7/31/2014, 10:48 PM

I confirm looping is all it is good for. And then rendering that loop at breakneck speeds. Anyway try 3 cam edits with external preview on with GPU on and then off. You will see a difference in frame rate. GPU off gives higher frame rate. GPU on also gives random ghost frames and blockier transitions.

Rob Franks wrote on 8/1/2014, 5:41 AM

"GPU off gives higher frame rate. GPU on also gives random ghost frames and blockier transitions."
Yeah. That's a conclusion I reached as well. GPU does little more than foul up timeline playback. You're better with it off.

OldSmoke wrote on 8/1/2014, 6:50 AM

[I]GPU off gives higher frame rate. GPU on also gives random ghost frames and blockier transitions[/I]

That certainly depends on your hardware. There are many users that have great success with GPU acceleration. But it is true that for a lower end graphic card it is better to leave GPU acceleration off. The minimum required to get a good acceleration is a Nvidia GTX560Ti, not sure what this equates to on the AMD side.

NormanPCN wrote on 8/1/2014, 12:43 PM

GPU off gives higher frame rate.

Not in my case.

In a recent project I had to turn Vegas GPU use off due to a conflict with third party FX. I left the third part GPU ON. No crash, but incorrect results. It really sucked in playback performance with Vegas GPU use off. I had to use the preview RAM for loop or Shift+B.

The conflict has since been resolved and if I open that project, then playback frame rate is excellent.

mdindestin wrote on 8/2/2014, 7:26 AM

"The minimum required to get a good acceleration is a Nvidia GTX560Ti, not sure what this equates to on the AMD side."

No actual experience with these particular cards, but have seen claims that the GTX560Ti falls between the HD 6870 and the 6950.

akayani wrote on 12/29/2014, 2:23 AM

8 core AMD, 2 X Nvidia GTX 760 16 MB RAM (HyperX FURY)

On 12 pro I can run Dynamic RAM at 500MB no problem beyond that trouble starts.

It seems one of the DIMMs likes it better than the other one.

Open GL is worse than CUDA.

The length of the rendering time makes a difference. (The risk clearly goes up.)

Nice to read a thread that confirms what I spent a day to work out. ;) It's 33C here and the first thing I blamed was the heat. I sort of remember this working fine with more Dynamic RAM. It was set on 2000MB from the last time I used it. I'm still a bit inclined to think heat is connected somehow. At least in my case.