Adobe Premiere: Encoding ist zu langsam?

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.

 

Smart Rendering?

Der Export findet für das FullHD- oder 4k-Videomaterial im h.264-Format statt, welches leider einen kleinen Nachteil hat. Das sogenannte Smart Rendering 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 Rendering 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 Rendering sowieso nicht nutzen.

Fazit: Smart Rendering ist bei einem aktuellen Videoformat oder bei einem eingesetzten Filter 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.

 

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 Rendering Problems ebenfalls nichts gebracht, da auch für diesen Fall das vorgerendete Material im gleichen Format vorliegen muss wie das schlussendliche Ausgabeformat. Dies lässt sich wohl auch so konfigurieren, dass man z. B. im unkomprimierten Format die Vorschau rendert, welches 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 wieder encodet werden.

Da bei uns der Workflow baer 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, außer dass diese nicht am Stück stattfindet, sondern schon vorher bruchstückhaft z. B. während einer Pause bei der Videobearbeitung.

Fazit: Aus den gleichen Gründen wie das Smart Rendering macht das Vorrendern meiner Meinung nach eher wenig Sinn, insbesondere wenn man nicht über einen längeren Zeitraum an einem Projekt arbeitet.

 

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 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 gleichwertig, wird aber wohl wesentlich mehr Speicherplatz belegen. Aaußer man wandelt ein Video um das wegen durchgehend schneller Bewegungen 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 Encodingzeit und der Dateigröße nieder:

 

Dauer Größe Dauer pro Min. Größe pro Min.
VBR mit Bearbeitung 14:32 Min. 106 MB 7:16 Min. 53 MB
CBR mit Bearbeitung 7:52 Min. 230 MB 3:56 Min. 115 MB
VBR ohne Bearbeitung 5:10 Min. 106 MB 2:35 Min. 53 MB
CBR ohne Bearbeitung 3:10 Min. 232 MB 1:35 Min. 116 MB

 

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. 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.

 

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 1 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.

 

Dauer Größe Dauer pro Min. Größe pro Min.
h.264 CBR mit 50 MBit/s 9:05 Min. 701 MB 4:33 Min. 350,5 MB
DNxHR (unkomprimiert) 2:50 Min. 6,41 GB 1:25 Min. 3,205 GB

 

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 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.

 

Schreibe einen Kommentar