Adobe Premiere: Encoding ist zu langsam? Wie beschleunigen?

Video-Encoding is schon immer, auch auf leistungsstarken Computern, eine absolut Performance-hungrige Aufgabe. Nicht zuletzt weil im Laufe der Jahre auch die gewünschte Ausgabe-Auflösung zeitgleich mit der gestiegenen Leistung mitgewachsen ist. Soweit ich mich zurückerinnern kann, war der Export eines Videos immer eine langwierige Aktion. Immerhin dann, wenn die Qualität und die Dateigröße passen sollen.

Für das Exportieren eines einstündigen Videos können auf unseren etwas betagten HP Z210 Workstations (Intel i7 2600, 32 GByte DDR3 Ram, SSDs, nVidia GeForce 9800GT / nVidia Quadro 2000) je nach verwendeten Effekten, Schnitten und Spurenanzahl in 1080p schon einmal 8 Stunden bei 30 fps oder in auch gerne 16 Stunden bei 60 fps vergehen.

Encoding vs. Rendering

Bei meiner Recherche habe ich gemerkt, dass die Begriffe „Encoding“ und „Rendering“ oft synonym verwendet werden. Das habe ich auch öfters selbst falsch gemacht, aber es führt zu Verwirrung da man bei den folgenden Ausführungen beide Prozesse getrennt voneinander betrachten muss. Denn beim Rendern handelt es sich eigentlich nur um die Umsetzung der Effekte, wie beispielsweise eine Bildkorrektur oder eine Texteinblendung, in ein fertiges Bild/Video. Das Encoding hingegen bezeichnet die Umwandlung des bereits fertigen Bildes/Videos in ein anderes (evtl. komprimiertes) Videoformat.

Encoding (laut Google):

Formatumwandlung, besonders Verschlüsselung einer Nachricht, eines Signals

Rendering (laut Google):

Vorausberechnung [von zu entwickelnden Produkten] am Computer mithilfe einer dreidimensionalen virtuellen Darstellung

Smart Encoding != Smart Rendering

Der Export findet für das FullHD- oder 4k-Videomaterial meist im h.264-Format statt, welches leider einen kleinen Nachteil hat. Das sogenannte Smart Encoding ist nicht möglich. Hierbei würde das Bildmaterial, welches im Projekt nicht verändert worden ist, ohne Bearbeitung/Umwandeln an den entsprechenden Zeitabschnitten in die Zieldatei ausgegeben werden. Dies geht nur wenn das Quell- und Zielformat absolut identisch sind. Dies ist schon schwierig bei der Vielfalt an Codecs für das h.264 bzw. mp4-Format. Man müsste also genau den verwendeten Codec vom eingesetzten Aufnahmegerät (Smartphone, Kamera) auch für die Ausgabe verwenden. Beim h.264-Format gibt es aber, wenn ich es richtig verstanden habe, ein grundsätzliches Problem weshalb Smart Encoding nicht wirklich möglich ist. Dies liegt wohl an den sogenannten Keyframes, die in diesem Format anders gesetzt/behandelt werden als z. B. bei MPEG2. Wenn man aber z. B. auch nur einen Filter zur Bildverbesserung auf das gesamte Video anwendet, könnte man Smart Encoding sowieso nicht nutzen.

Ob es Smart Encoding in dieser Form bei Premiere gibt oder gab ist mir gar nicht bekannt und ich konnte die Funktion leider nicht mehr finden. Es kann also auch sein dass ich mich irre. Zumindest gab es eine solche Funktion mal in NeroVisionExpress, weshalb diese eventuell oft fälschlicherweise mit dem Smart Rendering gleich gesetzt wird, was aber grundsätzlich falsch ist.

Man könnte eine Art „Smart Encoding“ in Adobe Premiere theoretisch nur nutzen, wenn man das Video vor der Bearbeitung in Premiere in ein „Smart Rendering“-fähiges Format (z. B. das unkomprimierte DNxHD) konvertiert bzw. die komplette Timeline in diesem Format vorrendert und dann nach der Bearbeitung auch wieder in diesem Format exportiert. Zeitlich gewonnen hätte man dabei aber nichts und zu funktionieren scheint dies auch nicht. Bei meinen Tests wurde das Video, obwohl es bereits eine Vorschau in DNxHD gab, wieder vollständig neu in diesem Format exportiert. Hier findet also leider keine Wiederverwendung des Videomaterials statt.

