Sorry if this has already been suggested but I'm pretty sure that if you change your preview resolution (say from best to good for example) that it will release the RAM in use. That has been my experience anyway.

Erik

How would I know it was crashing because of a lack of RAM?

This would usually be accompanied by a Windows message along the lines of "Windows is currently increasing the page file size. Memory allocations may fail during this time." You'd also probably have other programs crash left, right, and center as these days, many applications aren't prepared to handle a true out-of-memory situation.

I've never had that error come up (6gb fixed page file size), I've just had the "Ran out of memory" crash.

Seemed pretty explanatory to me. :) Easily repeatable, could watch the physical RAM usage go up until crashing.

The memory allocated for RAM Preview stores uncompressed frames as they were rendered for the preview window. The setting is a cap, not a fixed allocation, so if you've allocated 8GB but only 256 megs are being used then the rest remains available for everything else your computer could be doing...but the Preview RAM will keep filling until 8GB is used, so you'll gradually have less available for other stuff like rendering and encoding.

Rendering to a new track, or prerendering to disk, shouldn't be holding memory after the render is done. If it's not releasing memory after a render to disk then I'd think that's a bug, probably codec-specific.

If you feel like you want to release the preview RAM back to the system for general usage then the most straightforward way to do it is to go into your prefs and reduce the setting. This is kind of awkward so of course it'd be nicer if Vegas would just do this automatically during a render to disk, which is what Bob was suggesting.

The other way to clear the Preview RAM contents is to change the preview display size to half or quarter and then play the timeline a little or do a ram render. If you're watching task manager you should see your overall memory usage drop like a rock.

RAM Preview memory gets filled automatically as frames are shown in the preview window. Each of those frames your seeing is uncompressed and in RAM. The Preview cache allows Vegas to hold onto them for a while in case you need them again and this is why Vegas's playback gets better when you play a loop several times. More and more of the loop is cached into the preview RAM. If you then move further down the timeline Vegas will put new frames into the cache and if it runs out of room it'll throw old ones out. And if you use Shift+B for a RAM preview that also goes into the cache and old frames get thrown out as needed.

Most likely if you've set your dynamic RAM to 8GB it'll gradually fill up and then just stay that way for the rest of your edit session. It'll throw out old frames as needed and *should* just take care of itself. But have all that RAM locked up as a cache might not be helpful during a long render with a codec that isn't releasing memory when it should, so you might be better off sliding it back down to a low number for a big render.

BTW, Vegas does its frame caching in a kind of dynamic way. It tends to cache frames when it drops frames, in such a way as to make playback work better on the next playback. For instance, you might have noticed that sometimes a Shift+B covers more time than others. It depends on the complexity of the region you're rendering to RAM. If Vegas can render and play it in realtime then it won't use a lot of preview RAM. If Vegas can't play the region in realtime then the entire thing might get cached to RAM.

Rob

One discovery that might be of some use to Grazie is changing Preview Quality releases the Preview RAM.

One unpleasant discover is that adding Motion Blur causes the Preview RAM to hold less frames.

Bob.

Posted by: [r]Evolution

Yep; Shift + M = Saves the rendered file to hard drive.
(if memory serves me correctly) The location of these rendered files is shown under the Video Tab in Project Properties.

Admittedly, I've never tried Vegas' Proxy Stream which may void the need to Render at all... have you?

If the preview size is set to "Auto," just dragging the preview pane until it resizes clears the memory. I've considered this more of an annoyance than a feature.

Rob: Rendering to a new track, or prerendering to disk, shouldn't be holding memory after the render is done.

And THAT, right there Rob, is what I am exploring. By asking how I may, or expect to release SHIFT+B, I was wanting to open up my explorations around this whole Vegas+Memory Management process. After Render to New Track that activity, as far as I can tell, in Task Manager's Resource Monitor "Memory", is remaining HELD within the physical Memory.

Kelly and Friar and others here are telling me how things WORK. What I am trying to get across is how things ARE - when it comes to this Vegas+Memory stuff.

Rob: If it's not releasing memory after a render to disk then I'd think that's a bug,

Here's the Video of what I can tell is happening.

You will see the Memory usage increasing, as it should, I am presuming that's right and proper, and continuing till it tops-out at 10.4gb.

