Vegas Pro 8b Render Problem Identified

Comments

Udi wrote on 2/9/2008, 2:39 AM
Darren, do you have a jpg and png files in your project?, they are memory eaters.
I have a 25 minutes HD, using native m2t from Z1, with about 600 clips and "only" 25 tracks of audio - and it uses 620MB of memory.

Udi
rmack350 wrote on 2/9/2008, 9:37 AM
When I configure the task manager to show an applications RAM and page file usage it seems like Vegas seems to use both equally. Granted, i'm looking at Vegas while it's using about 300MB of each, but if the pattern held when Vegas was using a gig of RAM then Vegas would be out of memory. A gig of RAM and a gig of page file = 2 GB, and that's the limit.

I was looking through FCP tutorials last night on Lynda.com. The presenter was commenting that the current version can use up to 4GB and "unlike previous versions, won't crash when it runs out of memory"

Sounds like a familiar situation.

I agree, Terje, that it's more important for Vegas Pro 32 to manage it's memory well. Even if 64-bit Vegas solved the problem, the 32-bit version will still comprise the bulk of installed systems.

Rob
jabloomf1230 wrote on 2/9/2008, 10:36 AM
@Darren

Take a look at this:

http://blogs.gotdotnet.com/ptaylor/archive/2007/06/15/fsx-and-win32-process-address-space.aspx

The article is not about Vegas, but rather another 32 bit memory hog, Microsoft's own Flight Simulator X. It explains the limitation on address space in 32 bit Windows and how to eke out a bit more memory. I checked the exe file header of Vegas80.exe and the bit is NOT set to use the > 2GB address set. You can try to set the bit yourself with a program called CFF Explorer (Google it, it's freeware). If you are running 32 bit Windows, you would also have to make the OS changes listed in the Flight Simulator blog.
Udi wrote on 2/9/2008, 11:04 AM
The page file (virtual memory) is the total memory used by the program. Part of that memory reside in RAM. In most cases the RAM will be smaller then VM.
When you hve a lot of RAM and small number of active applications, the RAM will be close to the VM size.
You don't add the 2.

Udi
rmack350 wrote on 2/9/2008, 12:12 PM
Hmmm. So are you saying that "Mem Usage" is a subset of "VM Size"? I wouldn't have thought that since some applications have larger Mem Usage numbers than they do VM size.

In fact, looking at the list of processes in Task manager, an awful lot of them (maybe half) have higher Mem Usage numbers than VM Size.

I realize I was simplifying, but what you're saying isn't adding up for me.

<Edit>I'm totally willing to accept that adding the Mem Usage and VM size is wrong.

Rob
rmack350 wrote on 2/9/2008, 12:40 PM
Whew! This seems a bit like saying "Taste this and tell me if it's spoiled"

Have you tried this hack of the Vegas Executable? Did it work? Was it stable?

Darren's in the middle of trying to render a feature. This isn't exactly a good time for him to be hacking the Vegas executable.

Rob Mack
Udi wrote on 2/9/2008, 12:49 PM
As I said, it is most of the time.
RAM usage include cache data (and some other system segments) that is not backed in the VM.
So, the total memory is VM + Cache and the RAM is subset of the VM + Cache.

Udi
jabloomf1230 wrote on 2/9/2008, 1:41 PM
At the moment I am running Vista x64, so I can't really help with seeing if it's "spoiled", since I don't have any problems with running out of either virtual or physical memory. I have tried it with other software when I was running XP x86 in double boot and it gave the usual range of results, depending on the software: 1) It does nothing. 2) It gives you more memory and 3) It causes a BSOD, in order of frequency. You can run the utility Process Explorer (not the same as the CFF Explorer cited above) to check peak and instantaneous memory usage by process.

Changing the file header bit DOES work with FSX and that blog that I referred to was written by one of the FSX developers. The only way to try it is to make a copy of the Vegas exe and try it out with a "punishing" test project file.
Darren Powell wrote on 2/9/2008, 7:36 PM
Hi Everyone,

Well, lots of suggestions and ideas - thanks again ... as Rob asked ... has anyone tried this Vegas exe hack? Does it work?

I'm finding some really interesting things as I work on this problem ...
the /3GB switch in boot.ini was already part of my boot.ini file ... bummer ... I was hoping for a 1GB memory expansion !

I'll try Vegas without the 3GB switch ... haven't done it yet but maybe Vegas is crapping out because it doesn't know how to address that extra RAM which, if I understand this correctly, has effectively been stolen from the OS's 2GB portion of the available 4GB at 32bit? Who knows ... maybe the Sony software engineers didn't expect people to be tweaking their boot.ini files and allowing Win32 apps access to extra memory? I don't know.

