[Dave Haynie]

[Norman Black] “Vegas is GPU agnostic since it uses OpenCL. OpenCL can be implemented on a GPU or even a CPU. Your system has an OpenCL driver for the CPU but Vegas does not put it in the list of OpenCL devices.

I would expect that the Vegas 13 compatible GPUs will be the same list as the Vegas 12 compatible GPUs. Why would it be any different?”

Vegas itself is certainly GPU-agnostic… OpenCL runs on many different things, and it hasn’t changed much or dramatically over time, which is a good way to keep things headed toward stability.

On the other hand, some plug-ins are less well-behaved. Some still only support nVidia’s proprietary CUDA GPGPU system, though nothing that’s part of Vegas-proper. And then there’s the Main Concept AVC CODEC. This is very nicely accelerated, but they hard-code the supported GPUs, and only run OpenCL or CUDA on those. So anyone after top performance with AVC in Vegas has a problem… older GPUs may actually be faster than newer ones, at least for rendering the whole project.

As well, there are some weird artificial limitations in various nVidia drivers. They slow down certain OpenGL operations in the consumer/desktop GPU drivers (to justify the higher price of the Workstation cards), and some OpenCL/CUDA operations in both the desktop and workstation drivers (to justify the even higher price of the “computing” cards). It would be awfully nice to see Vegas not only update this stuff, but provide some 2014-era benchmarking on how well GPGPU is doing these days. Vegas 12 was an improvement over Vegas 11 in GPU support, and yet they barely even mentioned it.

-Dave

[Dave Haynie]

Yup… there’s low bitrate and there’s low bitrate. AVC from a camcorder or DSLR isn’t all that low in bitrate. A typical AVCHD camcorder will deliver 1080/60i or 1080/24p at 24Mb/s, which is higher bitrate than the maximum ATSC broadcast rate of 19.4Mb/s… AND you’re AVC. A good AVC encoder will have about twice the coding efficiency of the MPEG-2 used in ATSC. I’m not sure about the Nikon, but Canon DSLR video is usually at around 31Mb/s (newer IPB models) or 44Mb/s (older IP-only models), or 91Mb/s for I-Frame Only video on the more recent cameras.

Of course, blocking is also easier to see on a small video blown up to comfortable desktop viewing size than it is for a larger video. But the principle is the same. In pretty much all of the MPEG encoders, the video broken up into those blocks that you see, called macroblocks. Each of those gets its own discrete cosine transform, which is similar to a discrete Fourier transform, it’s converting spatial information to frequency information… and that’s reversible and lossless (well, aside from rounding errors). Then there’s the lossy part, a decimation pass that tosses out a certain amount of the higher frequency information any macroblock. Then that whole thing is losslessly compressed using Huffman or similar entropy encoding… and the process is reversed on the expansion.

When you see the macroblocks, what you’re seeing is essentially too much low-pass filtering… the content of one cell no longer quite matches the content of the next cell, and your brain, with it’s advanced image processing wetware and particular fascination with horizontal and vertical lines, fills in that mismatch as a line that isn’t really there. I’m sure lots of folks here understand this, but I figured I’m mention it.

So there are only two options to get rid of those macroblocks in most parts of the video. One is simply increasing your rendered bitrate. With a higher bitrate, there’s less filtering at each macroblock, and less chance that ajacent macroblocks no longer line up. The other thing you can do is run a slight blur over the video prior to encoding. “Blur” is another name for “low pass filtering”. When you remove high frequency information at a frame-global level, you’re eliminating the uneven removal of that same information in each macrocell… so you can have the higher compression without macroblocks being visible.

There’s one other case in MPEG you’ll see way too much macroblocking, and that’s in fast motion video. That’s because of the P and B frame types. An I-Frame is basically just a fancy Motion JPEG image. P and B frames use various motion prediction algorithms to essentially describe themselves in terms of the preceding (and for B, the subsequent as well) I-Frame. So what’s actually stored isn’t a whole frame, but that tiny set of motion vectors, and the difference between the predicted frame and that actual one. Which ideally is practically nothing… because “nothing” compresses really well. But once you have too much motion, the whole thing kind of breaks down, and you’re left with a tiny fraction of the I-Frame space to record a really big difference between last and predicted frames. So you see big artifacts then things get too fast… I have a Panasonic 3-chip consumer camcorder that’s even polite enough to detect this and warn you about it (my other cameras assume I know what I’m doing, and of course, a DSLR in I-Frame-only mode don’t care).

-Dave

[Dave Haynie]

