Vegas and 8-core or higher cpus

[Jeff Harper]

Am I reading correctly? CinemaCraft encoder SD version is $1750, and the HD version is $75,000?

[Jim Bucciferro]

I bought the basic version for $59

[Marcus Marchesseault]

"The whole idea behind using multiple cores is to enhance multithreaded applications. Instead of one CPU core doing all the work the work is divided among the four physical cores and thus allows these cores to do other tasks.
It seems that the MainConcept encoder is not releasing to the CPU enough to allow other processes to run - that is poor programming design."

Multicores are also meant to accelerate individual tasks. It is not bad programming that will allow an application to peg all the cores. If you want other tasks to run smoothly while rendering, simply change the priority of Vegas in the task manager to lower than that of other applications and it will peg the cores when available and release cycles when you want to do other things.

Regardless, if Cinema Craft Encoder is really that much faster it is worth investigating. It's too bad they have an insane pricing structure that prohibits HD, but faster SD rendering is still most important.

Jim, has Cinema Craft been easy to install and use? I assume you are happy with the encode quality from HDV to SD? It does not specify .M2T as an input format.

I just found this on the Cinema Craft page: "Note: 64-bit processors, multi-core and SSE3 are not currently supported." That would explain the cores not all being pegged. Have they updated the CC encoder to HDV input and multi-cores?

[David Hadden]

Originally Posted by Mel Enriquez

I know that Vegas supports up to 4 cores. Does v8 now support more than 4 cores? With the coming 8 or more cores in the future, I hope we can use them to speed up rendering and other tasks.

What's the status on this, and if it's not yet implemented, when do you think will it be?

Vegas will run faster on an 8 Core than it will on a 4 core but it won't make 8 video renderer's. Instead, it uses localized threading. so it's not going to double but it will be faster.

Originally Posted by Jeff Harper

My performance shows at between 73% and 90%, never 100% when rendering.

Q6600 is most definitely twice as fast as my duo core. Weird thing is when it is rendering section with MB effects, the processor usage drops down to 50%, don't understand that but that is the way it is for me.

I'm guessing that it's a simple matter of data access. The information has to push to the graphics card and then back to the CPU and so there is some loss there that is probably quite un-avoidable. Since MB is GPU powered it's got to push all the info from the footage over to the GPU and then back before it can be made into a video file.

Originally Posted by Jim Bucciferro

The fact that the Vegas MPEG encoder (MainConcept) is pegging the CPUs when running is not a good thing. The whole idea behind using multiple cores is to enhance multithreaded applications. Instead of one CPU core doing all the work the work is divided among the four physical cores and thus allows these cores to do other tasks.
It seems that the MainConcept encoder is not releasing to the CPU enough to allow other processes to run - that is poor programming design.

On the other hand, the CinemaCraft encoder (while faster than the MainConcept encoder) does not peg the CPU cores - each is at 50% or lower.

The first time I tried the MC encoder to encode 1.5 hours of video it said it would take 3 hours - the CC encoder took 20 minutes at 2-pass.

Just my 2 cents.

Thanks
Jim

I think that you're right and wrong Jim, (however I could be mistaken and would appreciate being corrected if I am) it seems to me that the optimum encoder should utilize all of the CPU power on all 4 cores, if necessary. (which when I'm using Vegas FX and encoding to MPEG-2 I see on my quad core ). So it's not just pushing to one or 2 cores, it's pushing all 4 to within 5-10% of full load if not pegging them completely. Now what is not clear here is are you using the same exact situation with both encoders? If I don't do anything to the files and I just compress videos to MPEG-2 then the only real bottleneck is the speed the files can transfer from one HDD to another HDD, as the encoding is done faster than real-time for me.

[Jeff Harper]

David, you might be right about quad core not doubling speed except what use to render in almost exact real time, like 60min video rendering on my dual core in 60mins, now takes thirty minutes, which is half. (without effects of course). So theoretcally it maybe it isn't supposed to, but it certainly does for me.

[David Hadden]

Originally Posted by Jeff Harper

David, you might be right about quad core not doubling speed except what use to render in almost exact real time, like 60min video rendering on my dual core in 60mins, now takes thirty minutes, which is half. (without effects of course). So theoretcally it maybe it isn't supposed to, but it certainly does for me.

No Quad Core should (more or less) half your time, *8* Cores won't. Sorry for the confusion.

Dave

[Jim Bucciferro]

It is my experience that threads do add a layer of complexity to an application. A multithreaded app allows individual pieces of the code to do different tasks while the main app does something else or waits for the threads to finish. However, if a thread, while looping through a process, much like an encoder does, does not atleast release some time back to the main thread, it will peg the CPU. I've done it before and wondered why my app was hanging. Once I put it in the code to release time back to the OS, the app ran as designed.

Threads were originally meant to divvy up tasks of the main process and thus make an application run more optimized, if you will.

If an app is pegging the CPU then it is not releasing back to the CPU - period!

I assume it does this to get the maximum amount of time from the CPU and it also assumes that nothing else will get done.
Multicore CPUs will divvy up a process automatically just by adding threading to an application, or even if the app is not threaded. In Windows, there is always one thread running.

As for MainConcept, I assume it is pegging the CPU intentionally since it takes so long to encode.
With CinemaCraft, I also assume that is using threading since it does not peg the cpu - it will however have high utilization. It is not an HDV encoder.

One more note - I have not worked with the multicore CPU capabilities so I do not know how take advantage of progamming the CPU directly to use a specific core - if that's even possible. Apparently Vegas has found a way to do that.

More 2 cents
Jim

[Jad Meouchy]

Originally Posted by Jim Bucciferro

It seems that the MainConcept encoder is not releasing to the CPU enough to allow other processes to run - that is poor programming design.

On the other hand, the CinemaCraft encoder (while faster than the MainConcept encoder) does not peg the CPU cores - each is at 50% or lower.

This is not entirely accurate. For encoding tasks, the bottleneck should be CPU, so if your CPU usage is not 100%, your bottleneck is disk or memory. Now the flipside is that if the encoder is well-written, the bottleneck very well could be disk access. However, for most modern encoding to transportable formats, with normal desktop machines (2-4core) that don't have FC SANs, your bottleneck will be CPU.