x264 Streaming und Aufnahme

  • Einen schönen guten Morgen

    Kurze Erklärung zu dem was ich mache.
    Es geht darum das ich über OBS Studio gleichzeitig streamen und aufnehmen möchte.
    Hierbei wird der Stream mit eine Bitrate von 2500 kbit/s und dem Preset Very Fast bei 720p@50 vorgenommen.
    Für die Aufnahme ist vorgesehen 1152p@50.
    Da ich eine I7-3930k habe muss ich je nach Spiel, wenn ich streame und aufnehme schon drauf aufpassen das der Prozessor nicht zu 100% ausgelastet ist.
    Daher war ich eigentlich am überlegen das Preset für die Aufnahme auf Ultrafast zu stellen, beim sichten der Testaufnahme musste ich aber leider sehen das selbst bei einem CRF von 18 Blockbildung vorhanden ist.
    Ich war eigentlich davon ausgegangen das der CRF das verhindern würde indem er die Bitrate anpasst.

    Daher die frage:
    Gibt es eine Möglichkeit die CPU soweit wie es geht zu entlasten bei der Aufnahme ohne eine Blockbildung zu erzeugen?
    Würde eher ungerne auf CRF Werte von 10 und niedriger einschlagen müssen.

    Encoding settings : cabac=0 / ref=1 / deblock=0:0:0 / analyse=0:0 / me=dia / subme=0 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=0 / threads=18 / lookahead_threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=0 / weightp=0 / keyint=100 / keyint_min=10 / scenecut=0 / intra_refresh=0 / rc=crf / mbtree=0 / crf=18.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=0

    Bild:https://abload.de/img/doomcrf18uescv.png

    Man kann es seht gut unten rechts in den dunklen Bereichen sehen.

  • Preset ultrafast deaktiviert mbtree und aq, daher sind die Ergebnisse bei gleichem CRF nicht mit veryfast vergleichbar. Die Presets sind bereits möglichst optimal in Sachen Kompression/CPU-Zeit, daher wirst Du da nicht viel tricksen können.

    Kannst höchstens Dir eine Art Zwischending der Presets bauen und evtl. über AQ mehr Bits in dunkle Bereiche schieben und/oder Deblocking wieder aktivieren. Kostet aber CPU-Zeit und Wunder darf man bei limitierter Bitrate eh nicht erwarten.

    Wobei ich auf Deinem Screenshot gar nicht sehe, was Du meinst.

    Einmal editiert, zuletzt von sneaker2 (2. April 2017 um 13:59)

  • Preset ultrafast deaktiviert mbtree und aq, daher sind die Ergebnisse bei gleichem CRF nicht mit veryfast vergleichbar. Die Presets sind bereits möglichst optimal in Sachen Kompression/CPU-Zeit, daher wirst Du da nicht viel tricksen können.


    Gut ich habe halt gedacht das die schlechtere Kompression, hat ja weniger Zeit zur Verfügung, mit mehr Bitrate ausgeglichen wird, halt so das er dann den CRF erreicht.
    Wie würde es den aussehen wenn man anstatt CRF, QP nutzen würde? Oder würde das zu den gleichen Problemen führen?

    Wobei ich auf Deinem Screenshot gar nicht sehe, was Du meinst.


    Kann man sehr gut über der HP Anzeige (blauer Balken) auf dem Boden erkennen.
    Da entstehen so richtig schöne Blöcke, ich weiß es ist im ersten Moment nicht so extrem schlimm, nur wenn ich es auf Youtube hochlade, wird noch mal ein Re-Encode gemacht und dadurch wird das dann noch mehr.

    Schon probiert, eins der beiden auf eine GPU auszulagern?


    GPU ist halt so eine Sache...
    Es bringt halt schlechtere Ergebnisse bei gleicher Bitrate, wodurch für den Stream schon mal nicht zu gebrauchen ist.
    Gerade versucht die Aufnahme über AMD VCE laufen zu lassen, wie beim letzten Test, alles über 1080p startet nicht.

    2 Mal editiert, zuletzt von GelberDrache (2. April 2017 um 14:19)

  • Wie würde es den aussehen wenn man anstatt CRF, QP nutzen würde? Oder würde das zu den gleichen Problemen führen?


    Welche Probleme meinst Du? Mit begrenzter CPU-Zeit und Bitrate wirst Du halt nur suboptimale Ergebnisse erreichen. Das wird mit QP nicht anders sein. Der CRF muß runter.


  • GPU ist halt so eine Sache...
    Es bringt halt schlechtere Ergebnisse bei gleicher Bitrate, wodurch für den Stream schon mal nicht zu gebrauchen ist.
    Gerade versucht die Aufnahme über AMD VCE laufen zu lassen, wie beim letzten Test, alles über 1080p startet nicht.

    Welche Auflösung hast du denn auf dem Bildschirm? Und wieviel Bandbreite zum Streamen?

    Und schon mal lossless für die Aufnahme probiert? Da du dass sowieso weiter verarbeiten wirst, wird dass dann später noch klein gerechnet.
    Brauchst halt nur viel Plattenplatz und musst hoffen, wenn die Dateien zu groß werden, du sie noch öffnen kannst.

  • Welche Auflösung hast du denn auf dem Bildschirm? Und wieviel Bandbreite zum Streamen?


    Die Auflösung des Monitors ist bei 2560x1440, Uploud habe ich 40 MB/s und Stream wird 1280x720 sein.
    Es ist halt einfach das 2500 kbit/s über x264 besser als 3500 kbit/s mit AMD VCE aussehen,
    Der Stream ist von der CPU Auslastung her nicht das Problem, sondern eher die Aufnahme, da es 2048x1152 ist und hier dann schon bei DOOM zum Beispiel mit einem Preset von Very Fast die CPU zu 100% ausgelastet ist, nur mit der Aufnahme alleine.

    Und schon mal lossless für die Aufnahme probiert? Da du dass sowieso weiter verarbeiten wirst, wird dass dann später noch klein gerechnet.
    Brauchst halt nur viel Plattenplatz und musst hoffen, wenn die Dateien zu groß werden, du sie noch öffnen kannst.


    Es geht ja eher darum das es nachher nicht mehr weiter verarbeitet wird, sondern nur über MKVToolnix an denn Keyframes auf die richtige länge getrimmt wird.


  • Der Stream ist von der CPU Auslastung her nicht das Problem, sondern eher die Aufnahme, da es 2048x1152 ist und hier dann schon bei DOOM zum Beispiel mit einem Preset von Very Fast die CPU zu 100% ausgelastet ist, nur mit der Aufnahme alleine.


    Ist denn Doom dann Vollbild (2560x1440), oder lässt du dann Doom z.B. im Fenster mit 2048x1152 laufen und nimmst nur das Fenster auf?
    Skalieren kostet auch CPU und Quali, das solltest du irgendwie vermeiden.

  • Das Skalieren Leistung und Qualität kostest ist klar.
    Würde aber der Skalierer an sich das Problem sein, müsste es ja übers ganze Bild sein, zum Beispiel bei Bilinear hat man dann ja eine gewisse Unschärfe mit drin, als Skalierer wird Lanczos (32 Stichproben) genutzt und das soll ein neutraler sein.
    Das Problem sind ja diese Makroblöcke, die aber auch wieder nicht überall sind, es sieht einfach nicht nach einem CRF 18 Bild aus.
    Bzw wurde mir immer CRF 18 so erklärt. das es für das menschliche Auge zum Original keinen Unterschied macht, sondern man das nur noch messen kann.

  • Das Skalieren Leistung und Qualität kostest ist klar.


    Die Frage ist, wie viel Leistung? Ich kenne mich da mit OBS nicht aus, aber das solltest Du testen. Denn wenn Du die Rechenzeit an den Scaler verschwendest, die Du effizienter in das x264-Encoding stecken könntest, tust Du Dir keinen gefallen. Normalerweise würde ich dann auch ein (weiteres) Runterscalen empfehlen, aber ich nehme an, Du willst Du hohe Auflösung wegen Youtube und da Du kein zweites Mal Enkodieren willst, fällt das weg.


    Das Problem sind ja diese Makroblöcke, die aber auch wieder nicht überall sind, es sieht einfach nicht nach einem CRF 18 Bild aus.
    Bzw wurde mir immer CRF 18 so erklärt. das es für das menschliche Auge zum Original keinen Unterschied macht, sondern man das nur noch messen kann.


    Jetzt weißt Du, daß das falsch ist. -> CRF weiter runter!

  • CRF 18 sieht toll aus ... wenn der Encoder genug Zeit bekommt, nach Bereichen zu suchen, die ähnlich genug aussehen, dass dies zur Steigerung der Effizienz genutzt werden kann.

    Wenn nicht, dann nicht. Echtzeit-Codierung erlaubt fast nur Intra-Frame-Codierung (I-Slices selbst in P-Frames), die ist aber sehr ineffizient, braucht viel mehr Bitrate für ähnliche Quantisierung wie eine aufwändigere Encodierung mit Inter-Frame-Codierung mit mehr P- und B-Frames, erzeugt also riesige Videos. Und weil man das nur mit noch feinerer Quantisierung beheben kann, wird das ganze noch größer, wenn man keine Artefakte mehr sehen will. Bis schließlich die Bandbreite des Netzwerkes beim Streaming nicht mehr reicht.

    Ach ja, beim Live-Streaming über begrenzte Bandbreite kann man ja deshalb eigentlich gar kein CRF verwenden, da müsste es ABR sein. Dann wird aber die Quantisierung bei viel Action eher gröber, die Qualität sinkt.

  • CRF 18 sieht toll aus ... wenn der Encoder genug Zeit bekommt, nach Bereichen zu suchen, die ähnlich genug aussehen, dass dies zur Steigerung der Effizienz genutzt werden kann.


    Das ist es ja was mich wundert, normalerweise sieht CRF 18 super aus.
    Je schneller der Encoder arbeitet umso ineffizienter kann er nur komprimieren, das heißt um die gleiche Qualität zu erreichen braucht er mehr Bitrate.
    Das müsste doch dann aber bedeuten das CRF 18 auf Ultrafast wie CRF 18 mit Very Fast aussehen müsste, nur das die Dateigröße größer sein müsste.
    Aber noch mal zum Verständnis, CRF ist ein schwankender QP der für jeden Frame einzelt gewählt wird, nach gewissen Algorithmen, abhängig davon wie sehr das menschliche Auge das mitbekommen würde, oder?

    Ach ja, beim Live-Streaming über begrenzte Bandbreite kann man ja deshalb eigentlich gar kein CRF verwenden, da müsste es ABR sein. Dann wird aber die Quantisierung bei viel Action eher gröber, die Qualität sinkt.


    Der CRF wird auch nicht beim Streamen genutzt, sondern beim Aufnehmen.

  • Je schneller der Encoder arbeitet umso ineffizienter kann er nur komprimieren, das heißt um die gleiche Qualität zu erreichen braucht er mehr Bitrate.
    Das müsste doch dann aber bedeuten das CRF 18 auf Ultrafast wie CRF 18 mit Very Fast aussehen müsste, nur das die Dateigröße größer sein müsste.


    Falsch. Der Irrtum ist, zu glauben, daß CRF 18 immer - also z.B. mit jedem Preset - gleich gut aussieht. Wie Du jetzt selbst gesehen hast, ist das nicht der Fall. Aus dieser falschen Annahme hast Du folgerichtig einen falschen Schluß gezogen.

    Aber noch mal zum Verständnis, CRF ist ein schwankender QP der für jeden Frame einzelt gewählt wird, nach gewissen Algorithmen, abhängig davon wie sehr das menschliche Auge das mitbekommen würde, oder?


    Nicht immer nur pro Frame, auch pro Block. Das ist das Ziel. Wird das erreicht? Nur eingeschränkt Und mit mbtree an/aus ändert sich eh alles.

  • Ok das machst das dann schon alles für mich verständlich, also hier auf jeden mal mal zum Beispiel schauen wie die Belastung ist, wenn mbtree an ist.
    Am Anfang wurde eine Liste der Parameter der verschiedenen Presets gepostet, das Problem ist für mich das ich bei den meisten Werten einfach 0,00... Ahnung habe was die genau verursachen.
    Welche der Werte die bei Ultrafast ausgeschaltet werden (zum Beispiel mbtree) wirken sich nicht nur auf die Komprimierbarkeit aus (ich glaub CABAC ist im großen und ganzen nur für Komprimierbarkeit), sondern auch auf die Qualität?

  • wirken sich nicht nur auf die Komprimierbarkeit aus (ich glaub CABAC ist im großen und ganzen nur für Komprimierbarkeit), sondern auch auf die Qualität?


    Spielt doch überhaupt keine Rolle. Das sind alles Parameter, die die Komprimierbarkeit beinflussen. Wenn die Qualität danach nicht mehr Deinen Vorstellungen entspricht, dreh am CRF-Wert!

  • Spielt doch überhaupt keine Rolle. Das sind alles Parameter, die die Komprimierbarkeit beinflussen. Wenn die Qualität danach nicht mehr Deinen Vorstellungen entspricht, dreh am CRF-Wert!


    Die Aussage finde ich etwas schade.
    CRF 18 sieht ja eigentlich sehr gut aus...
    So wie ich das bei mbtree verstanden habe wirkt sich das darauf aus welcher qp Wert genommen wird, das heiß wenn es ausgeschaltet ist werden bei schnellen Bewegungen zum Beispiel höhere Werte genommen, was dann die Qualität in schnellen Bewegungen reduziert.
    Dementsprechend wäre es für mich nicht schlecht solche Sache zu wissen um ein dementsprechendes angepasstest Preset mir zu erstellen.

    Was ich gerade bemerkt habe...
    Ultrafast: Wollte ich über mbtree=1 es aktivieren, ging aber nicht
    Very Fast: Wollte ich über mbtree=0 es deaktivieren, ging

    Ist das bei Ultrafast normal das man Parameter die über das Preset deaktiviert sind, nicht wieder aktivieren kann?

  • Nein, aber mbtree braucht i.d.R. den Lookahead, der in Preset Ultrafast ebenfalls fehlt. Also vermutlich über mbtree=1:rc-lookahead=10

    CRF 18 sieht ja eigentlich sehr gut aus...


    Das ist doch völlig egal. Warum ist Dir die "18" so wichtig? Ist das der Geburtstag Deiner Freundin? Deine Glückszahl? Gibt es irgendeinen rationalen Grund, warum es unbedingt die 18 sein muß?

  • Es ist doch vollkommen egal ob es CRF 18, 23 oder 10 ist.
    Ich möchte verstehen warum im Standbild oder nicht so schnellen Bewegungen alles gut aussieht, aber dann in schnellen Bewegungen der CRF den QP Wert für die einzelnen Blöcke so extrem hoch zieht das es Makroblockbildung gibt.
    Und das hängt ja dann mit den Parametern zusammen.

  • Das wird eben unter anderem daran liegen, dass bei schnellsten Presets auch der Suchradius für Übereinstimmungen stark verringert wird. Nur bei sehr kurzen/langsamen Bewegungen kann noch erkannt werden, dass es Ähnlichkeiten in aufeinander folgenden Frames gibt (was wenigstens in P-Slices noch mit Bewegungsvektoren ausgenutzt werden kann: Jede halbwegs brauchbare Differenz zu einem vorherigen Original ist effizienter zu codieren, als alles ohne jeden Vergleich komplett neu zu codieren). Die Kompressionsartefakte in Differenzen sind weniger auffällig als selbige in der direkten Encodierung, da sie auf eine kleinere Größenordnung wirken.

  • Ok, verstehe. Lies mal das. Bei Preset Ultrafast (kein mbtree, kein aq) kommt also --qcomp zum Tragen (wobei das auch mit mbtree ähnlich wirkt). Wenn das vom Standardwert 0.6 erhöht wird, werden die QPs nicht mehr so stark schwanken. Ähnliches gilt für --ipratio, nur umgekehrt (--pbratio ohne b frames irrelevant). Könntest also versuchen an diesen Werten zu drehen. Dazu vielleicht noch das Deblocking wieder einschalten. Ob das tatsächlich bei dem Spiel helfen wird ... ich weiß es nicht. CRF ist und bleibt die Hauptstellschraube, was Qualität angeht. Ich würde da keine Wunder erwarten.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!