I’m on my second Samsung tablet (a bit newer model), and they do a nice job. If you’re showing lots of video on this, you may want to rendering it directly at screen resolution (1024×600), which might result in smoother play and will definitely save battery life.

With a faster tablet I haven’t noticed it, nor on my 2+ year old phone, but awhile back, I found that Android didn’t actually handle multimedia playback correctly. Basically, the player would be fine, but it wasn’t locking video playback to audio. If the video decoding could keep up, no problems… but if not, rather than dropping a frame (which is the correct thing to do for a player), it just let the audio walk away from the video. This was hopefully fixed in Android 4.x — I have not seen it happen since then. But just something to watch out for.

And yeah, microSD is the right solution if you’re going to have lots of media to play back. It’s cheap memory, and obviously, if it’s fast enough for recording, it’s plenty fast enough for playback. I’d have recommended at least 16GB of internal flash memory, though Samsung does allow parts of applications to move to SD Card as well (that used to be standard in Android, but Google took it out, apparently some users found it confusing).

-Dave

[Dave Haynie]

The faster i5s may well render faster than some i7s, particularly the mobile type. Rendering is so CPU-bound, the OS overhead isn’t a significant factor. The algorithm, sure… one CODEC might be much faster than another, even for the same media type. Like Sony vs. Main Concept AVC.

-Dave

[Dave Haynie]

[John Rofrano] “Win the Loudness Wars with New Metering Options in Sound Forge™ and Vegas Pro
“

Ouch… I don’t want that! And oddly enough, I have used Vegas for more recent audio-only mixing projects than anything else. The Loudness Wars are destroying music… the only way to win that war is to not participate.

-Dave

[Dave Haynie]

“Rent” is too mild a term, albeit fundamentally accurate. I think we agreed on “Ransomware” here. That’s what I’m calling it.

-Dave

[Dave Haynie]

AVC works just dandy in Vegas. You do need a video editing class CPU, but .. well, just saying. Avid has its place in the industry, but it’s never been one to deal well with new or mixed formats. Vegas was the first to do this well.

Fact is, a Camcorder’s job is to capture the best possible video in the field. Today, that’s going to largely be AVC. The format is mature, and you will get twice the quality per megabit/second versus MPEG-2. Not the case for AVC-Intra, but for full IPB AVC, it really is that much better versus MPEG-2. It’s taken awhile to make encoders that do it well in realtime and under 3W or so, but it is good. Just not the best editing format for older software or slower hardware.

And that whole “transcoding to MPEG”… not so much anymore. I upgraded my PC last summer, and these days, AVC in HD is about on par with HDV or DV on the hardware I had in their heyday. Which, of course, tells you it’s time to make that shiny new PC suck again. It’s name is HEVC, it’s got twice the coding efficiency of AVC, and it’s being pushed pretty hard as the answer to 4K delivery, if not necessarily recording.

Which illustrates one truth: AVC is kind of old now. It’s been mainstream for five years or more. If you can’t edit this now, you’re like the guys in 2005-2007 who couldn’t edit HDV. You risk being left behind. Doesn’t matter if it’s hardware or software, if you can’t edit the most modern mainstream format now, you’re not going to love the next generation at all.

Not that I’m in any hurry for 4K HEVC… Vegas 12 already does a fine job of editing 4K AVC content on a good computer. It will be some years before an HEVC CODEC does realtime encoding on a camcorder better than AVC… just as AVC took awhile to rival, then better, MPEG-2. So much like HDV, we’ll get to experience the pain of moving to the next format in steps. I’m good with that… but I do want 4K. No practical reason at all, just for the art of it.

-Dave

[Dave Haynie]

[Raf Erosa] “Is it normal for a 30 min video rendering to the MPG2 720p @12mbps to take 8 to 10 hours to render? I am trying to render mpeg2 1280×720 12mbps (Upperfield first) so I can upload to Comcast. I usually dont have a problem because I used to upload 30 sec commercials. Now I am doing a 30 min tv show. UUGGH!”

Ok, a couple of things here. There’s no “normal”, since a video project can be anything, and it can be running on anything from an old Pentium to a dozens of modern CPU cores. I have AVC projects that render faster than realtime, and animation projects that take four hours for two minutes of video. And that’s on a very fast PC.

So, first of all, it’s fairly easy to find where your bottleneck might be. Start your render. Run the Windows Task Manager, and watch how the CPU is being used.

Do you have 90% or more CPU utilization? That’s a pretty good indication that your project is optimal for your hardware. The last time my system took really long to render, I was rendering 1080/60i HDV (MPEG-2) video to AVC (MPEG-4) for Blu-ray on an Intel Core 2 Duo 2.4GHz system. It ran about 24 hours rendering per hour of video. MPEG-2 is much easier to render, the bitrate not usually a big factor. So if this is you, nailing your CPU, you may just need a better PC. But post more details, maybe we can help.

