[Dave Haynie]

I’m an HMC40 user… it has a similar behavior.

First of all, you don’t need tsMuxer to join files, and in fact, I’m not sure that’s a good idea. When your Panny breaks files up, it’s breaking them exactly at the 4GB mark. So there’s no logical boundry there.. it’ll break in the middle of any frame. That’s why you can sometimes get a dropout at the transition point.

Because of this, all you need to do is concatenate the pieces into one large file. I have historically used a Cygwin shell command for this:

> cat 00000.MTS 00001.MTS 00002.MTS >thewholeschmeggie.mts

But these days I get lazy and use JD Design’s “File Concatenate/Split Context Menu” application, which basically adds this function as a Windows shell extension.

As for the cut-off… I don’t have anything recently that went over 1:30 in a single take. But be careful about mixing takes. In theory, you can concatenate MPEG-2 transport stream files all day, and Vegas should read them. But I think you get some kind of end marker when you stop the camcorder, and that’s used by many programs in the usual PC world (MPEG2-TS was defined originally for never-ending streams, like satellite/cable TV) to signal an end-of-stream. So if you concatenate multiple files in a single take, great. If you put together two different takes, many programs will only see one of them. Check what the Windows file browser thinks of your file lengths, and see if they match what Vegas believes. I’ve done a little experimentation here, and was able to create a 95 minute file that shows up in Vegas and Windows as a 44 minute file, based on where one of the streams ended.

-Dave

[Dave Haynie]

Right. If you have a properly tuned system, some computational resource will be the bottleneck. It should be.. that’s the sign that easy stuff (eg, your memory, your hard disc, etc) is performing properly.

Used to be the case that, if your CPU wasn’t maxxed out, there was something wrong with your system… something else was the bottleneck, but it’s ALWAYS computation that should be the weakest link (unless maybe you’re doing crazy stuff, like reading or rendering uncompressed HD). But now we have the GPU to consider as well.

I benchmarked Sony’s Vegas 11 GPU benchmark project on my system awhile back. Without GPU, I was at 96% CPU, which isn’t bad for a six core system. The same render took only 58% CPU with the GPU enabled, and 30% GPU.. but it finished better than twice as fast. So, no problem.

-Dave

[Dave Haynie]

I agree. I ran into one fairly annoying bug, apparently in a plug-in… it wasn’t a difficult work-around (I was kind of in a panic at the time, having found a 2-Day deadline was actually a 1-Day deadline, so I didn’t document it all), but otherwise, Vegas 11 has been a big win for me. Most of this paid stuff I’ve done recently lines up almost perfectly with the things that Vegas 11 actually does accelerate well (in particular, layers of animated stills mixed with bits of video).

With that said, you are taking something of a risk with any N.0 release from pretty much any software company. The most annoying thing about Vegas is the simple fact they never offer even a single revision backward compatibility in file format. So if you’re well into a project and discover a nice, shiny new bug in SVP11 that you can’t work around, you’re likely to spend some time moving the project to SVP10 (XML, AAF, cut & paste… each has its flaws).

-Dave

[Dave Haynie]

