[Dave Haynie]

My HMC40 does the same thing, only, they’re on 4GB boundaries, not 2GB.
And yeah, I usually copy to my HDD by concatenating the files I know are sequential.

Whether this works on the XF100 or not depends on how they break the files. The HMC40 actually wins on two fronts. For one, it’s breaking the recording stream on exact 4GB boundaries. This means that, not only is the merging possible, it’s actually necessary to get an unbroken shot — the fact that it’s breaking the files on exact 4GB boundaries means that it’ll break in the middle of a GOP, middle of a header, middle of a frame… anywhere.

Even if it broke things on a logical level, the fact that it’s MPEG-2 TS means that, as long as the format is the same, you can concatenate the files. Transport Stream is designed for transmission, not file storage, so there’s nothing like a global header or anything.

So, first to check is how the XF100 breaks up its files. If there are on clean 2GB boundaries, I’m certain that it’s actually necessary to concatenate them to use them properly. If they’re broken on logical boundaries, then I don’t know… that depends on how MXF is internally structured.

-Dave

[Dave Haynie]

I bought both nVidia GTX570 and AMD Radeon HD6970. I found the Radeon to be faster at everything that GPUs did help with, in Vegas 11… and curiously, in each case, that speed was with a lower CPU use and lower GPU use. That suggests there might be more some improvements to come. My target was the $300-$350 range. The AMD was the lower cost of the two cards, by $20 or so.

And the nVidia only supports two monitors; the AMD supports a third, though it has to be DisplayPort (or something else, via an adapter). On the other hand, CUDA does have some more support than OpenCL, so it’s possible that the nVidia would accelerate other things. I decided that wasn’t important. Also, the video output from the nVidia on my system was poor, even over a digital interface — haven’t quite figured that one out yet.

-Dave

[Dave Haynie]

For HDV or most AVC formats, you can just concatenate the files. They’re all based on the MPEG-2 transport stream format, which is why this works. Of course, for AVC, you don’t want to go joining different formats.

For the rare camera that does MP4 file wrappers, the freeware tool YAMB works pretty well. YAMB also looks to work pretty well with the typical Canon AVC file, anyway (AVC in a Quicktime wrapper), though the output will be MP4, not MOV/Quicktime. They’re very similar; the MP4 file wrapper format was derived from Quicktime; most tools that support Quicktime also handle MP4 just dandy.

-Dave

[Dave Haynie]

[Shelby Coger] ” I feel like an entire video with just audio then pictures (regardless of cool transitions and FX) would be really boring. I’d really appreciate any help.”

It doesn’t have to be boring at all. But you have to learn to “animate” the still images. This is done via transitions, pans and zooms, and keyframing. You can certainly Google this for more information.

Simply put, key frames are fixed points of pan, zoom, color, whatever — in Vegas 11, you can keyframe practically anything. Why is it important? Vegas does the “tweening” for you. So let’s say I have a 20 photo panorama, and I’d like to “fly” though it. I can pan and zoom, set one keyframe, move ahead in time, set another keyframe, and Vegas will smoothly move from one to another.

Some example might help. You can, of course, look up the work of Ken Burns, who practically invented the art of making very interesting films with pans and zooms in photos — particularly for the historical documentaries he makes, there’s no video, no film, so the photos are what you have to work with.

I’ve used similar techniques, always done in Vegas, for dozens of videos. A few of these are online. This is one I did, using my Dad’s photographs:
https://www.youtube.com/watch?v=uQGf7xjWc4E?hd=1

This next was commercial. They wanted a video for a two year anniversary, but didn’t really even have much in the way of photos, much less video. So this was constructed mainly from press clips:

https://www.youtube.com/watch?v=QYoszzMuaJE?hd=1

I spent less than two hours on the music, and got the whole video together in about six hours total… they forgot to actually tell me the schedule. Thought I had two days 🙂

-Dave

[Dave Haynie]

What kind of DVD with HD are you trying to make? Obviously, DVD-Video is out… that’s SD only.

You have two real choices: just a plain old Blu-ray file system on DVD, or the slightly different AVCHD file system. AVCHD DVDs will play on most Blu-ray players, Blu-ray on DVD is far less supported. The reason is simple: AVCHD is a camcorder format, so most manufacturers explicitly support it.

I don’t know anything about Adobe Encore, but general rules of DVDs and BDs, that I know. You can only count on 2x DVD support for BD players, which is going to limit your video on a high def DVD to about 18Mb/s. That’s actually why nearly every AVCHD camcorder has a 17-18Mb/s mode. What you’re seeing sounds an awful lot like you’re exceeding this, and the drive just can’t keep up.

-Dave

[Dave Haynie]

I had previously discussed this here. There was a real debacle in the Vegas 10 + Cineform update… and the worst part, none of it was even necessary.

