Hmm -- as far as I can tell the 3 video tracks are either H.264 or "AVC" formats that came from a FujiFilm camera (x100S); a Nikon DSLR, and the Polaroid Cube (H.264). None of them should require Quicktime (I think). Is QT a problem?

Edit: the files, even though they're H.264 are "contained in .mov" files which are Quicktime...

What does Mediainfo say about each of the input files? What codec was used to create them?

Is the memory actually eaten up? Look at Performance tab in Task Manager (Alt-ctl-del).

And what template are you rendering to?

The media files are H.264/MPEG-4 AVC compression with Linear PCM audio, and stores them in .MOV files.

The "in-use" memory stays steady, but the "Available" steadily goes down (and stops around 8 GB "available"), as the "committed" memory go up up up, until it hits the max memory of my system 36 GB (32GB RAM+4 GBvirtual).

I render to 8MBps 1080-30 fps WMV file (default).

.MOV is the Quicktime container. I'm not up on the problems with Quicktime but perhaps you can transcode them to an MP4 container and try that?

/jerry

Thanks for the suggestion to transcode. One of the reasons I jumped to the latest version (from VP8 to VP12 then VP13) was to avoid transcoding.

I'm not looking forward to doing it since I already edited the files together. But i will give it a go.

Any thoughts on Dynamic Preview memory settings (200 MB by default), and should I change the # of threads?

Quicktime on the PC platform unfortunately is only a 32bit app. My advice, stay away from it as far as you can.

That's a major bummer! How can I when my DSLRs all use the H.264 mov files? :(
Will transcoding help?

Sure it will! I personally like the new XAVC-S codec or XAVC-Intra which is 422 and does smart render.

Ok. Now, I suppose that I need to get a separate program that can convert.
Right now I have Freemake Video converter (a freebie).

Do you have specific recommendations for programs that can transcode to the XAVC-S or other codecs? Thanks again!

I personally use Vegasaur from within Vegas, others use Gearshift. Vegas itself also has a limited Batchrender script but I little experience with it. Vegasaur's feature is called Transcoder and it has many more features that are very useful.

Okay -- now I'm looking at the Vegasaur website. Very interesting. (Though I think it costs $100).

I do have Vegas Production Assistant 2.0, are you familiar with it? I'm not sure if it batch transcodes...

Thanks for the suggestions. (I'll look up Gearshift next).

I can vouch for Vegasaur as I have been using it since it first came out. There is a free 30 day trial. As far as I know it isn't limited in any way so you might want to try it on your transcoding.

That said, I also get MOV's out of my Nikon DSLR and so far (knock on wood) I haven't had any problems with them in Vegas 12, but I haven't tried anything very complex. I just know that lots of folks here in the forum do have problems with them.

One easy test you might consider trying just to verify it is the MOV container that is causing your problem - you can easily replace one piece of media with another in your Vegas project. So you could temporarily replace each of your MOV's with perhaps a JPG or MP4 just to see if it then renders ok. To replace a MOV just right click on it in Project Media and choose Replace.

/jerry

Thanks, Jerry!

So, I tried to recreate the original veg file (PIP, cropping, etc) after I transcoded the original out of the camera files to mp4 (using the freebie Freemake Video Converter, which I already have).

The results so far: it's rendering nearly 60% done and the "available" and "committed" memory levels have been steady (closer to what the initial values were. So there is no slow creep in memory usage at all! and the render time became normal (for a 4 minute video) at about 20 minutes (compared to 1h45min for the problematic one, That's great (tentatively).

Now, the biggest difference is that the 1.6GB mov file from the camera was transcoded to about 0.3 GB (I kept the settings at default -- meaning 1080p60.

I have to compare the final files as they play on an HDTV to see if the quality is or is not significantly different.

PS I am looking at the open source Handbreak program that also transcodes. And see well it does with the resultant filesize.

But overall, I am encouraged by the results. (I'm still not happy that I have to transcode the files in prep, though. But if it's going to save me troubles later, it's a necessary price to pay!

Thanks!

If you install QT version 7.6.2 it might help you stay with the native file formats.

You mean to install an earlier version of QT? (I have ver 7.7 something right now). I may try that too. Thanks!

Found something interesting about converting from MOV to MP4 containers here:

http://superuser.com/questions/378726/convert-from-mov-to-mp4-container-format

You are looking at the right tool. If your commit limit is creeping up then you may have found a genuine memory leak. Try rendering without the NB effect. If the commit is more stable then you need to ask NB to investigate. If the commit still creeps, I would make sure you have the latest video drivers.

You can also use Quicktime itself to losslessly convert MOV containers to MP4 containers. Load your .MOV into the Quicktime Player, go to "File" > "Export", select "Movie to MPEG-4", click on "Options" and under both "Audio" and "Video" select "Pass Through."

If it won't let you select "Pass Through" for the audio, select "AAC-LC (Music)" select the proper sample rate and channels and "320 kbps" for the data rate, set "Encoding Quality" to "Best."

I believe that by converting to .MP4, this will allow Vegas to use the MainConcept h.264 decoder instead of the Quicktime decoder. You might also try just renaming the .MOV to .MP4, this might work, too.

MFS:

Yes, 7.6.2 has proven the most stable for many of us. It seems that each new release from Apple gives Vegas a different kind of fit.

Thanks, Carlos. That article was very useful.
I just used Handbreak to transcode -- the video looks the same but a 1.6 GB became a 0.4 GB file. I'm ok with that but worried about loss of quality down the road.

Thank you, Steve. The "committed" really was creeping up as the "available" went down (and plateaud to about 8 GB). But when the Committed went 35.8/36 -- Windows complained and then Vegas complained.

I will test it with and without NewBlue's PIP effect. THanks!