[Dave Haynie]

[Norman Black] “MC did that with the OpenCL AVC encoder for AMD. Odds are they did it with Nvidia CUDA as well.”

That was supposed to say “Main Concept”, not nVidia. This is the same thing Adobe did for their GPU accelerated code early on at least — they looked for a few very specific bits of hardware, and supported only those.

And yeah, I found some online stuff from awhile back about the hard-coded chip family stuff in the Main Concept drivers. Really dumb. Hey, if you’re not sure, go ahead and pop up a warning notice. But looking at the actual chip is kind of the opposite of the point of OpenCL. It runs on nVidia, it runs (more slowly, but still) on newer Intel GPUs, and the fairly exotic Intel Phi coprocessor board (Intel’s sort-of answer to nVidia’s Tesla).

-Dave

[Dave Haynie]

I have done most of those things in Vegas and Photoshop… I’ve done photo-to-video, “The Ken Burns Effect”, as well as just plain short animations (not for a while… I was getting paid for that a couple of years ago).

And that’s exactly the technique I’ve used for shadows in composite stills.

I’ve done animations like the ball treatment directly in Vegas, then rendered out uncompressed with alpha channel so I could bring it back into an animation.

The “Ken Burns” parallax trick isn’t difficult. The key is what he’s showing — make yourself a clear background. I’ve usually just panned and/or zoomed the “cut-out” foreground figure a bit, never did one with as much complexity.

The thing that really sells it is the “puppet” effect, having the tennis player move really nicely. That would be pretty difficult to achieve directly in Vegas. I’d probably wind up breaking up the character into pieces and key-frame animating them in Vegas in separate layers… possible but tricky, and trickier still to get the motion right. Or just drawing them stop-motion-style in Photoshop… very time consuming if you need many frames.

I just bought HitFilm to make some of this stuff much easier. I have not had a chance to learn it yet, but the sale price was right a few weeks ago.

Just because I can figure out how to do it with just Vegas, Photoshop, and Boris Continuum doesn’t mean I should be happy with just those tools. It’s pretty busy work.

-Dave

[Dave Haynie]

Ok… first, let’s see here. He’s running an AMD FX-8350 CPU, which is a kind of hybrid 8/4 core processor. In fact you all don’t know the story, AMD’s latest SledgeHammer/Piledriver architecture builds processor “modules”, which consist of two Integer and one floating point unit. So it’s not bad on pure integer code, but tends to be slower than you’d expect on floating point code. There’s lots of floating point code in video. But of course, some of that can be done by the GPU. Sometimes. It really is getting hard to predict these things.

GPU is the nVidia GeForce GTX660Ti, which is based on the new Kepler architecure, runs internally at 915MHz, contains 1344 CUDA cores, and supports a 192-bit GDDR5 memory bus capable of 144.2GB/s memory bandwidth. In short, it’s a pretty good GPU. Also supports up to four monitors at up to 4K resolution.

So, one question: what was the Vegas setting of GPU acceleration? That’s the setting on the Preferences/Video panel. It would be interesting to change that setting (you have to reboot Vegas) and see how it affects playback.

So you ran MainConcept AVC, and got 2:56 seconds with the Main Concept CUDA setting set, 2.57 seconds with OpenCL set, and 2:56 seconds with CPU-only set. Pretty much the same with Sony AVC.

So… hmm. You didn’t specify your render settings, which does matter. For reference, my system did 5:19 for Main Concept rendered to 1080i60, 25Mb/s, with “8-bit best” set in the project settings. That was with GPU disabled in Vegas, and CPU-only as a render setting. And I got 0:57 with GPU enabled and CUDA rendering. I didn’t try a mix.

So your results: given that we KNOW that the Main Concept CODEC won’t use OpenCL, and you get the same result with both OpenCL, CUDA, and CPU-only, it sure looks like Main Concept isn’t using CUDA, either. I mean it could be, but the Main Concept AVC CODEC does practically everything except entropy encoding (the lossless compression phase) on the GPU. It would be nearly impossible for CUDA vs non-CUDA to give the same result. It could be that NC does the same brain-damaged things in CUDA that it does in OpenGL, only supporting cards it specifically knows about. The 6xx series shipped first in March of 2012, so it would be pretty poor if Main Concept didn’t support them. Also, given the result on the Sony benchmark suggests the same thing, I’d look at your CUDA support.

