[Dave Haynie]

Yeah… I shot a Catholic ceremony, back in the days of tape, and got really nervous as that 60min point came along, then passed. But just so.. that’s the reason the pro tapes are 63min.

The shortest ceremony was not quite 15 minutes. But the reception/party lasted all night…

-Dave

[Dave Haynie]

Blu-ray is in 17% of US households, as of last September. I rekon the penetration is much higher among, well, anyone interested in viewing films in their home (eg, most people who might receive a screener).

You can’t count on this, so if you’re only able to supply one disc, it has to be DVD. If you can hand out an Ansco case (you’re certainly going to want to including all your details, anyway), why not include two discs, one of each.

-Dave

[Dave Haynie]

I can add to that… if you have an audio editor like Sound Forge, you can pretty easily find the noise using a spectrum analyzer function. Look for a peak, usually in the low end (as many have suggested, 60Hz is really common in the US, 50Hz in Europe).

Use Sony’s “Track EQ” plug-in, or something like it. I like this one, becase it allows you to actually draw the band-stop (notch) filter than you like (set the type to “band”). You can slide the notch up and down using the “Frequency” slider, and set the bandwidth to ensure you get enough of the noise to hide it completely. If you’re also a Cakewalk/Sonar user, Cakewalk’s Parametric EQ is similar, but maybe a bit nicer at the GUI. NewBlue’s Paramertic EQ will do the job too, and has a nice enough sound, but I miss the graphical view.

I used this technique for just this purpose back in the early 1990s… my first digital camcorder, a small JVC model, had the annoying habit of recording motor noise when used with the internal mics. So I built a notch filter for that one sound, and it worked pretty well for years. This taught me the even more important lesson about camcorders — built-in mics stink. Use an external mic.

And don’t be cheap about it. I have over a dozen mics: dynamic, condensers (shotguns for camcorders, others for voice and instruments), even one ribbon mic. I have two Radio Shack mics… the purpose: those are the ones you hand to people who ought not to be trusted with a $500-$1000 microphone.

-Dave

[Dave Haynie]

I have a piece of HD production, I have used the “tools/Burn disc” and selected blu ray and used a regular dvd in my regular dvd burner. It seemed to burn the disc, but the disc will not play in my panasonic blu ray player, and shows it as an “Unsupported Disc”.
While DVD Architect can produce a Blu-ray file structure on a regular DVD, this is almost never supported by DVD players. No real idea why, it just isn’t.

Even more curious, nearly every Blu-ray player supports an AVCHD DVD. AVCHD is, of course, the camcorder format, originally defined for HD recording on 3″ DVDs and Blu-ray discs (some years back, I had a Hitachi Blu-ray camcorder). AVCHD was derived from Blu-ray, but it’s not identical. For one, I believe (as the name suggests) that only AVC video is supported — BD supports AVC, MPEG-2, and VC-1.

All Blu-ray players that support AVCHD handle 2x DVD speeds. You can legally put AVCHD file structures up to 18Mb/s on a DVD and expect it to play in nearly any DVD player, including the Sony PS3. Blu-ray players that support flash memory cards will usually play higher bitrate AVCHD file structures.

Unfortunately, DVD Architect does not create an AVCHD file structure, only Blu-ray. I recommend the freeware tool “multiAVCHD” if you need to create an AVCHD DVD. Of course, do realize, you’re compromising on quality versus Blu-ray (in theory, anyway… in practice, since Sony’s AVC CODEC only supports 16Mb/s video, you actually can’t deliver better quality on BD using Vegas/DVDA… unless you can figure out how to get a valid BD format using Main Concept’s AVC encoder).

Is there something I’m missing? Most people on this forum are using the regular DVDs as Blu Rays for short productions instead of the high cost of blank Blu Ray media. I would like to do that as well.
AVCHD is definitely useful for short video, though it’s a little questionable as a distribution format to customers. While it is largely supported, there’s no guarantee that any given BD player will play it. And, for that matter, there’s no guarantee that any BD player will play back a BDMV disc on BD-R, either. You would kind of thing these industry people would for once get their act together and create linked standards, not the Chinese Menu approach that seems to generally rule.

