Vergiss l nnedi3ocl, hab bis dato noch kein Szenario entdeckt, bei dem der:
a. an sich schon schneller wäre als wenn ich die normale Version nutze
b. die CPU so stark entlasten würde, dass ich ein schnelleres Ergebnis erhalten würde als wenn ich nur die CPU nutze
i.d.R. ist es bei mir (i7 4770k + Geforce GTX 660 ti) sogar so, dass ich mit 'nur CPU' schneller zum Ziel komme.
-> Mit AVSMeter kann man die Geschwindigkeit von Scripten testen.
Presets ändern mehrere Basis-Parameter gemeinsam in einem sinnvollen Verhältnis zueinander. Die Encodier-Geschwindigkeit ändert sich dadurch mittelbar nach dem Aufwand, mit dem der Encoder nach Redundanzen (ähnlichen und durch Inter-Codierung im Code verkleinerbaren Videobereichen) sucht. Selbstverständlich wird der Encoder häufiger Intra-Codierung nutzen müssen, wenn er bei wenig Suchaufwand häufiger keine geeigneten Kandidaten für Inter-Codierung findet. Die Qualität verschlechtert das aber nur dann, wenn man dabei die Bitrate begrenzt. Bei einer qualitätsorientierten Encodierung (CRF) wird das Ergebnis einfach nur wahrscheinlich größer, aber nicht grundsätzlich schlechter. Im Gegenteil: Inter-Codierung hat eher die Tendenz, Details zu reduzieren.
intra ~ für sich allein, ohne Abhängigkeit zu anderen Frame-Inhalten, wie Einzelbild
inter ~ im Zusammenhang, Unterschiede zu anderen Frame-Inhalten, Bewegungsschätzung
Wenn man ohnehin vorhat, einen recht niedrigen CRF (~15..18) zu verwenden, der schon nahe an der "visuellen Transparenz" ist (also vom Original kaum noch zu unterscheiden), und die Größe des Ergebnisses keine erhebliche Rolle spielt, dann dürfte es auch kaum einen Grund geben, langsamer als "--preset fast" zu arbeiten; schneller als Preset "faster" wäre dann aber schon wieder fast Platzverschwendung wegen zu geringer Komplexität.
Wer Platz sparen muss und einen CRF über 21 wählt, der wird sicher lieber etwas aufwändiger rechnen lassen; aber langsamere Presets als "slow" können zu Inkompatibilitäten mit Hardware-Playern führen, für die man dann zusätzliche begrenzende Parameter verwenden würde.
Das sind aber meine persönlichen Einschätzungen. Andere haben vielleicht abweichende Erfahrunge gemacht. Allgemein gilt aber: Wenn die Qualität zu schlecht ist, dann erhöhe lieber die Bitrate, wenn möglich, als mit langsameren Presets mehr herausquetschen zu wollen. Nicht möglich ist das Erhöhen der Bitrate nur bei vorgegebener Zielgröße, da sind langsame Presets legitim (aber jenseits von "slower" auch schon Verzweiflung).
Man kann sicherlich nicht sagen, dass das Preset "faster" generell für jedes Material die kleinsten Ergebnisse bringt; nur für dieses Testvideo bei diesen Parametern.
Beachte auch, dass x264 m.o.w. "progressiv" encodiert, also etwas langsamer arbeitet, je kleiner der CRF ist (es werden "mehr Details gesammelt, das dauert länger", stark vereinfacht).
Unendliche GOPs sind auch nicht zu empfehlen, wenn die Videodaten auf störanfälligem Weg übermittelt werden. Ein falsches Bit, das einen Decodierfehler auslöst, und im schlimmsten Fall setzt der Bildfehler sich bis ans Ende des Videos fort, während YouTube das hochgeladene Video konvertiert. Sicher ist das Risiko gering, aber es wäre schon schade, wenn das Hochladen von Gigabytes nachträglich umsonst gewesen wäre.
Völlig anders sicher nicht, es wird auch systematische Ursachen für die geringen Differenzen geben. Aber die Verhältnisse könnten sich schon verschieben.
Aber bis das nicht jemand ausführlich testet, wird man das nicht mit Sicherheit wissen.
Aber bis das nicht jemand ausführlich testet, wird man das nicht mit Sicherheit wissen.
Wie würde man sowas denn ausführlich testen? 
Mit Batch-Datei, FOR-Schleifen, Loglevel- und CSV-Parameter... x265 ist doch ein Kommandozeilen-Encoder, also hervorragend automatisierbar. Bei mir läuft aber schon was... 
Äh, ups, x264 wolltest du. Na ja, auch da gibt es Möglichkeiten, das wichtigste zu protokollieren. Zur Not mit FIND-Filter.
Nun ja, Grundlagenwissen über CMD und Batch hilft da schon... Nur ein kleines Beispiel:
FOR %%a IN (ultrafast superfast veryfast faster fast medium slow slower veryslow placebo) DO x264 --preset %%a (...)In einer Schleife jeweils x264 mit allen Preset-Stufen aufrufen (in Batch-Dateien wird das Prozentzeichen der Lauf-Variable verdoppelt, im Vergleich zum direkten Aufruf in der Eingabezeile).
Wer dann auch noch alle Presets mehrmals mit unterschiedlichen CRF testen will, verschachtelt zwei solcher Schleifen.
Und die Dauer des Encodings will man ja auch noch aufzeichnen. Leider hat x264 keine CSV-Ausgabe wie x265. Wenn man das nicht aus der Konsolenausgabe von x264 herausfiltert, dann hilft vielleicht nur ein zusätzlicher Benchmark-Logger (man wird ja möglichst alles über Nacht laufen lassen wollen, anstatt daneben zu sitzen und die Zeiten vom Bildschirm abzuschreiben).
Unendliche GOPs sind auch nicht zu empfehlen, wenn die Videodaten auf störanfälligem Weg übermittelt werden. Ein falsches Bit, das einen Decodierfehler auslöst, und im schlimmsten Fall setzt der Bildfehler sich bis ans Ende des Videos fort, während YouTube das hochgeladene Video konvertiert. Sicher ist das Risiko gering, aber es wäre schon schade, wenn das Hochladen von Gigabytes nachträglich umsonst gewesen wäre.
Einfach kein WLAN nehmen, dann passiert auch nix. Hat youtube noch nie gestört. Die encodierens ja auch eh um.
Im Doom9 forum stand aber auch geschrieben das trotz CRF die schnelleren Presets weniger Qualität liefern^^ Glaub das stand sogar auch mal hier, hm 
Kann ich mich jetzt nicht daran erinnern; ist aber auch im Bereich des Möglichen. Dafür sprächen eventuell, dass bei aufwändigerer Suche nach bester Übereinstimmung (auch in größerem Umkreis) auch wirklich bessere Übereinstimmungen mit minimaler Differenz gefunden werden, sowie dass die Inter-Codierung der Differenz möglicherweise mit höherer Genauigkeit erfolgt, weil Unterschiede ja einen geringeren Werteumfang haben.
Letztendlich sollte es aber wenig ausmachen. CRF versucht ja abzusichern, dass der Qualitätsverlust unter einem Grenzwert liegt, und bei kleinem CRF ist der Grenzwert auch hinreichend niedrig. Ob man also CRF 15 mit langsamem oder schnellem Preset erzeugt, in jedem Fall sollte "visuelle Transparenz" erreicht werden, nur mit mehr oder weniger Aufwand, und kleinerem oder größerem Ergebnis. Oder?!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!