The Elusive Search for Affordable HD Crunch Power

There are solutions but they are not perfect.

Ok to start off, Adobe’s latest offering of Premiere in both CS3 and CS4 to say in very restrained terms is very frustrating ##%&&*#@%&.  A simple render from the timeline just grinds and labours along like heavily congealed axle grease.  Unlike earlier versions in Premiere Pro 1.0, 1.5 and 2.0, — grease lighting in comparison.  Unfortunately, these earlier versions do not support the full 8bit and 10bit YUV 4:2:2 operation we need for our HD film transfer services.

We have used Adobe products for our video production work for some time and have gotten used to the workflow (albeit a bit of a learning curve) and tool sets.  However, migration to CS3 and then CS4 has been very disappointing.  We have looked at the competition for alternate solutions and found these to be even more wanting, though a great deal faster, they lack the features and modes we need.  This is another story.  So what to do????

After a great deal of research and testing there is some light at the end of the tunnel, though a dim one.  Sure there are top end solutions but with top end price tags.  The goal here is to keep costs and workflow efficiency as painfree as possible.

What is a good tradeoff between cost and performance?  The age old engineering maxim.

What is going to be proposed is a Windows solution sorry to say.  The MAC guys seem to have their act together on this front.

Tests have shown the bottle neck to be pure processing power.  Plain and simple.  Not hard disk data transfer, RAM or cache issues.  Core duo, Core 2 duo, Quad core or the latest Xeon.  Hmmmm.  Oh, note to Adobe — rework this application. It’s a compute cycle hog.

Things to consider then is — 64 bit O/S (CS4 only..arghhh), high multi-core processing speed and a fast FSB.  More RAM is not an issue, but a RAID 0 disk configuration may be a consideration (for input and export transfers).  Jury is still out.  Once processing speed has been improved a hard disk bottleneck may appear, but for now that is not the case.  The processors are not starved for data.

How about a distributed processing solution, in the sense of a second computer of similar characteristic and configuration running in parallel.  Rendering times can still be tolerably high, but is offset by using a second machine crunching new sessions in parallel. In our case when film reels have been digitized in say 400ft reel segments, each reel can be processed for color correction and standard edits, then submitted for render in one machine while the next reel is processed on the second machine, running overnight if necessary. We need this step to create the HD YUV Film Masters some customers have requested.

Bottom line, use a Quad core CPU at a speed of no more than 2.66GHz. Stay away from dual cores. There is a definite relationship between crunch times to the number of cores, but to a point. Though Adobe does take advantage of multiple cores, core counts greater than 4 appears to yield small returns. Higher speed quad cores is also an exercise in futility.  The law of diminishing returns exists here.  Higher speed cores have less than expected returns in crunch times, yet cost you many times more.  The speed – performance curve is not linear.  Also have FSB speeds of at least 1333 (RAM, MBoard) and run Windows 7 in 64 bit mode. You would have to use CS4 in order to get full performance (even though CS4 is worse than CS3 it is more than compensated for when in 64 bit mode).  What a waste.

What about i7’s you say?  Preliminary examination looks questionable yet promising.  No real hard test data just yet.

To complicate matters we want to have a physical render out facility when in edit mode for monitoring the results of work done. Besides the slow operations between edits on the timeline, having an external HD monitor, vectorscope and waveform monitor is a must.  Those same test measurement tools available within Premiere are clunky and can’t be made simultaneously available while in edit.  Besides it really slows things down even more.

One solution is to open an HDV session, since it supports Firewire out.  Keep in mind not to render out using this setting as it makes for bad results.  Export in full YUV 4:2:2 in 8bit or 10bit.  Another solution is to use the Black Magic Intensity Pro card.  It has HDMI and a built in HD to SD down conversion facility.  THe HDMI will only work when in an HD session and the analog SD stuff works only when in an SD session.  Works surprisingly well. However don’t count on this card as a hardware assist rendering card. I had my hopes on this card, but nada.

Use an HDMI capable monitor that has 1080 capability if you want to see the finer details of your edit work.  Downconverting to 720p using a 720p monitor, from an 1080 timeline can have crappy visual results just due to possible poor down sampling methods employed within the monitor hardware.  Alternatively, using an external HDMI to S-video down converting box will allow your HD video to be viewed on standard vectorscopes, waveform monitors and CRT or LCD video monitors.  Granted, it is not an SDI solution, but hey the videos are for Blu ray consumption not for broadcast. Color correcting casts and adjusting to legal IRE video levels yield very good results. From a spec point of view I’m looking into whether the 709 to 601 changes have an impact. Right now on just visual inspection, it looks just fine.  It is difficult to tell without proper HD test instrumentation.

Update: Jan 5th, 2010

Got my hands on a i7 920 based cpu running on a 64bit Windows 7 platform,  I loaded Adobe CS4 Premiere Pro this time as CS3 will not run on a 64bit O/S.

With the same video test footage I had when doing my previous tests, I added color correction and RGB curve filters as before, then ran a typical render to yield a YUV 4:2:2, 210, 8bit, 1920×1080 video.  The results were better than I expected.  The render time was less than half of my Quad computer at the same clock rate.

I examined the CPU load using the Task Manager and the new Source Monitor that comes with Premiere.  (oh, I also noticed that Premiere has finally brought back its batch tool, now called Render Queue, just like After Effects). The Source Monitor will look at hard disk traffic loads and memory usage in real time while any timeline activity is present.  This will allow you to assess whether the 8 CPU’s are operating as efficiently as possible.  I tried disabling a number of CPU cores (in Task Manager) to see if I could emulate my other Quad Core, but to no avail.  All 8 cores always kicked in.

The other interesteing note is that the time to observe any changes in an editing or filter change activity was the same as my quad core, at about 4 seconds per observable change, as I was hoping this would also be an improvement as this impacts workflow time.  Another key observation is that when making filter changes in the timeline, the hard disk load would dramatically ramp up to between 85MB/s to over 100MB/s, in contrast to small disk offloads of between 4MB/s to 35Mb/s when just playing the timeline with loaded filters in real time.

So, I can’t put my finger on what elements of the changes made contributed to the better render times, ie: running 64bit vs 32bit O/s, an i7 cpu vs Quad core or the Windows 7 O/S vs Xp Pro 32bit, but it sure made a difference. For a few dollars more being spent here may be a reasonable solution. I would put money on the 64 bit O/S as the main source of better render times, but only further testing would determine the answer to this question.