Rendering 4 days and counting...

jrazz wrote on 4/22/2007, 5:49 PM
I have 2 audio tracks, 5 video tracks (4 for text and one for actual video). All sliders are up to 100% both track and event level. I am encoding to uncompressed avi HDV Sony YUV 60i. The footage is from 2 HVR-A1U's in HDV. I have an event level FX applied to give it an old film look. The piece is 47 minutes long.

I started the encode on Thursday and left over the weekend to go to a shoot and just returned home. It shows approximately 9 hours and 40 minutes left. It shows 22 hours and 46 minutes has elapsed. The progress bar is at 87%.

Clues: When I brought the veg up on the timeline, it was slow to respond when scrubbing. I thought it may have been just because I brought it up. The render is only using 50% of my processing power and the frame rate is creeping along at the pace of a turtle.

The drive I am encoding to also has the raw footage on it. It is a eSata 500gig drive. I encoded a file previously with only color correction and it finished within a matter of hours. This was done on the same hard disk drive.

My question: If I stop this encode, since it is an avi file, will I still have what has been rendered up to this point? If so, I will stop it, restart, and pick up from where I left off to see if it goes any faster.

Specs: 5000+ dual core AMD 64 processor
2 gigs of ram
Asus Workstation Pro Mobo

j razz

Comments

John_Cline wrote on 4/22/2007, 5:55 PM
If you stop the render now, it will lose everything!
jrazz wrote on 4/22/2007, 5:59 PM
Thanks for the quick reply. I will let it press on... ever so slowly.

j razz
fldave wrote on 4/22/2007, 6:00 PM
I don't think it will preserve your avi if you stop it, but I may be wrong.

Some FX are single threaded only, so the second CPU is just twiddling it's finger on the sideline if one of those is what you picked. Can you state which FX you are using?

It sounds like a RAM/Swap File issue. I would be interested in what your Dynamic RAM preview settings are, how big and where your swap files are.

Also, as a "victim" of a multi-day render, Vegas doesn't report in days, meaning anything over 24 hours estimated or actual are not accurately reported.
jrazz wrote on 4/22/2007, 6:06 PM
fldave,

Once it finishes I will report back and answer your questions, I am just going to leave it be until it finishes.

j razz
MH_Stevens wrote on 4/22/2007, 7:08 PM
Make sure in Windows you have your pagefile settings and your processor preference setting right. I "think" for big renders "cache" is better than "programs" as a memory priority. Also make sure you have plenty of space on you HD and that it is defragged before you start. I don't recall seeing what your processor was but this seems too long to me to be normal.
John_Cline wrote on 4/22/2007, 7:16 PM
Rendering HDV takes a lot of RAM, if the preview RAM in Vegas was set to a high value, then there probably isn't enough physical RAM available for the render and it's pounding the pagefile like crazy. This will be extremely sloooowwww...

Open the Task Manager (you can do this while it's rendering) and see what the "PF Usage" is on the "Performance" tab.

John
Steve Mann wrote on 4/22/2007, 9:16 PM
"...it's pounding the pagefile like crazy. This will be extremely sloooowwww... "

Especially if the pagefile is on the same drive as the system files.
MH_Stevens wrote on 4/22/2007, 10:54 PM
So this sounds like your computer is doing what is called "thrashing". This is very bad for the drive, can cause early failure. Sort this out before you render again. I know we spoke about your pagefile, but do you have enough memory? I'm wondering that with the dual core maybe you need 4G rather than 2? Your page file should be about 3G and make sure you have a pagefile ON THE DRIVE TO WHICH YOU ARE RENDERING as well as on your system disk.
Laurence wrote on 4/23/2007, 5:21 AM
Do you have a 3d alpha layer by chance? Using this feature increases your render time an absolutely huge amount. Usually you only need this on a short section so what you should do is render that section by itself and then add the rendered section to the larger project.
jrazz wrote on 4/23/2007, 5:31 AM
Here is what I was using (and it finished over night!):

Add Noise/Sepia/Cookie Cutter/ Film Effects.

No 3D Alpha or anything like that.

My page file was at 1.9gigs.

The Dynamic RAM is 511MB.

The Temporary Files are stored on my C: drive (Windows Drive)

The resulting avi file was 356gigs.

I have yet to restart, but now the timeline is responsive again. I would have to assume that it was the FX I applied. I would think it would be one of the above settings mentioned if I have not been rendering with these same exact program settings before. I have rendered HDV since version 6 and have not had issues like this (Unless I applied the 3D track motion).

Thanks. If you have any suggestions to speed things up, I am open to them. Thanks.

j razz
vicmilt wrote on 4/23/2007, 5:31 AM
One of tbe techniques I use to avoid exactly your current problem is to prerender small portions of the project, as I proceed with the edit, as opposed to one gigantic render at the end.

I take a small completed section of the video and I "Render to a New Track". That rendered piece stays at the top of the timeline. If you looked at my timeline you'd see many of these little prerendered pieces sitting on top of their respective elements.

At the end of the project, when I'm finally rendering the whole mess to MPEG, there is no real calculating going on, at all. A 47 minute piece would take about an hour on my P4 Duo (not core 2 duo)
johnmeyer wrote on 4/23/2007, 8:26 AM
I doubt this explains everything, but when I compared the relative time penalties of applying various fX, the Film fX was almost at the top of being the worst:

Vegas fX Times

Looking further down that thread, when I re-did the test for later versions of Vegas, the Film fX didn't come out as badly. However, one of the big flaws in my test is that the performance of some of the fX varies depending on what settings you use. The fact that there was a wide variation with the Film fX between the two tests suggests that it may be VERY sensitive to settings (because I didn't use the same settings for the two tests because I lost the original VEG).

