[Dave Haynie]

When Vegas 11 first introduced full GPU acceleration, I bought both an AMD Radeon HD6970 and a nVidia GTX570 based board — neither was the fastest available, but they were $300 each. And that was nearly two years ago.

The HD6970 matched or outperformed the GTX570 at every benchmark, including Sony’s own. So that’s what I went with, and I haven’t been disappointed. You can certainly get faster versions of either GPU-company’s chips these days. And I suspect at least some of the problems were based on nVidia’s OpenCL implementation (with nVidia, CUDA is also OpenCL, so Sony says “CUDA-enabled”, but they’re really using the OpenCL APIs, which were not as debugged back then).

Given that, some things are still, years later, CUDA-only. Nothing from Sony, but some 3rd party stuff. So it’s important to know is you have anything critical that would benefit from CUDA but not from OpenCL.

It’s also important to understand that GPU acceleration isn’t a panacea. For one, it takes some time to compile a GPU problem, and some time to communicate to/from the GPU. So while your CPU may usually hit 95-100% alone, you may only see 70-80% use with the GPU. That’s the time the CPU is waiting for the GPU to finish things. What this implies is that, as your CPU speed increases and/or your GPU speed decreases, the GPU stops helping. So folks with fast i7 systems tend to downplay the effect of the GPU… meanwhile, guys like me (six core AMD 1090T at 3.2GHz) are slow enough to really appreciate the GPU.

There are also things it does well, and things it doesn’t. There are a couple things to be aware of. The GPU isn’t used much in just plain video decoding as part of a render. So if you’re rendering one video layer to another format, don’t expect the GPU to help much. Unless that video format itself is accelerated… most of the AVC CODECs get a boost on their own from the GPU. Once you start layering things and adding effects, the GPU starts being pretty helpful. I’ve seen 2x-3x improvements on some dense animation renderings, not too different in nature than Sony’s benchmark project (available on their site).

In short, like most things, it’s just another tool.

Also, watch recommendations for very expensive “workstation” GPUs, like nVidia Quadro or AMD FirePro, just in general. Yes, these are “optimized” for workstation use. But that generally means 3D mechanical CAD, since that’s about the only common workstation activity that’s really limited by OpenGL performance. And OpenGL performance is precisely what they’re optimizing here. Much of this is in software, not hardware. As well, at any given generation, the workstation cards may be using older technology. For example, until this year’s “K” (for “Kepler”) series of Quadro cards (K2000, K4000, etc), nVidia’s Quadro series were shipping with the same “Fermi” cores for the last three years, the GPU core that originated in the GeForce GTX480 in 2010. The consumer cards, GTX5xx and GTX6xx, where using the Fermi cores in early 2012.

So if you’re really planning to spend $700+ for a GPU card, at least be sure it’s not going to render video much slower than a $350 gaming card. All of these cards are doing video acceleration (which isn’t generally usable for editing, only playback) and compute acceleration (eg, OpenCL/CUDA), and this is what concerns you for video work. Nothing in the “professional” or “workstation” series are specifically optimized for video. Yes, some plug-ins (anything “3D”, for certain) do use OpenGL, and your pro-class cards have faster and more stable OpenGL than gaming cards. They may also have ECC memory and a few other things that say “professional”. You can even find a few cards, like nVidia’s Tesla cards, which offer really high-end GPU computing, cost more than all the rest of your PC put together (most likely), and don’t actually do graphics. Also not an issue in video computing.

-Dave

[Dave Haynie]

Yup.

There are a few problems with converting 60p to 24p. Let’s look at the basic issue of “jumpiness”.

When you shoot at 24p, for a normal cinematic look, you would normally want to use, in film terms, a 180-degree shutter. Classic cameras use a rotating shutter, and you would set the shutter speed as a fraction of a full 360 degree rotation, one rotation per frame.

So this is, of course, 1/48th of a second for 24p. This is why pro video cameras often include neutral density filters. Much of what folks recognize as “the film look” will be the degree of motion blur you’ll typically see within that 1/48th window. When you select frames shot a 1/125th second, the best you’ll get is the look of 24p shot at 1/125th second, which is going to look very stuttery on fast motion.

Only, it’s not quite even that look, because 60fps doesn’t map evenly into 24p. Your choices are to not blend, as John suggested, which gets you single 60p frames mapped into 24p, but not at an even cadence, since you have 2.5 frames at 60p per single frame at 24p. Or you blend (and there are some plug-ins which may do a better job than Vegas’s built-in bending algorithms) which will take 2, 3, or 2.5 (one frame weighted less in the blend) to deliver each 24p frame. This can restore something that hints more at a longer exposure, which may help, but it can also work out unfortunately, particularly on fast motion.

-Dave

[Dave Haynie]

Try one of those discs in a PS3. They might be just fine.

