[Dave Haynie]

Not yet… maybe, once they have that version for the 6D or 60D 🙂 Oh… wait… this is happening so fast! It’s showing up for the 6D and the 60D now. Maybe I’ll play… it does sound cool.

And the 50D!!! The 50D didn’t even have a video mode! Now they’re getting 1592 x 1062 video, effectively. Sure, it’s individual raw snaps, but still.

I’ve done very similar things, though… for animation, morphing, and time-lapse. Basically, you’re loading up a huge pile of PNG or TIFF or JPEG or whatever photos, importing them into Vegas as a frame each or so in your project.

Of course, it would be possible and great if Vegas would take the DNG files directly. Converting them to JPEG is not the answer; that’s basically going to given you a video file that’s more or less the same idea as the “All-I” mode on the 6D and the 5DmkIII. “All-I” means AVC-Intra in video geek speak; it’s AVC’s I-Frames only, each independently compressed, essentially an evolved version of Motion JPEG. Yes, this should be an improvement over Just Plain AVC (the IP frame version in the older Canons or the IPB version in the newer models).

Most of the tools I’ve used for this can render out in BMP, PNG, or TIFF format, all of which can directly import to Vegas. Additionally, at least BMP with proper sequences can import into VirtualDub as video, then easily rendering out (with your supplied frame rate) as uncompressed AVI, which is just as ginormous as all those photo files, but easier to handle. When I do bring the zillion photo files directly into Vegas, first thing I do is render out to an uncompressed video file (working with animation anyway, that’s a must, since I nearly always want to preserve the alpha channel and yet still load this into another project).

Of course, if you’re planning to render to intermediate files like DNxHD or Cineform, there may be little difference going through JPEG, particularly very high quality JPEG.

So yeah, Lightroom will batch convert from DNG to TIFF and others. Not sure it’s the fastest thing, but you at least have a chance to make adjustments there before sending down to an 8 or 10-bit life as a video file. More practically, though, I’d like a one-stop conversion, but I guess the Magic Lantern people are primarily concerned about getting their RAW dump files into any format regular folks can use.

-Dave

[Dave Haynie]

[John Sieber] “But has anyone noticed that the file size created from both new (old) Sony AVC render templates is the same? In fact, I’m getting a slightly larger file from the 720p as I am from the 1080p (using the default settings in those templates). Should it be?”

Sony’s AVC CODEC has always been constant bitrate. So the output file size is dependent only on that bitrate. It stands to reason that a 720p60 render would be about the same size as a 1080p30 or 1080i60 render per unit quality. But when you’re set for a specific bitrate, as the Sony CODECs are, that’s what predominates anyway, regardless of other video factors.

-Dave

[Dave Haynie]

You can definitely solve this problem in 4CH mode. There’s no independent volume control, but you can level the mics using the mixer. Hit MENU, scroll to MIXER, select it. Then scroll until you find INPUT PAN, and use this to match the mic levels. From then on, both mics should be good with the same gain set.

Or you could drop a pad on the hot mic.

-Dave

[Dave Haynie]

I looked up some of the specs of a few older digital recorders… pretty shocking stuff. Without going into too many technical details, it’s all about the accuracy of the clock (quartz crystal, same thing that sets time in just about any modern device). The worst clock crystal I’ve ever used in an electronic device, cheap 100ppm crystals, would give you about a half hour before dropping enough samples to lose sync. That’s bad.

But you can do worse. There are cheaper timekeepers, like ceramic resonators, that might only be 1/5th as accurate. Most cheap digital watches use 25ppm crystals or better. For my last major project, I used 1.5ppm crystals… you could stay in sink for over a day with one of those bad boys. Well, two.. both recorder and camera need to be accurate. But oddly enough, I haven’t seen this problem with cameras, only digital recorders.

-Dave

[Dave Haynie]

Your problem isn’t the 44.1kHz vs. 48kHz sampling. Rather, it’s the difference in sampling clock accuracy.

You tried the obvious solution.. stretch or compress the unsynched track to match. But if that syncs it at the ends but not in the middle, you have a wobbly clock source. This wasn’t digitized from tape or something, was it? What was the source of that track?

-Dave

[Dave Haynie]

You can basically put any kind of video clips on the Vegas timeline, and render to whatever format you like… Vegas does a pretty good job of dealing with the differences.

In your case, yeah, HDV and AVCHD will work just dandy together. You do want to use the same format, since you don’t want it to be visually obvious in the final video that there are two cameras in use. As well, you need to color match the two as closely as possible. The difference between 1440 and 1920 horizontal pixels souldn’t be easy to spot… the other stuff, yeah, you can see that.

-Dave

[Dave Haynie]

[John Rofrano] “The key is to buy a GPU that is more powerful that your CPU. Having a Quadro 2000 with a Dual Core is probably beneficial, having it with a Hex Core probably requires a Quadro 4000 or 5000 to see a benefit over 6 core. So you have to match your components. In other words, you have an underpowered GPU for your CPU.”

That’s pretty much it. Here’s basically what happens.

