Some interesting memory observations and avchd...

Back to post

Comments

marcel-vossen wrote on 4/14/2009, 2:45 PM
Update:

Halleluya! My difficult 1920x1080 25 minutes weddingmovie went through without any problem after this fix!!!

Since it crashed at least 5 times, earlier today, even after I tried to render 5 minute pieces and other things you try when you're getting desperate, its pretty fair to say it must have done something really cool !

Thanks again Blink for this great idea, I think you should sell this to the Sony guys as a 8.0d release , or they should hire you to do their friggin job! ;)

I hope this works all the time!


CorTed wrote on 4/14/2009, 2:52 PM
dude, that is great news. I'm glad your able to render completely.
Just be aware that if Vegas is not managing it's available memory correctly (which is what I suspect) you may very well run into this problem again once your time line becomes longer, or you have more tracks/ FX on the timeline to start bogging her down again.


Ted
blink3times wrote on 4/14/2009, 2:57 PM
"Halleluya! My difficult 1920x1080 25 minutes weddingmovie went through without any problem after this fix!!! "

Glad to hear it. I'm moving forward leaps and bounds as well. I just did a 4 hour render with avc 1920x1080 without a single crash.... this wasn't possible the other day.
blink3times wrote on 4/14/2009, 3:03 PM
"Just be aware that if Vegas is not managing it's available memory correctly (which is what I suspect) you may very well run into this problem again once your time line becomes longer,"

I'm not sure if that's true at all Ted. What I'm seeing here on the memory graph is vegas climbing to a much higher level and then leveling off and staying pretty steady for the rest of the render... varying maybe 100 meg or so up/down.

Time will tell I guess.
farss wrote on 4/14/2009, 3:34 PM
Curious how you failed to quote all of the sentence.
Project LENGTH has never been the issue, project complexity has been the issue.

It might be worth a mention that by doing this you're probably breaching the EULA. Not that I imagine SCS are going to care but it might have been polite to ask them first before advocating such actions on their own forum.

Bob.
CorTed wrote on 4/14/2009, 3:37 PM
Blink, you may be right, but I think that when you subject the timeline to far more "stuff" this leveling off point is further, and I do think (if my suspicions are correct) the improper memory management will start to become a problem once again.

Nonetheless, Blink I think you pointed out a possibly great workaround for the AVCHD users, and I'll say it again, I sure hope SCS is listening and going to the root of this, so VP9 should no longer have memory problems.

I find it rather ironic that Blink of ALL people here who has been dissing members with memory problems, comes up with a memory fix/workaround. lol

Ted
marcel-vossen wrote on 4/14/2009, 4:07 PM
"Project LENGTH has never been the issue, project complexity has been the issue." (how do you guys quote from other posts btw?)

I think that others will agree with me that CRASHING has been the issue, to me it doesnt matter if thats because the projects is too complex, too long or just had too many red friggin pixels in it....the fact is that almost any project with my Canon 5D mark II based 1920x1080 footage crashed at totally random moments during rendering

This workaround Blink has found offers a huge improvement in stability as far as I have tested it, and I'm looking forward to testing it further tomorrow.

I don't see why providing a workaround for a VERY SERIOUS instability problem would be a breach of the EULA, that is a ridiculous thought. After all he´s not providing a crack with a backdoor in it on the executable or something, come on!
Sony should give him a medal or offer him a job.

It might be worth a mention that this problem, for people who happen to have the bad luck to use footage that is affected, can be a real nightmare . These last few weeks it has cost me days of extra work in troubleshooting my systems. This also took away the joy and focus on creating something cool with Vegas.

Like probably all of you, I hate to switch to another software vendor, simply because Vegas has always been really cool to work with and I've always used version 7 with great joy with other media...but I guess its still a great challenge to get software to work with these huge exotic media formats.
I wouldnt even know if Adobe or any other vendor has it all under control, probably a whole new world of pain would unfold with other problems that are exclusive features for Adobe users...

I will keep you informed !






blink3times wrote on 4/14/2009, 4:51 PM
"It might be worth a mention that by doing this you're probably breaching the EULA. Not that I imagine SCS are going to care but it might have been polite to ask them first before advocating such actions on their own forum."