My first recommendation is to see if CUDA is actually working at all on this system. Try setting the GPU acceleration setting in Preferences/Video. If there is an OpenCL driver available, you’ll see it as an option there. Or download the Geeks3D CPU Caps Viewer https://www.geeks3d.com/20131113/gpu-caps-viewer-1-19-0-videocard-information-utility-opengl-opencl-geforce-quadro-radeon-gpu/ … this will show you that OpenCL and/or CUDA are enabled, and let you run a few short demos to prove it’s all working.

. When you say

-Dave

[Dave Haynie]

[Thayalan Paramasawam] “After i saw this forum regarding graphic card,i am confused to buy graphic card.So pls adivice me…….which is best card for SVP 12.
“

Honestly, I’d stick with my current one right now, particularly if AVC output is a primary target. Or look for a good deal on a used AMD Radeon HD6970 or maybe an nVidia “Fermi” board, if you’re really behind and can’t wait 3-6 months for something to change. Vegas actually supports the newer AMDs fine, but Main Concept is broken for anything beyond the HD6xxx series (and anything else doing OpenCL). nVidia could almost certainly make their Kepler chips run far faster in OpenCL, but at present, they run slower than the older Fermi chips on many if not most benchmarks.

-Dave

[Dave Haynie]

[John Rofrano] “I’ve read reports of FCP X handling 16 streams of 4K with it! With Dual GPU’s it should be a killer.”

While that’s probably true, let’s see where the dust settles on 4K. Right now, your HDD is the gating factor, since (well, at least until CES earlier this month) most 4K camera were using very light compression. Red encodes in R3D (already well supported in Vegas), some are using CinemaDNG, which is a similar idea (interframe “RAW” CODEC).

But that’s going to change fast. Sony put out a pro-priced camera at CES, the FDR-AX1, that’s recording in AVC. And a [pro|con]-sumer model, the FDR-AX100, also recording in AVC (also pretty interesting because it’s a consumer-ish camcorder sporting a single 1″ sensor — moving toward DSLR tech there a little). So whatever your PC can handle with regular camcorder AVCHD, you can handle about 1/4 as many of these streams. And some companies are looking at using a next-generation CODEC like HEVC, which is going to make that even worse.

On the plus side, the latest I’ve seen out of Vegas suggests that IF Apple really does finally have good GPU acceleration in FCX and can use both GPUs, the Mac Pro may be about where you’d want to be for a 4K workflow.

I noticed awhile ago that HD in AVC had fallen to a level of annoyance where I didn’t really notice that it wasn’t MPEG-2 or Cineform or some lesser CODEC. That alone clearly indicates it’s time for something more evil to slow us all down. Of course, any machine that gives you that HD/AVC ease of editing will be just dandy for the simpler forms of 4K… though you’ll need a very new (and as we’ve seen, not well/fully supported by today’s Vegas) graphics card to have actual 4K modes to drive actual 4K monitors. Not too worried about it, particularly given the price of 4K monitors right now and how new my 2.6K monitors are. But it is good to be aware of what’s coming. It’s also pretty clear to me that much of this comes from the GPU… that’s a critical part of the video editing PC formula, going forward.

-Dave

[Dave Haynie]

[Norman Black] “The Mainconcept AVC OpenCL does not support AMD graphics core next GPUs. This means 7xxx series and later. Includes the current R8/R9. I found this out the hard way. My old 5850 flew on MC OpenCL and my new 7950 gets no use at all. Vegas itself and Sony AVC are fine with current AMD cards.”

I didn’t realize that… looked up a little information about it. They basically pulled a “Adobe Premiere” here. They have a list of supported cards (or perhaps GPUs, like Juniper, Cayman… nothing beyond the HD6xxx series) hard-coded into the Main Concept driver. If you don’t have that device, you don’t get to use OpenCL. STUPID! Worst move I can imagine… the whole point of OpenCL is that the “compute device” doesn’t matter.

Now it makes sense why nVidia isn’t supported at all by the Main Concept driver, even though nVidia’s OpenCL sound work fine with it (if, perhaps, not as fast as CUDA, particularly on a Kepler chip).

-Dave

[Dave Haynie]