If you still have your VEG from the render that took days, the obvious thing would be to take five seconds and render it using your original settings. Then, remove EVERYTHING (all fX, and anything else) and render five seconds. A few tests like that should help you pinpoint what was causing it, if indeed it was caused by some combination of fX settings.

Steve Mann wrote on 4/23/2007, 9:51 PM
"The Dynamic RAM is 511MB."

WHOAH - here's your problem. With so little RAM you are seriously thrashing your virtual memory. Probably constantly. Operations that should take nanoseconds reading or writing to RAM are taking microseconds or longer because it's using the hard disk to simulate more RAM.

Steve Mann


blink3times wrote on 4/24/2007, 4:10 AM
"One of tbe techniques I use to avoid exactly your current problem is to prerender small portions of the project, as I proceed with the edit, as opposed to one gigantic render at the end. I take a small completed section of the video and I "Render to a New Track". That rendered piece stays at the top of the timeline. If you looked at my timeline you'd see many of these little prerendered pieces sitting on top of their respective elements.At the end of the project, when I'm finally rendering the whole mess to MPEG, there is no real calculating going on, at all. A 47 minute piece would take about an hour on my P4 Duo (not core 2 duo)"
======================================

It would be different if Vegas had a smartrender system..... things would not get completely re rendered every time. But because it doesn't then this procedure would amount to fairly large generation losses, would it not??
rs170a wrote on 4/24/2007, 4:43 AM
It would be different if Vegas had a smartrender system..... things would not get completely re rendered every time. But because it doesn't then this procedure would amount to fairly large generation losses, would it not??

Not necessarily. The DV codec in Vegas is recognized as being one of the best there is so the loss in going down one or two generations should be minimal.
Don't believe me? Try it for yourself and see.

Mike
Chienworks wrote on 4/24/2007, 4:49 AM
how about 99 generations? http://www.vegasusers.com/testbench/files/generations/
Xander wrote on 4/24/2007, 5:15 AM
Video FX plugins that have a little yellow square to the left of the name is an indication that the plugin does not support multi-threading. This means the Video FX plugin can only use one CPU so on a Dual Core, that is 50% of the processor power. I am not in front of Vegas right now, but think the Film FX is one of them. Generally, you can get a little more utilisation than 50% when using them, as a lot of the other Vegas functions are multi-threaded, but you won't get up to 100% when using non-threaded plugins on a mult-core machine.
blink3times wrote on 4/24/2007, 6:00 AM
Don't believe me? Try it for yourself and see.

Sorry... I didn't mean to call anybody into question... that was not my intent. I've simply been taught that the last thing you want to do is render and re-render, if it can be avoided.
Laurence wrote on 4/24/2007, 7:20 AM
>It would be different if Vegas had a smartrender system..... things would not get completely re rendered every time. But because it doesn't then this procedure would amount to fairly large generation losses, would it not??

Vegas does smartrender SD DV. Unless you're adding filters, titles, opacity or size, Vegas automatically does a smartrender and you lose no quality.

Vegas also smartrenders Cineform codec avis as well (as long as they were rendered or captured in VFW mode).

The thing that Vegas doesn't smartrender (that some other editors do) is M2T mpeg. A lot of us wish it could do that.
blink3times wrote on 4/24/2007, 7:34 AM
I sure did NOT know that that vegas smartrendered DV... that's good to know. But then I deal mostly with hi def so my thought pattern was on that level. Funny... I don't even think of DV anymore... I just automatically kick in to the HD thought patterns... I need to think a little more.
rmack350 wrote on 4/24/2007, 7:54 AM
I've never noticed Vegas smartrendering anything. Could you give some details?

Yes, it caches frames, but I wouldn't call that a smart render.

Rob Mack
ECB wrote on 4/24/2007, 8:21 AM
An easy way to tell when Vegas is rerendering is to watch the preview screen during DV render. The image will only appear on the preview screen when Vegas is rerendering otherwise it will be black. Vegas will only rerender the parts that have changed.

Ed
rmack350 wrote on 4/24/2007, 3:26 PM
Ah, I see what's being called a "smart render". But it isn't, not in the sense that some mean. It's just a direct copy from DV to DV. (Also works for direct copies of sony yuv to sony yuv, so I'm assuming it works for all media).

Don't get me wrong, what Vegas is doing is good. It's just not enough. What people mean by smart render (I think) is a background render of things that will need rendering. The problem for Vegas is "Smart Render to what?" You have to either tell an edit system what the output render format will be or the system has to have a default render format, like a default 4:2:2 format.

Rendering a project to DV25 is often not acceptable because it's too lossy. Yes, Vegas is pretty good with it but titles and graphics will always be ruined by a DV25 render.

Rob Mack
fldave wrote on 4/24/2007, 5:45 PM
RE: "Dynamic RAM is 512K"

This may not help your render speed, but it could be contributing factor.

This is the setting Vegas sets aside for your Dynamic RAM renders during editing, not final render. Problem is, though, is that it could be holding that amount of RAM out of the available pool available for final rendering.

I think your problems were: Film Effects plugin (super-super-slow); Set Dynamic RAM to 128 for final render (I use 0 sometimes, never in between due to previous problems with 16 and 64); but a big problem could be with your hard drive. You cranked 400GB to the drive during the render. Is it optimized (DMA set up for speed)? Firewire 400? SATA? Formatted with a large allocation size (64KB instead of 4K)?

All of my dedicated video drives I use 64KB allocation size during format instead of the default (4K). This allows the system to write data to the drive in 64KB segments instead of 4KB, or 16x quicker in the overhead of the write (NOT 16x quicker write time!!!) It seems to help some in my opinion.

Was that 400GB uncompressed? There was probably a significant hit on drive throughput. Try HuffYUV next time, it will be ~5X smaller.