Yeeeeah..... oooookay bob.

Just hhhhaaaad to give me sh*t for SOMETHING didn't you. Well... what ever makes you happy there guy
farss wrote on 4/14/2009, 4:58 PM
As I said, I doubt SCS are going to be concerned.
On the other hand it's a point that in all their suggestions to get projects to render they've not suggested this course of action. There could be a number of reasons for this, we simply don't know.
Getting a project to render without crashing is a good thing, doing so by sailing into untested waters has other risks associated with it, munged output being one.
Simply asking them would seem prudent, they may well have already tried this but found a serious issue or they might be able to offer better insight into how to use this to get a project to render.

Bob.
blink3times wrote on 4/14/2009, 5:01 PM
"Nonetheless, Blink I think you pointed out a possibly great workaround for the AVCHD users,"

Well it SHOULD work for those having HDV problems as well Ted. If I'm not mistaken the m2ts plugin is also for mpeg. I can't test it myself really because HDV was not one of those areas I was having trouble with.

And for the record Ted.... I have not and never have been "dissing" people on this sight. I've debated ideas... which is what a forum is for really.
blink3times wrote on 4/14/2009, 5:06 PM
"they may well have already tried this but found a serious issue or they might be able to offer better insight into how to use this to get a project to render."

Bob, as I pointed out above already... this is a work around just as killing cores is. It's not a fix. I don't know anyone on this board (including myself) that knows enough about these crashing issues to be able to come up with a pertinent and solid fix. That's for Sony to deal with.
cliff_622 wrote on 4/14/2009, 5:35 PM
Has anybody sent this to SCS?

I hope they are reading these threads,...if the fix is this simple, I'm SURE SCS can get this in an 8"D" realease BEFORE 9 comes out.

Wahoo,...we dont need to switch out our hardware afterall !! ; - )

SCS....what you you think?

CT
rmack350 wrote on 4/14/2009, 6:21 PM
I'm sure there are reasons why they've not combed through 8.0 and made it (every part of it) Large Address Aware. Maybe it's that they didn't want to put resources into it, maybe it creates buffer overruns (system security issues), maybe some of the DLLs and other parts aren't owned by them, maybe they didn't want to release a Large Address Aware app for 32-bit Windows.

Given that they've been working on a 64-bit release FOREVER, I'd guess that this has also occurred to them, probably a couple of years ago.

On the other hand, PPro has been Large Address Aware for quite a while and it still can't manage its own memory all that well.

Not that I want to pour cold water on anything. This really seems to demonstrate that some of these problems are memory bound.

Who's trying this on 64-bit Windows, and who's trying it on 32-bit Windows?

Rob Mack
MattR wrote on 4/14/2009, 9:01 PM
>"Who's trying this on 64-bit Windows?"

I'm trying this out on a Vista 64-bit system and am dismayed that I can't find any of the files blink3times mentioned. There is no vegas.exe on my system (though there is a vegas80.exe, so I modified that one). Searches for the other files (m2tsplug.dll, mcstdh264dec.dll, sonymvd2pro_xp.dll, and wmfplug3.dll) all return "No items match your search" for the entire computer.

Is there something I'm doing wrong or is this a Vista 64 issue? I've got both 8.0c and 8.1 installed.
MattR wrote on 4/14/2009, 9:06 PM
> "Searches for the other files (m2tsplug.dll, mcstdh264dec.dll, sonymvd2pro_xp.dll, and wmfplug3.dll) all return "No items match your search" for the entire computer."

Wow, how UNBELIEVABLY annoying... a search in Vista for "m2tsplug.dll" returns nothing, but a search for "m2tsplug" finds the .dll. Gee, thanks Microsoft. You're a pal.
MattR wrote on 4/14/2009, 10:51 PM
OH. MY. GOD! It worked! After about 10 days of hair pulling, I was finally able to reliably render my project using this workaround. I had tried about 13 other (according to my notes) troubleshooting approaches suggested here in the forum, straight from Sony, or just things I thought of, to no avail.

