Multimedia
Blogs
Forum
Affordable HD
Whitepapers
Newsletters
Events
Advertisers
Blogcast
MillimeterCS4 and 64-bit Systems, Part 2
Dec 22, 2008 12:00 PM, By Jan Ozer
Table 3. AVCHD files.
Click here for a larger image
AVCHD
I didn’t reuse the AVCHD tests that prompted this analysis, since the test took too long to complete, but to recount the results, I rendered a 4-minute project to Blu-ray compatible MPEG-2, which took 68 minutes on the 32-bit workstation and about 9 minutes on the 64-bit workstation. The shorter tests that I ran for this article showed a clear benefit for the 64-bit system, though not to that extent.
Specifically, rendering a two-track project with a picture-in-picture, the 64-bit system was 31 percent faster. Throw in a native greenscreen, and the 64-bit system proved 50 percent faster. Surprisingly, however, substituting After Effects via Dynamic Link for Premiere Pro’s native greenscreen actually narrowed the gap back to 25 percent.
Why didn’t these results reproduce the greater than 600 percent margin recorded in my initial tests? Hard to say, but the results from the Red One camera, discussed below, may shed some light on the issue.
Table 4. DVCPro HD files.
Click here for a larger image
DVCPRO HD
In contrast to the other 1080i HD streams such as HDV and AVCHD that use long-GOP compression, DVCPRO HD is essentially four DV streams, one for each quadrant. DVCPRO HD also has the fewest pixels to work with, with a native resolution of 1280x1080, compared to 1440x1080 for HDV and 1920x1080 for the AVCHD file. This makes it the easiest HD format to edit, and the format the showed the least benefit from working with a 64-bit system.
What is surprising was that editing DV showed more benefit from a 64-bit system than DVCPRO HD, which makes little sense, other then perhaps because the DV project was more complex. As Dick Cheney might say, however, it is what it is, and from where I sit, the only format that appears not to significantly benefit from a 64-bit system is DVCPRO HD.
Table 5. Red RD3 files.
Click here for a larger image
Red
Running short on time, I ran only two tests with Red’s R3D format, a 4K picture-in-picture-based project with native greenscreen of yet another R3D file, and a picture-in-picture-based project with an After Effects green screen via Dynamic Link. On the second project, I reached a memory-related tipping point that explained why my first AVCHD test took so long to complete.
As you can see in Figure 2, while rendering this project, the total Commit Charge exceeded the 3GB of system RAM, which meant that Adobe Media Encoder had to store data on the system’s hard disk while rendering. This is also called “paging” to disk, and it substantially decreases performance because writing to and reading from disk is much less efficient than working with RAM.
Figure 2. Commit Charge. To see this view of Windows Task Manager, click ctrl+alt+del and click the Performance tab.
Click here for a larger image
While rendering this project, the 32-bit system made very little progress until I shut Premiere Pro down, which reduced the total commit charge to less than 3GB. From there on, rendering was faster, but overall, the 64-bit system was well more than 200 percent faster. Had I not shut Premiere Pro, the results probably would have equaled or exceeded the 600 percent difference seen in my initial AVCHD tests.
If you’re running CS4 on a 32-bit system and you’re experiencing unstable or very slow operation, check your commit charge. If you’re consuming all of your system RAM and paging to disk, that’s probably the cause of both problems.
Continue the discussion on Crosstalk the Millimeter Forum.