[Stephen Crye] “For years I was spoiled in that I had only one camera a Sony HDR-CX550V. When the files were imported with the Sony Picture Motion Browser utility, they were all given a very specific date/time based name, for example:”

Yeah, that’s a really good point. When I used to use DV and HDV, the capture tools always gave me files with the date and time encoded in the file name. They were getting that from the metadata in the video. HDV of course uses MPEG-2 to store video and MPEG-2 Transport Streams to transport it. Curiously, AVCHD also uses MPEG-2 Transport Streams.

Not that I’ve tried this, but I’ll bet that, if you had the camcorder date set properly, you’ll have at least some files with time/date metadata. And going back some years (or maybe still, I didn’t catch the gear in question), pretty much for certain, at least back until the days of analog capture.

I did a 30 second Google search and found this:
https://www.dvmp.co.uk/

This does a bunch of stuff, but claims to be able to add time/date from metadata to your file. They offer a demo version. Again, not something I’m endorsing, and there may be other tools that do the same thing, but it’s worth a shot.

-Dave

[Dave Haynie]

FYI: I wrote the best disc data recovery program, in the 80s and early 90s, for an early multimedia-friendly computer system that’s perhaps faded from popular memory for some time (“DiskSalv”, for the Amiga OS). I have about ten years of experience in recovering data from bad discs.

Much of this is file system dependent. When you do a file recovery, the software for this will not necessarily trust the existing file system information, and perform a linear low-level scan, to build a model of that disc independent of the existing (or damaged) file system root information.

When directory and file information is available, there’s an awfully good chance the date information of the original file is available as well. But it is file system dependent. It’s common for the file name and data to be stored in the same locale, so if they’re restoring the original file names, there’s a pretty good chance the original dates were there as well.

It’s nearly impossible that a full restore of your original drive found 99% of every file and file name but missed the creation or modification dates. If some dates are missing and some restored, that may even be a little reassuring, that your videos lived but the date data perished. You lost a less-valuable thing. But if they’re all day-of-restoration, that’s pretty much a certainty that their restoration tool didn’t even try to do file date restoration.

-Dave

[Dave Haynie]

You got me curious about what my recently upgraded system would do in Vegas 12. When Vegas 11 came out, I bought both nVidia GTX570 and AMD HD6970 cards… both around my $300 budget, and did extensive benchmarking, versus each other and Vegas 10. I chose the HD6970. Have not taken a hard look recently, but I just ran a few benchmarks. Also didn’t use the accelerated Main Concept AVC encoder last time.

So this is the HD6970, an i7-3930K (6 cores + hyperthreading = 12 virtual cores), 64GB DDR3-1866. Rendering is from a 6TB RAID10 to a 960GB SSD (basically trying to eliminate any I/O-related issues).

So first, playback/preview. I set the mode to Best (Full), in a full sized 1920×1080 window on a 2560×1440 monitor. Ran these tests:

Frame Rate CPU GPU
8-bit, Good, GPU enabled 29.97fps solid 13% 36%
8-bit, Best, GPU enabled 29.97fps solid 20% 37%
32-bit, Best, GPU enabled 29.97fps solid 17% 48%

8-bit, Good, CPU-only 2.5-29.97fps 44% 11%
8-bit, Best, CPU-only 2.9-29.97fps 55% 14%
32-bit, Best, CPU-only 1.1-29.97fps 92% 13%

The effect of the GPU here isn’t even funny, how good it is. The CPU-only preview is very jumpy, the GPU smooth as glass in all cases. Though I’ll give some credit to Vegas here… in the past, Vegas didn’t make full use of a multi-core CPU for previews. Here, it’s doing pretty well.

Next is the actual rendering. Since I never render at anything less than “Best”, I didn’t bother benchmarking the “Good” setting, despite that being the default for the Sony Benchmark project. All renders are 1080i60. CPU is estimated average, GPU is peak.

Time CPU GPU
MC-AVC 25Mb/s 8-bit GPU-enabled 0:57 35% 93%
MC-AVC 25Mb/s 32-bit GPU-enabled 2:40 25% 77%
Sony AVC 16Mb/s 8-bit GPU-enabled 1:24 25% 56%
Sony AVC 16Mb/s 32-bit GPU-enabled 2:28 25% 63%

