Crash test results - some progress

farss wrote on 10/24/2008, 9:14 PM
My apologies for starting another thread however other threads are wandering all over the place and yes, I'm as much to blame as anyone.

I created a monster JPEG using PS from a 8M px still, blew it up to 8,000 x 6,000 for some serious Vegas abuse. Saved it from PS as both Max quality JPEG and PNG.

Started new V8.0b project. Put 10 seconds of HDV onto the T/L and 4 copies of the jpg on 4 upper track. Set track opacity to random values and used track motion to rotate the top track. Vegas could play this back OK. Dead slow in places as you'd expect but it got there.

I then attempted to render this to Sony AVC using a BD profile at 15Mb/s. Vegas pegged out, didn't crash, just an unresolved error message. The frame count was at 19 but after I clicked though the error message it jumped to 29. Frame 19 is where the first jpg was on the T/L, 29 the second.
I then swapped the jpg for the png version of the same still, same result except this time after the error dialogue all the frames of the still showed as red in preview but the thumnails were correct. Restarting Vegas cleared the red preview.

I then tried rendering to the XDCAM HQ MXF codec and not a problem, sailed through it considering the amount of data to crunch. I then brought that MXF file into a new project and rendered that to the same Sony AVC BD codec / template. Not a problem there either.

Now some aren't too keen on rendering to intermediates due to losses, I'd reckon the XDCAM HQ is pretty good but just to try to avoid that I tried another approach. I turned off the bottom track of HDV and created a region where the huge stills are. I rendered that to uncompressed AVI (big file). Saved my original project and Saved As a new one. Deleted all the big stills and replaced that section on the T/L with the uncomp AVI. Fixed the alpha channel so it was correct and then rendered all that again to the same Sony AVC BD template. It worked!

I don't have any AVCHD footage to test with at the moment however from what I've seen so far at least one of the problems seems to be encoding AVCHD in combination with something that chews up lots of memory. That's pretty consistent with the little I know about AVCHD and wavelet codecs, they can be really tough to encode depending on scene complexity i.e. lots of fine detail in the frame.

All this was done on a quad core with all 4 cores running, RAM Preview set to 1GB, just to tempt fate.

As I don't have 8.0c or 8.1 installed it'd be interesting for others that do to try similar tests. This test took less than 15 minutes out of my day. Hopefully we can find a way around the issues some are having but it could take a bit of effort on the part of a few of us.

Bob.


Comments

winrockpost wrote on 10/25/2008, 8:25 AM
just tried it and vegas rendered fine on 8.0c to Sony AVC using a BD profile at 15Mb/s,cheapo quad system
how many megs was your blown up photo ? I dont have a high res pic to start with
farss wrote on 10/25/2008, 12:09 PM
The photo is 8,000 x 6,0000, file size varies dramatically depending if it's PNG or JPG. Both formats caused the same thing to happen.

To create the photo I just enlarged one in PS.

Bob.
winrockpost wrote on 10/25/2008, 4:31 PM
OK, first test was with jpeg 4 tracks above hdv as you did,, rendered just fine. Added the png before i deleted the jpeg and vegas shut down.... no warning nothin, just gone. Opened back up and deleted the jpeg , added the png rendered fine, changed the ram preview from 128 to 1000, bam gone again. opened back up, changed ram to 1000 then added the png,,, rendered fine.
. I dont know
blink3times wrote on 10/25/2008, 4:37 PM
I shot a still in RAW format, saved it as a lossless PNG with a file size of 43.2Mb... placed it on the time line twice WITHOUT re-sizing. Threw in two 10 second HDV clips and put it all together with some crossfades and a color correction.

Rendered it as 1920x1080 (best) avc at 16Mbps. Did some HEAVY background work in Photoshop creating a photo merge with seven 3Mb jpg's while rendering.

Render completed successfully and memory rise through the entire render process was about 400Mb (pretty normal).

added:
I'm using 8c
winrockpost wrote on 10/25/2008, 4:44 PM
and i've climbed mt everest,,, try the test
blink3times wrote on 10/25/2008, 4:58 PM
"and i've climbed mt everest,,, try the test "

