Stop making excuses and start working

Robert W wrote on 4/1/2009, 2:52 AM
Yesterday I posted about a failed render. All I am trying to do is render a HD lagarith file, 1440 x 1080, ratio 1.333, with 5.1 mapped PCM surround track, with a colour conversion from studio RGB to computer RGB, into a WMV file.

Second attempt, switched video to a VBR peak Advanced Profile WMV. Did a short test render and it worked fine.

Started the full render, it gets 15 hours in, and then decided to endlessly hang at 95%

Now, what on Earth can cause that, apart from the most pathetic, rubbish, attrocius, clown like memory handling? So far I have wasted over a day and a half of rendering time trying to do what should be a completely simple operation.

There are people here that may pipe up and say "oh well, you are not using the software for what it is intended for. If you wanted to render videos with it, well then, you should have paid more money". Do me a favour, if you are thinking that way, please try to refrain from posting in this thread. I am a bitter person fighting to make my way in the world and I do not have time for people who are prepared to lie down and take it up the flue. It is bad enough that I have to deal with stupid problems like this, I do not need a bunch of fan boys taunting me into the bargain.

If there is anybody out there who can provide me with a solution please let me know.

Failing that, can anybody provide perhaps suggest an opensource/freeware alternative piece of transcoding doftware, which is able to perform studio RGB to computer RGB conversions on the fly and supports full configuration of WMV advanced profile? Because at present, I can't find one.

And Sony people, please slap each other heartily on the back for a job half done.


farss wrote on 4/1/2009, 4:19 AM
"All I am trying to do is render a HD lagarith file, 1440 x 1080, ratio 1.333, with 5.1 mapped PCM surround track, with a colour conversion from studio RGB to computer RGB, into a WMV file."

I've never seen Vegas get lost on such a simple task and if it goes down it's usually fairly quickly. That it ran for 15 hours before it hit a problem seems to indicate something else is remiss.

Hopefully you've checked the obvious possibilities of hardware issues such as CPU overheating or bad RAM seating or power supply from mains dips.

Next to consider is the source file itself and why the heck is such a simple task taking so friggin long. I've never used the Lagarith codec but a Google quickly reveals from Wikipeadia "encoding speed is comparable to many other lossless video codecs, although decoding speed may be slower" and even more interestingly "Recent versions also support parallelizing on multi-processor systems". Could be that Lagarith and Vegas are not playing together too nicely although I'd expect things to come unglued much quicker. You have got a hard to decode codec feeding into a hard to encode codec running 2 pass. By the sound of how long it took to go wrong it failed at the second pass, interesting. I think 2 pass WMV caches pass 1 into RAM.

Still, these are only stabs in the dark. I've yet to see Vegas have problems with uncompressed AVIs. File sizes are huge but disk space is cheap. CPU load decoding them is as low as it gets, suggest you ditch Lagarith or else try transcoding it to uncopmressed AVI or Sony YUV and from that try encoding to WMV.

John_Cline wrote on 4/1/2009, 4:36 AM
I use Lagarith all the time in Vegas at a variety of resolutions up to 1920x1080 HD and it works perfectly. The problem is probably elsewhere.
newhope wrote on 4/1/2009, 5:24 AM
I've had Vegas stop rendering on specific sections of a long edit.

It would do so every time when pre-rendering unless I selected the offending region and pre-rendered it first. I could then pre-render the project up to that point and then render from that point to the end.

Once the whole project was pre-rendered I could output the final AVI in one go using Render as... without any problems.

I could never find what was the cause of the fault but once the whole timeline was pre-rendered it would not fault on a render to file function in the same codec.

I then imported the new file to a fresh timeline for output in other formats like Mainconcept MPEG2 for DVD etc.
Robert W wrote on 4/1/2009, 5:31 AM
Thanks for the feedback chaps.

Yes, I have had no problem with Lagarith in the past in 6.0 and 8.0a. The original project had about 80 lagarith encoded media elements, and at no point did they cause any issue, and I tested Lagarith renders with no issues.

When I originally tested 8.0c on a spare machine, my test renders had random missing images throughout the content (whether it be HDV or lagarith). It was too late in my existing project to try and figure out the issue, so I stayed with 8.0a on our in use machines.

I made the switch to 8.0c on one of our main machines, to take advantage of the 5.1 mapped Wavs, hoping that the new issues may not be exhibited. Unfortunately the problems seem to be much worse.

I can rule out heat and power issues. That is not an issue with the platform I am working on. In fact, most of the rendering I do is powered by an exclusive and very well regulated circuit, with its own box that is not connected to the main building's circuit.

Dumping Lagarith is not really an option for me. I have developed a work flow for a future project that is dependent on using the format. For me, Lagarith has been a rock solid codec and I see no reason to dump it. It is worth pointing out that the last time I tried the coded was in a one pass mode. The first time, I tried in 2 pass mode, only the audio stream was written. That is nothing to do with Lagarith, that seems like Vegas falling on its backside. If it was Lagarith playing up, maybe I would have got a blank screen, or corrupted images. There is no way a codec issue should hang the whole render.