The Render to New Track finishes and that New Track is deposited way up there on a New Track 1. That's good. However you will see that the Memory, as far as I can tell or observe is NOT being handed back to the PC, and, I am presuming, being once again being made available to Vegas to use.

Should I expect this be the result of Rendering to a New Track?

I started off wanting to observe the results of using Memory in Vegas, to ascertain that which needs to be manually released back and that which is automatically released back. My motive is to focus on the way Vegas treats Memory usage so that I can determine what is a Memory management "feature" or a real/other type of bug. And for me that means the way Vegas is understanding ALL my various memory options: RAM, GPU, SHIFT+B; SHIFT+M or Render to New Track. And consequently determine if much of the issues of crashing is purely around this management/plumbing of Memory.

Again, I've been told how things WORK. What I am attempting to do, maybe be an awkward and non-engineer process, is to amass evidence based/backed results to hand over to SCS.

Thanks for reading my verbiage. I have spent many hours of thought and testing to determine some evidence for this.

Rob gave me some support in that this Render to New Track "process" really shouldn't be kept, and held in memory but rather handed back to Vegas. From my video, it appears that this is exactly what is currently happening - memory is NOT being handed back.

Cheers

Grazie

What I see there that's most alarming is the increasing use of memory during the Render To New Track. I would have expected it to increase a bit and then level out.

I wonder what happens if the RTNT is even longer, does it consume all available RAM and crash or what?

Regardless of my speculations, what you've found there does not look healthy.

Bob.

Bob: What I see there that's most alarming is the increasing use of memory during the Render To New Track. I would have expected it to increase a bit and then level out.

Yes, quite. I did a wee test back in VP9 and got a tiny RAM usage. But this voracious use of RAM in VP12 is quite scary.

Bob: I wonder what happens if the RTNT is even longer, does it consume all available RAM and crash or what?

So you are implying that this shouldn't be the case?

Bob: Regardless of my speculations, what you've found there does not look healthy.

Well, I'd like others to check this out AND against say VP11 or even earlier say in VP9 and see if they get any convergence or divergence of evidenced-based results.

Somebody needs to confirm my monitoring-approach, and that it is a true refection of what IS happening. I don't want to fall into the this is how it WORKS. I'd rather be sure about my approach being true and that this is how things ARE.

Thanks Bob for watching the video.

Grazie

Grazie, if you tell Vegas it's free to use an 8 GB frame cache, you shouldn't be shocked to see it create an 8 GB frame cache. If you prefer Vegas not using your memory (for example, because you'd like to reserve it for other applications), lower your buffer setting. I think the default value is 200 MB.

Having said that, it used about 6 GB during your render and your system seems to be able to handle the extra 2, so unless you need that memory for other things, there's nothing wrong with having the value set to 8 GB.

Should you change your mind about how much memory you'd like to give Vegas, you can lower the setting in the preferences, possibly play the timeline once, and Vegas will release the respective part of its cache. You can even set it to zero to have Vegas ditch all frames it cached during your render. Of course, the whole point of having a cache is to store things and keep them handy, so clearing it after every work step is quite pointless. It may be required if, for example, you plan to open up several instances of Vegas and don't want them to consume 8 GB each.

Satevis: "Grazie, if you tell Vegas it's free to use an 8 GB frame cache, you shouldn't be shocked to see it create an 8 GB frame cache. "

And that includes Render to New Track? And after that RTNT that completes a render to the drive, and it's finished, I shouldn't be "shocked"? Really???

G

"Somebody needs to confirm my monitoring-approach",
It's obviously happening on your system, what more proof does it take to show that *you* have an issue that support should look into?
Sure if a bunch of get the same result that adds some gravitas but so what, you still have the same issue even if no one else can repo the problem and that's what support is there for.


" and that it is a true refection of what IS happening"

Now you're inviting speculation.
None of us have the tools to say more with complete certainty. The people who do / should are in part paid by you and me to work this out.

Bob.

after that RTNT that completes a render to the drive, and it's finished, I shouldn't be "shocked"? Really???

Well, I'm not saying it's wrong to be shocked. People are shocked about all kinds of things these days, so why not be shocked about a completed render to new track? ;) But if you're asking whether what it does is technically sane, then I'd have to say there's nothing wrong with it.