There is mixed info about burning regular DVDs as Blu Rays. I have heard that you need a Blu Ray burner, but others have said that you do not need one, and a regular DVD burner will work. Also, Is there a certain format that I should use? 1440X1080? 1920X1080?
BD and AVCHD support the same video formats: 1920×1080/60i|50i|24p, 1440×1080/60i|50i|24p, and 1280×720/60p|50p|24p (and the “24p” can be either real 24p or “NTSCFilm” 23.976p). Keep the resolution you’re shooting in, when possible.

-Dave

[Dave Haynie]

Does vegas have a particular problem with handling mpeg files? I don’t use this all the time myself but a friend and I were wondering. Whenever we use mpeg (and sometimes mov files) vegas seems to lock up and show “media offline” frequently.
The usual “media offline” message is displayed when you’re modifying the file in question in another application, or, of course, when the file is not actually there.

Vegas, like most NLEs, is not terribly tolerant of errors in media. Particularly if you’re seeing occasional red frames in MPEG video, that’s an indication you have some kind of corruption. Is this MPEG video from an HDV camcorder, or some other source? Are you editing in MPEG-2 TS (.mts, .ts, .m2t, etc) or MPEG PS (.mpg) format?

I haven’t had this problem myself with other formats so I wondered if it meant Vegas wasn’t really compatible with mpeg. Or could this be down to RAM, codecs or something like that? Just curious really.
I believe the MPEG-2 decoding is built-in to Vegas. In general, though, you can screw up your system by installing poor quality CODECs.. most video types, particularly Quicktime and AVI, are handled by CODEC plug-ins to a generalized multimedia subsystem. So the quality and reliability can vary greatly. One good reason to NEVER install a “CODEC Pack” like K-Lite… you may get buggy, slow, or otherwise inferior CODECs replacing your good ones.

MPEG is, however, more CPU intensive to work in that many other formats. MPEG-2 is slow, MPEG-4 slower still. The reason is that these are interframe compressed. So the first frame is independent, like a JPEG photo — the following 14 or so are based on changes made to that first frame. So Vegas needs more CPU processing and more memory to work in MPEG than something like DV or some AVI formats. And it’s of course worse if you’re editing in HD. Just the nature of the beast.

My second question concerns the preview window; no matter what I do (i.e. changing from auto to best full etc) it doesn’t seem to produce very smooth playback of transitions and effects. Is there any particular reason for this and anything I can do about it or is it just one of Vegas’ bugs?
Plug-ins are a similar issue. Each plug-in does some kind of video image processing. Each one you use adds to the CPU overhead Vegas will incur. Some will play back pretty nicely on a fast machine, others can’t. For example, I’m lucky to see 10fps peak out of the Neat Video de-noising plug-in, and it can be much less.

If you need to see and edit smoothly, and run our of CPU time to do this (and, given enough complexity, everyone will, eventually), you can selectively pre-render a section in Vegas. That’s the best option if you need to view the edited video. If you have lots of memory, you can also use the RAM preview feature, which sometimes makes things go faster.

And ultimately, video is one of the few things we do on computers that still needs more CPU time. If you’re editing HD video, you really want at least a decent quad core processor for this. My system is based on an AMD x6 (6 core) processor running at 3.2GHz, with 8GB of DRAM and 64-bit Windows 7. MPEG-2 playback on my system is “like butter”, MPEG-4 (AVC is the usual kind, also known as H.264 and MPEG-4 Part 10) is usable, but still slower than you’d like. If you’re seeing slow play without plug-ins in use on a four-core processor, you have some kind of problem.

If you’re working with an older processor, it’s your PC — you’re unlikely to see much different performance with any other editing program. Note that players can sometimes use resources unavailable for editing. For example, I can play back full HD in MPEG-4/AVC on my PC using only 6-7% of the CPUs cycles (that’s all six). This is because, using the right player, my nVidia 8800GT GPU is doing most of the heavy lifting. If I didn’t have that GPU, a CPU only play-back of AVC would take 40-50% of all six CPUs. So you can imagine, you might be in trouble even playing back full HD on a PC with only two cores and no GPU. Editing is more complex, and Vegas (and most other) NLEs don’t use the GPU to accelerate editing (they’re starting to… Adobe does this now).

-Dave

[Dave Haynie]

FCP doesn’t render to DVD or Blu-ray. It can produce both DVD and Blu-ray compatible video.

