Vegas 8c Rendering problem!!

Back to post

Comments

Terje wrote on 10/24/2008, 1:38 PM
it is a deeply routed memory resident system

Oh, and one more thing... The concept of "memory resident software" was something that was needed for DOS and DOS-derived systems. These "memory resident" programs, typically virus software, a few utilities etc, were special pieces of software that popped into existence based on various signals etc. Writing memory resident software was not trivial at all.

In protected-mode Windows there is no such thing. The tasks you have running in your task manager obviously reside in memory, but they are not "memory resident software" in the terminology of DOS and Windows 98 etc.

Oh, and yes, memory resident software was notorious for fiddling with the memory of other software and even the memory of Windows and DOS it self. Since modern PCs and modern operating systems use hardware-backed memory management, this simply isn't possible. If it was, Microsoft would be in serious trouble in the professional world. Nobody would, for example, develop .NET applications for the net.
Terje wrote on 10/24/2008, 1:46 PM
Then I installed vegas. It ran quite sluggishly because of no drivers and such.

I am not going to call BS here, but I would like you to elaborate a little on this item blink. A driver is a piece of software that makes a piece of hardware accessible to the operating system (and thereby applications). If the driver isn't there the peripheral doesn't work on that system. A driver doesn't speed up (but can probably slow down) a system as such. The only situation where a driver would speed up something is if that something took advantage of acceleration provided with that hardware.

Since Vegas uses no hardware acceleration of any kind, I am dying to find out what drivers you installed to make Vegas faster (less sluggish).
Terje wrote on 10/24/2008, 1:48 PM
render out AVCHD from my Sony SR12

Crash reports come in various flavors. It used to be large JPEGs, now it is AVCHD. I would try to find a way to convert your AVCHD format to another format for editing. It isn't a very editable format. Look around here for various solutions.
blink3times wrote on 10/24/2008, 2:05 PM
"This isn't a matter of opinion blink. Bob is right and you are simply wrong. In this thread, twice. "

YUP! I knew you would be here just as soon as you read this and I'll say the same thing to you. You believe I am wrong and you are certainly entitled to you're opinion but we have had this debate already and no one's mind has change so there is no sense doing it all over again.

I will say however that SCS is now saying basically the same thing as per the above technical response note....so you need to send them an email and tell them they're wrong too. Please do let me know what the Engineers say when you try to correct them.
blink3times wrote on 10/24/2008, 2:13 PM
"I am not going to call BS here, but I would like you to elaborate a little on this item blink.A driver is a piece of software that makes a piece of hardware accessible to the operating system (and thereby applications). If the driver isn't there the peripheral doesn't work on that system."

And BTW... An ati video card (mine is a ati 1950 pro) WILL operate without its own drivers. Windows merely loads a basic set of drivers in their place... but have you ever tried to run a ati on basic windows drivers? VERY slow.
farss wrote on 10/24/2008, 2:54 PM
"And my PC isn't "bricked" at all. In fact it's working better than ever. You don't need to LEAVE things shut down, you just need to shut everything down until you have a stable situation and then turn things on bit by bit until you find the offender. I'm not sure why

I don't have a tough time understanding that at all but other people following your advise do:

"As I suggested before, go through ALL your hardware/software and turn off EVERYTHING that you don't absolutely need. If you have antivirus or firewall, then remove it from startup. Disable ALL services that you don't absolutely need and then give it a try again."

That's the advice that you gave sometime ago. How is the user going to know what they absolutely need?

It included NO warnings about making a disk image so the system could be restored in the event of them screwing something up. Following your advice not so tech savvy people are DELETING system files in desperation to shut down services, not all of them can be as easily shutdown and restarted as you seem to think. Some of them are vital to the PC and it's peripherals working correctly.

I haven't seen the entire boilerplate response from SCS regarding shutting down services but if it's anything like some of the previous ones that I had they go to great lengths to warn you of the dangers of following their advice. The last thing they (SCS) want is users doing more long term harm than short term good unless their users are carefully coached.

Issuing a white list is in my opinion a risky thing for them to be doing, you don't know what users might be running that are vital. If as you're suggesting it is some other program, service or driver causing the problem then SCS need to specifically identify it/them. Then they can issue a black list, a much, much safer thing to do.

Bob.
blink3times wrote on 10/24/2008, 3:16 PM
"That's the advice that you gave sometime ago. How is the user going to know what they absolutely need?"

And I'm supposed to be responsible for that?


