[Dave Haynie]

There are a thousand things you can do… mention a specific part of a specific song, and maybe some of the folks around here can tell you what’s being done.

There are some common treatments. Sometimes a chorus really is a chorus… a few background singers join in, creating a richer sound. Sometimes you just double the original singer — record the chorus twice, using both together. Or use a Chorus plug-in to create a similar effect from just one voice. Sometimes you muck around with reverb.

Really, if you know what you want to hear, mess around with things. That’s a good way to develop a sense of this stuff.

-Dave

[Dave Haynie]

I had a new marketing animation to render tonight.. so I decided to get all sciencey on it and see how tweakables affect performance. Here are the results:

System
3.2GHz AMD 1090T 6-core processor
16GB DDR3 DRAM
nVidia GeForce 8800GT GPU (runs CUDA, fairly ancient)

Project
1920×1080 59.94 fps progressive
32-bit floating point (full range) pixels
Best quality
Gaussian motion blur

Source video
1920×1080 59.94 progressive MPEG-2 at 50Mb/s.
Total time: 1:42:15
No video effects
Four fairly sparse audio tracks, applying some audio
effects (reverb)

Target video #1
1920×1080 29.97 fps progressive AVC at 10Mb/s.
Total time: 1:42:15
Sony AVC at Baseline, CAVLC

Trial Threads Preview GPU CPU RAM(GB) Time Size (kiB)
1 8 2GB yes 76% 7.96 12:26 126,829
2 8 1GB yes 75% 7.01 12:38 126,829
3 8 0GB yes 57% 6.12 15:52 126,829

4 8 2GB no 94% 7.90 10:10 112,335
5 8 1GB no 94% 6.95 10:12 112,335
6 8 0GB no 80% 6.21 13:20 112,335

7 6 1GB no 93% 6.87 10:41 112,335
8 12 1GB no 94% 7.13 10:27 112,335

Target video #2
1920×1080 59.94 fps progressive AVC at 20Mb/s.
Total time: 1:42:15
Sony AVC at High, CABAC

9 12 1GB no 80% 7.04 13:14 208,543
10 12 1GB yes 80% 7.00 12:33 228,431

Notes
It’s pretty clear, on my system, the GPU render isn’t always
helpful. Part of the problem of using alternate processors is
ensuing the overhead of the communications, the weird way you
have to structure the math, etc. actually yields a payoff.
And yeah, probably need a GPU update.. but which one?
Hopefully, Vegas 11 answers that question.

It’s clear they’re using a slightly different algorithm on
the GPU vs. non-GPU render. This is not a shock.

It’s also clear that “Preview” RAM is being used
constructively during render, as was my contention. And kind
of what you’d hope, but nothing I’ve seen documented.
If you don’t have crazy amounts of RAM, though, you have to
be careful with this, or you might slow rendering down in
other ways.

-Dave

[Dave Haynie]

[Brad Leigh] “Wow Thanks so much! I love this. I was embarrassed to post last night that I got CPU percentage UP and ram usage up when I increased my Dynamic ram preview. Everything I had read on this forum said drop it down to min. I have tried different thread numbers. It started to get interesting because I experimented with different Dynamic ram preview settings and cpu percentage, and ram usage went up, at a certain point it didn’t help render times with this simple test.”

The stated purpose of Dynamic RAM Preview is just that — preview rendering using RAM while editing. But Vegas does seem to statically allocate this… so it’s claimed during a render as well. That of course means that you don’t want this number set too high during a render, particularly if you’re on a multi-core CPU. If you think about it, even if all the code fits in cache and doesn’t need to be replicated, for each thread you add, you have a full image rendering pipeline, which means a number of uncompressed HD images in RAM at the same time. If there’s too much memory doing other things, you’ll start paging — virtual memory — and that’ll become your bottleneck. You want every render to take place entirely in RAM.

However, I’ve seen that setting this to zero can actually slow down a render, and I’ve heard others offer evidence of the same thing. This makes sense — if Vegas has some memory of its own pre-allocated, why wouldn’t the programmers use it for buffering. This was actually one annoyance I had with Vegas, from the start, coming in from the music world. In the day, audio programs like Cakewalk let you define RAM buffers, which essentially let you add speed and thus tracks, at the expense of latency. I never quite figured out how Vegas figured out what I wanted it to do in this. Once you get to video, maybe it’s too complex to leave to the user, but then again, if it can be left to the user — and by that I mean me — I might be able to solve a performance problem that Vegas can’t solve automatically.