Some BD players won’t play BDVM formatted discs from BD-R. Period. Technically, the BD spec didn’t originally allow playing a BDMV disc that’s not AACS encrypted. Some do anyway. Last I checked, my PS3 does it just dandy. On the other hand, I have heard that Sharp intentionally prevents all of their BD players from playing “home made” BDMV formatted discs, though they will play the lesser BDAV format.

BDAV is a much simpler format originally intended to differentiate “home movies” from “commercial” movies. And if it sounds like independent video professionals were not considered, that would be exactly correct. BDAV was also the basis for the AVCHD format, though they’re not identical either. Some BD players will also play AVCHD discs; usually those who made AVCHD camcorders, such as Panasonic and Sony.

Sometimes, the lack of BDMV support on BD-R is just due to bugs; always run your BD player with the latest software. Unless, of course, that software was released to disable BDMV on BD-R playback (never heard of that, but it’s not impossible).

THEN, there’s the BD-R format specifications. Originally, the Blu-ray specs only allowed BD-R to carry the BDAV format. In the 2.0 BR-R and 3.0 BR-RE specifications, they finally deemed BDMV worthy of living on a BD-R… that’s legal. But it still may be necessary to have it AACS encrypted, at least on some players. Players released before the 3.0 spec are technically following the spec in rejecting a BDMV formatted disc. So again, be certain they’re up to date.

BUT WAIT, there’s MORE!! Could be the media. The original Blu-ray recordable media was very unlike most DVDs. Rather than use an organic dye, it used a sandwich of copper and silicon. This started out very shiny, and the write-laser heats this sandwich hot enough to fuse the two layers, causing a nicely irreversible non-reflective “pit” to be created. This made BD-R immediately more reliable than most DVD-R formulations.

But that wasn’t good enough for a few comedians at Pioneer, Taiyo Yuden, and Mitsubishi. They worked up a version of BD-R that uses the same kind of organic dye technlogy as most DVD-Rs… you hit the dye with a laser to make it transparent, allowing access to the reflective layer behind it. Thus, the original formulation is called H2L (high to low), and this new and evil formulation is dubbed L2H (low to high). Players technically need a software update to correctly play L2H discs… the PS3 got this update in version 2.20 software, March of 2008.

So, things to try:

– Your burned discs in a PS3.
– Update all your BD player software and try again.
– Hut up some H2L discs and try again

-Dave

[Dave Haynie]

That’s just it — AVC delivers better quality for the same bit budget, or roughly twice the content at the same quality. Obviously, you’re not going to render anything better than your original material no matter what the bitrate. That’s the limit Rich seems to have hit on his example.

When very well encoded, AVC delivers about twice the coding efficiency. It does this at the price of complexity.. it’s probably at least 3x-5x as difficult to encode AVC, and about the same to decode it, versus MPEG-2. And it’s taken the industry awhile to develop the technology to encode it well — first generation AVC camcorders didn’t match MPEG-2… they didn’t have the computational performance to encode better AVC.

Get used to it.. things do advance. There’s a new one on the horizon, HVEC (High Efficiency Video Coding), which was accepted by the ITU as H.265. This promises twice the coding efficiency of AVC. It’s going to be 4-5x as difficult to encode, and about 3x as difficult to decode.

And just when my PC was getting fast enough to edit AVC without a great deal of pain 🙂

-Dave

[Dave Haynie]

I wouldn’t say “never buy an AVCHD camcorder”, just recommend that, particularly for professional work, that you know your camcorder and your file formats.

Full IPB AVC delivers twice the coding efficiency of MPEG-2, when well encoded. It took a number of years before AVCHD camcorders actually did a good job of encoding AVC, but they do these days. This means, as long as you haven’t blown past the limits of the format, a 25Mb/s AVC recording is going to deliver about the same quality as a 50Mb/s MPEG-2 encoding, all else being equal.

Editing time, sure, is slowed by any IPB format versus an I-Frame only format like DV or M-JPEG or Cineform. MPEG is so simple, in current terms, it doesn’t add dramatically to editing or rendering times.. until it does. One or two tracks, no problem. Dozens.. you’ll get hit by the decoding time. When I was doing benchmarks, I needed a whole Intel Core 2 Duo, both CPUs running, to decode a single stream of 1080/24p AVC, using the CPU (that same PC did it using under 10% CPU with GPU rendering, but our NLEs don’t really use GPUs for decoding, just FX and some aspects of compositing).

Still today, I’ll transcode to MPEG-2/MXF (I used to use Cineform, but it’s too broken these days, IMHO) before starting any complex edit. For simple stuff, though, not afraid of AVC.