"It included NO warnings about making a disk image so the system could be restored in the event of them screwing something up."
So we're now supposed to put warning labels on all our posts? come on Bob, get real.

Now unless Christian is lying (which I doubt) THIS is how they responded to him:

""This is usually due to some other process on your computer requesting resource allocation during the time of the render.

If you don't agree then by all means go ahead and tell them they're wrong.`
Rich Z wrote on 10/24/2008, 3:45 PM
Well, the project I am trying to render is VERY VERY simple. Simply put some trimmed video in the timeline, another video timeline with a text intro overlay, and a batch of jpg files at the end of the main video stream. ALL video and jpg files were taken with my Sony SR12. So the video files are AVCHD, of course. This is the FIRST time I have tried to work with the AVCHD, and I am leaning more and more to them being the problem, more than anything else.

Oh yeah, the project is only 6 minutes long, and it apparently crashes each and every time at the exact spot where Vegas Pro 8c starts to rending the jpg files into the created stream. Doesn't make a difference what type of file output I try to render to.

I was watching my Windows Task Manager screen during my last render (btw, I have a dual core Intel processor with 8 gig of ram) and noticed that the CPU was running between 94 and 100 percent. I had no other screens open at the time. Right at the time that Vegas crashed yet again, the CPU usage dropped flat down to zero. It was like the program just ceased to exist as far as the CPU was concerned.

My plan is to go back to my HDV footage and try basically the same thing using those HDV clips with jpgs to see what happens. I've been screwing around with this for DAYS now, and this is just plain ridiculous. Surely someone at Sony knows what the problem is by now. So if they aren't saying, then my bet is that it is something REAL embarrassing for them to have to admit, much less fix.
farss wrote on 10/24/2008, 4:12 PM
"And I'm supposed to be responsible for that?'

Yes.

"So we're now supposed to put warning labels on all our posts? come on Bob, get real."

If you're telling someone to do something that's potentially risky YES.
If one of us suggests say using the Curves FX and it's bad advise there's no harm done. I've given as much misguided advice as anyone. Messing around with drivers and registry entries is risky. If the user following the advice is not aware of the risks and isn't advised how to mitigate the risks then the person giving the advise is responsible for what goes wrong.
Look at posts from people like Glenn Chan, he's very careful about what he says because he doesn't know the level of expertise of the people reading what he says, his recent post about the accuracy of the scopes in Vegas is classic example. If you really understand the issues you can make them quite accurate, I do it all the time. Other users could get things mixed up and have bad and costly outcomes.

"Now unless Christian is lying (which I doubt) THIS is how they responded to him:"

At NO point did I suggest anyone was lying. What SCS is saying could indeed be true. What I questioned was if there was more to it than just that, did they include warnings about taking such actions.

Several times I've had responses from SCS suggesting all manner of risky actions. They very wisely include many warnings such as "If you feel comfortable editing registry entries"...."Make a backup of your registry" etc. As it happened in all cases though this had nothing to do with the issues at all. I knew it didn't. It took a trip to the USA to hand deliver the problem to them before I got a response along the lines of "Oh, that problem, we've known about that for some time, it'll be fixed in an upcoming release" which it was, thank you SCS.

You seem to think I'm having a go at you which I'm not. I'm certain you're intentions are admirable but you need to be aware that not everyone is as computer savvy as you. I've had my clients and even their IT people do the most bizarre things and totally screw things up. I've leant the hard way to never overestimate the technical skills of people, more so when they're stressed out at 2 AM trying to get a paying job out the door.

Bob.
blink3times wrote on 10/24/2008, 5:05 PM
"Look at posts from people like Glenn Chan, he's very careful about what he says....."
Ah yes... but it's okay for you to compare Vegas to a toy company ;)


"If you're telling someone to do something that's potentially risky YES."

Bob, it appears to me that you're going out of your way for what ever reason to spark up SOME kind of argument... and it really doesn't matter what it's on, just as long as it has something to do with inferring me as inept and/or wrong. You digress to such incredible degrees here that I wonder if some other underlying thing is not going on.

None the less, it doesn't really matter either way. I have stated my opinion as to how to correct things, (which turns out to be very much the same as SCS has said) which Bob... I am aloud to do... and no... there is no rule or written law as to a warning label on posts and people are free to take my advice.... or leave it. The choice is open. If you feel that we should start putting warning labels on posts then what you should do is forward your concerns to SCS and see how they feel about it. But until such point Bob, I am not breaking ANY rules by listing my opinions and will freely continue to do so.

You are certainly free to read them but if they really bother you to the extent that they seem, then maybe it's better that you don't... because that's YOUR right.

Now.... reallllllly sorry Bob, but I'm going to have to turn you off because I am not interested in another argument.
Rich Z wrote on 10/24/2008, 6:40 PM
Well, I realigned the timeline on my project. I forgot to mention that I have a lead in HDV video that came from my Sony HC3 camera. So the order of events was HDV clup, a series of AVCHD video clips, then a series of jpg photos. There is a WAV audio track as well that was done in SonicFire. In this sequence, Vegas Pro 8.0c would crash right when rendering got to the first jpg file.

So I moved the jpg files to be located right after the HDV cllip. When I tried rendering the project, it crashed AGAIN right when the first jpg file was to be processed.

So I think I'm going to play around with other jpg files to see if they might make a difference. BTW, those jpg files came from my SR12 camera. I'm going to try some jpg files from a different source to see what happens.

BTW, the argument in this thread is all well and good, but quite honestly all I want, as a user, is for this program to WORK as it is advertised to. If Sony does NOT know what is causing the problem, then farm out the work to someone who can figure it out. In any event, I am looking at other products right now, and I am certain other people are as well. I really don't have the time nor patience to be an unpaid beta tester for Sony. Please, just figure out the problem and FIX the darn thing. I don't believe it is asking too much to get what I paid for.
farss wrote on 10/24/2008, 7:21 PM
"When I tried rendering the project, it crashed AGAIN right when the first jpg file was to be processed."

Do you have the means to convert that jpg to png?
If so try that, it might get you past that problem.
If you don't have PS or the like feel free to email me the photo and I'll convert it and email it back to you. Email address is in my details, just click my user name to get to them.

Agree with the rest of what you're saying.

Bob.
CorTed wrote on 10/24/2008, 8:31 PM
Ok, now i'm getting P****d.

Now my last render even crashed with only one core !!!
wtf

I'm sorry for the language but it is just a bad night (only trying to render with Vegas, just to crash 2 hrs into it....)

i am going thru the list to make sure I end ALL processes as directed by our SCS team from the above posts.

I am running Vista, and I guess they forgot to mention DO NOT DELETE wininit.exe, as it is not on their list to keep (See below)
(Bob, I guess you are right about making sure not to give wrong info)

Well As I did the damn computer went blue screen and re-booted
I am getting real tired of this crashing thing.

please FIX this ASAP.
SCS please email me as soon as you find the problem......





from posts above:



""This is usually due to some other process on your computer requesting resource allocation during the time of the render. Since you have cores open for outside resource allocation, the render is not crashing when only using one core. There are a few troubleshooting steps I could recommend for this issue. First, try using three cores for the job and just leaving one open, by setting the max rendering threads to 3. As a troubleshooting step, you may also disable start up and background processes that may be requesting resource allocation on your system from time to time. End every process except for:

alg.exe
ccmexec.exe
csrss.exe
explorer.exe
lsass.exe
MsPMSPSv.exe
services.exe
smss.exe
spoolsv.exe
svchost.exe (there may be more than one of these, you can leave them all running)
System Idle Process
System
taskmgr.exe
winlogon.exe
wmiprvse.exe "

Terje wrote on 10/26/2008, 12:13 AM
You believe I am wrong

I don't believe blink. This is not a matter of opinion any more than gravity is a matter of opinion.

however that SCS is now saying basically the same thing

They are not.
Terje wrote on 10/26/2008, 12:22 AM
An ati video card (mine is a ati 1950 pro) WILL operate without its own drivers. Windows merely loads a basic set of drivers in their place... but have you ever tried to run a ati on basic windows drivers? VERY slow.

The only thing in reality that is going to be slower if your graphics card driver is not up to par is some user-interface items. On anything pre-Vista nothing will be slower (but it will be at lower quality), not even Windows operations since Windows prior to Vista didn't use graphics acceleration. On Vista the main things that are going to be affected are transparency and some of the new eye candy. The operation of an application that doesn't use graphics acceleration will not be affected.

So, given your non-answer, I am now calling BS. I think you are just making this stuff up blink.
Terje wrote on 10/26/2008, 12:43 AM
Finally, there is the post that gives the answer that shows how Bob and I are right and how blink is wrong. A little introduction

As I pointed out in a discussion about this topic earlier, on a modern PC there is no way an external process can get write access to the data (or code) of another process. Blink is convinced it can, and he is apparently convinced that SCS has validated his opinion.

Two processes can, on the other hand, compete for a shared resource, and if one of them is unable to handle said competitive situation, it can crash it self. This often happens when there are several independent threads running in the crashing process, and the appropriate mechanism for handling internally and externally shared resources are not used. Book after book is written about this topic alone, and lots of metaphors (real and metaphorically - sorry for the extremely internal pun, one of the tools used to handle this is called metaphors in computer speak) have been created to cover the topic. "Dining philosophers problem" and so forth.

So, blink, the quote:
This is usually due to some other process on your computer requesting resource allocation during the time of the render. ... the render is not crashing when only using one core

This is the crucial part blink, and as I have said before, you need to be extremely careful when talking about technical issues since you clearly do not understand them. I don't expect you to understand these issues, you are not a computer expert nor a software developer. Since you are not a computer expert and not a software developer it would therefore behoove you to speak with a tiny amount of humility and care rather than with aplomb and fanfare. Remember, some of the people lurking in these discussion groups are computer experts and there might even be a couple of current or ex software developers around.

What is stated in the quote? The following is stated: When Vegas is trying to access remote resources and the code is running on a single core, if there is an issue with the communication with said resource, Vegas can handle it. This is because Vegas will then typically not run into a situation similar to the dining philosophers. On the other hand, if Vegas is running on several cores (CPUs too presumably) then something goes wrong. In Vegas. Some Vegas code makes some invalid assumptions about what is and is not available or can or can not be used. The assumption leads to Vegas making bad decisions and writing to memory it probably does not have write access to or similar.

As I have stated all the time, and as the quote you are showing us details, this is a Vegas problem, but it manifests it self when Vegas is running on multiple cores and it is interacting with some external resource.

This isn't, hasn't been, and can not possibly be, an external process messing around with the internals of Vegas simply because that is not possible on a CPU and MMU from the 80386 and later era when running in protected mode. Oh, and please don't jump in with some Windows 98 anecdote until you know the difference between running in real mode and running in protected mode.
Terje wrote on 10/26/2008, 1:02 AM
it appears to me that you're going out of your way for what ever reason to spark up SOME kind of argument... and it really doesn't matter what it's on, just as long as it has something to do with inferring me as inept and/or wrong

Think about what the reason for that might be blink. I know I am argumentative, but you seem oblivious to the fact that you regularly express a strong knowledge of topics you are absolutely clueless about. When arrested on topics where you are wrong, you get argumentative and confrontational (I do achieve that state too, but I do so mainly in face of ignorance masking as certainty).

I have stated my opinion as to how to correct things, (which turns out to be very much the same as SCS has said)

Actually, that is not the case. SCS is conversing with a user, and the support person is saying "There are a few troubleshooting steps I could recommend for this issue.". What does that mean? It means that the tech support person is looking for more information down the line. Perhaps the user can even assist the dev team with finding the precise process that Vegas apparently is competing with for some resource. If they do they can make some educated guesses and perhaps even better than that, as to what resource the trouble stems from. SCS will then be better able to pinpoint the exact area of the Vegas source where the offending code resides, or if it is a DLL that Vegas is loading, which DLL it might be.

How do I know this? Because I have fixed hundreds and hundreds of bugs in code where this exact kind of dialogue was an important way of finding the problem.
blink3times wrote on 10/26/2008, 5:35 AM
Terje:

Haven't read your posts... don't intend to. I know it's just more stuff on how wrong I am. However i do suggest to you that instead of wasting so much time trying to prove myself and scs wrong, why don't you just simply prove yourself right?

That would be a pretty constructive thing to do. As you know I have no issues at all with admitting wrong..... so if you prove yourself right, not only will I stand and admit wrong but you will be going a long way to assist in helping other with their issues.

Find your "memory management" issue and provide a stable and reasonable work around.... THAT Terje would be a heck of a lot more useful.
CorTed wrote on 10/26/2008, 7:27 PM
So i decided to install Vista 64 bit, on another drive I had laying around and then installed V8.1 along with DVD arch 5.0
I am happy to report that by doing this, my project wich previously kept on crashing in 8.0c has now rendered multiple times ALL the way thru.
I am pretty happy about that. Still bummed it took 64 bit (8.1) to do it, but at least I got consistent renders.
Just wanted to share this.

Ted
tcbetka wrote on 10/26/2008, 8:14 PM
This is basically what I saw as well CorTed; when I installed 8.1. Although there are several bugs still in that version (cannot capture video from my FX1, for example), my simple renders do seem to go much faster. So it I am simply rendering HDV down to MPEG-2 for a volleyball DVD for my daughter's coach...I use 8.1. Render times are 30-50% on my machine.

TB
Rich Z wrote on 10/27/2008, 12:28 AM
OK, I did some playing around and I believe I found the solution for MY problem. Not saying there aren't others lurking about, but at least I have been able to render my simple little video without it crashing.

Here's what I found.

The jpg files I have been downloading from my SR12 are really rather large. Like 2.42 megabytes with dimensions of 3680x2070 pixels. Apparently Vegas Pro 8.0c just CHOKES when it tries to digest a jpg this large. So I went and resized all the jpg files I'm using in that project down to 1920x1080 (312 kb file size) and now Vegas seems happy to play with them.

Seems to me that the developers for Vegas Pro should spend some time writing error detection and recovery code into the program. You know, something like "Hey! That file XXXXXXX.jpg is too big! Make it smaller dummy!" This sure would be a whole lot more helpful than just doing a crash and burn leaving us all clueless as to what the cause was. I mean, COME ONE! Where did the developers learn to program at? Microsoft?
Terje wrote on 10/27/2008, 12:32 AM
trying to prove myself and scs wrong,

You should read them, it is SCS, not me, who are proving you wrong. Sadly you are now, as Bush and friends, flaunting your ignorance as a virtue. That is sad.
FilmingPhotoGuy wrote on 10/27/2008, 1:44 AM
It's taken me a few days to read and understand this thread.

Where does one set "512 Preview RAM" and does it really matter since it's only preview. How can this setting affect your render?
LReavis wrote on 10/29/2008, 12:14 PM
one adjusts preview ram with Options>Preferences>Video tab, top box; and yes, it definitely affects rendering, as we learned several years ago while checking Rendertest speed on DV.
--------------------
solution to my problems with my killer 1-hr., 40-min. project:
1. I put a marker at every 2-min. interval on the timeline.
2. Used Multirender from Veggie Toolkit to batch render all 2-min. segments.

Vegas first crashed on the 3rd segment at an .AVI (PicVideo MJPEG) placed on 2 tracks, one over the other, with heavily blured mask with Light Rays fx on the top track. I forced Vegas to quit, then opened it again and selected that 2-min. segment and manually set up a render for "Render loop region only." All went OK (but the render took 38 min. with all 4 cores enabled).

To make a long story short, Vegas would crash on average about every 5th or 6th segment while using Multirender. I watched the PF Usage in Task Manager and noticed that after rendering a segment, the PF Usage would drop back a lot, but not as low as it had been at the start of the previous render. After one unusually long string of successfull renders, it got up to an eye-popping 3.35 GB. It crashed, and that time I was greeted with the Blue Screen of Death when I forced Vegas to close.

All 2-min. segments that caused crashes - often, but not always, involving either large (4500+ pixels) .JPGs or else heavily blurred masks - rendered just fine by selecting them and manually setting up the render (what a relief! no more loss of resolution while panning across large .JPGs). But even with no .JPGs or masks, I got crashes after rendering too many segments with Multirender (the PF Usage always would be creeping up on each render, and would be markedly high just before the crash).

Some 4 or so of the renders were flawed: 3 had a SINGLE(!) black frame, at least one time in the middle of a segment that was rendering an ordinary .m2t file, with only a Brightness/Contrast FX; and occasionally in the middle of a render of a .JPG. I also got a single frame that had horizontal multicolored lines upon trying to render generated media (ordinary text over a background of a keyframed Color Gradient).

All renders were done with multicore rendering enabled, and with Vegas set for 4 threads (I'm running a Q6600 OC'd to 3.05 gHz on an Asus P5B w/4GB RAM), after having gone back to V8b (8c introduced too many new problems, with loss of sync on some clips). The last dozen or so renders were done with all antivirus etc. enabled, for a total Processes of 43 instead of the usual 37 or fewer that I typically allow to run (I really can't notice a lot of difference in number of crashes, with or without those other processes running).

I spent perhaps 2 hours human time, and probably 8 hours or more machine time, rendering this project. But now when I edit, I can simply render the 2-min. segment(s) involved and be done. I plan to switch to 64bit Vegas as soon as it can read Cineform & PicVideo .AVIs.