To echo what "The dude" said earlier, "Halleluya!"

The thing that was absolutely KILLING me was the the project would render just fine on my slower laptop that has less RAM, but absolutely WOULD NOT render without crashing on my desktop. Both are running Vista Home Premium 64-bit, both trying to render from Vegas 8.0c, both pulling the project and all media files from the same external drive, and the laptop will get through a render but the desktop won't to save its live.

But this solutions did the trick!

I can only guess that there is something about the memory usage on the laptop that kept it just this side of whatever magic memory line was causing the crashes on the desktop.

One thing I'd point out about CFF Explorer is that (at least on my install of Vista 64-bit), once I had checked off "app can handle > 2gb address space," I had to close down and re-open the program before proceeding to the next file. If I changed that parameter in one file, then just went directly to the next file to apply the same change, the program was reporting that that setting was already checked off. If I closed CFF Explorer then opened again, and opened the next file, it was reporting that the setting was NOT checked off after all, so I would close down between each change. Maybe I wasn't doing something right in the work flow, but not closing down between changes didn't seem to work for me.

In case anyone is wondering why I'm not just using Vegas 8.1 since I'm running Vista 64-bit, it's because the project in question, edited in 8.0c, will not even fully open in 8.1 without crashing right to the desktop with an exception in the MSVCR80.dll. The project begins to load, the timeline starts to be populated, then BAM! Hello desktop.

So then I tried the workaround suggested here in the forums where you start a new project and nest the troublesome one within it, and lo-and-behold! It rendered! (What the hell?! Why does THAT work?!) The only problem was, any shot that came from a Mini-DV tape rendered as black. Oh, sure I could go back and re-capture the Mini-DV stuff in 8.1 and maybe that would fix this particular problem, but we're talking dozens of shots from dozens of tapes, shots that NO OTHER video program is having problems with.

So anyway... thank you, thank you, thank you blink3times! I am SO relieved!
marcel-vossen wrote on 4/15/2009, 12:31 AM
Who's trying this on 64-bit Windows, and who's trying it on 32-bit Windows?

I'm trying this on a i7 based system with 6 Gigs of RAM and vista 64 bits
Terje wrote on 4/15/2009, 9:20 AM
>> Did you compare 8.0c and 8.1?

This will have no effect on 8.1 since 8.1 is 64 bit. Thanks for finding it though blink, I was finally able to render a project that has not been possible to render under 8.0c, and it was using stuff that wasn't available in 8.1.

This also gives a good indication as to where the problem lies with memory related crashes, and it isn't in the hardware.
Terje wrote on 4/15/2009, 9:23 AM
>> It's HDV crashes that I don't have.

Good for you. My project is HDV from the HV20, and Vegas has been going down like a two bit whatchamacallit. Thanks for proving that those of us who have been pointing out that this has to be software related were right though. You are a good sport when you are proven massively wrong AGAIN.
Terje wrote on 4/15/2009, 9:25 AM
>> But adjusting memory flags means this is a "memory" issue
>> just as much as killing cores means it's a "core" issue.

Something the technically literate amongst us have been trying to explain to you for a long time. The fact that multiple cores (or CPUs) exposes memory problems comes as no surprise to anyone who has done any software development. Shutting down cores doesn't fix the problems, it only masks it.
blink3times wrote on 4/15/2009, 10:00 AM
Did you pop in to actually contribute here Terje... or just lookin' for trouble?
tumbleweed7 wrote on 4/15/2009, 11:00 AM

I'm not as "technically literate" as some on here claim to be, & I can prove it... : ) .... But I do know bloviating, when I read it.....
CorTed wrote on 4/15/2009, 11:08 AM
I agree, no need to bloviate !!

Terje said it should not work for 8.1 since this is a 64 bit app.
I have not personally tested this, but I think it may very well work for 8.1, if you apply these flags for the various plugs outlined in the original posts as these are still 32 bit apps.

Ted
blink3times wrote on 4/15/2009, 11:30 AM
I haven't tried 8.1 either (and won't for a while yet). But according jabloomf1230 in a post above the file IO plugs are 32bit. That being the case.... some effect SHOULD be noticed.