Sony Vegas 10 Slow rendering CPU / GPU rending tested

[Davd Keator]

Upon my testing, I now have the GTX 460 in one computer and GTX 450 in another. I think the GPU processing is working just fine. It’s that there isn’t that much for it to do. The majority of processing must be done with in the CPU. Even Premeire Pro CS5 with MPE engaged, I only see about 10% speed improvment when rendering. The MPE is realy for timeline scrubbing, and that is really important to me. I need to see my results with out prerendering all the time.

Sales Gimiks and Hype to boost sales! What are we poor foolish consumers to do, but fall for it every time.

Has anyone done a visual comparison from GPU accelerated vs all CPU? I mean really blow it up on a projector? I would love to see if the gpu keeps the same quaility of the software. Thats where Vegas used to shine beyond all, visual quality.

[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

[Davd Keator]

Interesting read…

Things I have noticed:

I switched to Nvidia cards mainly for Premeire Pro CS5. I didn’t bother with the Vegas 10 lateral grade. I still use Vegas 9 on many projects though, fast and simple can not be beat by Vegas! However, I went from Dual ATI 5750 to the GTX460 and a GT 210. My previews or not nearly as smooth as they used to be. The 460 is used for preview and primary screen editing. The 210 is used soly for a file managment, internet monitor.

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. 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.

Other things I’ve noticed:

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.

This leads me to think part of the Vegas rendering issue is dealing with sound bits.

I just like speed and a good looking finnished product. I find it harder to keep my editors on the same page using the same codecs and redering to proper outputs on a consistant basis more challanging than any issue with any NLE for that matter.

Trying to apply a science to this edditing stuff is more akin to the acult for amazing output that some people get!

Have a good day…

[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

[Davd Keator]

We seem to have veered off subject…

Yes I do get nearly 100% cpu utilization once I turn off HYPERCHEEZ, and a slight performance boost once I do.

This forum thread was reference to the Advertising HYPE of CUDA and nothing more…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.

From oerformance testing, I don’t think Vegas 10 has been updated enough since AMD and INTEL yield the same results for rendering. Perhaps when they incorporate the K6-3D Now instruction set…LOL Just kidding…

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.

Many of my comments from the begining were editorials from several forum questions….

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

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…

I take that back, I have seen one time, to where it was a siple cut, slice and dice NTSC DV, that maxed out my HD’s at 650MB’s for read and write with minimal CPU utilization. That was Hyper REAL time, 1HR done in less than a minute.

Anyway, thanks for the lively debate, I love talking tech.

[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

[Konstantin Detinenko]

Dear Dave,

My friend has one of the latest i7 cpu with raid 0 hdd configuration and I was able to edit hd video streams from 3 cameras in multicamera mode in real time with sony vegas pro 10c, but I found it annoying that it would lag each time new event starts, especially those with transition applied on. The only way around it was building a RAM previews.

You made me realize hard drive bottleneck as I was experiencing not fully loaded cpu when rendering too, but I am more interested in flawless editing rather than quick rendering.

I made some research on seek time, as I conducted that lag happens because of the same reason you spoke in this thread, and the best solutions I came with were:

Solid State Drive in raid
https://www.ebuyer.com/product/258813
Cons
Quick throughput 740 MB/s and 0.1ms access time.
Pros
I have doubts about SSD handling multiple streams, so I searched about it and found that MLC (Multi Level Cell) is bad with it, while SLC is handling it pretty well. I am not sure about this SSD raid being MLC or SLC though.

Several regular hard drives in Raid 1 configuration.
Cons
It was hard to research this, but on some sites it is said that proper Raid controllers in Raid 1 configuration distributes files being read to different hard drives, thus freeing individual hard drives from seeking and putting them to linear reading. It should make it precache, read more efficiently and wear less the mechanical parts I believe.
Pros
It was hard to find any information on advantage of Raid 1 in access time because of everyone hyping over Raid 0 with its double speed and all, so I could not find how to discern controllers which can distribute tasks between drives and which cannot.

Spreding files accross hard drives as you mentioned.
Cons
Good idea as being the simpliest one. And it leaves all the space on the drive intact.
Pros
1st: I wouldn’t like to do workarounds all the time, instead I prefer to find 1 workaround which will make rest of the time as little work as possible. 2nd: It has limitations in how you can edit things. For example it is easy to separate footage from different cameras, but when there will be cuts and transitions between the same camera footage, so if Raid 1 solution would work, it would be better alternative. And its lack of space comes around with its reliability.

I was reading this forum quite a lot of times and people here seem pretty helpful. I tried to do as much on my own so I would contribute too in helping people get the best results out of their machines.
Thank you! looking forward for any thoughts.
Any information on behavior of raid controllers in raid 1 configuration will be greatly appreciated!

[Glenn Goodman]

Hello

I read with interest, and I have the same problem but worse. I am encoding now and hour long video to take about 4 hrs. I look at the CPU usgae and its only 20% across 6 cores.

AMD Phenom II X6 1090 3.2 ghz
8 Gig RAM
Win 7
Vegas 10
c: 1.5 TB free
I have got the assets on a windows home server machine.

In simple terms please – am I getting a bottleneck from my drive c? what would be a good way to identify the bottleneck or fix the issue.

I bought the rig especially for rendering. Would like to see it working close to 100%…

any help be appreciated…thanks

Glenn

[John Rofrano]

[Glenn Goodman] “In simple terms please – am I getting a bottleneck from my drive c? what would be a good way to identify the bottleneck or fix the issue. “

This is really easy to test. Copy one of the media files to your C: drive. Drop it into a new project and render. If you still get 20% it’s not the network drive.

~jr

http://www.johnrofrano.com
http://www.vasst.com

[Davd Keator]

About the bottle neck: I would just open up the task manager / performance tab and look at the memory usage as well… From there you can also launch the resource monitor. From there you can see everything your computer is doning. Check the Hard faults on memory. This tells you how often your memory errors and recalls to the hard drive for new info. You can also see how often or at all if you hit your swap file. That is the killer of all loads… Hard drive for swap kills rendering like crazy.

Since you are now in the world of GPU rendering as well. If you are using the Sony AVC and have GPU engaged & your video card is a crappy old 9800 or something, you are wasting resources by your processor cores waiting for the GPU…

Through my experiences: 2 gigs per core are needed for vegas, 6 cores means 12 gigs…

President: http://www.VertexMedia.com