MC-AVC 25Mb/s 8-bit CPU-only 5:19 90% 11%
MC-AVC 25Mb/s 32-bit CPU-only 6:52 90% 10%
Sony AVC 16Mb/s 8-bit CPU-only 3:59 75% 24%
Sony AVC 16Mb/s 32-bit CPU-only 5:33 70% 33%

The GPU peaks for non-GPU renders are very momentary… and noticeably higher for Sony than MC. No idea about that one.

It’s interesting that the Sony AVC seems to be less computationally complex vs. Main Concept, but the latter gets more help from the GPU.

Both CODECs use the GPU better than I had seen in Vegas 11, but the Main Concept CODEC is out of control here, really shows that most of the render is happening in OpenCL, not on the CPU. Of course Vegas itself is responsible for some of this, but both CODECs get that same boost.

-Dave

[Dave Haynie]

[John Rofrano] “[Stephen Crye] “But, there are posts that show that sometimes the newer GTX cards either don’t improve things or actually are slower!”
If I understand the problem correctly, it’s that NVIDIA changed their API for the 6xx 7xx Kepler series cards from the 5xx Fermi series. If you use the old Fermi API (as Vegas Pro does) on a Kepler card you will only gain access to 1/4 of what the card is capable of. This is why 6xx & 7xx series cards are actually slower with Vegas than 5xx series cards. “

That’s kind of a surprise… not so much the API changes, that happens. But OpenCL is supposed to avoid that, being higher level than CUDA (you can also run OpenCL on native x86 … or on FPGAs). Sony’s only using OpenCL for the in-program rendering, no more CUDA specifics. Are they claiming that nVidia hasn’t really supported OpenCL using the full Kepler architecture?

So I Googlez this… yeah, it’s apparently that, or at least in part… CUDA 4.0 seems to drop OpenCL performance by 50% compared to CUDA 3.x. And some folks claim that OpenCL has not been optimized for Kepler, at least not yet. I found a review on Tom’s Hardware of the GTX660/670 — consumer market Kepler-based devices — that covers a bunch of OpenCL benchmarks. It’s interesting:
https://www.tomshardware.com/reviews/geforce-gtx-660-geforce-gtx-650-benchmark,3297-19.html

Also, watch your card, because nVidia’s not big on naming changes. The Quadro 4000 is a Fermi-based GPU card, and should see none of the problems that may or may not exist specific to the new architecture (but possibly if CUDA itself has broken OpenCL performance). The Quadro K4000 is the card with the Kepler-based chip.

If you look at gaming or sometimes OpenGL benchmarks, the nVidia is usually leading the AMD. But on the majority (but not all) of the OpenCL benchmarks, AMD wins.. sometimes by crazy numbers (they include the Quadro 5000 and 6000, but not the 4000) One benchmark even has my HD6970 come out on top, even compared to the new AMD 79xx series. Go figure… that was $300 new, and today… cheap. And look at the “image surfacing” benchmark — the only explanation is that nVidia’s OpenCL there is horribly broken, an HD7970 should not run 29x faster than a Quadro 6000 only ANYTHING.. the Quadro 6000 is just too expensive to allow that to happen.

With that said, they have some video-oriented OpenCL benchmarks which greatly favor the Kepler chips. That may well be a place Sony needs to work on. Though OpenCL seems to change slower than CUDA. Open CL 1.1 was released in mid 2010, 1.2 was released in late 2011, and 2.0 came out last summer. No indication of the level these benchmarks are using, but given the review date, definitely prior to the 2.0 version.

As for your specific observation, John.. the only time I’ve seen such a slowdown on my system was when I had a single-threaded plug-in in a critical path. That’s really easy to see on a CPU monitor… only one CPU working. And of course, if it goes away when you switch off GPU rendering, you pretty much prove that it’s a big in the GPU drivers of some kind.

It sure seems, looking at various benchmarks, that nVidia isn’t giving priority to OpenCL, which may not be a shock given their devotion to CUDA. But worse still, they seem to be behind on OpenCL in the professional drivers. That’s not what I would expect, since there really aren’t many plain old consumer applications using OpenCL. They ought to be giving OpenCL — and CUDA — the similar attention as they give OpenGL in those drivers, and let that filter down to the consumer cards. Doesn’t seem to be the case here.

-Dave