I had been a pretty heavy Cineform user. I converted Panasonic TM700 video in 60p (for speed) and 24p (because Vegas doesn’t understand the pulldown needed for 24p-in-60i), and I used it for intermediate output, particularly for complex, multi-project animations.

When Vegas 10 shipped, I was using an older Cineform CODEC, regular Video for Windows stuff, so it shouldn’t have been an issue. But Vegas 10 had add some private secret interface between Cineform and Vegas. And apparently, they didn’t bother to actually check the version of Cineform you were using. So load up a Cineform with the old CODEC, and it was a major crash, instantly. Well… guess that’s better than random crashes somewhere in the hours of a long render, but still.

So I’m pretty much forced to buy NeoScene 5. You actually had to grab the latest Beta, since that was where Sony and Cineform actually agreed on the interface. Or so you’d think. It actually turned out that while I could now read Cineform, rendering crashed. Always. Instantly. Every time. This was true up to Vegas 10d, fixed in 10e. Keep in mind, though, that all along, new CODEC and old, Vegas 9 worked perfectly well with Cineform.

I thought they had pretty much resolved the issues — apparently not. I use Cineform much less than I used to; in fact, I really haven’t gone back to using it much.

[Putting on the Engineer Hat…] And the real kick in the butt — NONE OF THIS WAS NECESSARY. Sony and Cineform had this new API, fine. But it was clearly buggy… no telling who’s bugs, but when things crash like this, that’s a bug. Even if it wasn’t so clear that bugs existed, where’s the harm in making it optional? As an Engineer, particularly in software (but even in hardware sometimes), I may have clever new idea, but I don’t want to clobber the project schedule or the consumer if something goes wrong. So why not have one more switch somewhere in the Vegas preferences, that would turn off whatever special-but-flawed new magic they put into Cineform, and let me use it exactly (and as functionally) as in Vegas 9? And why not check the CODEC/DLL version in the first place, and not use the new API if it’s not there. That’s a major failing, like a first-year programmer’s kind of mistake. I know I’ve been making decisions in software based on library, API, OS, and chip versions since the mid 1980s at least.

-Dave

[Dave Haynie]

There are lots of ways. Much of this depends on how you intend to use the animation in your video.

If you want to use the animation as an underlay (for example, maybe I want an animation to show on a TV screen in another animation), you can render it to some reasonably sized output format. It should be rendered progressive, and ideally at the same frame rate you plan for the final product. In the next level of animation, you’d work on that video, perhaps shrinking and rotating it to fit in a cut-out (transparent area, keyed-out area) in this new level.

If you want to use the animation as an overlay, you need some kind of transparency. The simplest is to render uncompressed, with alpha channel — that’s the key factor there. Keep in mind, uncompressed files get crazy big, so keep this in mind.

To render uncompressed, select an AVI/Video for Windows output. Go to the “Custom” dialog, select “Uncompressed” as the Video format, and check the “Render alpha channel” box. This will produce a video with transparency anywhere you don’t have graphics/video in the animation.

When you load this into another project, it’s just like any other video, but you won’t see transparency right away. You have to select the video track, hit “Properties” and then select the “Media” tab. Where is says “Alpha channel:”, select “Straight (unmatted)” and you’ll probably get what you want.

If you don’t have the storage for a huge uncompressed file, you can do overlays via chroma keying. This works best with a single color background (red, green, blue), and of course, one that’s not contained in the original image. You can render out such a video in any format, technically, but something with 4:2:2 or 4:4:4 color will produce a superior result, at the price of larger files.

-Dave

[Dave Haynie]

The CPU is what you’d LIKE to see as the only important factor in rendering time. That’s because it’s fairly easy to eliminate all the others.

If you’re editing HD, it’s a useful though not cast-in-stone rule of thumb to have 2GB of RAM per CPU core. The bottom line is that you never, ever, ever want Vegas to run out of memory during a render or edit. Of course, Windows is a virtual memory system, and like any other program, Vegas will be happy to start paging memory… which will bring your system to its knees. So, start with enough DRAM. DRAM speed isn’t going to be significant enough to make a measurable difference: all of the critical stuff is happening in CPU cache.

Every hard drive that still works is likely to be plenty fast for an AVCHD stream or two. Ok, having 20-30 old drives on a shelf over in my hardware lab, that may not be technically correct. But I’m unlikly to feel the need to hook up a PATA drive again (much less the SCSI and maybe even an ST-506 or two). So you’re probably ok there. If you do crazy stuff with lots of mixed video, high resolution stills, etc. you probably want to split assets across multiple drives, and render to yet another drive (even a USB flash stick, unless you render uncompressed or something gigantic).

