Vor vielen Jahren habe ich auch viel mit TMPGEnc gemacht... aber seit ich Edius nutze sehe ich dafür eigentlich keinen wirklichen Grund mehr.Roland Schulz hat geschrieben: ↑So 29 Okt, 2017 19:28 Mit dem TMPGEnc Plugin lässt sich aus der Timeline des Editors direkt mittles des hochwertigen x264 Encoders exportieren, ohne den teils aufwändigen und zeitraubenden Umweg über ein Intermediate Codec gehen zu müssen.
Wo hast Du das denn her?!?! Im Plugin ist der x264 (ist auch kommerziell lizensiert bei x264...), in der TMPG Mastering Suite sind x264 und x265 drin. Von Mainconcept steht da kein Wort!
Das kann ich genau so bestätigen. Bei geringeren Bitraten ist x264 zwar erheblich langsamer, aber auch um Längen besser als der QuickSync-Export direkt aus Edius. Da geht es nicht um die letzten Feinheiten, sondern um wirklich beträchtliche Qualitätsunterschiede. Ich habe mit x264 (Handbrake) sehr ordentliche 1080/50p-Videos ausgeben können mit nur 5 MBit/s. Bei dieser Datenrate produziert QuickSync aus Edius längst übelste Artefakte.Roland Schulz hat geschrieben: ↑So 29 Okt, 2017 19:46 Die Qualität von x264 ist besonders bei geringen Bitraten deutlich besser als vom internen Encoder oder QuickSync. "Obenrum" finde ich QuickSync auf meinem Skylake schon gar nicht mal so schlecht
https://github.com/Vouk/voukodervoukoder
Use x264 and x265 from the libav library directly in Adobe Premiere (Pro and Elements).
Nix da Premiere bei mir keine Rolle spielt, primär geht's mir um EDIUS.ruessel hat geschrieben: ↑Mo 30 Okt, 2017 08:51 Was ist denn mit diesem kostenlosen Tool?
https://github.com/Vouk/voukodervoukoder
Use x264 and x265 from the libav library directly in Adobe Premiere (Pro and Elements).
Man kann die dafür benötigte Zeit noch etwas verkürzen, indem man HQ statt HQX exportiert (10 Bit braucht man für die x264-Weiterverarbeitung eh nicht) und sich mit Standard statt Fein begnügt. Ich habe das noch nicht gezielt verglichen, aber ich bezweifle, dass es am Endergebnis sichtbar was ändert.Roland Schulz hat geschrieben: ↑Mo 30 Okt, 2017 08:53 nur muss ich nach dem Rendern in HQX nochmal nen externen Prozess anstoßen
Das spricht erst recht für den Intermediate-Zwischenweg, weil man dann diese Berechnungen nur einmal machen lassen muss und dann aus der Intermediate ohne weiteren Zeitverlust verschiedene x264/x265-Varianten erstellen kann.zudem der Timelineexport mit diversen Plugins (Neatvideo...) schon mal ne Zeit dauern kann.
Gibt es dazu genaueres?beiti hat geschrieben:(10 Bit braucht man für die x264-Weiterverarbeitung eh nicht)
der convert Prozess belegt mir aber nicht den Rechner.. das macht der Slave..Roland Schulz hat geschrieben: ↑Mo 30 Okt, 2017 08:53 Klar geht das alles über nen Intermediate, nur muss ich nach dem Rendern in HQX nochmal nen externen Prozess anstoßen - also mir ist das die 79$ wert wenn das gleich in einem Rutsch geht zudem der Timelineexport mit diversen Plugins (Neatvideo...) schon mal ne Zeit dauern kann.
Das fertige MP4 aus x264 hat nur 8 Bit. Ob man das Original schon vorher auf 8 Bit reduziert oder erst beim Encoding, dürfte keine Rolle spielen.
x264 kann selbst (nicht im EDIUS Plugin) 10bit! x265 kann das ebenfalls und auch aus Handbrake wenn man die richtige lib in den Handbrake Ordner kopiert. So funktioniert mit nem 10bit HQX auch der komplette 10bit Workflow aus EDIUS, wenn man will und kann kann man das über mpc-HC auch in 10bit mit ner 10bit Grafikkarte auf nem 10bit TV wiedergeben!
*Dürfte* heisst, du nimmst das an. Meine Erfahrung mit Encoding-Prozessen hat mir immer gezeigt, dass aus besserem Ausgangsmaterial auch bessere Encodingqualitäten zu erwarten sind. Ganz allgemein. Den speziellen Fall 10bit -> 8bit habe ich aber keinen Tests unterzogen. Ich könnte mir allerdings nur vorstellen, dass 10bit als Ausgangsmaterial keine positive Rolle spielen, wenn beim Encoding als erster Schritt eine einfache Reduktion von 10 auf 8bit erfolgt und nicht als hohe Qualität direkt in den Prozess eingeht. Aber solche Details sind mir nicht bekannt (deshalb encodier ich 10bit Ausgangsmaterial).