Vegas suddenly disappears at 87% of render!

Laurence wrote on 6/18/2008, 9:06 PM
Of course this is a project that I'm trying to get done before I leave on vacation tomorrow.

Anyway, Vegas just did this charming thing that it does every so often where it gets most of the way through a couple of hour render, then just disappears leaving a partially rendered file. No error message, no nothing. Just one minute it's there, the next it's not.

If SCS wonders why people jump ship, this sort of thing is it. It's not the features, it's the reliablity.

Comments

StormMarc wrote on 6/18/2008, 11:46 PM
I've found that for any long form HDV projects (I use Cineform) I have to render in small batches otherwise I get render hangs where the time runs out and Vegas turns into the energizer bunny.

I've been working on a 7-hour educational series split up into (18) aprox. 25-minute segments and Vegas always chokes when trying to render any segment seperately (I never have them together on the timeline). I use a lot of psds and I think it must have something to do with memory issues but my system is pretty high end and Vegas should be able to handle it. I sure hope they get a handle on these render problems because I've had too many sleepless nights when on render deadlines.
Laurence wrote on 6/19/2008, 2:06 AM
I think you are right. I have done a whole lot of small projects but this was a larger event style project. It hangs in a different place every time, and if I try to loop and render the part were it hung up, it has no problem. It seems that there is an upper limit to the number of hdv clips you can have on a timeline. I can see nothing wrong in what I'm doing aside from having more m2t clips on the timeline.

Fortunately the SD DVD mpeg rendered ok. I just can't seem to render an HDV master.
ushere wrote on 6/19/2008, 3:01 AM
ever since i went vegas friendly, ie, png's, m2t's, and regular audio (wav / mp3), and NOTHING .mov, or other strange formats, vegas has behaved itself on my long form edits / renders.

still can't ptt if i use 'no-recompress', but if i render without it, i can ptt.

roll on c

leslie
blink3times wrote on 6/19/2008, 3:02 AM
I'm doing much the same. I try to use cineform where I can and I break the project up into smaller chunks so that if I crash I don't wipe out an entire render. I usually use Ulead for the burn which allows you to easily "join" segments.

The 87% render that you have now isn't garbage. I will usually use the crash parts, and simply trim the last couple of seconds or so off the end (in Ulead when I do the burn). Start the render again at a point just before you crashed and then trim and match when you do the burn.
Darren Powell wrote on 6/19/2008, 5:17 AM
A classic Vegas error I've had for months and months ...

It's simply not good enough ... Vegas needs to be able to render whatever I bloody-well put on the timeline (within the parameters advertised in the Vegas promotional material at the Sony website) ... and if 8.0c doesn't do it for me ... I'm buying a Mac.

(God I never thought I'd hear myself saying that ... )

Darren Powell
Sydney Australia

farss wrote on 6/19/2008, 5:25 AM
I'm buying a Mac.


Sorry too late, you should have watched the local news.
Anyone would think Apple opening a new store was the second coming.

Bob.
blink3times wrote on 6/19/2008, 5:34 AM
"Vegas needs to be able to render whatever I bloody-well put on the timeline"

It does get quite frustrating. Every time I have to do a render these days my heart goes into my throat, and my fingers are crossed the whole time. It shouldn't have to be this way. I'm sure hoping they have found the problems and corrected them for 8c.

I'm 98% sure this has something to do with the avchd engine. The addition of this in 7e seems to be where it all started. I think they should trash this avchd rubbish anyway
winrockpost wrote on 6/19/2008, 6:14 AM
its a big problem,, ,, but how I wish i had an error message
Monday I opened up a 40 minute project master rendered to hdv a couple a months ago. Client had a couple of updates.. no big deal. Silly me no error messages when i rendered it,, opened her up and got black frames here aand there and audio drop outs here there an everywhere. ARRRRR I also have a SD DVD copy which i am now using as my audio master.and spent the early week digging through tapes recapturing clips to fix black frames... half day edit pay,,,3 day edit work ...sucks,, but lesson learned.. sit my butt down and watch every frame of every master I ever make..
CorTed wrote on 6/19/2008, 8:11 AM
It has nothing to do with format. I have been having this problem since the release of 8.0. (Sept 07)
8.0a did not fix it, 8.0b did not fix it.
There are serious memory issues/problems within this software.
The more you put on the timeline, the greater the chance of render failures. Rendering to AVI, seems to be the format with the least problems.
I'm beginning to think that SCS may not have a fix, I mean with the amount of people(customers) having issues, one would think they would issue a fix/patch ASAP!!

Ted
StormMarc wrote on 6/19/2008, 11:13 AM
"ever since i went vegas friendly, ie, png's, ..."

I noticed that when I stopped using JPEGs and Quicktime files on the timeline things got more stable but I really like using PSDs because of the ability to change them at will and have various layers etc. available in the original file. One thing I've noticed is that if I forget to downsize a PSD that is around 4000 pixels and place it on the timeline Vegas usually crashes right away.

I never have problems rendering small projects and I'm glad to hear I'm not the only with these issues. Hopefully Sony is fixing this with 8.0c.
johnmeyer wrote on 6/19/2008, 1:17 PM
I am still using 7.0d, but here are two suggestions, even for those using more recent versions:

1. Reduce the resolution of all stills on the timeline so they equal the project resolution times the zoom factor (i.e., 1920x1440 times 1.5 if you zoom into the pic by that amount).

2. Uninstall all third-party plugins, fX, etc.

Now, if the problems truly are 7.0e through 8.0b problems, then neither of these suggestions will help a bit. However, I definitely have had render crashes -- both those with error messages, and those where Vegas just "disappears" -- which I have traced to these two causes. There are definitely certain plugins which can cause Vegas to crash.
blink3times wrote on 6/19/2008, 2:56 PM
"Now, if the problems truly are 7.0e through 8.0b"

That's at least when I noticed it. 7d was rock solid. I could throw anything at it (except for large jpg's) and it would render through with no issues at all. I would render HOURS of timeline with not ONE crash Even stuff from HDVsplit. (7d will even handle the HDVplit stuff that 8b is choking on). Then came 7e.... crash, crash, crash. It was so bad I had to roll back to 7d.

