Camtasia for 64 bit computer

[Mikie]

When do you think TechSmith will have a 64 bit version?

[coffee...@gmail.com]

I am sure they are working to make their new update Vista compatible
but not sure about the 64 bit version.

John

[Daniel Park]

4.0.1 will officially support Vista. They're holding off on versions
for 64-bit machines as well as multi-core processors, which is a shame
because I would love to see CS make use of both my cores when
producing a long FLV.

cheers, Daniel

[Brooks Andrus]

Direct Show and the on2 encoding library which are used under the covers
by CS to encode video are both highly threaded and will make use of
multiple cores (so rest assured that your multiple cores are being used
when you're crunching video). The MFC library (GUI) is also threaded,
so its really unclear what / where additional threading would provide
tangible value to users.

TechSmith as a whole is approaching 64 bit compatibility in a very
measured manner. It's likely to be a while before you see a 64 bit
version of the product. There aren't a whole lot of advantages to CS
becoming a native 64 bit application since the current and foreseeable
processor architecture will run 64 and 32 bit applications seamlessly.

Regards,

Brooks Andrus
Senior Flash Developer
TechSmith Corporation
b.an...@techsmith.com

[Daniel Park]

Interesting, Brooks. Can you think of a reason why I might not
experience this in practice? When I produce an FLV using VP6 (from
on2), and I go into my task manager, I see one core being utilized at
100% and virtually nothing on the other one. In the Processor Affinity
dialog, I made sure that both CPUs are checked for Camtasia Studio.
What gives? Is there a separate process that kicks in when VP6 is
doing its thang?

cheers, d.

[Brooks Andrus]

Maybe I was premature in my comments--wouldn't be the first time. :). My
little bit of a Java background may have jumped up and bit me--the JVM
handles concurrency behind the scenes handing off threads to different
cores if they are available.

Most operating systems by default will prefer to confine all threads
spawned by a single process to the same core.

So after checking with one of the C++ devs they confirmed the behavior
you're seeing. Despite the fact that the underlying engine is spinning
up multiple threads the rendering pipeline used by the codec's is single
stage. Meaning that multiple cores are not likely to help you
appreciably when encoding a single video. Multiple cores may be invoked
by file reader threads, depending on how the OS works, when they are
spun up, but this is unlikely to produce much of a noticeable benefit as
far as CPU usage on a second core.

One area where CS would benefit from writing multi-core code would be
when you produce multiple video or audio formats in a single production.
CS is currently not optimized for this type of scenario. However, its
unclear how much of a benefit having a second core is to encoding a
single video other than the fact that you have another core available to
work on other stuff.

Ok, I've danced around be wrong for long enough. :)

Brooks