It is correct that Apple does not offer a Blu-ray authoring solution.. their DVD Studio Pro application does support DVD, but not Blu-ray. Given that Apple is the only major vendor of media authoring tools not supporting Blu-ray at this point, one must assume that the media content software part of Apple has to cow-tow to the iTunes store. While it’s hard to imagine iPods, iPhones, iPad, or Apple TV are really in competition with Blu-ray (given the 720p, 1.5Mb/s videos in the iTune store… Apple TV doesn’t do 1080i, none of the other Apple devices do digital video output of any kind).

-Dave

[Dave Haynie]

I would double check that the project type exactly matches your video clip types. The project media type sets what you get when you nest that file.

I use this all the time, and have never noticed a loss in quality. My only complaint is that it doesn’t import 5.1 audio.

-Dave

[Dave Haynie]

Yes I do get nearly 100% cpu utilization once I turn off HYPERCHEEZ, and a slight performance boost once I do.
I’m certain there are some things that Hyperthreading improves. But it stands to reason rendering might not be one of them. The code is fairly complex, and unless it all fits in cache at one time, and every thread is using that, things will slow down. I’m not sure how effective the data caches can be for HD video sized chunks.

This forum thread was reference to the Advertising HYPE of CUDA and nothing more…
CUDA itself is very good, and really being used in many applications. Not all that different than OpenCL, other than that “getting there first” factor, but that ought to shake itself out before too long. It’s more Sony’s selling CUDA support, then discovering that, while it’s technically measurable, it’s not significant. And yet, on video PLAYBACK, I see a factor of 8 improvement, rendering AVC with the GPU’s help, versus no GPU. That’s actually not done via CUDA, either, but simpler interfaces (DXVA or nVidia’s proprietary video acceleration API… they’re about equally effective on my hardware).

Then I went on to explore possible bottle necks and only found the programming of Sony Vegas to be the bottle neck. Like Codec of choice or single threaded effects, which seem to be few and far between for the most part.
Some plug-ins are just big and hungry, even when programmed correctly. I do agree that most of Sony’s CODECs and plug-ins are fine, but in any realistic setup, you probably have these from dozens of vendors. My only point was that you can’t make general observations about Vegas when you’re running plug-in in your benchmark… unless you’re trying to figure some general rule about the plug-in interface. And that’s perfectly valid.. it wasn’t all that long ago that plug-ins ran single-threaded, always.

From oerformance testing, I don’t think Vegas 10 has been updated enough since AMD and INTEL yield the same results for rendering.
The AMD chips commonly do very comparably to Intel on rendering-class work in many of the usual benchmarks. I’m not sure how much any of the very new instructions would benefit Vegas-proper anyway, though, as with the GPU stuff, they probably make sense in some of the plug-ins and CODECs.

And you need really tight coding to see a very dramatic improvement, depending on what you’re accelerating. Yes, particularly the newer SSE instructions can do four 32-bit ops in a single instruction, and the AVX stuff better still (I’m sure that’s not a concern, yet), but it’s more setup code and pretty much still all coded by hand, despite some experiments at Intel with vectorizing code generators. I did some SSE programming for software radio/DSP stuff a couple of years ago, and the overall effect was faster, but not profound.

They have improved things in Vegas 10, at least here and there. The AVC display, while not GPU accelerated, is faster than it was in Vegas 9 and earlier, and faster enough to be noticeable. As mentioned, they did rewrite the FileIO module pretty seriously, though I don’t know just what changed. Hopefully a positive move.

But I agree there are areas that need improvement, and have not been improved in recent times.

As a case in point, CS5 has been out for a few months already compaired to the Sandy Bridge, yet, I repeat, YET – it has support for the AVX instruction set, this new i7-2600k is just as fastas my 980x.
References? I kind of doubt it. For one, Windows doesn’t have support for the AVX instructions yet. An OS needs explicit support for additional register state preservation on context switch, in the kernel.. can’t be added elsewhere. Which won’t be in there until Windows 7 SP1. Which is coming Real Soon Now (sure, there’s been a leak out for couple of weeks, and developers have the beta).

Adobe doesn’t have any word on AVX support on their web site, either, and according to Adobe Engineer Adam Jerugim, they’re still investigating the use of AVX in their products (as of the 27th, anyway).