-Dave

[Dave Haynie]

The problem with USB to Firewire isn’t speed… particularly since most video cameras run at 100Mb/s mode (the slowest Firewire mode).

The problem is more complex. When they worked out the specs for DV tape, the format was very much a digital version of analog tape, and very much NOT computer-like take. In short, none of the transport stuff that lets computers start and stop tape drives.

The upshot of this is that, when you play a bitstream from a digital tape, it just plays… it’s exactly like the output of an analog deck, only digital. You can control a deck with the usual tricks: LANC or whatever. But there’s no computer-like start/stop on a block or byte basis.

Enter Firewire… Firewire is a multi-mastered bus. It can just send, send, send out from the camera without any knowledge of the receiving device. Just like an analog output. So it was a great match for what they wanted to do in digital tape. This is also why you can get dropouts and have to “capture” rather than “copy” from your Firewire-based camera.

Ok, so that’s Firewire.. the camera can just send, send, send. USB is different, it’s not a multi-mastered bus, it’s a “master/slave” or “host/target” bus or whatever you want to call that. In short, a USB device can’t just start sending data. A PC or other device has to basically go ask each target if there’s data, then set up the transfer. Once the transfer’s set up, the device can send some finite number of blocks… a very computery way to do things. SATA and PATA pretty much work the same way, whereas SCSI (which was one model for Firewire, since Apple wanted SCSI to Firewire bridges to work easily) was multimastered.

So in your Firewire to USB converter, you need a Firewire port that can take in the data dump from your camera, and a USB target port that hooks to your PC. The PC sets up a transfer, you press play, data starts going into that brick. The PC checks USB, sees a transfer request, goes into DMA mode and lets the USB device send some data… it’s all good. For awhile.

At some point, the PC gets busy, in a driver or whatever… other USB activity slows things, whatever. The buffer fills and fills, then runs over… transfer failed. That’s really just the problem. With a massive buffer, a USB to Firewire device like this would work just dandy. But that gets expensive… many MB of RAM, in addition to the CPU, Firewire port, USB port, and software you need to run the device. So hey.. why not put in cheaper flash memory, an SD card or something, instead of that RAM. Or even a hard drive.

And that’s just what happens.. and so, there are plenty of Firewire to HDD devices, but no Firewire to USB worthy of mention.

-Dave

[Dave Haynie]

The primary reason you can’t burn Blu-ray on the “LiteOn ATAPI iHES208” is that… well, sorry to break the news, but it’s not a BD-R writer. Lite-On calls this a “Blu-ray Combo Drive”, which means it’s a Blu-ray reader and DVD/CD reader/writer in one.

Here’s the Lite-On press release about this drive:
https://us.liteonit.com/us/news/news-n-events/324-lite-on-ihes208-8x-blu-ray-disc-reader-with-dvd-writer-combo-now-available

-Dave

[Dave Haynie]

I hadn’t noticed that before… you’re using an i7 2600, 3.2GHz, four core, in hyperthreading mode (eight virtual cores). Just a question: how many renderning threads do you have set (Preferences/Video/Maximum number of rendering threads:)?

So you’re not seeing any core terribly busy… numbers 6 and 8 are downright sleeping.

There can be some weirdness with too many threads on such systems… the virtual cores eat up the on-chip cache twice as fast as regular cores alone (makes sense — same hardware, twice the program context).

It’s possible to get all those cores fighting each other — cache thrashing. Can’t be sure that’s it, but seeing as how none of your cores are all that busy and neither is the I/O, unless you’ve got some 1980’s Fast-Page-Mode DRAM in that rig, I can’t think of another obvious bottleneck.

What you want to have happen: program runs, rendering starts. The very carefully tuned rendering code plus data fits entirely in the CPU’s L1 cache for critical sections, L2 cache otherwise. Things go fast, life is good.

What happens when you “thrash” the cache: core 1 is rompin’ along, core 2 needs a different chunk of code or data that’s not in the cache… but until grabs that stuff, but it has to toss out the stuff core 1 was going to start using pretty soon. So core 1 gets to that part of the code, and has to wait for its stuff to get loaded.

Now, if you’re running a hyperthreaded processor, that was actually core 1a stalled waiting for a memory fetch… that lets core 1b on the bus (they’re a virtual pair)… and now it’s also contending for resources on the chip. And it gets worse if there’s much task swapping.