The GPU hasn’t yet had a huge effect on basic performance. I’m not sure how significant the GPU acceleration is in Platinum versus Vegas Pro. I’ve found it to be useful, but kind of a specialty item so far. It does speed up some kinds of renders, others, not so much. If you’re a heavy user of plug-ins, and can use GPU-enabled plug-ins (either OpenCL or OpenGL-based), the GPU may start to make a difference. But still, I’d get all the other ducks in a row before worrying too much about the GPU… with that said, all my other ducks have been in a row, and I did just add an AMD Radeon HD 6970 to my system. Works wonders on Sony’s VP11 benchmark. On my own projects, I’ve actually seen one real project double in preview speed, and render to AVC about 37% faster. Of course, if I were buying a new system, I already know that the fastest Intel systems around will about double that performance (I have an AMD 1090T x6 3.2GHz here), so GPU shopping would still give way to CPU shopping, for a new system.

-Dave

[Dave Haynie]

The length of a video really has no effect on performance; it’s all about the complexity of the moment. That’s true of any streaming application.

A couple of questions… are you using Vegas Multi-Cam for the 3-cam shoot? One guy here a week or two ago was suggesting that maybe multi-cam broke in Vegas 11, performance-wise. Not what you want to hear, obviously, but do you see the same performance drag with the three tracks as separate files?

How about your HDD performance. I found that, from a single drive, I maxed out at two 144Mb/s DNxHD files (at the time, Cineform was still broken) with Vegas 10… add a third, and I’m all of a sudden HDD-bound, when I really want to be CPU-bound. That’s particularly noticeable in editing.

As a musician, I was well aware of the realities of hard drive performance going way back to the dawn of practical audio multitracking on the PC (my first PC-based audio multitrack was Turtle Beach’s 4-track portastudio emulator). Basically, with a single track, you get the drive’s “straight line” performance, which might be 50MB/s-100MB/s these days. Add a couple of other tracks, though, and you’re going to see the drive performance start to move away from the peak burst speed and toward the seek time, which essentially means, forget about anything happening fast.

I haven’t seen problems with one or two Cineform tracks recently, but I did a wedding back in 2006 which really exposed the problem. I had only one HDV track for video. But as it was a single-camera shoot, I had stills from three different pro photographers essentially acting as my B-roll. Of course, these were all 6 to 8 megapixel JPEGs, and I didn’t downrez or anything, because I was getting all Ken Burns with these stills.

Bottom line: this reduced my system performance to practically nothing. I was seeing slow editing, renders that took 4x what they ought to, etc. Even render-time crashing, back in those days, Vegas didn’t like to be kept waiting, or maybe it was Windows issues. Anyway, once I relocated all the stills to a separate drive, and rendered out to a third drive, things got much, much better.

What you ought to see, for any render, is your CPU use, all N cores, as close to 100% as you can get. If you’ve got memory, I’d make sure there’s a RAM preview buffer set up… while this is supposedly just for RAM previews, I’ve experimentally found this is used for buffering during renders, too (which is precisely what it should be used for). If you’re not seeing close to 100%, there’s something wrong… and it’s likely affecting edit-time performance, too.

What goes wrong? The HDD bottleneck thing. A single-threaded plug-in… basically, you wind up funneling everything through a single CPU core. Bugs, yeah, that’s possible too, but if there is a bug, it’s likely been found here already, so you’ve come to the right place.

Another is just expecting too much. AVCHD is pretty damn difficult for a modern computer to decode. Without GPU, I can preview 720/60p track in Vegas in full quality realtime. More than one, and you’re simply running out of CPU. A good GPU might help here in Vegas 11. To make things a little more sane, I tried a four-layer composite of 720/60p converted to 50Mb/s MPEG-2, which is not as complex to decode. I saw about 2.4fps with three transparently layers over a non-transparent bottom layer, in full quality preview… that down from a just about full 60fps. With GPU, this boosted to 5fps. Of course, that’s four layers of compositing… four cameras with the occasional transition would still preview at 60fps, ‘cept during the transitions themselves (which is, of course, what selective pre-rendering can speed up). The GPU may help even more if you’re using an accelerated plug-in, versus no GPU.

-Dave

[Dave Haynie]

Did you try the Sony VP11 benchmark, by any chance? Probably not… but it’s worth a try, as a baseline. See here: https://www.sonycreativesoftware.com/vegaspro11benchmark

I did quite a bit of benchmarking when I first got VP11. I see this project in full quality 1920×1080 playback at 8fps in Vegas 11 no-GPU, 28.5fps (eg, nearly realtime) with the GPU enabled. No doubt Sony did this to show off GPU acceleration, but it’s a real short video, and not unlike some of the animated stuff I do (eg, mix of video and animated stills).

-Dave