Einen Testbericht über die Adobe CS5 Production Premium Suite zu verfassen ist kein kleines Unterfangen. Selbst nur die neuen Features aufzuzählen füllt unzählige Seiten, zudem findet man entsprechende Informationen auch überall im Netz. Auch bis ein entsprechender "Testbericht" fertig wäre, dürften Wochen vergehen, was uns wiederum zahllose ungeduldige Mailanfragen beschert. Daher werden wir diesmal einen anderen Weg beschreiten. In einzlenen Artikeln werden wir in den nächsten Monaten unsere Erfahrungen mit der Adobe CS5 Suite veröffentlichen. Ihr bekommt unsere Erkenntnisse bei der täglichen Arbeit mit der Suite dadurch extrem zeitnah zu lesen. Womit wir hiermit offiziell die "CS5 Files" öffnen. Und zwar mit einem Thema, das wohl die meisten Leser am brennendsten interessieren dürfte: Die integrierte Mercury Engine...
Bereits mit Ankündigung der Beta-Version war uns klar, dass wir für die CS5 wohl ein neues Testsystem aufsetzen müssen. Schließlich will sollte die neue Mercury Engine ein adequates Umfeld vorfinden, um sich austoben zu können. Die Mercury Engine ist eine neues Wiedergabe-Subsystem, das auch die Grafikkarte zur Beschleunigung nutzen kann. Hierbei setzt Adobe bis auf weiteres auf CUDA, wodurch nur Nvidia-Grafikkarten zur Beschleunigung eingesetzt werden können. Offiziell werden dabei nur spezielle Quadro-Karten (FX3800, FX4800 und FX5800) sowie eine Consumer-Karte (GTX 285) unterstützt.
Ein sehr einfacher Hack ermöglicht jedoch auch den Einsatz anderer Nvidia-Karten. Bei Veröffentlichung der CS5 wurden die Consumer-Karten dazu auch noch künstlich beschnitten, jedoch ließ Adobe diese Beschränkung mit Version 5.01 bereits fallen.
Das Testsystem
In unserem Testsystem landete eine FX4800, die Adobe selber auch in zahlreichen Präsentationen verwendet. Als Betriebssystem setzten wir ein frisches Windows 7 auf, das zusammen mit der CS5 auf einer ansonsten leeren Boot-SSD (Intel X25-M G2 Postville 80GB) landete. Schließlich sollte es auch hier vom feinsten sein. Als Prozessor kam ein Intel Core 2 Extreme QX6700 zum Einsatz, der mit 4x 2,67 GHz und 2 x 4 MB Cache eigentlich genügend Multiprozessor-Leistung versprechen sollte. Unterstützt wurde er von 8 GB DDR2-RAM mit 800 MHz. Laut System-Specs (die „nur“ einen Intel Core 2 Duo oder einen AMD Phenom II Prozessor und 4 GB Ram empfehlen) fühlten wir uns hiermit gut gewappnet für die ersten Gehversuche mit der neuen Mercury Engine.
Was geht?
In öffentlichen Demos zeigte Adobe die Engine immer mit DVCPROHD-Material, womit die Engine tatsächlich seht potent ist. Allerdings ist DVCPROHD auch ein Intra-Frame-Codec, der beim Dekodieren deutlich weniger Rechenleistung erfordert, da hier kein GOP-Decoding nötig ist. Das Scrubben mit diesem Format funktioniert extrem soft und es können tatsächlich auch auf unserem System bis zu sechs Spuren ruckelfrei wiedergegeben werden. Dabei ist der Prozessor noch nicht einmal ausgelastet, sondern bei diesem Test schien eher die Zuspieler-Festplatte der limitierende Faktor zu sein.
Uns interessierte jedoch vor allem die Königsklasse des Decodings sprich AVCHD- und DSLR-MPEG4-Dialekte, da diese viel häufiger zum Einsatz kommen und weitaus komplexer im Decoding sind. Und hier zeigte sich bei uns schon ein ganz anderes Bild:
MP4 to the limit
Auf unserem Testsystem konnten wir tatsächlich bis zu 4 AVCHD-Clips als Picture-In-Picture-Timeline abspielen, jedoch nur, solange der interne Cache nicht leerlief. Schon nach ca 2 Sekunden kam es dann zu einem Einbruch der Framerate. Interessant war dabei, dass die niedrige Framerate auch beibehalten wurde, nachdem die anderen drei Clips in der Timeline ausgelaufen waren und sich das Chaos in der Vorschau lichtete. Erst nach einem Wiedergabe-Stop und erneutem Start in der Timeline konnte man ab dieser Stelle wieder flüssig weitergucken.
Scrubbing und Shuttling
Auch das Scrubben und das JKL-Editing lief bei uns mit einem einzigen AVCHD-Clip schon nicht butterweich. Dazu fiel uns ein unangenehmer Bug auf: Shuttelt man mit der J-Taste in den Rückwärtsgang gab die Engine das Video nur bis zum Anfang des gecacheten Bereichs (max 2 Sekunden) wieder und zeigte ab dann ein Standbild. Es ist nahe liegend anzunehmen, dass hier die GOP-Grenzen das Limit setzen.
Dazu gibt es immer eine kurze Bedenksekunde in der Timeline, bevor der Player los läuft. Wahrscheinlich wird eben hier der Cache gefüllt. Das einfache, sequenzielle Abspielen der Clips gelingt anschließend dagegen tatsächlich ruckelfrei (auch mit CUDA-Effekten, s.u), jedoch NUR, wenn man bei der Wiedergabe keinen zweiten Monitor als Vollbild-Vorschau an der Nvidia-Grafikkarte nutzt. Schaltet man diesen in den Wiedergabe-Einstellungen dazu, so ruckelt es auch schon bei einem nackten AVCHD-Strom ohne Effekte.
Titel und die GPU
Wenn man nur einen bewegten Titel über eine Sequenz von AVCHD-Clips legt, verliert die Engine gelegentlich aber reproduzierbar den Anschluss und liefert nur noch ein Standbild. Dies passiert aber nur bei der Wiedergabe mit GPU-Unterstützung. Ohne GPU-Unterstützung läuft die AVCHD-Timeline durch, allerdings ebenfalls etwas ruckelig.
GPU und CPU Kompatibilität
Dabei sollte eine Besonderheit auch nicht unerwähnt bleiben: Wenn man zwischen CUDA/GPU und Software-Renderer hin und her schaltet, erwähnt Premiere, dass die gerenderten Vorschaudateien unterschiedlich aussehen könnten und gelöscht werden sollten:
Der Farbraum der beiden Engines scheint also nicht hunderprozentig gleich zu sein. Auch könnte diese Information dafür sprechen, dass die optimierten Effekte vielleicht noch nicht identisch berechnet werden. Eine ähnliche Problematik gab es übrigens in Sony Vegas Pro 8, als der 32Bit Float Farbraum nicht zum “normalen” 8 Bit Farbraum passte. Dort ist dieses Problem jedoch mit Vegas 9 durch eine spezielle Farbraum-Konvertierung gelöst worden.
CPU = Decoding, GPU = Effekte?
Nach unserem aktuellen Erkenntnisstand scheint selbst bei aktivierter CUDA-Unterstützung weiterhin die CPU alleine fürs Decoding zuständig zu sein. Denn mit Erhöhung der abgespielten Streams steigt die Prozessor-Auslastung linear an. Sobald Ruckler auftreten, liegt die Systemauslastung immer knapp unter 100 Prozent. Dabei werden alle vorhandenen CPU-Kerne tatsächlich genutzt. Wahrscheinlich könnte man daher mit einem Intel Core7-Prozessor dank Hyperthreding und SSE4.2 eine noch bessere Multi-Track-Performace erwarten, die hier die doppelte Anzahl an (teilweise virtuellen) Kernen zur Verfügung steht.
Sobald man jedoch Effekte einsetzt, kann endlich auch die verbaute FX4800 glänzen. Denn die Wiedergabe-Performance wird selbst durch komplexe Effekt-Verkettungen auf einem Clip fast nicht berührt. Ist ein Frame einmal auf der Grafikkarte decodiert gelandet, so kann hier auch eine komplexe Farbkorrektur mit 3D-Verzerrungen und Keying in Echtzeit angewandt werden. Hier lässt sich dann stacken, was das Zeug hält. Unser QX6700 Quad-Core konnte immerhin 2 AVCHD-Spuren ziemlich ruckelfrei wiedergeben, dies aber dank der FX4800 dann mit fast beliebigen Effektkombinationen. Sobald man jedoch einen nicht CUDA-unterstützen Effekt in der Kette anwendet, bricht die Performance schlagartig zusammen.
GPU-Effekt-Unterstützung
Die Auswahl der GPU- Effekte ist objektiv betrachtet eher gering, trifft aber voll unseren Geschmack, was die Auswahl angeht. Denn eigentlich sehen wir im Schnittprogramm nur Farbkorrektur-Möglichkeiten als enorm wichtig an, für komplexe Effekte oder ähnliches ist man in After Effects ja meistens deutlich besser aufgehoben.
Und gerade in der Farbkorrektur ist neben Gradations-Kurven auch eine komplexe 3Wheel-Gamma-Lift-Gain-Korrektur mit sekundärer Beschränkung vorhanden. Damit ist tatsächlich auch Realtime-Color-Grading direkt im Programm möglich.
In einem Test ließen wir das Bild von einem Filter komplett übersteuern (clippen) und in einem zweiten Filter holten wir die Belichtung wieder herunter. Dabei blieben alle Bilddeutails und Farben erhalten, was eindeutig darauf hindeutet, dass hier mit Float-Werten gerechnet wird. Dies ist gerade beim Grading enorm wichtig. Damit ist Premiere Pro das erste und einzige Schnittprogramm das eine echte 3 Wheel-Korrekur mit Floating-Point Genauigkeit in Echtzeit ermöglicht. Uns störte jedoch ein wenig, dass sich Effektparameter nicht bei laufendem Video einstellen lassen. Jede Veränderung stoppt die Wiedergabe zwangsweise. Edius und Vegas erlauben dagegen die Parameter-Veränderung bei laufender Timeline.
Die Konkurrenz
Gegenüber Sony Vegas ist der AVCHD- und DSLR-MPEG4 Performance-Unterschied tatsächlich spürbar. Vergleicht man Premiere jedoch mit dem Optimierungs-Zauberer Edius ergibt sich ein differenziertes Bild. Beim Scrubben von effektlosen Clips verhält sich Eidus beim Schnitt auf unserem Testsystem mit AVCHD und Canon DSLR-MPEG4-Files durch die Bank responsiver als Premiere Pro. Auch das sehr komplexe Rückwärtsschutteln mit der J-Taste gelang, wenn auch nicht komplett ruckelfrei. Sogar mit einer komplexen Farbkorrektur kam das System noch nicht ins Stottern, wohl aber wenn man weitere Effekte hinzu nahm. Mit stiegender Effektanzahl sank die Performance aber gegenüber Premiere Pro anschließend deutlich. Hier leistet dann die Nvidia GPU die Hauptarbeit und das mit äußerst ansprechender Performance, die sich kaum ans Limit bringen lässt.
Fazit
Auch wenn die Mercury Engine in der Praxis noch ein paar Kanten hat, scheint sie dennoch ein großer Wurf. Solange man sich auf die einstzbaren CUDA-Effekte beschränkt, merzt das Programm einen unserer größten Kritikpunkte (eben die mäßige Performance) aus. Dazu darf man nicht vergessen, dass die CUDA-Engine vollkommen im Float-Farbraum ohne Kompromisse arbeitet. Dies kann der bisherige Klassenprimus Edius nicht bieten, dominiert dafür beim reinen MP4-Schnitt ohne dezidierte GPU nach wie vor. Eine potente CUDA-Karte ist also nur die halbe Miete, wie unsere Erfahrungen zeigen. Einiges deutet darauf hin, das der von uns eingesetzte Intel Core 2 Extreme QX6700 das aktuelle Nadelöhr in unserem Testsystem darstellt. Die Speicherauslastung ging jedenfalls bei unseren Test niemals annähernd an die 8 GB-Grenze heran. Und die Festplattenleistung war bei komprimierten MPEG4-Strömen ebenfalls nicht am Anschlag.
