MXF Render issue (anyone seen this?)

PerroneFord wrote on 6/2/2010, 10:34 AM
Ok,

I loaded some MXF files from my EX1 onto the Vegas timeline. Many short clips that totaled 1hr 33min. Simply wanted to render it as one large file in the same compression format.

Selected my render settings, render started and got mostly "no recompression required" as expected. At about 6k frames or 4min in, render stopped. No error messages, no crash, time counters still counting, frame counter not counting, and file size not growing.

I let it sit for 2 minutes, then tried to cancel the render which didn't work. Tried to close the program, that didn't work. Killed it in Task manager.

Before I killed it, I noticed that most of the RAM was not in use, CPU usage was at idle essentially, etc. No other programs running at the time.

I am currently rendering the exact same timeline to a .AVI (Matrox codec) at the moment and it is nearly complete. Render is just slightly slower than real-time.

This is in 32bit Vegas 9.0c running on Win7 64bit.

Comments

rmack350 wrote on 6/2/2010, 11:50 AM
Maybe encoding type is irrelevant but Sony's MXF for HD is MPEG2 on the inside, isn't it?

The solution would still be the same, if a corrupt source is the problem.

Rob Mack
PerroneFord wrote on 6/2/2010, 12:26 PM
Yes, MXF in Sony world is Mpeg2.

However, my AVI render of exactly the same timeline proceeded without issue. Nothing is corrupt.
LarsHD wrote on 6/2/2010, 1:42 PM
"I let it sit for 2 minutes, then tried to cancel the render which didn't work. Tried to close the program, that didn't work. Killed it in Task manager"

Needing Task Manager as part of the Vegas to force quit when things go ugly is one of the reasons why I appreciate apps like Avid and Premiere Pro etc. It is frustrating when Vegas freezes and there's no way out and you have a deadline. I have had to use TM many, many times with Vegas. Not a single time with other apps.

MY PC? No. Vegas.
rmack350 wrote on 6/2/2010, 1:44 PM
For the fans out there we should just point out that MXF is yet another container format. It can hold a wide variety of encodings. Vegas outputs just a small sampling but as more applications adopt MXF we're probably going to see more cases of MXF not working.

The Matrox AVI probably gave you something serviceable. Don't know what to say about Vegas hanging silently in the middle of an MXF render. I wish their bug reporting page was a little more friendly.

One thing to toy with if you're in the mood and curious, is to prerender the project to the same MXF settings. The reason I suggest this is that Vegas will create a new string of (presumably smart rendered) MXF files. You ought to be able to figure out approximately when the render dies (if it's consistent). This also gives you a chance to save the existing prerenders - you could move them to a new folder and then use them as timeline media (which could also be smart rendered). It might make no difference since you're trading one set of MXF files for another...on the other hand it might be a useful dance step.

<Edit>I'd forgotten why I ever had this idea until I read Lars response. Part of my thinking with this strategy is that you don't loose as much of the render if Vegas is writing and saving segments as it goes.</Edit>

Rob
robwood wrote on 6/2/2010, 1:55 PM
isn't smart-rendering just transcoding, and not a render?

if so, rendering to AVI wouldn't necessarily guarantee the same footage will smart-render.

have you tried removed the clip where Vegas stopped doing the smart-render and seen if that fixes it? or does Vegas just stop after a certain length of time regardless of what clip its on?
rmack350 wrote on 6/2/2010, 2:15 PM
or does Vegas just stop after a certain length of time regardless of what clip its on?

Perrone could give specifics on his situation but from what I've seen on this forum over the last few years the answer is Yes to all of the above. Sometimes it hangs at a predictable spot, sometimes at random spots. So sometimes it's a corrupt clip, sometimes it's not.

Someone recently said their solution was to set RAM Preview to zero. There's a lot of downside to that but an upside is that it should flush cached frames out of RAM. I suppose it's possible that Perrone was hitting a corrupt frame cached in RAM?

Rob
PerroneFord wrote on 6/2/2010, 2:43 PM
The question I have then is if I was hitting a corrupt frame cached in RAM, why did the render work perfectly when I changed to a different render codec? Or maybe it was restarting Vegas that did the trick? But the fact is, I've *never* had this issue unless I was rendering to a long-GOP codec. I was hoping that since this was merely a copy, i.e. no recompression required, that it would be fast and easy.

I had a hard deadline of this afternoon for this project, so I didn't have time to fool around. I'm running out the door right now with DVD in hand for delivery.. and it's nearly 6pm my time.

More later tonight when I get home.
rmack350 wrote on 6/2/2010, 3:16 PM
Restarting Vegas would definitely clear the cache, but that doesn't mean it's a cache problem. Cached frames is purely conjecture on my part based on Vegas' long history of black frames and just plain wrong frames appearing in renders.

I really have no idea how Vegas is caching long GOP media but it seems like it would need to read the whole GOP to cache any frames from it.

As a design goal, Vegas should just get through renders perfectly. No excuses. However, as a fallback, it'd be great if Vegas could save a partial render and let you resume after a crash or hang. The worst case scenario should be that Vegas wastes as little of your day as possible.

The closest thing to partial renders that I can think of is Prerenders. This at least makes a string of short files and if you have Vegas configured to save the prerenders then there's a chance you could use them to continue a job that hangs in the middle. One gotcha to that is that there are only a limited number of formats available for prerenders. You want to use something that can smart render to your final output.

Rob