Vegas will cache frames whenever it renders them. It doesn't matter if it renders them because you scrub or play back the timeline, ask for an explicit RAM preview, render to a new track... These pre-rendered frames might come in handy later during the editing session, so it keeps them.

You may argue "But Vegas! I'm rendering to a new track, because I'm going to delete everything I just rendered afterwards, so caching these things is such a terrible waste of time, resources, and human life. Well, maybe not human life." But I think it'd be a bit much to ask Vegas to come up with delicate theories on whether a specific frame might or might not be used again in the future. That would take time, be based on pure speculation, and annoy users that argue "But Vegas! I rendered this new track as a backup! That doesn't mean I'll never use the original clips again! Why, oh, why did you throw away all those lovely frames you already had?"

So the logic is rather simple: "Oh, a new frame. Lovely. Let's keep it." Still, there's some intelligence to identify frames it already knows. If you've got 15 minutes of a non-animated solid color generator, Vegas will cache one frame to cover the entire 15 minutes. Also, if you just move an event in the timeline, so that the actual frames don't change and are just played back at another time, Vegas will understand that and use the cached frames it already has. Also, if you've got several events that show the same section of a source clip (and use the exact same effects, if any), Vegas will share the cached frames between these events.

Now, the special thing about the explicit RAM preview is that while all other methods will just overwrite old frames once the buffer is full, the explicit Shift-B preview will stop rendering instead. Also, playing the timeline will skip frames when it lags behind, Shift-B won't. So using Shift-B once, you get a section that's guaranteed to play only pre-rendered frames from the cache.

Bob, you are correct. But when I get a response such as Satevis's it's as if he hasn't understood or seen the video, and what I am driving at.

As to others checking this, I was wanting others to confirm that my testing, using the Task Manager, was/is the correct way to proceed.

All I'm wanting from here is that the method I've used, and yes that MAY include others testing what I MAY have found, is a correct method.

Cheers

Grazie

when I get a response such as Satevis's it's as if he hasn't understood or seen the video

Oh, I've seen the video (loved the music, by the way ;)). What I see is that you tell Vegas it's okay to cache up to 8 GB of prerendered frames, then have it render a section of your timeline, then see it using about 6.5 GB of RAM to cache this section, then are shocked, because... well, actually, that's the part I don't quite understand. If you think 6.5 GB is way to much to waste on Vegas' frame cache, the simple answer is: Don't tell it to use that much memory for its frame cache. :) I mean, as I said, the default is 200 MB. Increasing that value to 8 GB (nothing wrong with that on your system), and then complaining about Vegas actually using it... that's a bit inconsequent, isn't it?

So, Rendering to a New Track will hold the same RAM in place, even AFTER that procedure is done?

I liked the music too.

G

OK, what Satevis is speculating is that the Selective Prender is ALSO filling the RAM Preview buffer. I cannot for the life of me see what purpose this serves and as you've said previous versions do not exhibit this behavior you're seeing. Plus this seems related to V12 crashing. I'd also add that I don't recall this changed behavior being in the release notes for V12.

So the test would be to see if, after you've done the Selective Render does changing Preview Quality release RAM?

Bob.

So, Rendering to a New Track will hold the same RAM in place, even AFTER that procedure is done?

Yes. The frames cached in there may be reused later during the editing session. If they aren't, they will eventuelly be replaced by other frames, once the buffer has reached its 8 GB limit.

Rendering To A New Track. Not PreRendering. Rendering to a New Track.

G

Yes. In fact, prerendering kind of changes the source clip for the section (from the original to the prerendered file), so while these frames, like all rendered frames, will be stored in the cache, they will only be used again if the original source clip is referenced in other parts of the project or if you soon delete the prerendered file (effectively changing the source back to the original). If they aren't used again, they will eventually be replaced by other frames, such as those from the prerendered file.

Prerendering supplements the RAM cache rather than replace it. Vegas will always display a frame from the cache if it's in there. If it's not, it will read it from the prerendered file. If there is no prerendered file, it will render the frame from scratch. Unless the frame was read from the cache in the first place, it will then be placed there for quick access in the future. Thus, after you've been using Vegas for a while, your cache will contain 8 GB worth of the most recently used (during playback, rendering, prerendering, RAM previewing, scrubbing, ...) frames.

Not PreRendering. Rendering to a New Track. It's a file on a Drive.

I really don't understand this.

G