Ich weiß gar nicht ob vielen das interessante TMPGEnc Plugin für EDIUS und Premiere bekannt ist. 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.
Ich nutze das Plugin schon lange für EDIUS (und Premiere, da aber "low usage") und bin eigentlich sehr zufrieden damit. Jetzt fände ich nicht schlecht wenn Pegasys auch x265/10bit da mit reinbringen würde.
Weiterhin bietet das Plugin die Möglichkeit auch Intel QuickSync als Encoder zu nutzen - für ne schnelle Voransicht auf jeden Fall schon mal nicht schlecht, vor allem da Premiere das meines Wissens im Gegensatz zu EDIUS gar nicht nativ unterstützt.
Der QS Support ist allerdings sehr elementar, da funktionieren derzeit leider aus dem Plugin keine UHD Formate (wahrscheinlich alte Intel SDK/libs) - für die EDIUS User allerdings auch weniger schlimm da das da direkt geht.
Vielleicht könnten die die's interessiert dem Pegasys Support ja auch mal ne E-Mail schreiben und um die "Modernisierung" des Plugins bitten. Pegasys teilte mir mit dass das Plugin weiterentwickelt wird wenn denn Nachfrage bestünde.
Die Technik (x265/main10) haben die schließlich schon in Ihrer Mastering Suite, also nahezu Copy&Paste ;-)...
Auch wenn EDIUS 9 jetzt HEVC/10bit direkt exportieren werden kann wird das qualitativ wahrscheinlich wieder ne Krücke sein denke ich, bisher waren die internen Encoder auch nie so dolle, Quicksync ab nem Haswell bot mehr Qualität.
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.
Vor vielen Jahren habe ich auch viel mit TMPGEnc gemacht... aber seit ich Edius nutze sehe ich dafür eigentlich keinen wirklichen Grund mehr.
Und was meinst du mit einen "aufwändigen, zeitraubenden Umweg über ein Intermediate Codec" ?
Wen ich Material aus meiner h.264 Sony Kamera nativ in Edius reinwerfe und editiere - gebe ich über den Edius eigenen Encoder auch wieder solch ein File aus... Welchen Umweg sollte ich da über einen Intermediate Codec gehen? Weder beim Import - noch beim Export sehe ich dafür eigentlich einen Grund.
Klar - man wird bei dem Plugin sicherlich noch einiges mehr einstellen können - aber mit entsprechender Datenrate finde ich den h.264 MP4 Output den Edius mir ausgibt sehr brauchbar... und da ich 'ne I7 Cpu verwende - kann ich auch direkt aus Edius Gebrauch von Quicksync machen...
So gesehen: Für mich gibt es da tatsächlich wenig Gründe etwas am mehr als einfachen Worklfow mit Boradmitteln ändern zu müssen.
Hast du qualitative Erfahrungen mit dem Output im A-B Vergleich?
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, trotzdem geht kein Weg an x264 vorbei wenn man die höchste Qualität will, höchstens x265!
QuickSync zeigt besonders auf Wasseroberflächen häufig I-Frame Pumpen, wobei QuickSync von Generation zu Generation auch immer besser wird. H.265 Encoding kann man bei QuickSync aber zumindest auf dem Skylake noch ziemlich vergessen.
Ich finde das Olugin klasse und nutze das bei jedem finalen Export!
Für nen 10bit Export (nach x265) geht's bis EDIUS 9 zudem nur über z.B. den Canopus Codec und dann in x265. Was der EDIUS 9 HEVC Encoder zudem leisten wird steht auch noch in den Sternen, denke aber mal Referenz wird das wieder nicht werden...
Alf_300 hat geschrieben: ↑So 29 Okt, 2017 19:48
TMPGEnc benutzt den Mainconcep/DivX h-265 Encoder, da werden sie kaum selber was entwickeln
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!
Die sollen nur x265 auch in die Plugins bringen sowie die neuen Intel SDKs inkludieren.
Steht doch ganz oben was ich wollte, daran hat sich auch nix geändert...
x265 ist zudem nen H.265 Encoder, nix anderes. Den mit in das x264 Plugin zu bringen sollte für Pegasys eigentlich nicht die Kunst sein. Möglicherweise ist aber die Nachfrage einfach zu klein - verstehe ich eigentlich nicht da zumindest das x264 Encoderplugin ziemlich klasse ist, kein Vergleich zu den Bordmitteln bei EDIUS und Premiere!
Mir war so als hättest Du gescruieben man soll Tmpgnc anmailen das sie das Plugin modernisieren
weil der Encoder in Edius 9 wahrscheinlich eine Krücke ist ;.)
Die Geschmäcker sind halt verschieden.
Ich hab mir dass x264 Update 10.10.11 jedenfalls gespart.
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
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.
Zu meiner Überraschung habe ich allerdings auch festgestellt, dass der lahme Software-Encoder von Edius noch ein bisschen schlechter ist als der QuickSync-Encoder (in meinem Fall Haswell/i5). Also wenn man schon direkt aus Edius ausgibt, dann spricht alles für den flotten QuickSync-Export.
Bei Datenraten über 15 MBit/s werden die Artefakte und somit auch die Unterschiede zu x264 sowieso immer geringer. Also überall dort, wo ein etwas größeres File nicht stört, kann man getrost direkt mit Edius/QuickSync exportieren. Das geht dann teilweise sogar schneller als der HQ/HQX-Export.
QuickSync ist eigentlich immer schneller und ab dem Haswell eigentlich auch schon sehr gut - da muss man bei höheren Bitraten echt schon genau hingucken um nen Unterschied zu x264 zu sehen - aber den gibt es!
Der EDIUS interne H.264 Encoder ist mies, da bin ich dabei!
x265 im Plugin wäre nett...
Trotzdem werde ich als Gelegenheitsnutzer bestimmt nicht 79$ ausgeben für ein PlugIn, dessen einziger Nutzen gegenüber dem kostenlosen Handbrake darin besteht, mir den Umweg über eine Intermediate-Datei zu ersparen. Die Ausgabe in HQ-AVI geht ja halbwegs flott und das Encoding in x264 mit 2-Pass und VBR ist recht gemächlich. Ich gehe davon aus, dass das PlugIn auch nicht schneller arbeitet als Handbrake. Also unterm Strich würde man mit dem PlugIn vielleicht 1/4 oder höchstens 1/3 der Zeit sparen.
Was stört Dich eigentlich daran über Staxrip oder Handbrake zu gehen?
Dort ziehe ich das entweder über x264/265, NVENC265 oder QS265 durch und gut ist.
Ich lasse der NLE die Zeit um mit dem für sie von der Qualität und Leistung her besten Codec zu arbeiten..
Im deinem Falle Edius mit den HQ und HQX Files...Files parken und übers Netz über einen Encoder Knecht per CPU,GPU oder IGPU wandeln lassen.
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.
Roland Schulz hat geschrieben: ↑Mo 30 Okt, 2017 08:53 nur muss ich nach dem Rendern in HQX nochmal nen externen Prozess anstoßen
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.
zudem der Timelineexport mit diversen Plugins (Neatvideo...) schon mal ne Zeit dauern kann.
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.
Klar wäre es nett, wenn man - neben den anderen Optionen - auch direkt aus Edius in x264 und x265 ausgeben lassen könnte. Die Frage ist nur, wieviel Geld einem das zusätzlich wert ist. Knapp 80 $ lohnen sich wirklich nur für Leute, die das täglich mehrmals brauchen und dabei noch unter Zeitdruck stehen.
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.
der convert Prozess belegt mir aber nicht den Rechner.. das macht der Slave..
dienstag_01 hat geschrieben: ↑Mo 30 Okt, 2017 09:20Gibt es dazu genaueres?
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!
Deshalb hätte ich 10bit auch gerne im Plugin!
BTW: 10bit macht sogar Sinn auch wenn das Quellmaterial nur in 8bit vorlag. Sobald man Farbkorrekturen etc. vornimmt bietet ein 10bit Workflow Vorteile, zumindest für Enthusiasten ;-)!!
dienstag_01 hat geschrieben: ↑Mo 30 Okt, 2017 09:20Gibt es dazu genaueres?
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.
*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).
Rechtliche Notiz: Wir übernehmen keine Verantwortung für den Inhalt der Beiträge
und behalten uns das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
