I agree with Geoff:

If you render i.e. full HD AVCHD, you read max 28 Mbps (Mega bit per second) = approx. 3 MBps (Mega Byte per second) from the disk where you have your input media.
Most rendering does not output over 30 Mbps = approx also some 3 MBps.

Now - most modern hard disk drives read and write with some 40-100 MBps - so probably any harddisk today will be at least 15 times faster than what you need for rendering at "full speed" (1 minute finished video takes 1 minute to render).

Sorry, flawed logic. Rendering is not real time, so the rendering process will read/write as fast as the render and encode can run. I've got lots of situations (especially on SD work) where the render can run 3 or 4 times faster than real time, so the video stream is being written around 15MBps. On occasional sections where re-encoding isn't necessary i've seen DV streams go through better than 10x real time, writing data around 40 to 50MBps.

On the other hand, a lot of my AVCHD renders take 4 to 20 times longer than real time.

You'll never "outrun" your hard drive for rendering. A modern hard drive will write at over 50MB/sec. Actually closer to 100MB/sec.

I'm using an SSD for boot drive and another for data (non video). I could never go back to a slow motion mechanical drive. The biggest advantage for me is application opening. Nothing requires more than 1 or 2 seconds.

So, no correct answer, it all depends.....

Personally I'd suggest the money that would be spent on an SSD would be better spent on a faster CPU. The other thing is the rendered data isn't going to stay on the SSD, it's going to have to be written to something affordable and during that process the speed of the SSD isn't going to help.

Personally I've never understood the amount of importance given to render time. If time to air is important then everything in the chain matters.
When we had to punch out a lot of DVDs of kiddie football quickly we used disk caddies plus a capture PC, an edit PC and a render / author PC. We also used Peachrock's Multirenderer to automate the rendering, I'm still using that tool and I haven't given author a dime in ages.

Bob.

Sorry, flawed logic

My idea was that the OP himself should use the example - with numbers from his given environment - to calculate if he might gain anything buying a fast SSD.

If we use the numbers from Kellys "occasional" example it shows that even a standard hard-disk would be fast enough.

And at the end this is all just theory because Vegas does a great job trying to open and pre-read the input-media when rendering. Check the Windows Task manager / Resource monitor - and you will see the results of some very good programming.

Thanks guys, I am still a little wary of SSD because of the finite life span, but I do like the sound of the speed of the OS and applications running faster.

Paul B

I'm a big fan of hardware RAID10 for working with HD video because it allows you to multi-task. RAID10 provides an increase in speed combined with redundancy if you use (4) or more matching drives. For instance, last year I had a 2TB drive fail while working on a huge project. I just pulled the failed drive & replaced it with a matching drive & no time was lost.

A few of our premium clients send uncompressed HD & want uncompressed HD in return. Therefore our source video is copied to a (4) 2TB drive RAID0 and our work/target folders are all on an (8) 2TB drive RAID10 for redundancy. Both RAIDs have read/write speeds of around 400 Mb/s. Stock video footage is on a separate (2) 2TB drive RAID0 and background music on an SSD.

When rendering HD video our 6-core 980X CPU overclocked to 4ghz can max-out at 100% useage. At the same time we can transfer files to/from our clients' drives without any loss in rendering performance. I have never had a bad Blu-ray burn even while rendering-out 2 projects in the background. I can also burn (2) DVDs at once and I have even burned (2) Blu-rays at once, although I prefer not to take the risk due to the greater cost of BR discs...

For the price of a 500GB SSD, which is really the minimum for serous HD work, you can get (4) 2TB hard drives and set them up as a 4TB RAID10 with approx. 200Mbs read/write speeds. Or, you could make (2) a RAID0 for source video (that has been copied elsewhere) and (2) a RAID1 with redundancy for your target drive.

I would avoid RAID5 & RAID6 for video. It takes too long to rebuild the data if a drive fails. HD files are huge & drives can fill quickly. If you max-out the capacity of RAID5 or RAID6 it can take more than a day to rebuild the data...

WOW Rhino that was a great read, I have always wanted to build a raid, our projects are getting bigger and I am always stressed about losing data. What type of enclosure are you using or does it really matter? and would a NAS fast enough to edit from if attached to a Gigabit network. that way I could have all the files available to any of the workstations we have.

Paul B

@Chienworks,

That's not exactly correct either, because you have several steps that occur before encoding and file output. First, each clip on the timeline must be decoded. Then, the FX must be applied. What is often overlooked as a bottleneck, is the decode phase. Decoders are often not multi-threaded and even if they support multiple threads, it often is no more than 2 or 4, at most. Why is this so? because decoders are designed to work best with output devices, which generally operate between 50-60 fps. There is really nothing to be gained by writing a decoder that can run at 200 or 300 fps, unless you are doing 3D or working with a specialized monitor. This isn't a video game that we're talking about here, but rather video with a fixed fps.

The decoder bottleneck is only reached with extremely fast systems (fast CPUs with multiple cores and hyperthreading, plus a fast GPU and an SSD, etc.), but it does explain why people complain that their renders do not cause the CPU and GPU to "pin" at 100% usage during a render. Generally, though, the disk I/O system is the bottleneck, if one does exist.