If it comes down to it, I will just switch back to 8.0a for my next project and hope it still works. Then I shall move to another platform in the future, and clinically explain my issues with Vegas at any opportunity I have in the industry press. Still it does not fix my immediate issues.
apit34356 wrote on 4/1/2009, 5:37 AM
A few years ago I had a couple of similar 95% hangs!!!! One system was suffering a overheated MD memory controller, but the most common for me has been disk overheating, usually the disk with the working temp files on it. But as others have pointed out, CPU overheating is usually the villain.
Robert W wrote on 4/1/2009, 6:24 AM
Absolutely no chance it was a cpu or drive over heat, especially at the time of night and the temperature of the rendering room at that time. I closely monitor temperatures.

Newhope, thank you for the suggesting, but rendering in sections is not an option here as it is going to a final wmv file for final use. All Vegas is doing is taking one long Lagarith file with a colour correction plugin converting Studio RGB to Computer RGB, and one 5.1 mapped Wav, and rendering it to the target codec. There are no tricks or other plugins being used in a non-uniform way. If it renders the thousands of frames before it, there is no reason for it to suddenly bomb out at 95%, other than poor coding on Vegas's side leading to stack overflows etc.

Come to think of it, Vegas 8.0c actually rendered the source project to Lagarith no problem (from what I have checked so far - I was waiting for the WMV to do a full inspection). So the finger points ever more at shoddy Vegas having trouble with the WMV codecs on my system.

Andy E wrote on 4/1/2009, 7:20 AM
So the finger points ever more at shoddy Vegas having trouble with the WMV codecs on my system

...or alternatively at Vegas having trouble with the shoddy WMV codecs on your system. If I monitor Vegas when it's rendering out to WMV I can see several Microsoft Media Encoder DLLs being loaded.

For example:

C:\WINDOWS\system32\WMVXENCD.dll (Windows Media Video Encoder) Version: 11.00.5721.5145

C:\WINDOWS\system32\WMVSENCD.dll (Windows Media Screen Encoder) Version: 11.00.5721.5145

C:\WINDOWS\system32\WMVENCOD.dll (Windows Media Video 9 Encoder) Version: 11.00.5721.5145
Robert W wrote on 4/1/2009, 7:41 AM
Well no it doesn't point that way at all, because WMV rendering was functioning correctly on previous releases of Vegas, including 8.0a, and it does so in other applications as well. I do not see what bringing up the fact that Vegas calls WMV DLLs is supposed to prove. It has to do that, that is how a codec works! But clearly Vegas is falling over when it is preparing the data to pass to the DLLs, and interfacing with the rather robust and well engineered codec system.

But on this rendering system, the WMV codecs are properly installed and working fine. The problem is Vegas.
Andy E wrote on 4/1/2009, 7:55 AM
Thank you. I'm well aware of how encoding works - I write software for a living. My point is that those are Microsoft DLLs not Sony ones and you source decoder is Lagarith not Sony.

Your problem may well lie in the interaction between three different versions of software produced by three disparate parties running on your unique combination of hardware.

Others can render out to WMV (as can I) without continual crashing on Version 8.0c but I'm not using Lagarith files as a source and I' m not encoding on your hardware setup.

There have been countless updates to those WMV encoders as you can see by the version numbers I posted - it would be worthwhile checking what versions you have installed as a comparison (regardless of whether you can encode from other apps).

In addition, you have the option of trialling uncompressed as recommended above - that would help eliminate Lagarith as a potential complication.
ForumAdmin wrote on 4/1/2009, 8:58 AM
I spoke to the Vegas PM about Lagarith and he reminded me that this is not an officially support codec in VP8 (and also in VP9). For this reason, stability will be sporadic with little reason for this behavior.

I have sent an e-mail to Lagarith's developer to contact our Vegas development team. There is no guarantee we'll support it, but this will start a dialogue between our camps.
Robert W wrote on 4/1/2009, 11:49 AM
Well that is great that you are contacting the Lagarith developer, but I thought the point of a codec is that it does not need to be "officially supported". The point of a codec is that it fills a standardized spec and can be used interchangeably between applications without approval.

Actually, your development team has to accept that the software does not deal with codecs in a compliant way. This is the reason that it can not even handle a simple task like rendering to a higher bit rate MP3 through the LameACM codecs. Every other ACM application runs that codec fine. Vegas falls over. It can not even manage to run an 18 year old framework correctly! Maybe they might want to think about moving to a more recent codec architecture?

I actually have to use VirtualDub to combine Vegas rendered video with mp3 streams. And it took me ages to figure out the workflow to do it, and then resynce the audio by hand. What should have been the most simple basic task, made into a great big fuss because of development shortsightedness.

But anyway, it is nice to see a response, but I am frankly grossly underwhelmed. There seems to be no danger of anybody actually taking any accountability for anything.
Stringer wrote on 4/1/2009, 12:38 PM
Pass the popcorn...
farss wrote on 4/1/2009, 2:35 PM
Whilst I agree with most of what you're saying it moves you no closer to resolving your current issue(s).

I'm curious as to why your workflow is tied to the lagarith codec.
I just checked and I cannot see anything that it's capable of that the Sony YUV codec isn't capable of including multichannel sound.

I try to stick to the Sony YUV codec which also has several issues which hopefully will not impact you but at least then SCS have to take responsibility.