Transcoding t3i footage in Premiere Pro CS5?

[Noa Put]

Thx Harm for the explanation

trans-coding to an intermediate format will not be beneficial at all, it will only slow you down

Cineform doesn't seem to be that optimised for use in Premiere, the intermediate codec in Edius f.i. gives a major speed improvement, both in Editing and exporting. But like cineform intermediate files size can be a lot bigger, average of 3x which lets you run into disc space problems quickly.

[Harm Millaard]

Noa,

I'm not sure about this, but the 32 bit nature of Edius may be beneficial for Cineform trans-coding, PR OTOH is 64 bit and that may lower the benefit of trans-coding, because the CPU heavy decoding of difficult codecs like AVCHD are handled more efficiently. On modern fast CPU's like the i7-2600+ or i7-3930+ the time to trans-code and the disk space consequences make it unlikely to be a real benefit to use Cineform any longer. However on lesser systems or on many laptops, it may still be beneficial to trans-code, with the caveat that on many notebooks you can easily run into disk and memory problems.

[Noa Put]

PR OTOH is 64 bit and that may lower the benefit of trans-coding, because the CPU heavy decoding of difficult codecs like AVCHD are handled more efficiently.

28mb avchd and 45mbs dslr mov files run smoother in edius 6 then a trial of premiere cs6 on my pc, That is when scrolling the timeline, there I don't see any benefit of working with a 64 bit system.

[Harm Millaard]

Scrolling a timeline is very much disk I/O dependent.

[Noa Put]

Where do you see then the advantage of decoding avchd footage with 64bits NLE's? Does that show during playback?

About fast scrolling the time line, with 80 to 100 mbs edius HQ avi footage that is butter smooth on my system and 28 mbs I get footage that jumps which is a bit worse in Premiere, I would expect theh 80 to 100 mbs sec footage to need fast disks but not 28mbs avchd, only big difference is that avchd has a much tougher compression for the cpu to handle to give a realtime smooth preview, is the cpu then not the limiting factor when fast scrolling the timeline?

[Sareesh Sudhakaran]

Originally Posted by Noa Put

28mb avchd and 45mbs dslr mov files run smoother in edius 6 then a trial of premiere cs6 on my pc, That is when scrolling the timeline, there I don't see any benefit of working with a 64 bit system.

The CPU and RAM is used no matter what you do - even if you move the mouse an inch.

It is very likely video scrubs in CS6 are stored in HDD buffers (how else will uncompressed footage play back?) - but they have to be processed the first time for playback. This - as claimed by Adobe in answer to a specific question - is more GPU dependent in CS6. Earlier versions, and other software, utilize the CPU for it. According to them, 64-bit is only tangibly useful if the mercury engine is enabled, and this directly affects AE, not Premiere Pro.

If the GPU is not found, the mercury playback engine is not used in its hardware mode. However, CS6 supports OpenCL (but not completely) and thereby a few ATI cards. Could this be the reason you are not seeing a playback improvement in your trial version? Was the software mode turned on?

Unfortunately it has become too complicated to compare software without supporting hardware. It's tough as it is to build a system that utilizes all of the CS6's programs efficiently within the production premium suite. Adding third-party software to a workflow makes it almost impossible.

[Bart Walczak]

Premiere generates thumbnails for video tracks on the fly. For each clip it has to read it and generate the thumbnail. It only reads those clips which are in the current view, so scrolling the timeline will result in slower response when it needs to generate many thumbnails on a big zoom out, and big change, especially when you are dealing with AVCHD codec. The program is pretty good at not getting in your way (ie. the thumbnail generation has lower priority than playback, etc.), but the performance hit can be seen, especially on older machines.

Of course, you can skip it by minimizing the track or choosing not to display the thumbnails in the track option. And if you use uncompressed, or any codec that is not CPU-intensive, the UI and scrolling is pretty snappy. Thus comparing Edius' codec to AVCHD on the basis of bandwidth is totally irrelevant.

[Noa Put]

And if you use uncompressed, or any codec that is not CPU-intensive, the UI and scrolling is pretty snappy. Thus comparing Edius' codec to AVCHD on the basis of bandwidth is totally irrelevant.

Harm said scrolling the time line was disk I/O dependent, that's why I refered to canopus own codec as I would expect a high bitrate format to benefit from a raid set up and a heavily compressed format to benefit from a fast cpu. I at least had a gtx460 card that was enabled for mercury playback by using that "hack" so I was not in software mode and on my system at least I saw no benefit in that compared to a 32bit NLE, neither in playback or faster scrolling the timeline.

Also about generating thumbnails etc, I had to wait about 10 minutes before all that background stuff was done and I could do any serious editing, so when I was testing there was, as far as I could tell, no background tasks running.

On a bit older systems premiere runs ok but you shouldn't expect any miracles during editing, you only will benefit most from faster exporting.

[Harm Millaard]

Also about generating thumbnails etc, I had to wait about 10 minutes before all that background stuff was done and I could do any serious editing, so when I was testing there was, as far as I could tell, no background tasks running.

A good way to see how many background processes are actually running and consuming CPU cycles and using memory, is to start Task Manager and click on Show Processes for All Users, or use Process Explorer. I prefer Process Explorer, because of the additional functionality, but that is just me.

Normally on a properly tuned system you will have around 40 - 50 processes active, more means that you will have to kill superfluous processes. Often there are unneeded processes like mDNSResponder, all kinds of Apple stuff if you have QuiRcktime installed, Java updater, and the like.

When scrubbing, consider what happens. The clip or clips have to be read from disk. If it is a single clip, that is pretty fast, but if it is about many clips for all your tracks, possibly located at different locations on your hard disk, short clips that change rapidly, all those clips need to be read from disk and that is where the bottleneck often is, due to the half duplex nature of SATA drives. Once read, the CPU decodes the long GOP format to an internally used intermediate intra-frame format so all frames can be rapidly displayed. This decoding ought to be more efficient on 64-bit systems than on 32-bit systems, but of course the algorithm used is the overriding factor. Most modern day CPU's are quite capable of handling that task while the disk fetches the clips which can be time-consuming because of relatively long access times when the disk is fragmented or the clips are physically located on different locations on the disk. This problem gets worse when the fill rate on a disk goes up. On memory starved systems, this can lead to further deterioration in performance because of the use of the page-file. You have to store the decoded results somewhere, right?

On testing the new PPBM6 timeline, using 6 tracks plus an overlay track and with a mix of DV, HDV, AVCHD, XDCAM-EX, XDCAM-HD, Canon MXF 422 and Red 4K material both in NTSC and PAL, I have seen that sustained transfer rates were in excess of 300 MB/s for playback. Usually scrubbing moves along faster than playback, so the requirements for a high transfer rate increase.

Hope this explains it a bit.

[Bill Pryor]

I don't transcode and don't have any problems. Using the 8 core Mac Pro, basic system.