Fazit: Smart Encoding ist in Adobe Premiere und bei einem aktuellen Videoformat oder bei einem durchgehend eingesetzten Filter sowieso keine wirkliche Option. Da das Quellmaterial zumindest von Smartphones heute im mp4-Format kommt, kann man es auch aus diesem Grund wegen der Codec-Vielfalt vergessen.

Smart Rendering – Vorrendern der Vorschau?

Ein Tipp, der oft gegeben wird, ist das Vorrendern bereits fertig bearbeiteter Abschnitte der Timeline. Dies hat bei uns aber aufgrund des angesprochenen „Smart Encoding“-Problems des h.264-Formats ebenfalls nichts gebracht, da auch für diesen Fall das vorgerenderte Material im gleichen Format vorliegen muss wie das schlussendliche Ausgabeformat. Ansonsten muss es ja am Ende trotzdem noch encodiert werden und kann nicht einfach übernommen werden. Hierfür müsste man, wie bereits geschrieben, die Vorschau z. B. im unkomprimierten Format DNxHD rendern, welche dann am Ende in das Zielformat umgewandelt wird. Dies bringt wohl den Vorteil, sollte man beispielsweise einen Fehler im finalen Export feststellen, dass man nicht alle Zeitabschnitte mit Effekten neu rendern muss. Stattdessen muss nur die entsprechende Vorschaudatei bzw. Stelle der Timeline wieder gerendert werden.

Da bei uns der Workflow aber keine großen Pausen für ein Vorrendern bietet, haben wir dies erst einmal nicht weiter verfolgt. Letztendlich ändert dies auch nichts an der eigentlichen Encodingdauer am Schluss, außer dass diese um das Rendering der Effekte gekürzt wäre. Das Rendering würde man stattdessen schon vorher bruchstückhaft, z. B. während einer Pause bei der Videobearbeitung, erledigen.

Fazit: Das Vorrendern der Vorschau macht meiner Meinung nach nur bedingt Sinn. Insbesondere wenn man nicht über einen längeren Zeitraum an einem Projekt arbeitet lohnt es sich kaum. Wenn die Ausgabe des Videos in Premiere allerdings in einem „Smart Rendering“-tauglichen Videoformat wie DNxHD stattfindet oder das Projekt wirklich umfangreich ist macht das ganze natürlich wiederum Sinn.

Encoding-Preset anpassen

Das einzige Mittel, das man noch hat, sind die Einstellungen des Encoders. Hier habe ich bisher stets ein Preset mit VBR 2-Pass (variable Bitrate mit zwei Encoding-Durchgängen) und maximaler Render-Qualität gewählt. Warum? Weil es überall so empfohlen worden ist und bei guter Qualität aufgrund der variablen Bitrate eine vergleichsweise „kleine“ Datei produziert.

Hierzu ist allerdings eine zeitraubende Analyse des Quellmaterials durch den Encoder nötig, da geschaut werden muss welche Szenen/Zeitabschnitte aufgrund schneller Bewegung mehr Bildinformationen benötigen als eine langsame und eher ereignislose Szene. Damit es besonders gut wird, lässt man auch noch einen zweiten Durchgang drüberlaufen um das Ergebnis zu verbessern. Im Gegensatz dazu wird bei einem Encoding in CBR (konstante Bitrate), unabhängig davon ob es nötig ist, immer die gleiche Anzahl Bildinformationen gespeichert. Das Ergebnis ist also qualitativ meist gleichwertig, wird aber wohl wesentlich mehr Speicherplatz belegen. Außer man wandelt ein Video um, das wegen durchgehend schneller Bewegungen in VBR dauerhaft die maximale Anzahl an Bildinformationen veranschlagt.

Da die entsprechenden Videos in unserem Fall am Ende auf Youtube landen werden, ist es auch eigentlich völlig egal ob diese in VBR oder CBR encodet worden sind. Denn Youtube wandelt die Videos sowieso noch einmal selber um. Von daher macht es gar keinen Sinn sich diesbezüglich Gedanken zu machen oder etwas zu beachten. Lediglich eine lahme Internet-Verbindung könnte hier zum Flaschenhals beim Upload der größeren Datei werden.

Test: CBR vs. VBR

Seit kurzem haben wir eine Glasfaserleitung mit 500 MBit/s Uploadgeschwindigkeit und weil Speicherplatz wesentlich günstiger ist (externe HDD mit 8 TB gibt es bereits unter 150 €) als ein teurer Video-Schnittrechner (~ 2000 €), habe ich als Experiment mal einen Vergleich zwischen VBR und CBR in zwei verschiedenen Export-Szenarien angestellt.