8a was just as bad. They did something in 8b because the crashing isn't QUITE as severe.... which makes me believe (fingers crossed) that they're onto what ever the problem is and we'll see some better results in 8c
farss wrote on 6/19/2008, 3:03 PM
During my time with Darren I observed two things of interest.

1) Vegas crashing trying to render his m2t files. As Darren recently reportedmy suggestion to render them to different codec and then use those rendered files seems to provide viable if not long winded workaround.

2) Darren had originally tried capturing his HDV to the CF codec and had major grief. He showed me a sample frame of what went wrong and CF were unable to resolve the problem so he gave up using the CF codec. That was strange as others seem to be having good results using the CF codec in V8. Difference was that Darren was doing the conversion during capture, not capturing the m2t and then rendering to CF AVIs.

But the most interesting part was looking at a screenshot of the mangled frame that he'd saved. It looked exactly the same as what I see when DVB broadcast gets a glitch in it. You get macroblocks from previous frames in bands accross the frame. I don't know exactly what CF do during transcode on capture, maybe because of the need to keep up they don't don't wait for the error corrrection, maybe their mpeg-2 decoder doesn't do error correction, maybe they too use the MC codec and handle it differently to Vegas. Regardless it's hard to say that what ended up in the CF avi file wasn't from an error in the mpeg stream coming from the tape!

I don't believe the problem created from errors in m2t capture is the only problem in Vegas at the moment however it does seem to be the most annoying one, wellthe random black frame problem is even more of a problem for me, I'd rather the Vegas crashed than left me to check hours of rendered output withou blinking. My advice to work around this problem is to do everything you can to avoid getting m2t files with errors in them.

1) Take good care of your camera.
2) Use good tape stock.
3) Capture using a good VCR such as the M15

I do all of the above and apart from one recent event where I know what caused the glitches on my tape I've not had a problem with rendering m2t in V8.0b. However even if the crash is fixed in V8.0c it may still be awefully slow when it hits mpeg-2 errors. This is what I'm seeing with V8.0b, it doesn't crash on me but renders that should take a few hours can take over a day, it'll take upto 5 minutes on one frame. Playing back that part of the T/L also drops the fps to minutes per frame. Also worth noting, in that state I cannot reliably abort the Vegas process.

Hope this helps someone.

Bob.
blink3times wrote on 6/19/2008, 3:28 PM
"I don't believe the problem created from errors in m2t capture is the only problem in Vegas"

I'm having a hard time believing it's m2t capture errors.... period. I 'm pretty much running the exact same type of m2t captures through 8b as I did with 7d.

Now that's not to say that there were no errors in the m2t captures rendered through 7d... but I will say that if there were errors in the m2t files that I was running through 7d, then it means that 7d was a heck of a lot more bullet proof and accepting of those errors.
farss wrote on 6/19/2008, 4:02 PM
"then it means that 7d was a heck of a lot more bullet proof and accepting of those errors. "