You show plenty of free memory, so I don’t think that’s the problem.

So here’s my advice. First, find the Options/Preferences dialog. Go to the Video tab, look at “Maximum number of rendering threads”. I’d set this to eight, one for each processor, to start with. Definitely no more… that will help with the possibility of cache thrashing.

Also, while it doesn’t seem related, try setting Dynamic RAM Preview max (MB) to 1000MB (1GB)… you can spare it. I have a theory that Vegas will use this otherwise useless memory during rendering to better chunkify the disc access (eg, larger disc reads deliver better throughput, since there’s less seeking between files on the same disc for the same amount of data loaded over time).

-Dave

[Dave Haynie]

From the description, the big deal is GPU acceleration. While perhaps not a new “feature”, the idea of making my workflow run 2x, 3x, 5x faster than it currently does, particularly on native AVC editing, is more generally useful than anything I can think of in terms of features at the moment.

Thinking of this way: one AVC decode of a 1080/60p video takes my system about 60% CPU, just using the CPU. Using the GPU, this same decode takes about 8% CPU… that’s all six cores in both cases. Just for rendering, Vegas is going to be doing that same kind of work, and currently, it’s all done on the CPU. If they see a similar performance boost just on video decoding, I would expect that just rendering an hour’s worth of 1080/60p on a 2-stream project, I’d see more than an extra hour’s worth of performance… that’s just factoring in a decoding boost I’ve already seen in the real world.

Another point of reference here: Adobe Premiere CS5.5, which has extensive GPU-based rendering improvements… folks claim AVC editing feels more like DV editing, with a decent GPU.

So anyway, I’m really excited about this, if they meet the potential.

Ok, it also supports RAW photos, but via the Microsoft interface stuff, which isn’t usually all that up-to-date. Other things: a new synchronization feature, and some new plug-ins (improved text tool, improved image stabilizer). Nothing there that would of itself justify the upgrade. Looks like improved stereoscopic video handling… probably AVC-MVC across the board (input, output). Not interesting to me just yet, but if you’re doing “3D”, I suppose. There is now an AVC-MVC spec for camcorders, based on the AVCHD 2.0 stuff.

-Dave

[Dave Haynie]

If you’re not seeing much beyond 20-25%, it sure sounds like you have a plug-in somewhere that’s single-threaded. Or you have Vegas set to limit the number of threads.

I’d step back a little. Check the setup to ensure Vegas can use at least one thread per CPU. Try rendering just a plain, unchanged HDV track to AVC (AVCHD is the disc format, not the video format, so it’s proper to say “AVC” here) and see how your CPU percentages run. If that’s in the 90-100% range, try adding complexity until it slows down, and you may be able to identify the culprit.

You should always see something over 90% CPU when rendering. If not, that’s an indicator the CPU isn’t the bottleneck. But it should always be, since it’s the only thing in a typical system that can’t match the demands we video folks put on the system.

-Dave

[Dave Haynie]

In what way are you “just getting the audio”?

You can burn a Blu-ray file system to a DVD, of course. But a good number of Blu-ray players won’t play it.

In addition, for any DVD project on a Blu-ray player, the maximum video speed is 18Mb/s. That’s the standard for AVCHD video on DVD (AVCHD is a format for camcorders, supported by nearly every Blu-ray player, that’s derived from — and very similar to — Blu-ray. But not identical). This indicates a 2x DVD player.

Assuming this is the result you see on your Blu-ray player (you didn’t actually state where the playback isn’t occurring), it sounds like your player actually does support the Blu-ray on DVD formatting, but is failing to play back 25Mb/s video on DVD. Try rendering to Sony AVC at 16Mb/s or so (there’s a template) and see if your Blu-ray player will handle that.

-Dave

[Dave Haynie]

A couple of things. Run the preview in DVD Architect — you should see, in the preview window, exactly what you’re going to see on a video screen. If you see a full screen DVD, you’re making it correctly. If not, double-check that the project settings in Vegas are also for a 16:9 DVD, when you created that MPEG-2 video.

Also, make sure that commercially produced DVDs fill the sides and the top when played on the same gear. There are dozens of different settings on hardware these days.

That is the correct format to use — you’re doing something else wrong. Try this, and perhaps we can figure out just where the problem is.

-Dave