HEVC Encodierung mit TMPGEnc Video Mastering Works 6

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • HEVC Encodierung mit TMPGEnc Video Mastering Works 6

      ro_max schrieb:

      Da ich andernorts die CPU-Auslastung von Vegas bemängelt habe, sollte ich fairerweise erwähnen, dass auch die aktuelle Version von PPro sich ca. 8x Echtzeit für das Rendern zu HEVC auf einer 8-Core-CPU (Ryzen 1800x) nimmt und die Auslastung der Kerne dabei im Schnitt unter 50% bleibt...
      Gerade mal ausprobiert:
      7 sec MP4 AVC/XAVC S 3840x2160 25FPS 100 MBit/s aus AX53 zu H.265 gleiche Auflösung braucht bei mir genau 7 sec.

      Dazu verwendet:
      TMPGENC Video Mastering Works 6 , dazu Decoder NVENC benutzen.

      Hardware I7 2600K nicht übertaktet und GTX 1050 ti 4GB
    • bs3095 schrieb:

      7 sec MP4 AVC/XAVC S 3840x2160 25FPS 100 MBit/s aus AX53 zu H.265 gleiche Auflösung braucht bei mir genau 7 sec.
      Ohne Angaben zu Bitrate für das Zielformat und Qualitätseinstellungen ist das nicht so leicht vergleichbar.

      Im meinem Fall ging es auch um ganz anderes Material, nämlich um Einzelbildsequenzen (PNGs in UHD mit 16 Bit Farbtiefe und 24 FPS (d.h. 24x29 MByte = 5.568 MBit/s pro Sekunde Ausgangsmaterials verglichen mit dem 100 MBit/s Sony Material), die nach Bearbeitung mit einem Gradingfilter zu 10 Bit HEVC heraus gerendert wurden, wobei Quell- und Ziellaufwerk die gleiche Normalofestplatte war. Ich bin sicher, unter solchen Umständen macht Dein System auch kein Rendern in Echtzeit. ;)

      Ein Test mit 24p AX53 Material ergab einen Faktor von ca. 4x Echtzeit bei einer Zielbitrate von 50 MBit/s und einem Maximum von 60 MBit/s sowie einer Renderqualität von "Good". Prozessorauslastung lag bei ca. 80%.
      Greetings,
      ro_max

      Grüne Kommentare sind als Mod, der Rest als User geschrieben.
    • Input/Output waren 100 MBit/s. Es wurden übrigens alle 4 Cores ausgelastet.
      Wäre doch trotzdem von Interesse, wie sich Deine Aufgabenstellung und dem Ryzen mit diesem Programm schlägt.

      ro_max schrieb:

      bs3095 schrieb:

      7 sec MP4 AVC/XAVC S 3840x2160 25FPS 100 MBit/s aus AX53 zu H.265 gleiche Auflösung braucht bei mir genau 7 sec.
      Ich bin sicher, unter solchen Umständen macht Dein System auch kein Rendern in Echtzeit. ;)

      Ein Test mit 24p AX53 Material ergab einen Faktor von ca. 4x Echtzeit bei einer Zielbitrate von 50 MBit/s und einem Maximum von 60 MBit/s sowie einer Renderqualität von "Good". Prozessorauslastung lag bei ca. 80%.
      Leider gibt es hier ja niemand, der die TMPGenc-Programme verwendet. Die Auslastung beim Rendern liegt bei mir zu je ca.50% bei CUDA und CPU.
      Also nur 4x Echtzeit beim AX53-Material ist schon sehr schwach, da würde ich mir schon Gedanken machen.
    • ro_max schrieb:

      Ich bin sicher, unter solchen Umständen macht Dein System auch kein Rendern in Echtzeit.
      Das bezog sich nur auf das von mir geschilderte Szenario mit der PNG-Sequenz und nicht, wie es Deine Zitierweise meines Texts nahelegt, auf das der AX53. Du stellt durch das nur auszugsweise Zitieren einen nicht vorhandenen Bezug her. Ich bitte, das zu unterlassen.

      bs3095 schrieb:

      Da kann ich gern mal ein Video machen, was das beweist, was ich geschrieben habe.
      Dass Dein System das AX53-Material in Echtzeit zu HEVC rendern kann (mit Hardwareunterstützung) kann ja sein und braucht auch nicht bewiesen zu werden.

      Für mich ist die Zeit der HEVC-Umwandlung ohnehin ziemlich unerheblich. Das Erzeugen der PNG-Sequenz hat auf dem Ryzen 2,5 Stunden für 5 Sekunden Material (120 Frames) gebraucht (also 1.800 mal Echtzeit). Da ist es mir dann doch eher egal, ob die HEVC-Umwandlung 1x, 10x oder 20x Echtzeit braucht. ;)

      Ich hatte bisher keine Veranlassung, mich mit den TMPGenc-Programmen zu beschäftigen. Aber wenn Du mir sagen kannst, dass diese Programme mit Bildmaterial in 16- und 32-Bit-Farbtiefe arbeiten und 10-Bit HEVC mit HDR--Metadaten schreiben können, schaue ich sie mir vielleicht doch mal an. An 08/15 HEVC (also ohne HDR-Metadaten) habe ich jedoch kein Interesse.
      Greetings,
      ro_max

      Grüne Kommentare sind als Mod, der Rest als User geschrieben.
    • Ich habe das Encodierung von HEVC mal mit der Testversion von VMW6 und 24p 100 Mbit/s Material von der AX53 ausprobiert:

      1) zu x265: ca. 6x Echtzeit (CPU-Auslastung 84-89%)
      2) zu NVEnc: je nach Einstellungen zwischen 0,5x und 1,5x Echtzeit (Graka GTX 1070, CPU-Auslastung <30%)

      bs3095 schrieb:

      Kann man hier nachlesen:
      Eine Möglichkeit für das Einlesen von Bildsequenzen habe ich noch nicht gefunden. Auch in den Spezifikationen habe ich nichts zu Einzelbildern gesehen.

      Nach meinem Eindruck ist VMW6 keine NLE im herkömmlichen Sinne, sondern eher ein Encodierungsprogramm, das um ein paar Bearbeitungsfunktionen ergänzt wurde. Scopes oder ähnliches habe ich auf die Schnelle auch nicht gefunden.
      Greetings,
      ro_max

      Grüne Kommentare sind als Mod, der Rest als User geschrieben.
    • bs3095 schrieb:


      Leider gibt es hier ja niemand, der die TMPGenc-Programme verwendet. Die Auslastung beim Rendern liegt bei mir zu je ca.50% bei CUDA und CPU.Also nur 4x Echtzeit beim AX53-Material ist schon sehr schwach, da würde ich mir schon Gedanken machen.
      Wie kommst auf sowas? Ich verwende und empfehle TMPGenc seit Jahren.

      Und ja, es kann durchaus 10bit.
      Lieben Gruß,
      Wolfgang

      Grüne Kommentare sind aus der Admin-Funktion geschrieben
      Der Rest ist meine Privatmeinung
    • Nachtrag: Habe erst jetzt gesehen, dass der ursprüngliche Post um folgende Aussage ergänzt wurden:

      bs3095 schrieb:

      Also nur 4x Echtzeit beim AX53-Material ist schon sehr schwach, da würde ich mir schon Gedanken machen.
      Warum sollte ich mir da Gedanken machen? PPro verwendet anscheinend keine Hardwareencodierung für HEVC. Und wie unten gezeigt, ist VMW6 bei einer Software-/CPU-Lösung (also x265) auf meinem Rechner noch langsamer als 4x Echtzeit. Nur wenn das Encoding über die Graka läuft, wird es schnell.

      ro_max schrieb:

      Ich habe das Encodierung von HEVC mal mit der Testversion von VMW6 und 24p 100 Mbit/s Material von der AX53 ausprobiert:

      1) zu x265: ca. 6x Echtzeit (CPU-Auslastung 84-89%)
      2) zu NVEnc: je nach Einstellungen zwischen 0,5x und 1,5x Echtzeit (Graka GTX 1070, CPU-Auslastung <30%)
      Wenn, dann sollte sich wohl eher Adobe Gedanken darüber machen, Hardware-Encoding über NVEnc zu unterstützen. ;)

      Ich bin ja durchaus mal für Benchmarks zu haben, aber realistischer Weise sieht zumindest mein Workflow mit Videomaterial eher so aus:
      1) Alles Material in die TL
      2) Material sichten, kürzen, löschen
      3) Ggf. Farbkorrektur
      4) Rauschfilter bei Bedarf (also oft)
      5) Audiobearbeitung
      6) Titel
      7) Testweises Rendern
      8) Ggf. Korrekturen/erneutes Durchlaufen der Schritte 2-7
      9) Finales Rendern

      Ich will damit sagen, dass die reine Rendergeschwindigkeit am Schluss nur ein Faktor von vielen ist, und der genannte Workflow (nach meinem aktuellen Kenntnisstand) in VMW6 nur teilweise umsetzbar ist.

      Meinen Einzelbildsequenzen-Workflow kann ich anscheinend gar nicht dort umsetzen.

      Mein Eindruck ist, dass VMW6 eher zur Bearbeitung/Umwandlung von vorhandenem Videomaterial (z.B. von TV-Recordern) gedacht und nicht so sehr als klassische NLE konzipiert ist. Vielleicht erklärt das auch, warum hier nicht viele das Programm zur Bearbeitung ihrer selbstgedrehten Videos einsetzen.
      Greetings,
      ro_max

      Grüne Kommentare sind als Mod, der Rest als User geschrieben.
    • Dafür gibt es noch die beiden anderen Programme Authoring und Smart Rendering.
    • bs3095 schrieb:

      Dafür gibt es noch die beiden anderen Programme Authoring und Smart Rendering.
      Ja, das habe ich auf der Website gesehen. Aber beide helfen mir nicht weiter: BDs mache ich nur noch in Ausnahmefällen zum Verschenken (und dann in Encore) und Smart Rendering geht bei mir nicht, da praktisch immer Filter eingesetzt werden (wie oben bereits erwähnt). Einen reinen "Schnitt" von ansonsten unbehandeltem Material - also wenn z.B. Smart Rendering möglich wäre - gibt bei mir so gut wie nie.

      Die TMPGEnc Programme sind für ganz bestimmte, relativ eng gesteckte Anwendungsfälle. Dort sind sie sicherlich gut, preiswert (und bei entsprechender Hardwareunterstützung) auch schnell. Die eierlegende Wollmilchsau im Videobereich sind sie IMO aber nicht.
      Greetings,
      ro_max

      Grüne Kommentare sind als Mod, der Rest als User geschrieben.
    • ro_max schrieb:


      Ich bin ja durchaus mal für Benchmarks zu haben, aber realistischer Weise sieht zumindest mein Workflow mit Videomaterial eher so aus:...
      Benchmarking wäre schon eine tolle Sache.

      Aber das bedingt fundamental eine Qualitätsmessung des encodierten Materials.
      Diese Messung müsste das decodierte Zielmaterial mit dem vorliegenden Quellmaterial
      vergleichen (Differenzbildung) und bildweise quantifizieren, evtl wahrnehmungs-gewichtet.

      Gibt's sowas? kennt jemand so ein Programm?

      Sehr beliebt ist ja bei Cam-Nutzern der Trugschluss, dass eine höhere Bitrate
      bessere Bildqualität ergibt. Das mag bei konstanter Testumgebung oft stimmen,
      ist aber im Vergleich zu anderen Systemen nicht aussagekräftig, somit irreführend:
      ein schlechter Encoder benötigt eine höhere Bitrate um die gleiche Qualität wie
      ein guter Encoder bei niedrigerer Bitrate zu generieren.

      Ich nutze mit X.264-Encoder wahlweise ein Encoder-Profil, dass recht niedrige Bitrate
      bewirkt, indem der Suchraum der Bewegungsvektoren vergrößert wird
      (wo ist das vorige Bildelement im Folgebild geblieben und muss somit nicht neu
      encodiert werden?). Dies ergibt (mit long-GOPs) bei ähnlicher Qualität (?) etwa die
      gleiche Kompressionsrate wie H.265.
      Aber Vergleichsmessungen/Benchmarks der Qualität wären hier schon hilfreich...
    • dosaris schrieb:

      Aber das bedingt fundamental eine Qualitätsmessung des encodierten Materials.
      In diesem Zusammenhang/Thread ging es jetzt erst einmal nur um die Geschwindigkeit und nicht um die Qualität des Endprodukts und damit indirekt um die Performance des eignen Systems aus Soft- und Hardware.
      Korrekterweise wäre ein solcher Vergleich jedoch nur unter gleichen Bedingungen (gleiche Software, gleiches Quellmaterial, gleiche Rendereinstellungen, etc.) zulässig und das ist hier nicht gegeben. Stattdessen wurde das Ergebnis mit Software A (PPro 2018) in Situation B (PNG-Einzelbildsequenz) und CPU-Rendering mit dem Ergebnis von Software C (VMW6) und dem Material D (100 MBit/s Videomaterial) sowie GPU-Rendering verglichen, was, wie ich oben bereits ausgeführt habe, nicht wirklich etwas bringt.

      dosaris schrieb:

      kennt jemand so ein Programm?
      Ich nicht.

      dosaris schrieb:

      Sehr beliebt ist ja bei Cam-Nutzern der Trugschluss, dass eine höhere Bitrate
      bessere Bildqualität ergibt.
      Das ist nicht automatisch und immer ein Trugschluss, sondern hängt von einer ganzen Reihe von Faktoren ab. Man muss auch unterscheiden, ob es sich um das Aufnahmematerial oder um das Endprodukt des Bearbeitungsvorgangs handelt. Hoch- bzw. effizient komprimiertes Quell- oder Aufnahmematerial macht i.d.R. mehr Probleme bei der Bearbeitung, u.a. wegen des höheren Decodieraufwands für die NLE.

      dosaris schrieb:

      Ich nutze mit X.264-Encoder wahlweise ein Encoder-Profil, dass recht niedrige Bitrate
      bewirkt, indem der Suchraum der Bewegungsvektoren vergrößert wird
      (wo ist das vorige Bildelement im Folgebild geblieben und muss somit nicht neu
      encodiert werden?). Dies ergibt (mit long-GOPs) bei ähnlicher Qualität (?) etwa die
      gleiche Kompressionsrate wie H.265.
      Warum nimmst Du dann nicht gleich H.265? Und warum sind Dir möglichst niedrige Bitraten im Endprodukt wichtig?
      Greetings,
      ro_max

      Grüne Kommentare sind als Mod, der Rest als User geschrieben.
    • Ich habe es so verstanden, ob es ein Programm gibt, das eine solche Differenzanalyse automatisch für ein ganzes Video macht und die Unterschiede in Prozent o.ä. ausgibt. Dass ein solches Differenzbild z.B. in Photoshop erzeugt werden kann, dürfte bekannt sein.
      Greetings,
      ro_max

      Grüne Kommentare sind als Mod, der Rest als User geschrieben.
    • Sowas habe ich schon vor einem Jahrzehnt gemacht und damals mit einem Tool von Peter quantifiziert.
      Lieben Gruß,
      Wolfgang

      Grüne Kommentare sind aus der Admin-Funktion geschrieben
      Der Rest ist meine Privatmeinung
    • ro_max schrieb:

      ch bin ja durchaus mal für Benchmarks zu haben, aber realistischer Weise sieht zumindest mein Workflow mit Videomaterial eher so aus:
      1) Alles Material in die TL
      2) Material sichten, kürzen, löschen
      3) Ggf. Farbkorrektur
      4) Rauschfilter bei Bedarf (also oft)
      5) Audiobearbeitung
      6) Titel
      7) Testweises Rendern
      Ggf. Korrekturen/erneutes Durchlaufen der Schritte 2-7
      9) Finales Rendern

      Ich will damit sagen, dass die reine Rendergeschwindigkeit am Schluss nur ein Faktor von vielen ist, und der genannte Workflow (nach meinem aktuellen Kenntnisstand) in VMW6 nur teilweise umsetzbar ist.
      Denke mal das geht alles:

    • wolfgang schrieb:

      Sowas habe ich schon vor einem Jahrzehnt gemacht und damals mit einem Tool von Peter quantifiziert.
      verrätst Du, welches Tool das ist/war?

      Ich will damit sagen, dass die reine Rendergeschwindigkeit am Schluss nur ein Faktor von vielen ist,

      genau.

      Ich hatte aber versucht den gesamten workflow zu optimieren und dabei festgestellt,
      dass der rein visuelle Qualitätsvergleich zw 2 Stream sehr schwer zu beurteilen ist.
      Und die Bild-Qualität verläuft typisch analog zur Encodierungs--Dauer
      (Bewegungsvektoren-optimierung und Suchraum-Eingrenzung).
      Ergo ergibt der Vergleich div Encoder-Zeiten (benchmarking) ohne Relation zur
      resultierenden Bildqualität kaum Sinn. Deswegen möchte ich die Qualitäts-Auswirkung div
      Encoder-Einstellungen gern mit berücksichtigen bzw objektivierbar haben.