And the other thing about AVC format camcorders (not so much AVCHD, which is the Blu-ray derived specific consumer format, but AVC in general) is that not all are IPB AVC. Newer Canon HDSLRs, for example, can do IPB AVC, but they also do AVC-Intra, which has lower decoding overhead than MPEG-2 (it’s effectively an updated version of high-def DV). Older Canons only encoded IP, so the CPU overhead is less (but at 44Mb/s, the HDD overhead about doubles.. which is usually the trade-off).

-Dave

[Dave Haynie]

Yup.. not sure if that’s a Microsoft thing or a Sony thing, but it is limited. With that said, if it’s importing as a 48-bit image, I don’t really need to tweak the raw import anyway… normal color adjustments will work fine. If it’s importing as a 24-bit image, then I need more control.

Given that Sony’s now supporting Lab color images (as of Vegas 12) it’s clear that at least someone there is thinking about still image issues. And still or not, they are going to have to add RAW support into the workflow, one way or another.

And that was kind of my argument for .DNG and CinemaDNG support being built-in. Vegas is directly dealing with raw at that point, as they have to with R3D (Red camera compressed raw format) files today. I don’t expect them to get too involved in the DSLR raw format of the week (a new for at least each new sensor if not each new camera), but there are plenty of tools for turning any other raw format into DNG.

-Dave

[Dave Haynie]

You can take the DVD Architect project, change the project type to DVD, save it separately of course, and produce a DVD. Maybe.

Sometimes graphical elements won’t line up perfectly, depending on the complexity of your Blu-ray. You may be doing things that don’t really map to DVD, despite the fact that DVDA is basically modeling Blu-ray as an High Def DVD (eg, it’s not doing many Blu-ray specifics).

There’s an awfully good chance that’s all you need. Sure, the Blu-ray project video will have been compressed once from your originals to Blu-ray, and you’re recompressing to DVD in DVDA. But Blu-ray video contains about 6x as much useful information as DVD, so DVD video rendered this way will look pretty good.

It will definitely get better if you re-render video from Vegas for the project… same thing you had before, but rendered to DVD’s MPEG-2 format. The real win here is less avoiding the extra compression step, and more that Vegas gives you much more control over MPEG rendering than you can get in DVDA. For example, for any longer project, you want VBR MPEG-2, which you can’t get in DVDA (last time I checked, anyway).

Same goes with audio… if your DVDA project is using audio rendered at Blu-ray resolutions, it would have to be recompressed for DVD. If it’s the same old, same old 192kb/s or 448kb/s AC-3, it’s already in DVD format.

-Dave

[Dave Haynie]

I did put in the suggestion.

Vegas supposedly uses the Microsoft RAW camera support system now. This works something like audio or video… they add CODECs to the system and it automagically lets new cameras into the party. But Microsoft isn’t always that diligent about it, and I do wonder if they’ll “pull an Adobe” and start making this tied to Windows 8 or whatever’s current.

This is a support means I find acceptable far as that goes… Sony’s not directly in the camera/photo business. But DNG is a kind of a special case. For one, it’s not camera specific, but the anthesis of that — one format that’s supposed to cover any camera’s RAW sensor model (well, most). Secondly, once you have DNG support, since they already have MXF support, it doesn’t seem a big jump to support CinemaDNG, which is basically just DNG frames in an MXF wrapper — an open format for RAW video.

-Dave

[Dave Haynie]

I didn’t think Sony had support for .DNG just yet, though that would be a sensible way to go. I usually keep stuff around in Canon format anyway, not doing much with .DNG itself, though that might be a wise move at some point… the RAW tools do occasionally drop a camera model from their list of supported Cameras (my old Canon Pro90IS, from way back in the early days of digital cameras, was such a model that was dropped from some of the common RAW libraries).

-Dave

[Dave Haynie]

It’s not a video file, it’s a motion sequence of still image files that resolve to a video file when that sequence is used on playback. Not a significant distinction, other than the fact it may be a bit unwieldy to deal with 1,440 files per minute of video.

But this isn’t all that unusual. I’ve dealt with a number of animation/rendering programs that output in individual still photos in sequence. It’s pretty common to render stills from an animation/rendering program like Blender, for example, just to that if there’s a crash, no need to lose days of rendering progress.

This is also what I’m already doing (and yeah, I guess, it’s technically just as RAW…) when I create a time-lapse video with one of my Canons (something I switched to after hitting the wall on the built-in intervalmeter on my Panasonic camcorder — it just stops after 24 hours); you can pretty much decide if you want RAW or JPEG, and HD, 2.5K, 4K, 5.5K, in video terms.

What you’re recording in both cases is motion video. What you’re saving are individual files in sequence, not a video file. And not an important difference, either, once you do the extra work to get your stills into some reasonable video file format.

Adobe already has a format called CinemaDNG, which isn’t actually only DNG, but basically can encapsulate DNG in an MXF file to deliver exactly what you’d want (well, as soon as Vegas supports it) — a true RAW video format based on standards.

-Dave