I find it shocking that 2 DNxHD clips bottle necked an HD. Most of my expereince is from native codec – 6MB/s tops to Cineform at 25MB’s
It just barely started to be the bottleneck… I really should have tried three streams. They’re 145Mb/s… 18MB/s, and I was rendering to relatively lightweight output, MPEG-2… it’s render a bit better than realtime. Which means, the 18MB/s is really more like 20-22MB/s, depending on just how much better than realtime you want to go. Say the drive supports 50MB/s reads (could be faster, no guarantees), so the 40MB/s ought to be just dandy, right?

Well, maybe not. Seagate specifies a random read seek time on my 1.5TB drives of 8.5ms. Assuming no fragmentation, you’ll have to seek when jumping between files, and, on occasion, from track to track, though that’s hopefully faster (it would be, if the drive was totally defragged, which mine wasn’t). Each seek consumer 0.85% of the drive’s bandwidth. And they have to come in pairs.. you seek to the second file, then back to the first. If the program does 24 per second, that along would be enough to slow down two 20MB/s streams. And you wouldn’t need that every second to add up to a slow down… I only lost about 5% CPU over the course of a 15 minute render.

Does it make sense? 20MB/s would be an effective 33.3fps, assuming the original file was 30p/60i. Two streams, that’s 40MB/s, not much data by today’s standards. But it has to be decoded to raw for work, so that’s about 527MB of RAM per second, in 32-bit pixel mode. And that doesn’t take into account any buffer memory for rendering or output.

So maybe there’s an issue here. Back in the old days of computer audio, you always got to tweak your DAW program to optimize the amount of RAM that would set aside for just such buffering. And this was precisely to allow the user to tweak the system… more RAM means more tracks but more latency (bad for realtime overdubs, good for mixing those 64-tracks without glitching on playback), less RAM means less latency but fewer tracks (less buffering = more seeks per second). It’s always kind of bothered me that Vegas didn’t let me define how input buffering worked, or how much memory it could use. Obviously, 527MB of buffer memory on a 32-bit system is bad, that doesn’t leave enough for everything else, since you only get 2GB total. On my 8GB system, Vegas can take 2GB, maybe more, if it’s going to make things go faster.

Anyway, if they’re not allowing this much RAM to be used, they’re doing exactly what the DAW does — adding seeks to reduce buffer size. Of course, they could read larger blocks of compressed video and only deal with a few uncompressed, to speed disk I/O up. But that’s still a bad idea on a small system, particularly if you don’t believe typical disk I/O is ever going to be a bottleneck.

Again from the Processing LAG on the CPU, like you note Neat Video’s degrain, any sort of filter for that matter if it’s: multithreaded/muliticore/hypercorn supported, etc.. will always slow down the CPU, way below any bottleneck in the system…
Depends on the plug-in and the system. But yeah, just about any non-trivial plug-in, even if it’s a fully modern one, will emerge at the bottleneck. That’s ok, as long as you’re seeing close to 100% CPU use… that should be the goal, to use your system to its fullest. When it drops, that’s a bottleneck you can do something about.

-Dave

[Dave Haynie]

I switched to Nvidia cards mainly for Premeire Pro CS5. I didn’t bother with the Vegas 10 lateral grade.
Well, as I pointed out, if your main priority is video, that is precisely the right reason to buy a new GPU card. Otherwise, you don’t need it.

Vegas 10 is far more than a lateral move — it’s an upgrade if you’re a serious Vegas user. But like every upgrade, it contains things people may care about, and other things they may not. I often use Vegas for live multitrack audio recording (I bought the Sonar X1 upgrade as well, but have yet to get that one working with my Tascam US-1800, or figure out the flow of the thing), so the per-track VUs and additional audio features are key.

I do agree that apps should support OpenCL (OpenGL is also a useful thing for some video FX, but not the same kind of thing), but as I understand it, many of the app developers judge it not-ready-for-primetime. nVidia and AMD/ATi are both supporting OpenCL, so chances are, this won’t last.

Using a multiple SSD’s for assets and Rendering made no difference in rendering speeds, still averages the same as a single HD or a Large RAID with 2gig cache.
Depends entirely on where you bottleneck actually as. As I posted in my benchmark, just two DNxHD streams made my input drive the bottleneck (7200RPM SATA 3.0Gb/s link). Once you add in plug-ins, though, there’s an awesome chance they become the bottleneck. I’ve run a bunch of BCC7 stuff, the Neat Video noise reduction plug-in, etc. which completely dominate rendering times. That’s a very good argument for pre-processing your video for things like Neat that might involve your whole shoot. I spent the better part of a week preprocessing all 6 hours of a wedding shoot though that (in a dark nightclub, not the usual thing), so I could then forget about those issues.