Simple preview from AVCHD is not where Vegas 11 is using the GPU. Not sure why… GPU acceleration for video playback is pretty mature, and can really do wonders (I get something like 5-6 1080p60 streams playing at full speed these days on my AMDx6 plus AMD HD6970.

What I’ve seen really accelerate on preview are projects with a mix of effects, animated stills, and video… exactly what you find in Sony’s benchmark project (you can find this linked from the “GPU” page on the Vegas product info web site).

CPU and GPU aren’t fully interchangeable… I’m not sure how Vegas decides where the GPU will be applied. And sometimes, I’m seeing the CPU percentage drop, the GPU get used but certainly not overloaded, and yet, the whole effect is a faster preview or render. This suggests there’s some optimizations yet to be worked out. And these may be even more glaring on a lower powered system like yours.

I did a benchmark a bit like one of yours. I had four video streams in one project… half the benchmark was resizing and animating the four streams, the other half was rendering all four with transparency.. this was 720p60 video, 50Mb/s MXF/MPEG-2 (a bit easier on the CPU than AVC). I saw 2.4fps across the project with Vegas 10, Vegas 11 no GPU, or Vegas 11 with the nVidia GTX570, and 5fps with the HD6970.

On the Sony benchmark, I saw 8fps with Vegas 11, no GPU, and 96% CPU use (all six cores). For preview on the HD6970, I got 28.5fps (this is a 29.97fps project), 58% CPU and 30% GPU, average use. For preview on the GTX570, I saw 27.5fps, 75% CPU and 50% GPU. In either case, that’s a pretty sweet boost in preview speed. And rendering to AVC, I got just over 2x speedup with either GPU; rendering to XDCAM EX 1080i60, I saw a 3x speedup with the HD6970.

So the GPU performance is real, it’s just not a big factor in video decoding, which is the major overhead element in a simple project.

-Dave

[Dave Haynie]

You can still save an AAF (modern or legacy) from Vegas 11… you just have to be using 32-bit Vegas. Why? I believe it’s because the Advanced Media Workflow Association has not release a 64-bit version of the AAF libraries (though some NLE makers have done their own).

-Dave

[Dave Haynie]

Yup. AVC editing was just functional in Vegas 8, and for some camera output, not stable. Also, for any serious HD work, you really want the 64-bit version of Vegas. Vegas 8.1 was the first 64-bit release, but it was more of a technology preview… it had issues.

While its true that Canon’s Quicktime format is a bit easier on the CPU than AVCHD from a camcorder (Canon uses I and P frames only, plus 44Mb/s bitrate, rather than IPB frames and 24Mb/s… B frames require more CPU and memory to process), I would still want a fairly modern 4 to 6 core CPU with 8GB memory.

That doesn’t have to be the very top of the line stuff, either. I saw 16GB of RAM on sale at Newegg this week for $60 or so. I have long been an advocate of buying technology “at the knee of the commodity curve”. At commodity prices, when pay twice as much, you get twice as much. At the high end, you might pay twice as much for only 25% more performance, maybe even less.

-Dave

[Dave Haynie]

I agree here. I’ve done a bunch of tests. IN THEORY, at least based on the original documentation, preview RAM would be entirely a waste during a render. The main point of preview RAM is for RAM previews. That’s it.

In practice, at least in more recent versions of Vegas, it’s clearly being used for buffering during a render. But it can’t be used for the render itself. I have found that 1GB vs. nothing is going to keep my renders much closer to 100%. That makes some sense — if Vegas is grabbing large blocks from your source drives all at once, that’ll be much faster than multiple short reads, just the nature of hard drives. But like the study Steven quoted, I have not seen 2GB make any difference.

And while it’s tempting to set up lots of memory when you have lots of memory (I have 16GB as well), I have never seen a difference at render time between 1GB and 2GB. And yeah, if you devote more memory to RAM preview, Vegas will allocate more memory, and that will be unavailable to anything else. It sounds like you told Vegas to take nearly all your memory for RAM preview, forcing your system to run mostly out of virtual memory, paging to disc like crazy on a system that should never have had to page at all for such a render.

-Dave

[Dave Haynie]

You can EASILY get long render times by doing complex things. Years back (and on a much weaker PC), I found the best looking PAL conversion I could get from an NTSC source was via Vegas, with supersampling and a few other things enabled. It took 8 days to render two hours (and that was SD), and I’m not sure how much all that was necessary. But I did get PAL that looked better than any of the dedicated PAL converters of the day (all of which pretty much just did a 3:2 pulldown, then boosted the frame rate by 1fps). So it was worth it.

In more recent times, I managed to take up several days of much faster computer time rendering a few hours of video through the Neat Video de-noising plug-in. Again, a long time, but very definitely worth the effort.

So my first question: any plug-ins we ought to know about?

-Dave

[Dave Haynie]

I believe what you’re seeing very much is a Vegas error. Or, more correctly, a Vegas + Main Concept error. Here’s what I think is happening.

Ok, so you set up all the parameters for an MPEG-2 render with Main Concept. Vegas doesn’t have the Main Concept code within the main Vegas program, it’s launching a separate process to actually do the rendering.

What I believe happens is that the Main Concept subprogram fails. In this case, you’re trying to render 1920×1080 HDV, which isn’t a supported HDV format… no huge surprise that fails. But you should be told that. The big failure here is that the Main Concept subprogram and Vegas don’t have any reasonable upstream communication — Vegas is not reporting the reason for the failure back to the user. This is a major design flaw.

And I’ve had this basic idea supported by the move to Vegas 11. A number of Main Concept templates I’ve used in the past now error out in this same way. As well, it’s obvious that Sony had to supply an updated version of the Main Concept rendering engine for Vegas 11, since now Main Concept can use the GPU, previous versions did not.

In your specific case, as mentioned, you’re rendering to an illegal version of HDV. HDV is a very specific format that uses MPEG-2, and it doesn’t have any support for 1920×1080 video. If you want this to go to tape, you’re going to have to use a legal HDV format.

If you just want MPEG-2, you can render to a generic MPEG-2 file, however, and get your 1920×1080 if you like. First, go to the Custom Settings panel. Change your “Output type” to MPEG-2. Change the width to 1920, and the Level to High. Also set the bitrate. HDV is fixed at 25Mb/s. You can use that for 1920×1080, but the quality may suffer a bit, depending on your material. Main Concept will support higher bitrates; I used to render at 50Mb/s, but that’s one that seems to be broken in the new release of Main Concept. Try VBR at 35Mb/s average, 45Mb/s peak, or something like that… not sure what this is for.

Next, go to the “System” tab. This specifies the container you’re going to get. If you select “Program” here, you’ll get an MPEG-2 program stream file (.mpg), if you select “Transport”, you’ll get an MPEG-2 transport stream file.

Finally, go to the Audio tab. If you want audio, select “include audio stream”. Your only choice is MPEG Layer 2 audio.

Anyway, follow this, and you ought to get a perfectly good MPEG-2 file. You can tweak this as you like — the important thing is to understand what you’re doing here. Keep in mind that the MPEG standards, while actual standards, are also standards-generators. MPEG-2 is a component in other standards such as DVD, ATSC, Blu-ray, HDV, etc. Each of those things has additional rules on top of the rules that define MPEG-2. So things that seem perfectly reasonable when you’re thinking “MPEG-2” don’t necessarily work for any of the standards built on top of MPEG-2.

-Dave

[Dave Haynie]

[Dan Volker] “And then, the hope that there is an encoding solution for a web based format, that takes better advantage of the perfection you can achieve with a 4-4-4 cineform avi or mov. On this topic, I just downloaded the trial of Sorenson Squeeze 8, and was quite impressed with the x264 encode options–Squeeze 7 has only the bare minimum of encoding options you can set for the H264 encode”

Just curious… if you’re intent on using x264 (the increasingly famous open source h.264 encoder — incidently, the same one used for YouTube encoding), what the point of Sorenson? Just like a fancy front-end? I’ll admit I paid something like $50 for a TMPGenc MasteringWorks upgrade, to get x264 encoding along with a pretty nice batch encoding system for most Windows media types. But Sorenson is pretty expensive, if you’re mainly after something that’s otherwise free (you can use x264 for anything you’re already licensed on H.264 for, if you’re concerned about the legalities). Maybe the upgrade price is decent?

-Dave