That's a logical conclusion from what I'm seeing.
Maybe the MC codec got changed after 7.0d.

Bob.
johnmeyer wrote on 6/19/2008, 5:36 PM
FWIW, I have an AVISynth script that scans any video file and finds all blank frames, and outputs a text file with the frame numbers of those blank/black frames. Obviously Sony should have fixed this problem two years ago, but since it's been around so long, I figured I'd just try to deal with it, and so I created the script.

If anyone is interested, I'd be happy to email it or post it. It can also be used to find commercials in video you capture off the air (since most commercials have a head/tail of all black).
Darren Powell wrote on 6/19/2008, 10:14 PM
Hi Bob, everyone ...

I'm thinking it must be an MC problem ... mcplug.dll seems to feature in many error messages ... and then by rendering to Sony YUV through the Veggie Toolkit I'm having a reasonable success rate ... while the MainConcept stuff simply doesn't work ...

I sent an email to MC support a couple of nights ago asking if they were aware of any issues with their codec and Vegas Pro 8 ... their response ... 'you should talk to Sony about that' ... mmm ... I wonder who's ticked off who out there in MNC land ... ??

Probably doesn't answer all the questions ... memory usage is a big one ... but it's interesting.

I wish someone from Sony would give us a straight answer instead of 'have you tried lowering the number of render threads?' .... bollocks! The software's broken and we need a fix ... or at least some idea of ... IF and WHEN it's going to be fixed ...

Cheers,

Darren Powell
Sydney Australia


Laurence wrote on 6/20/2008, 6:45 AM
i haven't really had many problems up until this project. Usually I go tape by tape and render the footage into a single "best of that tape" clip and edit from those clips.

This particular project was a simple event where I was basically just sticking all the raw footage (in individual clips) on the timeline at once. There were no stills at all. I ran into the problem when I tried to smart-render the footage.

What I am going to do (when I get back from vacation) is render it in sections and stitch them together with Womble MPEG Edit. I'll use Mpeg Edit instead of Vegas to do this because Mpeg Edit smart-renders the audio during a smart-render rather than just smart-rendering the video.

I won't switch to a Mac and FCP because I have already tried that several years ago, I like the Apple OS system a lot, but really don't like working in FCP.

That plus, I really rely on several Vegas scripts, mainly Ultimate-S and Excalibur and would hate to work without them.

Right now my only problem with Vegas is that if you put too many m2t clips on the timeline and try to smart-render them into a single file, Vegas will crash. Normally I don't work this way anywaym but when I do, I can render them into smaller clips and stitch these together with Womble. In the long term, hopefully this problem will be fixed.
scottbrickert wrote on 6/20/2008, 10:02 PM
87% sounds about right. It might even be repeatable, if I cared to look closer.

I can limp through an edit, but can't get it to render. Nothing on the T/L but m2t's from two HV20's and a V1U.

In any case, I'm looking for a backup NLE.
StormMarc wrote on 6/20/2008, 10:41 PM
"I'm thinking it must be an MC problem"

But I have this problem just trying to to render a project in the Cineform format so it's not just Main Concept. Though I've had the problem there as well.
Laurence wrote on 6/21/2008, 7:51 AM
Rendering into Cineform is one thing, having clips converted into Cineform is another. From my experience, you can have as many Cineform clips on a timeline as you want. It's only m2t clips that seem to have an upper limit of how many clips a Vegas project can deal with at once. The format you render to isn't what's important. It's what's on the timeline.
StormMarc wrote on 6/21/2008, 11:30 AM
I'm talking about capturing clips in Cineform with HD Link, editing in Cineform and then rendering in Cineform. Using this workflow I am also experiencing the the render hangs etc..
ShawnLaraSteele wrote on 6/22/2008, 10:38 AM
For me its 41% and it repros 3/3 times rendering to wmv. Changed to .mpg and its was fine. I'd be happy to send the project to sony if they could figure it out. This was a new machine with no 3rd party stuff. (Ok, sony avchd capture stuff, but that shouldn't count, its still sony!)

I've had similar problems with other projects. One time it was because I was rendering part of the project. I rendered a bigger section and it was fine.
Darren Powell wrote on 6/22/2008, 5:43 PM
Ground Control to Sony ...

Your software doesn't work.

I repeat ...

Your software doesn't work.

Where's 8.0c?

Ground Control to Sony?

Are you there ... over?

Has a space alien eaten your brain?

I repeat.

Your software doesn't work.

Darren Powell
Sydney Australia

Oops ... just tried to open a little 10 minute project with m2t's.