Anway, I'll try it and see what happens.

Lastest news is that I can render a .wmv from my 10 minute portion but I can't render an m2t yet ... I need the mpg's to play as a test at my local cinema on their HD Projector ... and eventually hopefully play the whole film.

Interestingly I've found that Vegas falls over at the exactly the same spot every time ... frame 8551 which is the start of the classic old 'moon shot' with the clouds moving across etc ...

The moon shot is the only clip on the timeline which is still at 1440 x 1080 with a HDV pixel aspect ratio ... the procs hate it ... they max out and Vegas just disappears off the screen ... all the other ciips have been laboriously converted from Cineform's to 720p m2t's on my Dual Xeon box ... which was process I had to go through a couple of months ago to get any sort of rendering happening out of Vegas ... Cineform's were causing all sorts of trouble, black frames, red frames, no frames etc ...

Anyway, I think it's interesting that the 1080 clip is causing so much grief ... I'm just about to convert it on the Dual Xeon ... and bring it in as 720p square pixel aspect ratio clip and that will hopefully solve the problem ...

I have a screen cap of the Task Manager Performance graphic if anyone's interested.

Can you post pics on this forum?

Cheers,

Darren


Darren Powell wrote on 2/9/2008, 10:53 PM
Latest is that I can make small wmv's but anything HD including wmv's m2t's etc ... fall over when the procs peak at 99% usage... this is crap!

I've cut the film down to 10 mins chunks.... pretty small really ... and still the HD stuff doesn't work.

jabloomf1230 - I'm firing up CFF Explorer 7 - I'll see if I can set that bit thingo and then restart with the /3GB switch in boot.ini ... and see what happens.

I just want to render this effing film. I don't want to learn how to be a computer programmer.

I might call my lawyer about what my options for legal action against Sony. It's not like I haven't given this my best shot. Now I just look like a total effwit in front of my client.

My apologies for the implied language ... I'm just so fed up with this now.

Thanks everyone for your help.

Darren Powell
Sydney Australia
farss wrote on 2/9/2008, 11:09 PM
One thing you could try.
Reduce the number of tracks. Save project under new name, delete all the audio tracks and try rendering that out, start with a small chunk obviously.
Are you using any of the iZotopes plugs, I think I figured out why they were freebies with SF9, had them total Vegas more than once :)

If that fails, vision only but render a few tracks at a time and composite them. That could be a real PIA though as you'll need to a codec with alpha and uncomp is going to be huge in HD, still would help narrow things down a bit. I've noticed that more tracks - more pain in Vegas. Even when a track has FA in it it slows Vegas down throughout the whole render, probably renders a blank frame and composites that.

Bob.
busterkeaton wrote on 2/9/2008, 11:20 PM
If it's failing in the same spot each time, I would try to render just that section, maybe a minute before and minute after to see if that is just when the memory issue is being hit or if you have a problem with a certain file type.

Have you tried changing the number of render threads in the Vegas preferences? You can change them from 1-4. If you get into the internal settings of Vegas (search the board for the way how) you can set the number of threads up to 8.


By the way, I don't think your lawyers would get you any money beyond the cost of Vegas so you would lose out on lawyers fees. I'm sure the Vegas License is written to protect SCS from a lawsuit like you are contemplating.
busterkeaton wrote on 2/9/2008, 11:21 PM
I also think rendering out all the audio and then video and then combining them may help.

Darren Powell wrote on 2/9/2008, 11:47 PM
Thanks Guys,

Yeh, I'm not going to sue Sony ... it just makes me feel better comtemplating it...

I guess all that's left is the track by track thing until something works... yes, I've tried all the render thread stuff ... never heard of it going up to 8 so I'll check that out ...

The really disappointing thing is ... after all this work and tearing my hair out I'll probably render the film and have the critics say ... this is crap! :-) Here's hoping that's not the outcome.

Cheers,

Darren
Darren Powell wrote on 2/10/2008, 12:51 PM
FINALLY!

I separated out the audio tracks / video tracks / removed all of the unused clips etc.

Set up a new directory structure to manage .veg files with audio only and video only ... plus an audio and video directory so I can keep track of the all the segments ...

I got the video to render at 720 and the audio as 48k wavs in 5.1 ... and now I'm just watching the combining of those two renders to finally give me a 720 / 5.1 m2t file to play u pat the cinema ... and that's only the first 10 minutes.

What a P.I.T.A. !!

Oh well ... that's just added about 10 times the amount of work required to make the film.

Thanks again to everyone who's helped me with this. I feel like giving you all a credit on the film.

Cheers,

Darren Powell
Sydney Australia