Zu allererst habe ich ein möglichst realitätsnahes Projekt erstellt. Hierzu habe ich ein zwei Minuten dauerndes Video zusammengeschnitten und mit Blenden, einer zweiten Spur mit einem Overlay-Video, verschiedenen Texteinblendungen und einem Overlay-Bild versehen.

Als Gegentest habe ich ein zweites Projekt mit einem zwei Minuten langen Video komplett ohne Schnitte, Bearbeitung, Blenden oder eine zusätzliche Spur erstellt.

In beiden Fällen lag die maximale bzw. konstante Bitrate bei 16 MBit/s. Bei der VBR-Variante wurde als minimale Bitrate 7 MBit/s gewählt und der zweite Durchgang aktiviert. Ebenfalls wurde in beiden Testfällen die maximale Render-Qualität aktiviert und es wurden 1080p als Auflösung und 60 fps als Framerate verwendet:

Das Ergebnis schlägt sich wie folgt in der Encoding- und Renderingzeit und der Dateigröße nieder:

Wie der Test gezeigt hat, ist ein Export mit konstanter Bitrate zeitlich gesehen der klare Sieger und es macht doch enorm viel aus, wie stark das Quellmaterial verändert wird (Renderingdauer). Bei der Dateigröße ist die CBR-Variante wie erwartet klar im Nachteil.

Zu beachten ist, dass natürlich bei einem langen Video wo nicht an jeder Stelle ein Schnitt, eine Blende oder ein Effekt auftaucht für diese Zeitabschnitte das Encoding schneller voranschreitet als für den Rest des Videos.

Nachtrag: Leider sind beim Export größerer Videos doch noch starke Abweichungen aufgetreten und es wurden dann für den Export von einer Minute Video trotz CBR-Preset teils 6-7 Minuten benötigt! Was das ganze noch einmal deutlich beschleunigt hat war das Deaktivieren des Punktes „Maximale Render-Qualität verwenden“. Für den Upload auf Youtube sollte man hier sowieso keinen Qualitätsunterschied bemerken.

Test: Hohe Bitrate oder sogar unkomprimiert?

Um noch schneller zu encodieren hatte ich noch die Idee die Bitrate maximal hochzuschrauben, weil ich dachte dass dadurch weniger Kodierungsaufwand besteht. Dies hat sich als falsch herausgestellt. Eine niedrigere Bitrate scheint schneller zum fertigen Export zu führen. Vermutlich liegt dies einfach daran, dass bei einer höheren Bitrate mehr Daten ausgegeben werden müssen. Dies ist unabhängig vom Quellmaterial und dessen Qualität zu betrachten.

Anders sieht es hingegen aus wenn man ein unkomprimiertes Format wie Apples ProRes oder DNxHR unter Windows nutzt. Hier ließ sich die Kodierungszeit für das effektbehaftete Testprojekt noch einmal drastisch reduzieren. Leider wurde dadurch die Dateigröße auch massiv erhöht. Für den Upload ist dies bei unserer Glasfaserleitung trotzdem kein Problem (siehe rechts den Upload einer mehr als 1 GByte großen Datei bei Youtube). Das Lagern von 200 GByte großen Videodateien bei einer Laufzeit von gerade mal einer Stunde ist aber der absolute Overkill. Ebenfalls gilt es das aktuelle Limit für die Dateigröße bei Youtube zu beachten. Aktuell liegt dies bei 128 GByte pro Videodatei.

Fazit

Als Kompromiss zwischen Speicherverbrauch, Encoding- und Uploadzeit hat sich bei uns nun ein Export im h.264-Format mit konstanter statt variabler Bitrate herauskristallisiert. Allerdings ist dies nur eine Momentaufnahme, da in Zukunft 4k-Videos folgen werden… Ein Export im DNxHR-Format bietet sich für die meisten wohl nur dann an, wenn die Exportdatei nach dem Upload zu Youtube wieder weggeworfen wird. Das kann aber durchaus eine Option sein, wenn man das Premiere-Projekt sowieso als Backup aufhebt. Den Export könnte man im Bedarfsfall vergleichsweise „schnell“ noch einmal wiederholen. Als Vorschau-Video könnte man sich das von Youtube umgewandelte Video herunterladen. Zwar ist dieses qualitativ schlechter als ein selbst durchgeführter Export im h.264-Format, reicht aber als absolutes Notfall-Backup.