Why is rendering SOOOO SLOOOOOOOW?

krehbiel wrote on 5/25/2002, 8:45 PM
Athlon 1.4GHz, 512MB DDR; 27GB 7200RPM UDMA66 hard drive in a single NTFS partition; Windows NT 2000 SP2; VideoFactory 2.0c.

Why does it take bloody 17 hours to render a 13 minute clip? This is un-freaking-believable. It seems to me that rendering would be a CPU-intensive activity, but my disk light stays on, and I can hear the hard disk thrashing. What in the world is wrong?

Comments

Chienworks wrote on 5/25/2002, 9:06 PM
Tell us more about the video you're rendering. What is the source material? How many effects/transitions are you using? What format/file type are you rendering to?
Grazie wrote on 5/26/2002, 12:31 AM
Grazie's Do's & Dont's Rendering Checklist:

1. Do test a Small piece first - and then do the math
2. Do make sure I've got enough HD left to render to. Windows uses lumps of HD for its own purposes too!
3. Do make sure I've got my "msconfig">"Startup" stripped naked to something like systray plus two other functions.
4. Don't run any other windows programmes during render - Norton, Windows schedular kicking in half way through!
5. Do have a separate Hard Disc to render to or to capture to.

17hours for 13 minutes is I think truly a record! There has to be reason for your pc taking this amount of time. I've got less ghzt than you and less ram and I'm on WinME! BUT, but I do have a separate external HD used solely for rendering to and capturing to. NO not 17 hours! it would drive me insane.

Perhaps others wish to add to the "Do's & Dont's" list.

Krehbiel, there will be a solution, just keep looking in this thread.

Grazie
kcarroll wrote on 5/26/2002, 8:21 AM
I have to agree with the above post. You have set some kind of record!

It sounds like your machine has all the right stuff, with the possible exception of hard disk space. How much actual free space is on your disk when you start rendering? Has the disk been freshly defragged?

Another thing I have to ask about: (forgive me for asking obvious stuff) Have you shut down all other software that may be running in the background?

My machine is very similar to yours, except that I'm running a 1.0ghz P3. I used to have problems with slow rendering, but nothing like you're experiencing. I added an external 80gig Maxtor (firewire) as a video capture drive, and I am able to render a two hour movie (fast video resize = on) in something like 3 hours.

kcarroll
maccullo wrote on 5/26/2002, 1:51 PM
That is quite high! My record so far has been 2.5 hrs for a 6 minute clip! Mind you I was rendering a 720x480 8.7gb avi uncompressed to a 720x480 1.5 gb dv file. I think it may have been quicker if I had defraged my hard drive first.

Ian
Kalvos wrote on 6/13/2002, 9:03 AM
Did you ever solve this?

I am new to this with a system almost exactly like yours. I have great response in other demanding apps like Sonar, with virtually nothing in the background (a system stripped for audio, and only this browser running).

Right now I'm looking at 43% of a 2-minute file, 9 short clips, plain old boring crossfade only -- at it's been 25 minutes.

Dennis

Dennis

Vegas Pro Version 21.0 Build 108
Windows Pro 10.0 20H2 build 19042.1110
AMD Radeon R9 280

Processor    Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz   3.30 GHz
Installed RAM    16.0 GB (15.9 GB usable)
System type    64-bit operating system, x64-based processor

 

maltedmedia.com/bathory

Kalvos wrote on 6/13/2002, 12:40 PM
Further to this: The encoding gets progressively slower. For a 2-minute 16-second clip, it reached 25% in about five minutes, 50% in about 30 minutes, and 100% in about 3 hours.

I am editing a 22-minute piece now. At that rate, it will be 2004 before the rendering will finish!

Any clues, please? I tried rendering in a few different codecs, the results all being the same.

Dennis

Dennis

Vegas Pro Version 21.0 Build 108
Windows Pro 10.0 20H2 build 19042.1110
AMD Radeon R9 280

Processor    Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz   3.30 GHz
Installed RAM    16.0 GB (15.9 GB usable)
System type    64-bit operating system, x64-based processor

 

maltedmedia.com/bathory

Kalvos wrote on 6/13/2002, 12:43 PM
Final postscript (sorry): Rendering is not topping out the CPU or the hard drives. CPU is at 68-70%, hard drives appear to have plenty of lounging-around time.

Dennis

Dennis

Vegas Pro Version 21.0 Build 108
Windows Pro 10.0 20H2 build 19042.1110
AMD Radeon R9 280

Processor    Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz   3.30 GHz
Installed RAM    16.0 GB (15.9 GB usable)
System type    64-bit operating system, x64-based processor

 