-----------------------------------------------------------------

Sony Vegas Pro 8.0
Version 8.0b (Build 217)
Exception 0xC0000005 (access violation) READ:0x258ED79C IP:0xD12F221
In Module 'mcmpgdmux.dll' at Address 0xD120000 + 0xF221
Thread: ProgMan ID=0x878 Stack=0x306F000-0x3070000
Registers:
EAX=00000000 CS=001b EIP=0d12f221 EFLGS=00010246
EBX=0000003d SS=0023 ESP=0306f130 EBP=0306f16c
ECX=78134c58 DS=0023 ESI=257f8f48 FS=003b
EDX=016a0608 ES=0023 EDI=258d4f48 GS=0000
Bytes at CS:EIP:
0D12F221: 8B 87 54 88 01 00 50 56 ..T...PV
0D12F229: E8 12 F7 FF FF 83 C4 08 ........
Stack Dump:
0306F130: 25809058 24340000 + 14C9058
0306F134: 257F8F48 24340000 + 14B8F48
0306F138: 0D12B52E 0D120000 + B52E (mcmpgdmux.dll)
0306F13C: 257F8F48 24340000 + 14B8F48
0306F140: 258D4F48 24340000 + 1594F48
0306F144: 00000000
0306F148: 25782F48 24340000 + 1442F48
0306F14C: 3BFFDD90 3A0C0000 + 1F3DD90
0306F150: 2322453A 23200000 + 2453A (mcmpegin.dll)
0306F154: 257F8F48 24340000 + 14B8F48
0306F158: 257971B8 24340000 + 14571B8
0306F15C: 00000000
0306F160: 00000000
0306F164: 7C838F36 7C800000 + 38F36 (kernel32.dll)
0306F168: 7C838F36 7C800000 + 38F36 (kernel32.dll)
0306F16C: 00000000
> 0306F170: 33BBB3DA 33BB0000 + B3DA (mcplug.dll)
> 0306F188: 33BBB520 33BB0000 + B520 (mcplug.dll)
> 0306F194: 33BB8449 33BB0000 + 8449 (mcplug.dll)
> 0306F1AC: 01163691 01150000 + 13691 (vegas80k.dll)
0306F1B0: 05DC1EF8 05AD0000 + 2F1EF8
0306F1B4: 0306F1E8 02F70000 + FF1E8
0306F1B8: 0000A6B4
0306F1BC: 3A47EF3C 3A0C0000 + 3BEF3C
> 0306F1E0: 01163578 01150000 + 13578 (vegas80k.dll)
0306F1E4: 05DC1EF8 05AD0000 + 2F1EF8
0306F1E8: 3BFFDD90 3A0C0000 + 1F3DD90
0306F1EC: 3A47EEF0 3A0C0000 + 3BEEF0
0306F1F0: 00000000
> 0306F1F4: 007425B2 00400000 + 3425B2 (vegas80.exe)
0306F1F8: 01FC6870 01F30000 + 96870
0306F1FC: 3A47EF3C 3A0C0000 + 3BEF3C
0306F200: 3A47EEF0 3A0C0000 + 3BEEF0
0306F204: 00000000
> 0306F21C: 00744E70 00400000 + 344E70 (vegas80.exe)
0306F220: 0306F234 02F70000 + FF234
0306F224: 00000000
0306F228: 0306F7A8 02F70000 + FF7A8
0306F22C: 00000000
> 0306F294: 7C910945 7C900000 + 10945 (ntdll.dll)
> 0306F298: 7C91094E 7C900000 + 1094E (ntdll.dll)
> 0306F2AC: 7C914190 7C900000 + 14190 (ntdll.dll)
> 0306F2B4: 7C901005 7C900000 + 1005 (ntdll.dll)
> 0306F2C4: 7C90EE18 7C900000 + EE18 (ntdll.dll)
> 0306F2C8: 7C910970 7C900000 + 10970 (ntdll.dll)
> 0306F2CC: 7C97E4C0 7C900000 + 7E4C0 (ntdll.dll)
> 0306F2D0: 7C913E6F 7C900000 + 13E6F (ntdll.dll)
> 0306F2D4: 7C913E62 7C900000 + 13E62 (ntdll.dll)
> 0306F308: 006E006C 00400000 + 2E006C (vegas80.exe)
- - -
0306FFF0: 00000000
0306FFF4: 005258F0 00400000 + 1258F0 (vegas80.exe)
0306FFF8: 00ADA678 00400000 + 6DA678 (vegas80.exe)
0306FFFC: 00000000