The turning off of preview for faster rendering originally stemmed form Vegas Video 2.0, but that was abolished as a speed help in V4, if I remember right. Somewhere I've got an email explaining what changed, but darned if I know which year archive it's in. But your speed differences are more significant than I'd have thought.

Yes, John, the source material is on an external firewire HD and I rendered to an internal drive on EIDE.

Because of the time involved, this is not something I would repeat too often, although I shall be doing another render in a couple of weeks, but I am wondering myself if the first render was affected by some other variable - as far as I know every other setting was identical but maybe the system was having a "slow day".

Is the internal drive a system drive or and entirely separate drive? Is it on the Primary IDE channel or the Secondary? What else shares the channel?

These were long renders so it seems like they were nowhere near real time. I'd interpret that as meaning the writes were happening much more slowly than the disks could write them. Makes me wonder if there was some sort of CPU hit associated with the internal disk.

Long ago I was playing with render times to different media and found that I could write a particular CPU intensive render to a parallel port zip disk nearly as fast as to a firewire disk. The render itself was so slow that either drive had plenty of time to write the data.

Rob Mack

Rob, I'm rendering something else on that machine right now, but I'll take a look in the BIOS later. It definitely isn't a system drive.

The slow time would mainly have been caused by rendering superimposed captions right through the 30 min program, plus rescaling from HDV to MPEG2 widescreen.

I just spent a few minutes trying to duplicate your problem, but with no success.

You don't have to render for hours; just a few second of video usually will do the trick. I rendered 30 seconds of video to an MPEG-2 file. No matter what I did, it took 50 seconds. I tried turning off Preview; I tried 128 MB RAM preview; 64 MB RAM preview; and 0 MB RAM Preview. Someone suggested that this setting can make a difference, but in Vegas 6.0d, when simply encoding/rendering to MPEG-2, it makes zero difference.

As far as a second hard disk not making a difference, I am quite certain that it DOES make a difference, but the amount of savings is fixed and is usually more or less the same as the time it takes to copy the size of your final rendered file. Thus, if your final MPEG-2 file is 4 GB, then the time saving is the time it takes to copy 4 GB, which might only be a few minutes. Compare to seven hours, this is lost in the round-off error. However, if you are rendering to AVI, and the file it going to be 25GB, and the overall render is only 25-30 minutes, then the savings, as a percentage, can be quite substantial. It is ALWAYS worth doing, if you value your time.

Thanks for your comments John.

Firstly - this was never a problem as such - I set the PC to render when I finished work and it completed the job overnight - it was just a different result time wise than I expected.
The important thing was that Vegas did an excellent looking render each time!

The main time taken I'm sure is all the number crunching which goes on adding superimposed captions, creating the MPEG2 and rescaling from HDV etc, and as you say, once this is done the actual writing is a less significant part of the process.

Incidentally, for RobMack - the internal drive I was writing to was the Secondary Master, and shared that EIDE channel with another Hard Drive not used in this project.

The more interesting difference was the slower-with-video-preview-OFF result, and whilst I have no knowledge to back this, I'm wondering whether in fact having the pixels displayed at whatever rendering quality is chosen might not be some sort of aid to rendering (?).

Peter

Fan and cooling check? - G

Fair question Grazie - no smoke without fluff ......

It probably is time for another vacuum session, but whatever the situation, my three renders were on consecutive days so there would be no great variation in the fluff coefficient!

- I know that cooling has been responsible for rendering not being finished, but have you heard of times when rendering was completed but took longer because of suspected heat?

Peter

I wonder if the render time difference changes depending on whether you use the preview window itself or set preview to secondary monitor.
I usually render with the vegas preview window, due to the fact you can minimize vegas and use the screens for other apps.
If you leave the secondary monitor preview on that screen or monitor stays on the preview, overlaying on top of any app that might us it.

They are interesting results. Did you reboot between renders? If not, maybe some of it was still "cached" somewhere for the second/third runs.

The testing I did comparing V5 with versions of V6 were with generated media with output to HDV m2t, not resizing. I found that dynamic ram settings and the preview on/off did come into play with the effects/generated media used in the veg, which included Text, chromakeyed png, and a changing color gradient map. RAM probably doesn't come into play with resizing, that may be where the good/best settings come into play (?).

Then I see in another thread that some renders stop with the dynamic ram settings too low.

I guess the only thing to take away from this is that "mileage may vary". It totally depends on what's on the timeline as to the expected/unexpected render times.

I'm not questioning the render time overall, just observing that when it's that long there's probably plenty of time to write the render to disk, so i'd be wondering what it was about the internal disk that would add so much time to the render. Seems like there's more here than meets the eye.

Rob

Thanks Peter,

I understand that you're not reporting a problem, just an observation.

Do you have your Windows page file also on that disk or channel? Is Vegas using it for temp files? It's a real curiosity to me.

Rob Mack

Howdy....

I have found that there are renders where drive location/speed makes a difference, and renders where it doesn't. Renderes that are far below real-time require so much cpu-crunching that the drive becomes irrelevant. On the other hand, I have noticed that when rendering to wmv, with the preview window open, my CPU sits at 60%, whereas with it closed, it runs at 100%.

I always close my preview window when I render, just in case, but for effect-intensive renders, I'm not too concerned with teh location of the hard drive.

Best,

Benjamin


----------------------------------------------------------
http://www.neo-fight.tv <----- Have you seen it yet?

I wonder what "preview on" means. There is a preference setting in Vegas that says it should (or shouldn't) update the preview window during a render. I usually turn that off. Then there is the other "off" standard: closing/killing the preview window entirely. And yes, there is the secondary monitor too (which is probably almost like running another render - to DV/Firewire).

Good topic for testing.

Yes, I'd think that if preview is being sent to an external monitor then Vegas would have to be doing DV25 encodes along with your other encode. So if I were to test it I'd try:

--External preview on
--External Preview off
----Both again with the "Update Preview while reindeering" unchecked
----Same with preview on second computer monitor
----Same combos with the preview window closed. (If you close the preview window while outputting over firewire do you still get the firewire output?)

Rob Mack

found that dynamic ram settings and the preview on/off did come into play with the effects/generated media used in the veg, which included Text, chromakeyed png, and a changing color gradient map. RAM probably doesn't come into play with resizing, that may be where the good/best settings come into play (?).

My brief test was simply rendering 30 seconds of NTSC DV AVI to MPEG-2. No fX or anything; just a straight encode. I "turned off" the video preview by simply closing the preview window. I don't know what Peter meant by "video preview off." I didn't know about the Preference to turn it off during render. That option was enabled during my tests.

Interesting thought that the type of media might make a difference. If I had infinite time, I could re-do the test with still photos.

...

Hmm ... I just did a VERY quick test with one single still photo, and I performed the test several times (to avoid caching making a difference). Sure enough, there IS a small difference between having the Preview window on and off (off is faster by about 10%). Dynamic RAM was 156 MB for all these tests.

Just another confusing data point.