maltedmedia.com/bathory

kcarroll wrote on 6/13/2002, 12:58 PM
The fact that you seem to be seeing a render time that is getting progressively longer as the completion percentage increases, makes me wonder if this might be a Windows Virtual Memeory problem.

Although I know nothing about VF's actual written code, I would suspect that as more of the project is rendered, VF finds itself dealing with a larger and larger data file that has to be swapped in and out of memory. Once your physical memory was exceeded, VF would have no other option but to go to virtual memory resources. If your VM settings were incorrect, or if the disk it is assigned to has space or fragmantation issues, you would see huge delays from any program requiring the resource.

If there are any Windows Gurus out there, jump in now!

kcarroll
Kalvos wrote on 6/13/2002, 1:11 PM
Virtual memory is an interesting thought.

The recommendation for my DAW is a fixed VM swapfile of 512MB. If VF uses huge chunks of VM by rendering in uncompressed format (does it do that?) it might exceed the swapfile.

But between physical memory and swapfile, that's still 1 GB, and this is a 136-second file. Likely?

Thanks for that idea. I might set the VM back to Windows management and see what happens (but I am worried about realtime audio being affected).

Dennis





Dennis

Vegas Pro Version 21.0 Build 108
Windows Pro 10.0 20H2 build 19042.1110
AMD Radeon R9 280

Processor    Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz   3.30 GHz
Installed RAM    16.0 GB (15.9 GB usable)
System type    64-bit operating system, x64-based processor

 

maltedmedia.com/bathory

kcarroll wrote on 6/13/2002, 1:43 PM
Dennis;

My understanding is that 136 seconds of uncompressed video and audio could be pushing the 1 GB limit.

You really need someone who is much deeper into the dirty world of Windows. I know just enough about it to be a real danger to myself.

Like I've said many times before; "Please God, give me a version of VF that runs under Linux!"

kcarroll

P.S. (Late addition) Keep in mind that if your VM scratch file is being written to a drive that is fragmented, you might see just this sort of problem.

KLC

Kalvos wrote on 6/13/2002, 2:34 PM
Thanks for sticking with me on this.

I've searched the knowledge base with no luck for any of these issues.

Changing the swapfile back to Windows management did nothing. Rendering was the same.

Maybe it's a format thing? I just rendered a 50-second bit complete with audio and effects and titles in 6 minutes -- but the video was one Pinnacle-produced .avi (Indeo 5) and the other was a Ulead-produced MPEG-2.

Likewise, I rendered a 2:30 clip in 10 minutes using Pinnacle-produced .avi and Ulead-produced MPEG-2.

The long-rendering problem came from VirtualDub produced files of any type.

Is there some way I should produce my original video clips so VF doesn't go to sleep during rendering?

Once I get the info in hand, I think I can create the originals without problems so they'll work in VF. (I deleted Pinnacle and Ulead after I bought VF! Duh for me!)

Continued thanks,
Dennis



Dennis

Vegas Pro Version 21.0 Build 108
Windows Pro 10.0 20H2 build 19042.1110
AMD Radeon R9 280

Processor    Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz   3.30 GHz
Installed RAM    16.0 GB (15.9 GB usable)
System type    64-bit operating system, x64-based processor

 

maltedmedia.com/bathory

kcarroll wrote on 6/13/2002, 2:51 PM
OK......., Here is one difference between what you're doing and what I do. I am using the Main Concepts MPEG-2 plugin sold by Sonic Foundry as a download.

When I render MPEG-2s from freshly captured stuff, I have never had a render time that was worse than 4 to 1. (One hour rendering for 15 minutes of video.) My rendering times also seem to be linear. (The last 25% takes about as long as the first 25% did.)

Maybe VF is having an allergic reaction to "Mixing & Matching"! (???)

kcarroll
Kalvos wrote on 6/13/2002, 3:23 PM
Yes, I bought the MPEG-2 along with VF. But I can't capture to it -- it doesn't show up in any other applications or the control panel multimedia video codec section (I posted that elsewhere).

All I can capture in VF apparently is uncompressed video (and I have several hours of original video to edit from) -- nothing in the help file or the knowledge base shows me how to capture to that nifty MPEG-2 plugin.

Do you know how to capture in other than uncompressed form? Am I just dense?

Dennis



Dennis

Vegas Pro Version 21.0 Build 108
Windows Pro 10.0 20H2 build 19042.1110
AMD Radeon R9 280

Processor    Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz   3.30 GHz
Installed RAM    16.0 GB (15.9 GB usable)
System type    64-bit operating system, x64-based processor

 

maltedmedia.com/bathory