Are you running any really CPU-intensive plug-ins, Neat Video for one? If so, yeah, this is going to eat CPU like a fat kid eats cake. On a slower system, color grading can also be slow-ish. If I have video that’s noisy enough for Neat Video, I’ll do my color grading and the Neat setup, run that out to some good intermediate format (probably while not counting on using my PC for something else for a day or two, if possible), and then not worry about that level of slowdown ever again.

Are you seeing something like 25% CPU use on a four-core system, 50% CPU use on a 2-core system, etc? That tells you that some plug-in you’re using is single-threaded, and thus the bottleneck in your system. Try disabling plug-ins until you see the numbers jump.. then stop using that inferior plug-in and find something from this century that does the same job with multi-threading.

Do you get either really low or somewhat random CPU performance? Check your media assets for the project. Hard drives as video input are fast, but they’re straight line fast… a GTO, not a Porsche. Streaming speed is fast, but seek time, not so much. For each file you need at the same time, you have one additional seek. Add up enough of these and your HDD performance drops through the floor. First thing to do: render your output to something else. Doesn’t matter what.. any other drive, a network share, a USB stick, an SD card. Going out at 12Mb/s is not a performance issue, but it can be a latency issue if you’re sucking in large input files.

-Dave

[Dave Haynie]

Yup. Keep in mind that HDV is MPEG-2 video encoded CBR… it’s always 25Mb/s, no variable bitrate (I still have an HVR-A1, the “Sony Professional” sibling of the HDR-HC1, though it’s been awhile since I used it). I’m not always sure what magic I need to do to invoke MPEG-2 smart rendering.. BUT taking a CBR source and rendering VBR will always cause a re-encode, in my experience.

-Dave

[Dave Haynie]

This week, if I had to buy a new GPU card for Vegas, I would buy the HD6970 if I could find one, the HD5870 otherwise. I don’t think there’s a substantial difference between the two. But honestly, if I was about to buy, I’d at least wait to see if Sony has anything new to say at NAB in two weeks.

I did a little more checking into these GPUs. AMD/ATi have pretty consistently done a kind of tick-tock product line update, and also within a product line, they roll out their new stuff for the high end. So the HD5870 architecture, VLIW5, also showed up as the basis for much of the HD6xxx line. These were all 40nm (chip geometry), the lesser HD6xxx cards downsized memory bus width and/or clock speeds to save power and deliver a cheaper chip package.

Then the HD69xx series launched with a new microarchitecture, VLIW4. Applarently, AMD did a detailed analysis of their VLIW5 instruction set and found it did an average of 3.6 instructions per cycle. Not the five that were possible. VLIW4 reduces the parallel ops to four at a time, but adds a few tweaks on top of those. The HD69xx is also in 40nm design rules, but the architecture change cuts out a bunch of transistors, so the power is lower, performance about the same, give or take, depending on the benchmarks. The simpler design also let some things run faster, clock-wise, but really, these seem pretty evenly matched.

So I looked at all the info I had last summer and determined that going to a new GPU card probably wouldn’t give much if anything, and it would cost quite a bit. And more to the point, if I kept my HD6970, I would have a better notion of which direction to upgrade, based on Vegas 13. This was even before I realized that the Main Concept CODEC was crippled for newer cards and more recent nVidia drives may well cripple some CUDA and OpenGL operations.

I have not seen detailed Vegas benchmarks on the 7xxx, and nothering on the R9 series. I would expect these to run faster still for Vegas internal/plug-in GPU acceleration. But you get nothing out of the Main Concept CODEC… it’s going to be 100% CPU. In some of the OpenCL benchmarks I posted, the 7970 was far and away faster than anything else, the first GPU from anyone at 28nm. This was AMD’s first board using their GCN architecture, their answer to nVidia’s Kepler.

The R9 280x is pretty much the same architecture, also 28nm, some potential performance tweaks, once again, this tick-tock approach (pretty common in the semiconductor industry — whole new chip architectures cost lots of money and years to deliver). I would like to get my hands on one and compare, particularly after Vegas 13 ships.

I’d like to think that in two weeks, Sony will be at NAB introducing Vegas 13 with full support for the newer GPUs. So the equation could change pretty soon. Not that a 5870 or 6970 would be any less suitable, just hoping the modern stuff is supported. And maybe Sony will have something to add on the nVidia vs AMD question. Maybe even some info on potential nVidia software imposed performance limitations.

-Dave