Matt Carlson
Forum Replies Created
-
If you want a blow by blow of people with 460m problems go here
https://forums.nvidia.com/index.php?showtopic=187110
It appears that even Nvidia’s own update systems do not recognize certain 460m configurations so it is not a surprise that old drivers would cause Vegas to look at GPU acceleration from the 460 as a non-starter.
-
Are you going to be using Media Composer on your Windows PC? I had a chance to work in Avid Symphony (which I believe is ninety percent the same as Media Composer) a few weeks ago. While the playback on 1920×1080 was flawless I found the new hardware-less version of their product to be very flawed. The interface has problems accurately identifying cursor position (making window resizing and positioning almost impossible.) Their move from native hardware systems (which of course are amazingly fast) to a consumer setup seems to be in its infancy.
Your machine is fast enough to reduce the conversion process to a reasonable time but that flawless playback comes at a cost. Avid converts any non-native footage to an MXF wrapped clip in the project folder that when I did it (an hour long clip but on a less powerful machine) took fifteen minutes while Vegas does not need a conversion step. Of course that lack of conversion and dealing with more codecs natively is why Vegas playback is always slower.
You mentioned the learning curve necessary to get in to Avid. Do not underestimate how excruciating this will be. The reason people keep using Vegas despite its many problems is that the interface is (insert your own multiple here) times better than pretty much all the others. I found Symphony’s setup even more annoying than Boris Red’s which is hard to do.
In my opinion (and that is all it is) unless you are going to go the very expensive hardware setup route all Avid does give you is flawless playback. As much as editor’s consider “the preview” the most important thing in their work it is actually less necessary than having a good reference in audio work. (Note I said less necessary not unnecessary.) Just fight a bad NLE interface for a few days and then flawless playback starts to look like a luxury only. After finishing my project in Symphony (the hardware-less version) I will avoid it in the future if I can. Now with Vegas moving in to hardware acceleration I would guess in a year or two of CUDA tweaking on Sony’s end HD playback will start coming close to Avid’s.
Why do you find the Vegas “proxy” system to be a workaround that annoys you? It sounds as if you had a hands on test of Media Composer. Was the footage in your test a native Avid codec? If it was not then the proxy system that you use in Vegas is actually what Avid did albeit in an automated process.
-
Just as a point of interest… you do not have to always believe what you read. Since the manual on the Secondary Color Corrector has not changed but the plugin obviously has the “rectangle” may no longer exist. I have used secondary a lot recently and it seems to be acting as if it is now doing point by point averaging. Since the manual is describing an actual visible rectangle it my just be plain wrong.
-
Go to Options -> Preferences. While selecting this menu item hold down SHIFT and a previously hidden tab will exist named Internal. There is a parameter called “Enable scanning for closed captions” that defaults to TRUE. Type in FALSE in the value field and make sure you hit Apply.
-
First the implementation of non real time events. They are in basic terms the clip level audio you are seeking except they always have to be rendered.
If you choose ANY audio event including one grouped to video about a third of the way down on the right click menu you will see the Audio Event FX option that is the redundancy of clicking the event chain button at the end of the event. Directly below that in the menu is the option for non real time events that you want. Upon clicking that you can build the audio event chain and when you hit OK the render will portion come up to make the alternate take. When you do this the alternate take will immediately replace the original audio event (not the entire media original.) If you right click the event again this time go to Take on the menu (below Switches.) You can choose between the multiple possibilities (in this case we would now have just 2) by selecting Choose Active.
By creating a scratch track of the original media you can render out a new audio file that you can then use as the replacement option in the media bin. Unfortunately here is where my usual workflow conflicts with the problem you have. I normally split the audio from the video before I begin editing. In your case replacing the original clip with a new rendered audio take will turn the original video in to a black audio only clip. I will look to find ways to quickly replace the original audio of a video with the new rendered take. It seems like it should be possible. The replacement scenario will work if you choose to render the original video and effect audio out as a whole. How long is the original clip? I sense that this will be more time wasteful than the other option of finding all the events by hand and adding audio effects.
-
There is not a media level effects chain for audio. It is possible to affect an audio clip scattered in edits throughout a project though. It is not pretty but it works. Create a new audio track and place the complete audio clip there (or use Soundforge or another external editor as another possibility.) Right click and apply a non-real time event FX. This will bring up the render templates and continue to render out a new clip. Since it is audio it takes very little time. A new clip (usually named with a “Take 2” after) now exists. Go back to the media bin and right click your original media. Choose replace and then pick your newly rendered clip. All the non linear edited events in the timeline remain intact replaced by the new “Take 2” clip. You can reverse the process by choosing replace again and going back to the original one.
-
The problem of transitions and fades being intermittently wrong still exists in Vegas 11 (build 511) as well. My problems have almost always occurred if the clip is stretched and then put in a transition or has a fade. The horrible thing about this problem is that it is not consistent. It will render as a problem if the preview shows it (most times the clip will just change to one color channel and not break up as you have shown) but reopening the project or even just playing the preview again later on it will be clean. This makes it impossible to know when and where these transition anomalies will show up unless you preview the entire project before rendering.
What I have found trying to fix these problems is this. It happens almost exclusively in 32 bit color format. Unfortunately switching to 8 bit color mid project is an impossibility. Are you working in 32 bit color? By deleting a frame here and there or just changing the transition cross points the anomaly will go away. I have yet to find a reason for the anomaly in the first place as most of the time the transitions are put on the same video clip (so codec issues are not the problem.)
-
Vegas has some instability issues with mouse drivers that have programmable buttons (some wacom tablets as an example.) The fix was an odd one but it makes a small bit of sense. If you uncheck “Enable Joystick Support” in the preferences (general) tab it might clear up your specific mouse issues. Then again it might not.
-
If your render runs fine for the beginning of it’s run then I would say memory calls are being duplicated (or tripled, or quadrupled)over time but I have done some tests as well and the memory does not see to fluctuate at a rate that could induce such extreme behavior. In fact system memory seems to hold steady. There are two reasons an “all other things being equal” computer slows down. The first is truly awful coding circumstances where a set of instructions are repeated (and because we are talking about modern cpu speeds these repetitions are in the tens of thousands) for one result. I am trying to think of a scenario where a change in available system ram somehow causes this kind of repetition but have not come up with any. The second scenario is a program waiting for the Windows API to get around to managing something. Windows indexing, etc., would have been my go to problem areas as well but that means the amount of memory task manager has been reporting used in these cases is flat out wrong.
That leads us back to CUDA or maybe just straight video card memory being messed with and not released over time. Over the YEARS that Vegas has been discussed on boards knowledgeable people have always said that preview ram has nothing to do with rendering. Somehow with the implementation of acceleration in 11 they now are stomping on the same turf. Several people since 11 came out have received the usual weak response from tech support but on one post I remember reading the person was told that the implementation of graphics acceleration was improperly done in 11. The people seeing strange behavior have all had cards above the 2.0 CUDA implementation from what I have read (while the ones below 2.0 have cards that do not seem to be affected by much but their performance is not making a big difference one way or the other anyway.)
Unfortunately this leaves us with the most likely possibility that a serious logic error is hiding in the Vegas code that programmers are assuming does not exist. One way to narrow down the possibilities is to take out some ram. Reduce your ram down to 4GB and keep preview at 128mb and see how long renders take. If it flies by at the same rate then it would point to Vegas forcing the Windows API to accept a memory limit that is faulty (as opposed to low preview allowing Windows its usual bullying of memory which in this case seems more effective.) If at some threshold of preview ram Vegas is forcing a static set of addresses (on gpu or motherboard memory) and it is not managing it correctly Windows would start to choke possibly trying in blind repetition to find some way around this memory hole.
Obviously all of these things are not what you want to hear. It would be nice if some distinct parameter was just easily fudged and things would slide back in to place. What are the results if you choose to force CPU rendering on the different preview ram scenarios?
-
I can put forth a theory here after reading several weeks of better than average PC builds choking on renders. The facts in this instance are pretty straightforward. System Ram = 12GB. Setting preview ram to 8GB seems reasonable since most only have 4GB to begin with (although 8GB preview ram is probably unnecessary in most work flows.) Once the preview ram is set to 0 or 128mb render times are cut buy a factor of ten or twenty.
A GTX 460 is a reasonable card and miles ahead of say a 9800gt and the 9800gt does a serviceable job. A difference of 50+ minutes down to 2 minutes suggests something to me. Vegas may be walling off CUDA cores to run the preview ram. When it comes to final rendering CUDA is not being released and whatever small amount Vegas is leaving open is being seen as the total of CUDA cores available. This may be some small amount like ten percent or less. With only a small percentage of CUDA cores available Vegas then begins to render inefficiently because the graphics card is seen as capable but has no power left. Under these circumstances the graphics card would actually be a major hindrance. Once the preview ram is optioned back to being insignificant the GTX 460 gets back to chewing on the render the way it should.
This is only a theory but it would explain the massive inconsistency in render times.