Voukoder: x264 / x265 Plugin für Adobe Premiere

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

  • Anzeige

    Sagaras schrieb:

    z.B. wenn ihr die Videos aufnehmt in z.B. MP4/h264, dann würde Premiere oder Co. länger zum decodieren des Videos brauchen.
    rationalqm.us/dgdecnv/dgdecnv.html

    Das teil ist btw GODLIKE. Indexierung bei 2std video in 2min fertig.
    Decode via GPU - BRUTAL SCHNELL, das Ding kann sogar nun auch upscale via GPU

    Verdammte 100% CPU Nutzung trotz upscale.
    Also wer mit Avisynth arbeitet und h.264 Quellen encodieren will, dem sei die investition in das Ding empfohlen. Einfach nur top!

    Aber jetzt wo NVEnc so stark geworden ist, kann man imo auch den Encode mit NVEnc bedenkenlos machen. x264 medium effizienz - holy moly.





    Seit etlichen Monaten komplett veraltete Signatur, wie ihr sicherlich schon bemerkt habt. Habe mittlerweile mehr als 4 Projekte, weshalb die Signatur leider momentan gesprengt ist xD
    Notdürftig die Liste was aktuell läuft: Unreal | DooM 2: Project Brutality | Complex DooM (LPT) | DooM 2016 | Need For Speed III: Hot Pursuit | Dirt 4 | WRC 7
  • Guten Abend, ich antworte morgen mal ausführlicher bzw. lese mir Eure Postings nochmal genau durch.

    Also x264.exe kann ich gerne mal testen.
    Ja, die Kerne waren alle zu 100% ausgelastet bei mir.

    @De-M-oN Das waren bereits MP4's. Allerdings würde NVENC dann ja auch arge probleme beim decoden haben müssen.
    Ganz unkomprimiert wäre ja eh nicht sooo gut, weil riesig. Normal ist ja die Empfehlung CQP 15 oder so. Aber das würde am evt. Grundproblem nichts ändern, oder? Lagarith ist mittlerweile nicht mehr up-to-date, oder? Wie wäre eine Empfehlung von Dir.
  • Anzeige

    Sagaras schrieb:

    Knackfrisch schrieb:

    Dann ist es aber trotzdem merkwürdig, wenn der Ryzen 2700x da so langsam ist. Auch ich würde da mindestens doppelte Echtzeit erwarten, gerade wegen zusätzlichen Kernen.
    Wurde doch schon erwähnt weiter oben. Bestimmte Sachen sind einfach nicht Parallelisierbar.Bedeutet einfach das gewisse Dinge einfach eins nach dem anderen abgearbeitet werden können.

    Ein Bildliches Beispiel um dir das Problem zwecks Multithreading zu erläutern
    Dann erklär mir mal das hier: *klick*

    Gleicher Content und die 16 oder 18 Kern CPUs encoden immer noch schneller. Das ist nicht nur Takt alleine...

    Mal ein Beispiel:

    [Blockierte Grafik: https://images.anandtech.com/graphs/graph13539/102827.png]

    Wenn man sich die anderen Tests ansieht, scheint weder x264 noch x265 den AMD CPUs sonderlich gut zu liegen... Vom 32 Kerner sind das zwar immer noch 179 FPS und damit 3-fache Echtzeitgeschwindigkeit, aber wenn der 7960x da trotzdem enorm zulegt, trotz "nur" 16 Kernen.Ich weiß, dass die IPC Leistung von Ryzen/Threadripper bisher Intel immer unterlegen war (und das wohl auch erst einmal bleiben wird, auf die Ryzen 3000 Benchmarks bin ich wahnsinnig gespannt)

    Und die Intel CPUs haben alle Sprungoptimierung für h26x Encoding.

    Außer die Infinity Fabric drückt durch die Latenz die Leistung enorm nach unten. (sieht man ja sogesehen bei den Tests, je weniger Kerne, desto höher die FPS)
  • Naja, dann erklär du mir auch was bei den Test als Input gedient hat?
    z.B. laufen verlustfreie Aufnahmen wie MagicYUV, Lagarith, UTVideo ODER aber auch Sachen wie XVID, DIVX etc.. schneller durch eine Decodierung und können somit auch schneller durch eine Encodierung.

    Nächste Frage: Was sind an Filter alles aktiv im Einsatz? Musste bei dem Test Skaliert werden oder andere Bildbearbeitungen durchgeführt werden? Wenn NEIN, dann ist die jeweilige Transkodierung mit selber Auflösung, FPS, und ohne sonstige Filternutzung enorm schneller.

    Nächster Punkt bei deinen Benchmarks: Es wurden recht schnelle Presets verwendet um keine großen Encodingbremsen verwenden zu müssen.
    Aber nirgends stehen genaue Settings dafür was genommen wurde.
    Einzig und allein das mit exakten Bitraten getestet wurde steht da, das wars aber auch. Sonst steht da gar nix.

    Das die jeweiligen AMD und Intel Produkte beim Test anders abschneiden ist klar. Aber nirgendwo stehen exakte Angaben mit was das ganze getestet wurde.

    Es fehlt halt das Input Material, welche Settings in Handbrake genutzt wurde.
    Theoretisch sind das total vage Statistiken.

    Wenn du ein Bild Filter nutzt, der dafür sorgen muss das z.B. das Bild skaliert werden muss oder was immer du im Video bearbeiten willst. (Dazu zählt keine Schnittfunktion), dann kann es durchaus sein das solche Prozesse mit limitierten Kernen arbeiten. Kommt dann drauf an wie programmiert wurde oder was zur Unterstützung dient um diesen Prozess zu beschleunigen. In der Regel können GPUs diesen "Render" Prozess beschleunigen. Ansonsten werden sie mit limitierten Threads betrieben.

    Wie gesagt, ich kann dir nicht sagen wo deine Schlinge in diesen Kreislauf ist, da du keinen Aufschluss darüber gibst, sondern einfach nur anprangerst das das Encodieren zu lahm sei, obwohl die Benchmarks was anderes sagen.

    Du als auch die Benchmarks geben mir aber 0 Aufschluss wie was getan wird um solche Ergebnisse zu erzielen.
    Ich kann dir lediglich nur sagen wie was funktioniert. Aber das scheinst du vllt. nicht so recht zu verstehen. Weiß ich nicht.

    Du könntest genauso hohe Encoding Raten erzielen, musst nur den richtigen Input haben, die richtigen Settings und dann könntest du so in Richtung deiner Benchmarks Ergebnisse auf dieser Webseite kommen.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Sagaras ()

  • Also rein von der Idee her würde ich ja Encoden für Multitaskingfähig halten.

    Milchmädchen-Beispiel: 8 Minuten Video. 8 Kerne. Jeder Kern kann 1 Minute encoden, wenn man einfach stumpf an der Stelle ein I-Frame packt. Im I-Frame sind ja alle Daten enthalten. Und wann ein neuer I-Frame kommen muss/soll/darf sollte ja ermittelbar sein.

    Oder stelle ich mir das zu einfach vor?

    Der Solveig MM-Video-Splitter schneidet z.B. B-Frame genau und encoded dann eben fix die paar Sekunden bis zum nächstne I-Frame und der rest wird einfach nur so in der Zieldatei beim schneiden gespeichert. Gut, das ist kein Multithreading, aber zeigt ja, dass ein I-Frame als definierter Start/ZIelpunkt reichen würde.
  • Sagaras schrieb:

    Naja, dann erklär du mir auch was bei den Test als Input gedient hat?

    Aber nirgends stehen genaue Settings dafür was genommen wurde.
    Einzig und allein das mit exakten Bitraten getestet wurde steht da, das wars aber auch. Sonst steht da gar nix.

    Das die jeweiligen AMD und Intel Produkte beim Test anders abschneiden ist klar. Aber nirgendwo stehen exakte Angaben mit was das ganze getestet wurde.

    Es fehlt halt das Input Material, welche Settings in Handbrake genutzt wurde.
    Meine Güte, das steht doch im Test...

    Handbrake, High/Main Profile und Bitrate. Scheint sehr kompliziert zu sein. Handbrake zu nehmen, High Profile auszuwählen und dann die Bitrate zu ändern. Info zum Sourcematerial steht genauso im Text..., sogar mit Auflösung und FPS, sogar das Model der Webcam wird genannt.
  • x264 @ preset slow wird auch einen 9900k alle Kerne was zu tun geben. Dennoch ist die IPC sehr wichtig.

    Ich muss aber auch sagen, das meiner Meinung nach Intel einfach auch die besseren Prozessoren baut..
    Selbst wenn Ryzen 3000 was taugen sollte, würde ich persönlich eher auf Icelake warten.

    Irgendwo stand aber auch das Premiere zb ebenso mit Intel besser harmoniert als AMD. Premiere ist intel optimiert im generellen. So das was ich gehört habe.





    Seit etlichen Monaten komplett veraltete Signatur, wie ihr sicherlich schon bemerkt habt. Habe mittlerweile mehr als 4 Projekte, weshalb die Signatur leider momentan gesprengt ist xD
    Notdürftig die Liste was aktuell läuft: Unreal | DooM 2: Project Brutality | Complex DooM (LPT) | DooM 2016 | Need For Speed III: Hot Pursuit | Dirt 4 | WRC 7
  • Knackfrisch schrieb:

    Meine Güte, das steht doch im Test...
    Meine Güte, sei mal nicht so herablassend. Danke.

    Knackfrisch schrieb:

    Handbrake, High/Main Profile und Bitrate. Scheint sehr kompliziert zu sein. Handbrake zu nehmen, High Profile auszuwählen und dann die Bitrate zu ändern. Info zum Sourcematerial steht genauso im Text..., sogar mit Auflösung und FPS, sogar das Model der Webcam wird genannt.
    Wenn du weißt was du da tust, warum fragst du dann erst? Weil dann sollte es doch klar sein, oder?

    1. Das Input Material ist mir immer noch Unbekannt. In was hat er es denn aufgenommen? HVEC? H264? RAW? Was? Je nachdem dauert das Decodieren.

    2. Bei Handbrake kann man zwars das Preset einstellen, aber auch diese durch andere Settings verstellen. Das Preset ist nur die erste Vorgabe, die letzten Settings werden vom User getätigt und die stehen da nicht.
    Da steht jetzt z.B. nicht wieviele Kerne er maximal genommen hat. Denn sobald Automatik aktiv ist, werden nur soviel genutzt wie x264 verarbeiten kann zur Laufzeit. Sprich wenn er nur 2 brauch, dann nutzt er nur 2, auch wenn er ein 5 Kerner verwendet.
    Mir fehlen die Diagnostic Statistiken vom Encode mit den genaueren Werten. Die wären interessanter gewesen bei nem Benchmark.

    3. Benchmarks mit so schlechten Settings zu machen liegt in keiner Relevanz zu dem was normale Menschen machen. Die Settings zwecks fast und faster + 3500kbps für ein 1080p60 Video, das ist mehr als Unterirdisch und dann auch noch mit ner CBR. Oje... das ist Video Vergewaltigung.

    Fazit: Keine Sau kann mit den Statistiken dort großartig was anfangen. Da fehlt jeder Bezug zum anderen Benchmark.
    Du hast 3 für Handbrake. Und jeder dieser 3 ist hat entweder ein anderem Codec, andere Bitrate, andere Bitratenmodus, andere Presets ODER ein anderes Profil.

    Einen vernünftigen Benchmark macht man mit einem Vergleich wo sich nur eine Option ändert und nicht alle bei jedem Test. Das ist nämlich nicht Überschaubar sonst.

    So, und nun weiß ich immer noch nicht was du tust bei Handbrake. Genausowenig wie ich immer noch nicht weiß was der Threadersteller von deinem Handbrake Benchmark da alles noch getan hat. Da sind einfach noch Unbekannte drin. Das Benchmark wirkt wie Hingeklascht mit dem Argument: "Ist so, weils so ist".
    Ja, kann man machen, muss man aber nicht, wenn man verstehen will warum.
  • Es geht doch nicht darum, ob deren Encoder-Settings sinnvoll sind oder nicht, weil das zum Teil subjektiv ist. Man kann davon ausgehen, dass sie für die Tests die gleiche Source genommen haben.

    Ihr wisst doch alle das Twitch bspw. nur max. 6mbit erlaubt. Wieviele Streamen mit weniger Bitrate? Also ist deren gewählte Bitrate nicht unbedingt zweifelhaft, sondern kommt der Realität recht nahe.

    Du wirfst mir vor, herablassend zu sein? Interessant, da kann ich echt nur den Kopf schütteln...

    Bin aus dem Thread raus, dass ist mir zu blöd.
  • Knackfrisch schrieb:

    Ihr wisst doch alle das Twitch bspw. nur max. 6mbit erlaubt. Wieviele Streamen mit weniger Bitrate? Also ist deren gewählte Bitrate nicht unbedingt zweifelhaft, sondern kommt der Realität recht nahe.
    Also willst du streamen und dir ist das Encodieren mit Echtzeit zu langsam. Hab ich das jetzt richtig verstanden? Also wenn das so sein sollte, bin ich raus. Wüsste nicht wie man beim Streamen schneller Encodieren kann als Echtzeit.
  • Sagaras schrieb:

    Knackfrisch schrieb:

    Ihr wisst doch alle das Twitch bspw. nur max. 6mbit erlaubt. Wieviele Streamen mit weniger Bitrate? Also ist deren gewählte Bitrate nicht unbedingt zweifelhaft, sondern kommt der Realität recht nahe.
    Also willst du streamen und dir ist das Encodieren mit Echtzeit zu langsam. Hab ich das jetzt richtig verstanden? Also wenn das so sein sollte, bin ich raus. Wüsste nicht wie man beim Streamen schneller Encodieren kann als Echtzeit.
    Oh je... das Forum braucht echt 'ne Ignore-Funktion... :/

    Man kann dich überhaupt nicht ernst nehmen.

    - du interpretierst Dinge in Posts, die man nicht geschrieben hat bzw. verdrehst Dinge (weil du offensichtlich nicht verstehst, was man schreibt)
    - bist nicht in der Lage Artikel zu lesen (und zu verstehen)

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Knackfrisch ()

  • Der ist nicht merklich schneller, weil sich der Encoder nur so viele Threads nutzt wie er braucht. Das wird dann auffällig wenn der gewählte Encoding Prozess nicht parallelisierbar ist, weil dann nutzt er weniger Threads.
    Aber er wird nicht schneller werden Echtzeit. Zumindest dann nicht, wenn noch was brauchbares dabei raus kommen soll.

    Man muss doch nur mal Überlegen mit was Streamer kämpfen. Die Kämpfen um Qualität, weil die Bitrate zu gering meist ist. Kommen aber weil die Bitrate so gering ist und weil es oft eine Konstante Bitrate ist einen guten Upload auf ihre Streaming Plattformen hin. Ohne das da soviel Latenz zwischen liegt.
    Und dafür braucht man nicht zwangsweise ein 4 Kerner. Sowas hab ich schon damals mit nem 2 Kerner hinbekommen. Und das in Echtzeit.

    Wenn er schneller als Echtzeit enkodieren will, muss er alle Schranken deaktivieren die bei x264 z.B. aktiv sind. Also das allerschnellste Preset wählen. Und er müsste eine relativ geringe Auflösung wählen. Dann kommt das schon hin. Daher hat der TE in seinen Benchmarks auch schnelle Presets verwendet. Die würde aber kein normaler Mensch der sich da auskennt empfehlen, wenn es sich nicht grad um Streaming handelt.

    Und natürlich spielt die Quelldatei eine entscheidene Rolle. Es ist nämlich ein Unterschied wie Tag und Nacht ob das Quellvideo das mit z.B. h264 erst aufwendig mit x Threads decodiert werden muss, während die Restlichen Threads dafür sorgen müssen das es wieder encodiert wird. Oder ob es eine Aufnahme ist die nur 1 Thread benötigt zum decodieren und ultraschnell durchgejagt werden kann, was dann halt auch mit besseren Encodiersettings verarbeitet werden kann.
    Würde man letztens nehmen, kann man auch mit besseren Encoding Settings schnellere FPS Raten beim Encodieren erwarten.

    Aber das hab ich ja schon geschrieben, und er ignoriert das gefühlt. Weiß ja nicht was ich noch schreiben soll. Oder anders gesagt weiß ich nicht was er gerne hören möchte.


    Knackfrisch schrieb:

    Man kann dich überhaupt nicht ernst nehmen.

    - du interpretierst Dinge in Posts, die man nicht geschrieben hat bzw. verdrehst Dinge (weil du offensichtlich nicht verstehst, was man schreibt)
    - bist nicht in der Lage Artikel zu lesen (und zu verstehen)
    Komm auf den Teppich mein Freund.

    A) Ich interpretiere gar nix rein, sondern lese nur das was du schreibst. Du schreibst das du mit dem Encodieren in Echtzeit unzufrieden bist. Später gibst du Beispiele die sich um das Thema Streamen handelt. Was soll ich denn deiner Meinung nach denken auf was du hinaus willst?

    B) Du bist auch nicht in der Lage Beiträge zu lesen und zu verstehen, weil ich dir gefühlt schon zig mal geschrieben habe warum und wieso das so läuft.

    Und ich weiß nicht ob ich dich ernst nehmen soll? Was möchtest du denn gerne hören? Das deine CPU scheiße ist oder ob sie gut ist? Ich weiß es langsam nicht.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Sagaras ()