Not everybody has access to MXF files.
blink3times wrote on 10/25/2008, 5:23 PM
Did the test again as closely as I could to Bob's (pretty much the same as last only I added the 360 dgree track movement which I did not have before)

Again I tried to tie up the computer with other back ground things. I had a video going in Nero showtime and I was doing photomerge work in photoshop.

The render completed successfully with a total rise in memory of about 420Mb. Frame count during render was slow but steady.

I should add that I do not have acess to MXF files so that part of the test was NOT completed.
farss wrote on 10/25/2008, 5:27 PM
Did you have the still on the same track?
I've put 3 of about that size onto their own tracks and composited them together, that's when things go wrong.

Except I just went back and tried rendering the same project again. Different results, it will not even render to HDV, problem is when it hits the stills. I tried reducing the complexity by deleting all but one of the tracks with the still in it and still no go. In one of the renders Vegas itself seemed to get corrupted, the message box's text was trashed.

Throughout all of this memory usage for Vegas80.exe was a reasonable 390MB rising to 410MB when it hit the still.
Got to get back to capturing, I'll try some more experiments when I borrow a AVCHD camera. I'll also try imaging the HDD and installing 8.0c.

Bob.
farss wrote on 10/25/2008, 5:30 PM
No, no. I'm not using MXF files, I found I could render to MXF and it worked fine. It was only rendering to AVCHD the problem showed up. But now, see below.

It'd really be good if we could get some consistent results but that's not looking too likely.

Bob.
blink3times wrote on 10/25/2008, 5:43 PM
"Did you have the still on the same track?"

No. I had my still placed four times on the upper track with that track doing a 360 spin and faded slightly. I had a lower track that contained HDV with some random color corrections.

My time line palyback was bloody awful... couldn't get much over 10 on preview mode.... but then I run a preview display size of 989x556 so a bad preview is kind of expected.

ADDED:
I DID just now notice that you composted the three which I did NOT do... I'm not sure that wouldn't make a huge difference though would it?
blink3times wrote on 10/25/2008, 5:48 PM
"Throughout all of this memory usage for Vegas80.exe was a reasonable 390MB rising to 410MB when it hit the still."
That's about when mine went up as well..... when it hit the stills
farss wrote on 10/25/2008, 6:09 PM
"I'm not sure that wouldn't make a huge difference though would it?"

It could well make quite a difference. Vegas is pretty smart. If you have an upper track that's 100% opacity Vegas ignores anything below that. It has to do this otherwise the Render to New Track feature would not achieve anything.


Bob.
blink3times wrote on 10/25/2008, 6:14 PM
"Vegas is pretty smart. If you have an upper track that's 100% "

Opacity on the upper track was about 60%

I should mention that in 8b I used to have to re-size my photos or suffer a crash. This is not the case with 8c however... size doesn't seem to matter anymore.
farss wrote on 10/25/2008, 8:12 PM
"This is not the case with 8c however... size doesn't seem to matter anymore. "

I don't know about that last bit, after all those emails I get there must be something to it :)

Bob.
johnmeyer wrote on 10/25/2008, 8:46 PM
Why not post the VEG? We can add our own HDV and photos.

Does frameserving work with 8.0c? Sounds like you could frameserve from one instance, and then put that in a second instance and render. This is different than nesting, which I assume would choke (although it should probably be tested). If frameserving works, there are scripts which can take a file and render it, so you wouldn't even need to open a second instance of Vegas and put things on the timeline, although I guess that isn't too much work ...
apit34356 wrote on 10/25/2008, 10:17 PM
Why not zip or rar the entire test veg and files? This should ensure better testing.....
blink3times wrote on 10/26/2008, 4:46 AM
"Why not post the VEG? We can add our own HDV and photos."

Well I don't think it's the veg's that are at issue here. What's being purposed on the time line is not that complicated and you can easily do on your own. It's the content here that is of importance. Some really Vegas twisting content that has been known to raise hell with Vegas.

Bob:
I should add one other thing here which *MAY* be making a difference here.... I don't run with a paging file. If there are memory issues... could it have something to do with the paging file?