But if you’re not seeing something close to 100% CPU, that indicates the kind of bottleneck you’d like to remove. I have seen this with plug-ins, I have seen this with hard drive access. You never know where they all are until you discover which of the bottlenecks is the dominant one. If I have a slow or single-threaded plug-in, I might read video from a USB 1.1 drive and not go any slower.

My basic point stands — I can get damn near 100% CPU with an AMDx6 processor, once I tune up the project. If you’re at 50%, you have work to do, and you have only so far proven it’s not the hard drives. So back it up. Try 8 video and 16 audio tracks from multiple drives or faster drives. SDDs are good idea for input, but all that does it remove the seek penalty. If you eliminate enough CPU work, that becomes the bottleneck… put some assets elsewhere, and that one bottleneck is lessened. SATA drives all run in parallel, so even with a single wicked fast SATA SSD, you still have requests from Vegas coming in faster than the drive can supply data, in the simplest case (CPU not set up as the bottleneck).

Sure, you can get 700MB/s sustained with a single stream read off the best SSDs today. But not every SSD does this. And your memory bandwidth is 20+GB/s on a modern CPU… the CPU is still waiting for data, if it’s not otherwise occupied.

Also, writes to an SSD are, currently, slower, by a good bit, than writes to an HDD. Many, many writes all happening at the same time probably run faster, due to the lack of seeking… one reason these things are starting to be popular in big-ass datacenter servers. But a single stream or two writes faster to a good HDD.

Although: I noticed that just after a few months All this rendering and asset managment KILLED, I repeat KILLED the SSD’s. Nand Flash is not a consumer product, Xerox needs to sell them, they are only good as prity paper weights.
The cheaper SDDs use mult-level (MLC) flash. This has as little as 10,000 write/erase cycles, and the write times are even slower than SLC flash. The idea with MLC is that there are multiple charge levels at each memory cell, so the device can store 2 or 3 bits per cell. SLC memory writes faster, but still not all that fast, and can deliver 100K-1M writes per cell.

All SSD and other flash controllers do wear leveling.. they logically map sectors to ensure you’re not pounding on the same cell. It’s kind of an enhancement of bad block mapping that’s been used on HDDs since the transition from ST-506 to PATA. But that only helps when the drive contains a mix of static and dynamic data. If you constantly rewrite the disc, no good. This is why SSDs are usually suggested for system drives (as long as you move the swap file somewhere else), not so much for project drives.

Vegas Takes lirterally 3x longer to render audio than Adobe products, audition/soundbooth/PPro. Of course all the settings are slightly diferent and I’m no audio engineer with super sweet hearing. But it sounds the same to me.
I dunno… it’s so fast, I never really gave it much thought. I have found Vegas 10 faster at some file-based things, I have not benchmarked audio. And as pointed out, the CPU time in the File I/O module vs. Vegas-proper changed fairly dramatically from Vegas 9 to Vegas 10. So clearly, the Vegas software people had some mission in mind here — they probably don’t fix what isn’t broken (well, one can hope).

The other thing.. ok, it’s been over a decade since I used Premiere, in any form — it was just so wrong (you need the app to match the way your thinking goes.. that’s why there’s more than one), I could no longer use it. And one big complaint was that it completely ignored audio. Vegas started as a DAW… they added video in Version 2. It still does audio at the level of pretty much any other DAW. I’ve kept Sonar alive, largely because I can get MIDI, audio, and sample synthesis in the same app.. when I can get it working 🙂 But for audio-only, I still start with Vegas.

