I rarely bother trying to render in Vegas 32bit if I'm doing HD. I get low memory all the time, especially with long-GOP codecs on the timeline...which I try to avoid. I'm sure someone will come along soon and tell you that they never see this error, but I have, and it's darn frustrating...

I'm using 64 bit Vegas. Are you saying that 64 bit Vegas should be better for HD rendering than 32 bit Vegas, or vice-versa? I haven't tried rendering this project this project yet in 32 bit Vegas.

Vegas 64bit should not see memory errors for the most part. What are you doing on the timeline? Given your rather healthy memory, unless you are doing some fairly heavy duty effects, you should be just fine.

I have 12 Neoscene .AVI clips, ranging in length from 20 seconds to 20 minutes. I placed them on the time line in order, used Ultimate S to eliminate gaps, and then used Ultimate S again to create uniform 4 second transitions. There are no other effects.

Those are good ideas. I'll try the render again today and see what that shows.

As a separate experiment, I tried using the original 12 Panasonic AVCHD clips and assembled the project in the same manner. This project successfully rendered in about 2 hours.

Yes, it is. I just wish I understood why some things work and others don't. By all accounts, AVCHD is not a good choice for building complicated projects with many effects, etc. Apparently, for me at least, Neoscene-generated .AVI is also not a good choice, even for simple projects.

drmathprog, perhaps there is a memory leak in the Neoscene codec? I know there were some problems early on - are you on the latest version?

I just rendered a 1hr 36min DVD from panasonic hmc150 AVCHD footage. On my 9c 64bit it rendered in 1hr 16 min. Yesterday I did the same render on 9c 32 bit and it took nearly 3 hrs. I'm surprised how well it rendered today. Tomorrow... who knows?

Jerry

Jerry;

I haven't licensed Neoscene yet; I'm on day 2 of the 7 day trial. I downloaded the software yesterday from their site, so I have to assume it's current.

My experience with long GOP mpeg4 codecs like AVCHD and even mpeg2 HDV is the because Vegas needs to buffer so much at the beginnings of the clips, a timeline can only handle so many of these long GOP clips before you run into memory problems.

With HDV you can get around this by prerendering clips into chunks. It's not the quantity of video, it's the number of clips and beginning buffers that this number requires.

All this is yet another reason why I am such a Cineform fan.

I'm missing something here. I am using Cineform, and the resulting render fails. Why is tis another reason you a fan of Cineform?

Separate question: if I want to have short transitions between each pair of my 12 clips, how do I pre-render them into chunks to avoid the memory issue I'm experiencing?

Shift + M , or look under tools menu/selectively prerender . . . On the previous issue - I have discovered on my system that if Windows wants to do an update,and if the update icon is visible in the systray, it will absolutely mess up what I am working on in Vegas. One of the symptoms was what you described , error mess while rendering clips- running out of memory, It will also reverse previously worked and saved masks (from pan and crop) I've done, if the computer has not been rebooted after the last update, whether windows asks to be rebooted or not. hmm, very interesting . . . .

my sys is Vista 64 QC6600 8GB Vegas 9.0c 64bit

Thanks,
Will

So I can render the clips individually in Vegas Pro, and then still create transitions later, presumably in DVDA?

>I'm missing something here. I am using Cineform, and the resulting render fails. Why is this another reason you a fan of Cineform?

Sorry, I have had this problem with long GOP but not with Cineform. My mistake. I don't know why it is failing for you. It shouldn't be.

You're not editing to a FAT 32 formatted hard drive by chance are you? Maybe you're running into the four gigabyte limit of FAT 32. That or maybe your C drive is FAT 32 and you're running out of memory as the page file increases beyond the FAT32 limit.

>By all accounts, AVCHD is not a good choice for building complicated projects with many effects, etc. Apparently, for me at least, Neoscene-generated .AVI is also not a good choice, even for simple projects.

drmathprog, I use AVCHD on the timeline unless the project gets really complex. For these, I have had good luck first transcoding to mxf which is included with Vegas 9. You might want to give it a try - on my machine it edits smoothly and is visually lossless.

Jerry

I tried using .MXF last night, and it seems to have worked fine. It took a very long time to transcode the 12 clips comprising 59 minutes of content (nearly 7 hours), but the .MXF version of the project took only 75 minutes to render to Bluray HD. Thanks for the suggestion!

By the way, does this transcode time seem reasonable? Should it take a 2.6 MHz Q6600 with 8 GB memory about 7 hours to transcode 1 hour of AVCHD?

"You're not editing to a FAT 32 formatted hard drive by chance are you? Maybe you're running into the four gigabyte limit of FAT 32. That or maybe your C drive is FAT 32 and you're running out of memory as the page file increases beyond the FAT32 limit."



No, I'm not. The longest AVCHD file, a 3 GB file, copies from the camera to my work drive (it happens to be the 1.5TB E: drive), and the .AVI file that Neoscene transcodes this file to is 28 GB, and it sits comfortably on the E: drive as well.

>By the way, does this transcode time seem reasonable? Should it take a 2.6 MHz Q6600 with 8 GB memory about 7 hours to transcode 1 hour of AVCHD?

Sounds too long to me. I edit on an i7 940 with 6GB ram, Vegas 9c 64bit. I just ran a test render of a 720p60 AVCHD (high profile) clip. The clip is 1:54 long and it took 1:29 to transcode to MSF.

Some things to check:

1. Is your source and your rendered files on separate (fast) drives? I use three drives. One for Vegas program, one for source and one for render to.

2. Are you rendering to the MXF template that shows an "=" next to it signifying that it is using the same settings as your source?

3. Is Vegas using all your cores. I bring up task manager and all 8 (hyperthreaded) of my cores are pegged at 100%.

4. Do you have antivirus running? I do, but I recently switched from McAfee to Microsoft Security Essentials which is very lightweight and it has improved stability and render speeds for me.

There are probably other things to check I am not thinking of but I'm sure others will jump in with additional ideas.

Jerry

If you have anything set for auto update kill those settings. Don't even think about it just do it.
JJK

Be sure and check these settings under options/preferences . . .

1.) Dynamic RAM preview; the temptation with 8GB's of RAM is to be real free with the RAM here, don't! Vegas uses what you specify for RAM pre-renders and then has to use what's left for it's other functions, like rendering. I know when I set this too high I was having similar rendering problems just as you are.

2.) Maximum rendering threads. Since your computer is a quad core w/no hyper-threading, the max it can use are 4 threads. So set it to 4 threads or at least 3 if you want to leave one core open to do other work while you render, although I don't recommend you do that. Go to 4 threads.

Jerry;

Thanks for the reply.

1. Yes, separate fast drives.
2. I'm using Ultimate-S "render" tab to batch render the files. I don't see a "=" on the any template.
3. All 4 cores are near 100%.
4. I have Kaspersky, but I disable it when running Vegas.

>2. I'm using Ultimate-S "render" tab to batch render the files. I don't see a "=" on the any template.

Try this. Load one of your source clips into Vegas and select "Render as". Select MXF as your type and look at the list of templates. One or more will have the "=". Then, in Ultimate-S be sure you are selecting one of those templates.

Also, I am assuming you are NOT applying any FX's during the transcode (i.e., no sharpening, no color correction, etc.) Applying FX's or mismatched template properties would probably be the most likely cause of longer render times.

Jerry