For CPU-only, you have a traditional multiprocessor, which can handle pretty heavy lifting. Other than waiting on I/O, the CPU can be kept pretty well fed in rendering, this is all pretty well understood by programmers. A few things, like tapping SSE “vector” instructions or efficiently breaking up a render across multiple CPUs requires some talent to do well, but it’s not new, and it’s “immediate”… the whole program runs on that CPU.

The GPU is a strange ranger. It’s got somewhere between 200 and 2000 simple but fast floating point processors. These aren’t necessarily ideal for general purpose computing, but they have been evolving that way. The job of actually scheduling code to the GPU is complex enough that you never do that — you write code in abstract under the OpenCL (or CUDA) computing model, which is compiled and sent to the GPU of choice as needed.

Those last pieces are critical: the CPU does a job other than rendering… compiling that OpenCL code. Then it has to copy stuff to the GPU. Only then the GPU starts working, and it signals the CPU when done, which then does a bit of cleanup and unpacking of results. It looks like of like this:

CPU-Only Activity:
CPU ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
GPU ________________________________________________

CPU + GPU Activity
CPU ^^^^^^^XXX_________XX^^^^^^^^^^^XXX_________XX^^
GPU __________^^^^^^^^^________________^^^^^^^^^____

So, in solving just one problem set, the GPU is taking over for the CPU, and there’s the relatively small bit of overhead, represented by XXX, compilation and communications. It’s easy to see here that, unless the GPU is at least a bit faster than the CPU, you might be better off just running the CPU.

Now, this is vastly oversimplified. For one, you may have multiple CPU threads, all doing things with the GPU. Ideally, there’s enough work to pipeline everything, so that no CPU is actually idling (the _____ in my graph). In practice, not yet… I get a nice boost in rendering and even editing with the GPU (my six core is AMD, so it’s maybe half the performance of the Intel i7 six core), but I do see CPU performance drop from nearly 100% to 75-80% during a GPU render.

Another thing… it’s pretty complex to go from regular CPU coding to GPU coding. So there’s a certain learning curve, and there’s no reason to expect it’s even close to optimal yet.

-Dave

[Dave Haynie]

Well, it’s a new option… it may be awhile before it replaced H.264, just as MPEG-2 is still in use.

I’m sure they’re thinking “4K” with this. The coding efficiency is supposed to be 40-75% better than H.264 (somewhat dependent on how you measure relative quality, by PSNR or by subjective human judgement), which means that 4K on standard Blu-ray is possible. Then again, 4K would fit just dandy with the existing CODECs on the BDXL format, which already exists. As they say, 4K at 20-30Mb/s, which is certainly in keeping with current Blu-ray rates. Or Red’s RedRay project, which is claiming 4K at 20Mb/s.

The standard includes support for both kinds of 4K: 3840×2160 and
4096×2160, at up to 120p, as well as the two corresponding 8K versions, also at up to 120p. What it doesn’t include: no interlace support.

Of course, what this means for us is another round of encoding and playback pain on PCs. Chances are, AMD and nVidia will work H.265 decoding into their GPU accelerators, since these are all software programmable. I didn’t find an estimate of the additional coding or decoding complexity over H.264. But some things, like the motion estimation space, are dramatically larger. Add that to 4K resolutions, and you’re definitely talking an exponential increase.

Looks like Intel gets to sell us faster CPUs for another ten years 🙁

-Dave

[Dave Haynie]

The good news for Blu-ray is that BD-R and BD-RE were released as part of the original spec, rather than something that came much later. The bad news is that, despite this, there is no requirement for a Blu-ray player to support either recordable format. And some players may even reject BDMV on BD-R, because there was a big contraversy over whether this would be fully supported.

Your best bet is to use a high quality HTL type disc… some sites, like videohelp.com, track users’ compatibility results with different media. Worth a look.

-Dave

[Dave Haynie]

A decent power estimator is here:
https://www.extreme.outervision.com/PSUEngine

You’re probably ok, assuming you don’t have any PCI cards, rarely use powered USB devices, etc. Probably.

But keep in mind, a 450W supply may or may not power a system that’s actually using 425W-450W. A proper supply IS overdesigned, so that the rated output is greater than the sum of the individual outputs.
A cheap supply, not so much. You don’t have one PSU at 450W — one supply might deliver +3.3V@16A, +5V@25A, +12V@21A, -12V@0.8A, +5VSB@2.5A (a lousy one), another +3.3V@20A, +5V@20A, +12V@33A, -12V@0.8A, +5VSB@2.5A (a decent one), which lets you trade off power demands from that total. Or you may have something like +12V@18A, +12V@18A, +5V@15A, +3.3V@24A, -12V@0.3A, +5VSB@2.5A… less +5V power, more overall +12V power, but that power is split between the CPU and the peripherals… if your CPU needs +12V@20A but the peripherals are only using +12V@10A, you’re still overloading your supply.

This is the usual reason people recommend a higher spec supply. That, and the idea that you may eventually upgrade… a higher end GPU could easily add 100W to your power budget, pushing you into a new PSU as well. I don’t see an obvious problem with your system as-is, but any significant changes may demand more power.

-Dave