I used to use Audition back before Adobe owned it and it was called Cool Edit. Good enough, but I’m not quite sure it’s as powerful as Vegas, and they certainly get to leave out some overhead not doing Video. The main reason for buying Cool Edit in those days was a very good but proprietary noise-reduction plug-in.. the price of CE and the plug-in was about 1/3 the price of Sonic Foundry’s plug-in (for Vegas or Sound Forge… standard DirectX plug-in, versus Syntrillium’s proprietary format.

With that said, there’s certainly a good deal of talent in optimizing HDD thoughput with any application. So of this is based on how you tweak your system, and the individual app. I started doing PC audio stuff back in 1994 (moving over from the Amiga), and in those days, getting anything to work… well, let’s just say, it helped to be a computer engineer. In modern times, if you’ve ever played with the open source VLC video/audio player, you’ll find it simply fails at playing high bitrate HD video. Far as I can tell, that’s entirely problems with their file reader… they just break down once the bitrate gets too high. Of course, the classic idea in UNIX/Linux was “byte at a time”… most DAWs grab huge chunks, the only way to actually get full performance out of any kind of storage device.

This leads me to think part of the Vegas rendering issue is dealing with sound bits.
So, given all the benchmarks, I assume you tried a render of the same project without audio. Did that support your hypothesis?

I just like speed and a good looking finnished product.
Ditto. But the most expensive time is editing time. I really don’t care if a render takes 2x as long on one app as another. Sure, I’ll take what speed I can get at unit quality. But even if it took me a day to render, I’m spending a week or more on any non-trivial edit. The real concern is saving clock time. And, as mentioned, there are many things along the way that, once shown to be bottlenecks, I can pre-process in various ways.

Of course, for my stuff, it’s just me, I can usually devote a day to render, as I’m always pipelining projects. And I always find the bottleneck, if I don’t believe my system is delivering the performance I paid for.

-Dave

[Dave Haynie]

Sony Vegas coding has not been updated in many years. New buttons, pretty colors, a few filters are in deed the bulk of updates. Support for new file formats of video cameras are the primary reason for the updates, that’s it.
Not entirely. They completely re-did the file interface engine for Vegas 10. They added the VU meters, per-event audio plug-ins. While they didn’t do GPU acceleration at runtime, AVC playback is faster than in Vegas 9. And they added the OFX plug-in architecture, which is a very significant improvement.

I do agree, however, that some things have been ignored. I mean, why, after all of these years, is Sony’s AVC plug-in limited to 16Mb/s output at CBR?

The old magic number of 2 gig’s per core remains the same from Vegas 6 to today.
That’s a general rule for any heavy-lifting on a PC, not just for Vegas. It should be obvious: 4x the CPU can actually take 4x the memory.

Sony Vegas Pro really likes FOUR cores and about 6 gigs or ram.
I have an AMDx6 CPU, and can get that same ~95% utilization from all six core. That’s with 8GB of memory. But it’s far easier to find HDD is a bottleneck. Read on…

While looking at the disk I/O meter in the computer I realized that my computer is only creating a file at around 5Mb/s – mega bytes per second! Why so slow?
First of all, watch your units. “Mb/s” = “mega bits per second”, “MB/s” = “mega-bytes per second”.

There are two possible reasons. The first: HDD isn’t your bottlneck. The hard drive speed is NEVER the bottleneck for output. At best, you’re creating something in the 100-150Mb/s range, rendering to Cineform or DNxHD, maybe 300Mb/s if you’re crazy enough to use RAW video. But even a single hard drive can keep up with one such stream.

However, rendering the output stream to the wrong place absolutely can slow down your render. On a simple project, the CPU will nearly always be the bottleneck, and for a properly managed complex project as well. Hard drive read time is not your bottleneck in most cases… but hard drive seek time can easily be. And while a RAID helps you on full throughput, it actually makes seeks worse, at least potentially. That’s because a single RAID sector, read from multiple drives, can’t be ready until all four drives are ready. So your seeks are always the worst-case of all N drive seeks. This is usually not an issue, because your logical sectors are N times larger, potentially, than a single drive’s real sectors.

But there are limits. Vegas is only going to read so much data into memory at once… in processing video, you’re using significant chunks of data at once. So while you may have a crazy fast drive, too many assets on that same drive in the same project used at the same time, and it won’t matter — your performance will be bound by seek time. How much? On a single drive, I was able to just barely hit the seek-imposed limit on my x6 machine with just two DNxHD ~150Mb/s files on the same drive. Move one to another drive, and I’m back to full speed.

Now that I have a powerful computer with 12 gigs or ram, why not use 5 gigs of it and make a ram drive! I scoured the internet for such a device.
Well, you could. But it’s only going to be useful if you can put a significant set of input assets on that RAM drive. Output is never the bottleneck, it can’t be. As long as you’re rendering to a device other than one containing input assets, you’re doing just fine. A USB 2.0 drive will not slow anything down on most output renders (sure, you could find some crazy old uncompressed format to challenge that, but there’s no point).

I mean if Vegas sends off the frames one at a time and then sends that to the HD, there would be tremendous lag in creating a file!
One would certainly hope this process is pipelined, and it did seem to be is was. You do have to test this with Vegas only, no plug-ins active, since they can change the order of processing. It’s actually the right thing, to write one frame at a time to HDD… multiple threads writing multiple sections of a file will run into their own seek time issues. Vegas proper and the Vegas File I/O manager are separate processes. Maybe you’ve seen more detail here than I have, but it makes no sense to build the architecture this way, then have the main process waiting for the file I/O process to complete. The proper behavior is to complete one frame, send it off to the file I/O thread, and then get to the next one. And I’d also expect the requests for those input assets to have already been made frmo the file I/O manager, so that next frame is ready for rendering. Of course, not everyone knows how to design proper multithreaded code, but you’d think they would… this isn’t conceptually difficult.

I also know they made a huge change in this design going from Vegas 9 to Vegas 10, the CPU time balance between the two processes is entirely different.

I’ve always loved fast drives, so lets test my RAID 5 array.
More interesting… see how your RAID does reading 50BM, 100MB, 500BM, 1GB chunks out of a dozen 50GB files. You might be surprised.

4K setting 23.97 32bit float…
Short 30 second commercial with 8 layers of RED 4 K footage and 16 layers of Audio.
Is that all on the RAM disk? That’s where your bottleneck is. The output could be going to a USB flash dongle.. well, maybe not the Cineform 4K output.

You need 31MB per 4K frame just for the frame buffer, not to mention the processing of it all. So Vegas isn’t going to be able to read a huge number of frames from one stream, then go to the next, etc. You’re going to have all kinds of seeking, unless this is all on the RAM disc, not to mention the 16 tracks of audio.

And once you have plug-ins involved, you can’t really benchmark Vegas-proper anymore. Some plug-ins are single-threaded, some are dependent on multiple frames, etc.

Sad, SAD, SAD…in all rendering tests, it did not matter how fast my hard drives were. Simply put my throughput did not exceed 7 megs a second to the hard drive. There is no bottle neck in the hard drives.
You shoulda asked 🙂 I could have told you that years ago. There is no bottleneck TO the hard drive. There may be a bottleneck FROM the hard drive, depending on other bottlenecks you have.

Given all of the other processing you’ve layered in there, it’s impossible to tell if the bottleneck you are experiencing is based on pure CPU load (probably not, given your 50% CPU utilization) or plug-in limitations. One single-threaded plug-in in the mix, and everything else will have to wait for it.

The only real benchmark of Vegas’s performance relative to HDDs has to be done without plug-ins. I did a simple performance test, some months ago, just using DNxHD inputs and compositing… only using Vegas-proper, not plug-ins (well, other than rendering outputs, but they’re ALL plug-ins, even those from Sony). See here: https://forums.creativecow.net/readpost/24/919135

Clock cycle for clock cycle, my AMD is 26% slower. That is 2.8 GHz vs 3.33 GHz intel. The rendering times for this comparison was 26% slower! On the AMD! That is amazing to me…. Everyone always says Intel has more instructions per clock, yada yada yada…well, not according to real world rendering. After all, rendering is what really matters to us anyhow….
Yeah.. well, like everything else, your mileage may vary. The Intels probably do a bit better vs. the AMD’s when you factor in lots of SSE code, particularly the i7, which has an inherent boost in RAM speed as well (three banks from an on-CPU controller, versus two on all the AMDs). When it’s more dominated by integer and traditional FPU, AMD does much closer. In fact, many of the benchmark/review sites show AMDs pretty close to Intel on just what we do — video rendering, with the Intel pulling ahead, sometimes quite a bit, on games and some other things.

SIDE BAR: GPU rendering HAD NO EFFECT, I repeat NO EFFECT on my quadcore…
The GPU rendering effect is small at best. And it’s only a feature in Sony’s AVC CODEC. So, if you’re rendering via MainConcept or Cineform or something else, it doesn’t apply.

Fastest Quad Core you can afford, HT doesn’t do much but help in multitasking, barely…
Hyperthreading is always a question. When you’re CPU-bound, it MAY help. The big reason that’s a MAY is complex. For one, HT only helps on multithreaded code, not multiprocessing code. Each process that’s single-threaded will run on one CPU with HT effectively switched off. Only full cores have their own separate MMU context.

Second one: you double the effective number of cores, but don’t double the amount of on-chip cache. So it’s possible for caches to thrash, and actually result in a slow-down. Similarly, if your bottleneck is somewhere else, not the CPU, HT can’t help, and might actually exacerbate the problem.

At least 8 gigs or ram – 6 for Vegas and 2 for your computer use.
1 fast HD for your computer. One HD for your projects. Cheapest Video card you can get away with.
8GB is a good answer, particularly given how cheap 8GB is these days. You don’t need that for SD, but you shouldn’t be doing SD anymore. I always shoot in HD, even for DVD projects.

Cheapest video card, no. Well, maybe… if it’s actually a physical card. The cheapest video you can get is motherboard video, and since it’s sharing main RAM, it’s slowing you down, potentially, even just doing display fetches. And you really need two full HD screens for editing. If you’re not, try it.. you’ll never want to go back to a single screen.

And there are two reasons I kind of agree ahout “cheap video card”. One is simply that all video worth using these days on a PC is digital. There was a time when you had to get a Matrox card, because they used much better DACs than everyone else. And later, when ATi could do clean video but nVidia stunk. That’s mostly gone… I have seen a few cards that somehow managed to screw up HDMI/DVI, but that’s rare.

Second reason is that, until Vegas does something more than maybe use 8% CPU for some small improvement in rendering speed, it’s not worthwhile buying a GPU for Vegas. If they improve this in any useful way, like Adobe did, you may find it’s only useful on some GPU cards. That’s when you want to spend real money on a GPU.

The one caveat is video preview… if you’re doing previews on your PC on a regular basis, you want a decent if not earthshaking GPU, just for playback. Full HD AVC can take more than 50% CPU on my AMDx6, depending on the player, and not necessarily even play back smooth. Using a player that supports my aging nVidia 8800GT for playback, I’m using 6-8% CPU. That means I can direct HD preview video to my 32″ TV and still get real work done on my normal monitors.

As for HDs.. one HD for all your projects will guarantee that, on any complex project, you’re slow because of the HD. As I pointed out, this is a seek problem, not a throughput problem. You are far better spreading out a dozen large assets across 3-4 drives, and rendering to your C: drive or a USB drive, than your are rendering everything to and from a fast RAID.

I have lots of drive. I have a 2TB NAS, an 8TB Firewire RAID, several random 1TB USB drives living externally. I have a main C: at 1.5TB, and a D: also at 1.5GB, for small projects and as a spreading drive (if I have a complex enough project to need assets spread out). I have two SATA “cartridge” drives.. these use SATA drives as if they were cartridges. For large projects, I put a blank 1TB 3.5″ drive in for the main project drive, and that’ll function as the archive of it once I’m done. For smaller ones, I can fit two 2.5″ drives in the other “cart” holder.

As far as organization goes, spread out your assets. I’ve done a number of projects with 40-50 video layers… it’s amazing that a 2 minute music video can take 4 hours to render, but it can. If you have serious multitrack audio, either put this on a drive of its own (seek time matters, speed doesn’t, so a USB drive is fine), or better yet, mix the audio before you get to video editing.. that’s usually what I do. If you have lots of large digital photos (I have done a number of “Ken Burns Effect” videos), keep these on a separate volume (it was on my first major HD project, a wedding video with hundreds of 6-8Mpixel photos, that I found seek time being the limiting factor on a render). Then spread out your video inputs, if there are lots of these that’ll be used at the same time. You can render output to any old drive that’s not otherwise seeking.

And don’t fear using the C: drive for things, either. The conventional wisdom a decade or more ago was to avoid the C: drive, since that’s where your apps and swap partitions were, most likely. And when you didn’t have half the memory you needed for the application, that made sense. Still might, if you have some realtime app like Ableton Live, and don’t have confidence the whole thing is loaded before you have to go on stage. But otherwise, that C: drive may occasionally load things while you’re rendering, but probably not much.

-Dave