Chienworks wrote on 6/13/2002, 3:46 PM
VideoFactory's capture program will capture in DV from DV sources or uncompressed AVI from analog sources. (Unless you get an external analog->DV converter like the Canopus ADVC-100, then you'll be able to capture DV from an analog source.) You really don't want to capture directly to MPEG unless you are destitute for hard drive space or are planning on doing no editing at all. DV is so much better for editing that it's definately worth the drive space it takes. It's about 1/5 the size of broadcast quality uncompressed AVI. If nothing else, you can capture short sections as uncompressed, then render these sections into DV as you go to save space.
Kalvos wrote on 6/13/2002, 3:58 PM
Thanks -- I have the disk space. It just seemed, well, a bit overmuch! But VF renders these at quite a good speed, so I guess that's the tradeoff.

Thanks to everyone who helped on this. I am gonna go buy another disk drive, though, just in case!

Dennis

Dennis

Vegas Pro Version 21.0 Build 108
Windows Pro 10.0 20H2 build 19042.1110
AMD Radeon R9 280

Processor    Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz   3.30 GHz
Installed RAM    16.0 GB (15.9 GB usable)
System type    64-bit operating system, x64-based processor

 

maltedmedia.com/bathory

kcarroll wrote on 6/13/2002, 4:45 PM
Well....., I see that I'm a couple of responses late here,.....but whatever!

Kalvos; On my drive home, I was thinking about your last few posts, when something came back to me. Months ago, when I first started frequenting this forum, I remember seeing a post from one of the more knowledgeable people, admonishing another user to "Never try to string together and re-edit MPEGs". If I remember the thread correctly, one of the things that can happen is really long renders.

I have always done my editing in DV captured AVI (I use a Canopus ADVC-100), and I only crush it into an MPEG-2 when it's done to my satisfaction.

I'm no real expert, but the comments by Chienworks seem to support this approach.

I noticed, upon arriving at 50, that your memory does start to go. (As an aside; One of the surest signs of "getting old" is when you notice that pretty girls have stopped smiling at you, and are now laughing outright!)

kcarroll


Kalvos wrote on 6/13/2002, 8:54 PM
You said: "I noticed, upon arriving at 50, that your memory does start to go."

I had to write that down. I'm 53. :)

Anyway, I think I've got it going. I'm doing the capture directly from the video capture card's native software, and the rendering appears to be going fine.

Dennis

Dennis

Vegas Pro Version 21.0 Build 108
Windows Pro 10.0 20H2 build 19042.1110
AMD Radeon R9 280

Processor    Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz   3.30 GHz
Installed RAM    16.0 GB (15.9 GB usable)
System type    64-bit operating system, x64-based processor

 

maltedmedia.com/bathory

Grazie wrote on 6/14/2002, 1:01 AM
Kalvos - great!

If I've learnt anything from all this DV stuff is K.I.S.S. ["keep it simple stupid"]. Just because a software publisher says what MAY be done I stay with what CAN be done.

It's the creative and intuitive side I'm looking for - not only in NLE's but also my standard Word and Excel packages.

Soooooo... I now tend to start with the basic "can do's" and slowly build up my arsenal of activity-tools to "can't do's" and STOP. This may be a real downer for myself who is always looking for more from a S/w package, but hey even the code in these packages was written by frail humans. N'est pas?

Using VF is a dream. I use it for the usual stuff - but using Studio 7 for the Print-to-tape works for me.

I've read posts on the "Dark Side" saying something along the lines that "All I want is this @=?#ing package to do is what it claims to do!" that's different to VF - VF rocks! However, there is an argument that says "Don't put all yer eggs in one basket" I've spread my betting over VF,Studio7 and - yes - VW. So that's a total of NLE packages equating to under £200 GBp. When I read of the experiences of others I now consider myself lucky/fortunate.

Golden rules for me are also :

1. You can never have enough memory and storage AND do everything to keep your Main processor from working overtime.

2. Capture AND edit in native DV [yes yes I know this IS a lot of HD disk space].

3. Confirm the final cut/video is what yer want.

4. Select a really tricky selection - lots of trannies and dissolves, throw in some PiP just for good measure plus some aduio effects - this maybe less than a minute, and experiment with render times and quality.

Okay dokey, I started off talking about KISS - I've ended up with rules I try and stick to, so whose perfect - I think that's my point! If it works for me/you DO IT! Then start pusing the envelope. Phew - finally got there!

I've really enjoyed reading all the VFers contributions on this particular thread. And d'yer know what? I've also learnt more.... strange that eh.

Ahem! Krehbiel where are you, and where are on this problem you've been having? C'mon gives us an update... if you can.

Grazie