OBS Studio - Mit NVENC effizient aufnehmen

Unterstütze das Forum mit einem kleinen Beitrag und sichere Fortbestand und Weiterentwicklung: Jetzt Unterstützer werden!
  • Diese Anleitung bezieht sich auf eine Aufnahmemethode die De-M-oN immer wieder für Capture Karten mit FFMPEG Empfohlen hat, die mittlerweile durch ein Drittanbieter Plugin auch in OBS Studio mit NVIDIA Karten möglich ist und bei mir sehr gute Ergebnisse erzielt. Dies ist keine Anleitung für die Verwendung oder Standardkonfiguration von OBS Studio.


    Im wesentlichen geht es darum, dass man neben einen festen Quantizer in NVENC auch einen minimalen und maximalen Quantizer angeben kann, wodurch z.B dunkle Szenen in Aufnahmen viel bessere Qualität erzielen, ohne wirklich viel mehr Performance oder Speicher zu kosten (Da diese Szenen sehr gut komprimierbar sind). Dazu zitiere ich am besten einmal De-M-oN, da dieser sich um einiges besser mit encoding auskennt:

    Das Problem ist halt das OBS keine qmin, qmax Kombo anbietet wie ffmpeg es tut.

    Dadurch leidet Dunkelheit relativ schnell, weil die ja dann auch mit 16 quantisiert wird. qmin würde dann die Dunkelheit kleinere Quantizer geben (zumal die eh gut komprimierbar ist) und dann würde man sogar mit CQP19 auskommen, bissl puffer für re-encode schadet aber nicht und 16 ist dann schon ein sehr guter Weg.

    Aber da OBS diese kombo nicht hat, würd ich bei OBS eher zu CQP10 raten. Dann brauchts bei 4k/UHD aber schon recht gute Schreibrate.

    Zusammengefasst

    Mit OBS-Studio hat man also das Problem, dass man nur einen festen Quantizer angeben kann (Wenn man für die Aufnahme: CQP verwendet) z.B CQP 16

    Kleine Quantizer z.B QCP 1 = Hohe Qualität/Bitrate

    Großer Quantizer z.B QCP 25 = Niedrige Qualität/Bitrate

    In FFMPEG wird dies durch qmin und qmax gelöst, wodurch ein dynamischer Quantizer erreicht wird, der also nicht nur einen festen CQP Wert verwendet.

    Lösung durch StreamFX Plugin

    Damit wir jetzt auch diese qmin und qmax Kombination für einen dynmaischen Quantizer in OBS-Studio verwenden können, müssen wir uns das Plugin StreamFX, welches weitere Encoder für OBS enthält, von Xaymar (Ein deutscher Entwickler, der sehr aktiv an der Entwicklung von OBS-Studio beteiligt ist) herunterladen. Zuvor war StreamFX in zwei unterschiedlichen Plugins aufgesplittet: Stream effekte und FFMPEG Encoder. Zur Vereinfachung von Updates wurde beides in ein Projekt zusammengeführt.

    StreamFX download: https://github.com/Xaymar/obs-StreamFX/releases/latest


    Für den Download nach ganz unten unter "Assets" scrollen und die Version mit den Dateinamen ".exe" herunterladen.

    Das Setup kann normal ausgeführt werden und installiert das Plugin StreamFX in eure aktuelle OBS Studio Version. Das Plugin kann über die Windows Systemsteuerung auch einfach wieder deinstalliert werden.

    OBS Studio Konfiguration

    Für die Konfiguration des dynmaischen Quantizer geht ihr als erstes in OBS Studio oben links auf:

    Datei > Einstellungen > Ausgabe > Ausgabemodus: Erweitert > Reiter: Aufnahme.

    Oben könnt ihr eure Standardeinstellung wie den Pfad, Format und Audiotracks definieren.


    Wichtig ist, dass Ihr als Kodierer folgendes vom StreamFX Plugin auswählt:

    H.264/AVC Nvidia NVENC

    StreamFX Konfiguration

    Sobald der Kodierer ausgewählt wurde, kann in den Aufnahmeeinstellungen vieles für die H.264 Nvidia NVENC Aufnahme konfiguriert werden. Die Konfiguration wird auf eine hohe Performance mit den dynamischen Quantizer konfiguriert.

    Einstellungen die nicht genannt werden, sind auf den Standard belassen, befinden sich aber noch mal unter den Button "Alle Einstellungen":

    • Preset: High Performance
    • Profile: Main
    • Mode: Variable Bitrate
    • Buffer Size: 0 kbit/s
    • Target Bitrate: 0 kbit/s
    • Maximum Bitrate: 0 kbit/s
    • Target Quality: 0,00
    • Minimum Quality: -1
    • Maximium Quality: -1
    • Interval Type: Seconds
    • Interval: 2,00 seconds
    • Custom Settings: -b=0 -maxrate=0 -bufsize=0 -qmin=1 -qmax=16

    Am wichtigsten sind die Custom Settings, welche FFMPEG Parameter zulassen und Einstellungen in der Graphischen Oberfläche überschreiben. Hier definieren wir also den dynmaischen Quantizer, welcher für euren Bedarf angepasst werden kann. Es sollte nur -qmin und -qmax angepasst werden, da die anderen Werte in den genannten "Custom Settings" für die Methode auf 0 stehen müssen.

    Empfohlene qmin und qmax Einstellungen

    -qmin=1 und -qmax=16 wird für eine Aufnahme in [email protected] empfohlen, da die Bitraten für normale Festplatten tragbar sein sollten. Falls die Festplattengeschwindigkeit nicht ausreichen sollte, muss der -qmax Wert angehoben werden. Hier aber am besten nicht über 20 gehen, da die Qualität sonst leiden könnte (Am besten selber testen!).


    Ich selber hatte mit -qmin=1 in dem Spiel Apex Legends Probleme, wodurch die Aufnahme ab und zu gehangen hat. Deswegen verwende ich für Apex Legends einen -qmin Wert von 10, wodurch bei meinen Setup keine Probleme aufkommen. Warum der -qmin Wert in Apex Probleme macht, kann ich leider nicht beantworten.


    Als zusätzlichen Test habe ich eine Aufnahme mit einen festen CQP Wert von 20 aufgenommen und danach eine Aufnahme mit den StreamFX Plugin -qmin 1 -qmax 20 gestartet.

    In der Aufnahme bin ich in einen dunklen Bereich gelaufen, um zu überprüfen wie sich die Bitraten verhalten:


    Aufnahme fester CQP Wert 20

    Offener Bereich: Ungefähr 50000 kbit/s

    Dunkler Bereich: Ungefähr 9000 kbit/s


    Aufnahme -qmin 1 -qmax 20:

    Offener Bereich: Ungefähr 50000 kbit/s

    Dunkler Bereich: Ungefähr 20000 kbit/s


    Wie man anhand der Beispiele sieht, bleiben die "schwer" (Offenen) komprimierbaren Bereiche gleich von der Bitrate, aber Szenen die einfacher (Dunkle Bereiche) zu komprimieren sind, genießen mit der -qmin und -qmax Kombination mehr Bitrate.

  • In deiner Liste gibt es Target Quality.

    Dürfte CRF sein. Bei H.264 geht CRF normalerweise auch bei NVEnc.

    Bei H.265 war es buggy, wobei es in TMPGEnc 7 und einer RTX Grafikkarte nun auch bei H.265 korrekt zu klappen scheint.


    Ich habe meine Aufnahme in:


    Code
    ffmpeg -rtbufsize 2147M -f dshow -framerate 60 -thread_queue_size 1024 -probesize 10M -pixel_format bgr24 -i video="Datapath VisionSC-DP2 Video 01":audio="Wave (ASUS Xonar HDAV Audio Device)" -f dshow -thread_queue_size 64 -i audio="Line (AudioBox 22VSL)" -map 0 -map 1 -vcodec h264_nvenc -pix_fmt yuv420p -rc:v vbr -b:v 0 -qmin 1 -qmax 16 -preset hp -acodec pcm_s16le -audio_buffer_size 80 "%fullpath%\%filename%.mkv"
    PAUSE

    Bei 2560x1600.

    Er scheint aber trotzdem nicht tiefer als QP 9 zu gehen. Keine Ahnung wie das bei deinem Plugin ist.

  • In deiner Liste gibt es Target Quality.

    Dürfte CRF sein. Bei H.264 geht CRF normalerweise auch bei NVEnc.

    Bei H.265 war es buggy, wobei es in TMPGEnc 7 und einer RTX Grafikkarte nun auch bei H.265 korrekt zu klappen scheint.

    Muss man für CRF noch etwas zusätzlich Konfigurieren? Wie z.B wieder die folgenden Werte auf 0: -b=0 -maxrate=0 -bufsize=0


    Er scheint aber trotzdem nicht tiefer als QP 9 zu gehen. Keine Ahnung wie das bei deinem Plugin ist.

    Leider hat man im Gegensatz zu FFMPEG in OBS keine genaue Anzeige welcher QP verwendet wird, was das Testen schwer macht.

  • Grade mal getestet, indem ich die Target Quality auf 16 und danach auf 10 geschaltet habe.

    Qmin und Qmax habe ich entfernt.


    Leider geht die Bitrate nicht über 40mbits.

    Wenn ich die Target Quality auf 70 setzte geht Sie aber auf 5mbits runter. Scheint also noch irgendwas nach oben hin zu blockieren.

  • Kommt ganz drauf an wie das Plugin und OBS an den Encoder letztendlich senden.

    Zur Sicherheit kann man ja maxrate und bufsize auf 0 setzen.


    Alles andere ist einfach nur für maximale Performance, da ich mein Video nach der Aufnahme eh neu encodieren muss

    Sollte die Aufnahme direkt auf Youtube dürfen, könnte man natürlich auch in CRF19 aufnehmen und Qualitätssettings verwenden. Aber wenn ich eh neu codieren muss kann ich ja den Video Encoder der Grafikkarte entlasten.

    Leider hat man im Gegensatz zu FFMPEG in OBS keine genaue Anzeige welcher QP verwendet wird, was das Testen schwer macht.

    Kann man allerhöchstens eine Videodatei als Quelle nehmen und die anschließenden Dateigrößen vergleichen (aber OBS kann wahrscheinlich nicht erst Aufnahme beginn wenn die Videodateiquelle spielt und aufhören wenn sie fertig ist, was ffmpeg ja kann.

    Aber wenn paar sekunden mehr schwarzbild beim OBS Video mit drin sind, sollte es trotzdem noch auffallen hoffentlich^^

  • Moin allerseits, der ersteller des StreamFX Plugins hier! Sorry für den Nekropost, ich hatte den thread einfach nicht vorher gefunden - tauchte nicht als referrer auf.


    Erstmal finde ich das echt super, dass das plugin auch von Let's Playern verwendet wird - es war hauptsächlich für Streamer gedacht, aber Let's Play geht ja heutzutage auch live. Leider trauen sich sehr wenige mir E-Mails zu schicken in dem diese mit der Nutzung des Plugins prahlen, was echt schade ist - jeder Entwickler will immer gerne sehen für was seine Kreationen eingesetzt werden.


    Zu den einstellungen selbst habe ich etwas Kritik:

    • Das "High Performance" preset setzt nicht alle nutzlosen Funktionen für CQP/VQP außer kraft. Idealerweise sollte hier "Lossless High Performance" verwendet werden, da die bandbreite sehr heftig variiert.
      • NVIDIA hat dies korrigiert mit der neuen SDK version, diese ist allerdings noch nicht in OBS Studio verfügbar - vielleicht sehen wir diese Ende 2020 oder Mitte 2021.
    • Idealerweise sollte das H.264 Profil immer auf High bleiben, gerade bei CQP/VQP.
    • Nicht vergessen alle Optionen die nicht genutzt werden auszustellen.
      • "Look Ahead" auf 0 frames.
      • "Adaptive I-Frames" und "... B-Frames" auf "Disabled".
      • "Spatial Adaptive Quantization" und "Temporal Adaptive Quantization" auf "Disabled".
      • "Maximum B-Frames" auf 0 - diese kostet eine Menge CUDA Leistung!

    Und De-M-oN hat hier korrekt identifiziert das NVENC ab Pascal (6. Generation, Turing und Ampere sind 7. Generation) einen CRF-ähnlichen Modus unterstützt. Ähnlich wie in x264 ist dieser mit seiner Qualität und Effektivität abhängig von den Einstellungen. Aus diesem Grund kann ich nur meinen Blog post "The Art of encoding with NVIDIA Turing NVENC" empfehlen, welcher euch auf ein Qualitätslevel bringt das x264 slower ähnlich ist und manchmal sogar besser als x264 veryslow.


    Dort muss man nur den "Mode" auf "Variable Bitrate" ändert, sowohl "Target Bitrate" als auch "Maximum Bitrate" auf 0 setzen, die "Buffer Size" auf entweder 0 oder einen hohen wert, und dann die "Target Quality" auf einen Prozentwert anpassen der euch gefällt. Leider war ich beim programmieren ein Idiot und habe den slider so programmiert das höhere Werte weniger qualität ergeben - nur das beste von Kaffee-gesteuerten Entwicklern!


    Persönlich habe ich diese CRF-ähnlichen settings für Stream archive, und nutze folgende FFmpeg-ähnlichen Einstellungen: -preset hq -profile high -rc vbr_hq -rc-lookahead 32 -2pass 1 -no-scenecut 0 -forced-idr 0 -spatial-aq 1 -aq-strength 8 -temporal-aq 1 -bf 4 -b_ref_mode none -b 0 -minrate 0 -maxrate 0 -cq 15 -qmin 0 -qmax 51. Als StreamFX encoder einstellungen wären das:

    • "Preset" "High Quality"
    • "Profile" "High"
    • "Level" "Automatic"
    • "Mode" "High Quality Constant Bitrate"
    • "Two Pass" "Enabled"
    • "Look Ahead" "32 frames" (24 frames geht auch, sollte auf 1080p60 zweieinhalb encodes ermöglichen)
    • "Adaptive I-Frames" "Enabled"
    • "Adaptive B-Frames" "Enabled"
    • "Buffer Size" "0 kbit"
    • "Target Bitrate" "0 kbit/s"
    • "Maximum Bitrate" "0 kbit/s"
    • "Target Quality" "28.00" (<=20 ist indistinguishable, >45 ist sichtbar blockig)
    • "Minimum QP" "0"
    • "Maximum QP" "51"
    • "Spatial Adaptive Quantization" "Enabled"
    • "Spatial Adaptive Quantization Strength" "8"
    • "Temporal Adaptive Quantization" "Enabled"
    • "Maximum B-Frames" "4 frames" (In spielen mit viel Post-Processing und schneller Bewegung sind 3 frames besser. APEX Legends, Forza 4 Horizon, Final Fantasy XIV, usw. sind da gute Beispiele)
    • "B-Frame Reference Mode" "None"/"Disabled"
    • "Custom Settings" "-forced-idr 0"
  • -cq ist ja 'nen richtiger CRF. Man muss aber aufpassen das man das H.264 Level nicht zu tief ansetzt. Vor allem bei H.265 NVEnc wichtig, da Level 5.1 ohne High Tier auf 40 Mbit begrenzt. Das sprengt dann den Sinn von CRF.


    Ist nämlich exakt das, was hier auch passiert ist

    Leider geht die Bitrate nicht über 40mbits.

    ______________________________________

    Ich würde nicht über 20 gehen bei H.264.

    Bei H.265 geht auch 25 noch.

    28 wär mir bisschen zu viel.


    -preset p7

    aktiviert eig. schon alle qualitätsoptionen. Da braucht man sich eig. nicht so eine lange commandline machen.

    und dann die "Target Quality" auf einen Prozentwert anpassen der euch gefällt. Leider war ich beim programmieren ein Idiot und habe den slider so programmiert das höhere Werte weniger qualität ergeben - nur das beste von Kaffee-gesteuerten Entwicklern!

    Das ist doch aber richtig?

    Quantisierung 0 = Lossless und je höher der Wert, desto mehr Kompression.

    Was ist daran denn falsch? CRF / CQP = kleinere Werte = bessere Qualität. Ist exakt richtig so.

    "Mode" "High Quality Constant Bitrate"

    Du meintest bestimmt eher Constant Rate Factor?



    Zitat


    -b_adapt <boolean> E..V...... When lookahead is enabled, set this to 0 to disable adaptive B-frame decision (default true)

    Warum hast du adaptive b-frames und lookahead kombiniert?

    Zitat


    -no-scenecut <boolean> E..V...... When lookahead is enabled, set this to 1 to disable adaptive I-frame insertion at scene cuts (default false)

    Warum ist scenecut auf 0?

    "Maximum B-Frames" "4 frames" (In spielen mit viel Post-Processing und schneller Bewegung sind 3 frames besser. APEX Legends, Forza 4 Horizon, Final Fantasy XIV, usw. sind da gute Beispiele)

    Der Encoder nimmt sich das was er braucht. Du gibst nur das Maximum an. Vorausgesetzt adaptive b-frames ist aktiviert. Da du aber ebenso lookahead nutzt, wird sich adaptive b-frames wahrscheinlich deaktivieren und dann wäre deine Aussage korrekt.

    Warum hast b_ref_mode aus?

  • -preset p7

    aktiviert eig. schon alle qualitätsoptionen. Da braucht man sich eig. nicht so eine lange commandline machen.

    Ja, das ist technisch korrekt. Dennoch kann höhere Qualität mit einzelnen Parameter-tuning erreicht werden, und vorallem reproduzierbare Ergebnisse über alle möglichen Systeme. Man sollte hier auch dann "-tune hq" angeben, auch wenn dies der standard ist - für komplett lossless gibt's sogar ein eigenes tuning.

    Das ist doch aber richtig?

    Quantisierung 0 = Lossless und je höher der Wert, desto mehr Kompression.

    Was ist daran denn falsch? CRF / CQP = kleinere Werte = bessere Qualität. Ist exakt richtig so.

    Nein, ist es leider nicht. Die Option nennt sich "Target Quality", nicht "Target Quantizer"/"Target Quantization Parameter". Somit ist es rein von der UX her vollkommen falsch das niedrigere Werte bessere Qualität ergeben - vorallem da der slider von 0.00 bis 100.00 geht, und somit in Prozent angegeben ist.

    Du meintest bestimmt eher Constant Rate Factor?

    Nein, "Constant Rate Factor" gibt es bei h264_nvenc und hevc_nvenc nicht. Die Einstellungen die ich genannt habe sind für die FFmpeg NVENC integration vom StreamFX plugin. Ab FFmpeg 4.2.4/4.3.x/4.4+ muss dies allerdings auf "Variable Bitrate" angepasst werden, da "vbr_hq" nicht mehr funktioniert.

    Warum hast b_ref_mode aus?

    Ist in FFmpeg 4.2.2 kaputt und führt zu aufnahmen die kaputt sind in OBS Studio. Ab 4.3.1/4.2.4 ist dies behoben worden und kann auf "middle" (H.264/AVC) oder "each" (H.265/HEVC) gesetzt werden.

    Warum hast du adaptive b-frames und lookahead kombiniert?

    Warum ist scenecut auf 0?

    "-no-scenecut 0" aktiviert Adaptive I-Frames, das einfügen von I-Frames wenn diese besser wären für die massive Änderung. "-b_adapt 1" aktiviert Adaptive B-Frames, das einfügen von mehr oder weniger B-Frames als das limit. Beide dieser Optionen brauchen "-rc-lookahead" mit einem wert größer als 0.


    Der Encoder nimmt sich das was er braucht. Du gibst nur das Maximum an. Vorausgesetzt adaptive b-frames ist aktiviert. Da du aber ebenso lookahead nutzt, wird sich adaptive b-frames wahrscheinlich deaktivieren und dann wäre deine Aussage korrekt.

    Leider ist das nur teilweise korrekt:


    Adaptive I-Frames und Adaptive B-Frames funktionieren nur mit Look Ahead und sind vollkommen inaktiv sofern kein Look Ahead erlaubt ist. Standardmäßig werden beide Features aktiviert sofern Look Ahead aktiviert ist. Dies kannst du der "nvEncoderAPI.h" und Dokumentation entnehmen.


    Auch das mit dem "nur das Maximum" ist auch nur teilweise korrekt. Wenn dies "libx264" wäre, hättest du (mit einigen Ausnahmen) recht, aber leider ist das hier NVENC. Dort hängt das vollkommen ab von der NVENC generation, und von den Einstellungen.


    Mit "-rc-lookahead 0 -bf 3" bekommst du immer exakt drei B-Frames reingedrückt, auch wenn diese komplette Zeit- und Bitratenverschwendung sind. Erneut kann ich dich hier nur auf die Video Codec SDK verweisen, denn dort ist dies erklärt: "... Specifies the GOP pattern as follows: \p frameIntervalP = 0: I, 1: IPP, 2: IBP, 3: IBBP ...".


    Siehe auch diese fast 5 GiB große Datenbank an VMAF, SSIM, MS-SSIM und PSNR vergleichen zwischen original und kodierten videos. Inzwischen arbeite ich an neuen Daten für die neue SDK version, weil die alten presets ("slow" und so) bald nicht mehr funktionieren.

    Einmal editiert, zuletzt von Xaymar () aus folgendem Grund: Forumeditor kaputtgegangen, zeit zu editieren.

  • Ja, das ist technisch korrekt. Dennoch kann höhere Qualität mit einzelnen Parameter-tuning erreicht werden, und vorallem reproduzierbare Ergebnisse über alle möglichen Systeme

    Hmm bist du da sicher? Weil P7 ist ja nun deutlich intensiver als slow.

    Die fps mit dem preset ist auch ziemlich langsam. Ist denn irgendwo gelistet was die presets beinhalten? Weil bei x264 ist ja angegeben was die presets an settings beinhalten.

    Nein, ist es leider nicht. Die Option nennt sich "Target Quality", nicht "Target Quantizer"/"Target Quantization Parameter". Somit ist es rein von der UX her vollkommen falsch das niedrigere Werte bessere Qualität ergeben - vorallem da der slider von 0.00 bis 100.00 geht, und somit in Prozent angegeben ist.

    Achso bei der einfachen Ausgabe meinst du? weil bei der erweitert gibt man ja direkt den CQP Wert an.

    Naja ich bin kein Fan von Qualität %, weil dann muss man immer erst ausrechnen welcher CRF oder CQP Wert das entspricht :D


    Nein, "Constant Rate Factor" gibt es bei h264_nvenc und hevc_nvenc nicht

    Doch das gibt es.

    der

    -cq

    switch. Da brauchts auch dann kein qmin, qmax. Aber bei H.265 NVEnc ist es sehr wichtig das man das Level auf 6.1 high tier stellt. Bei nur z.B. 5.1 würde es auf 40 Mbit limitiert sein. Und das würden den Sinn von CRF ja sprengen.


    Code
    -cq <float> E..V..... Set target quality level (0 to 51, 0 means automatic) for constant quality mode in VBR rate control (from 0 to 51) (default 0)

    Und das funktioniert bei mir auch einwandfrei - sofern ich eben das Level beachte.

    Ist in FFmpeg 4.2.2 kaputt und führt zu aufnahmen die kaputt sind in OBS Studio. Ab 4.3.1/4.2.4 ist dies behoben worden und kann auf "middle" (H.264/AVC) oder "each" (H.265/HEVC) gesetzt werden.


    "-no-scenecut 0" aktiviert Adaptive I-Frames, das einfügen von I-Frames wenn diese besser wären für die massive Änderung. "-b_adapt 1" aktiviert Adaptive B-Frames, das einfügen von mehr oder weniger B-Frames als das limit. Beide dieser Optionen brauchen "-rc-lookahead" mit einem wert größer als 0.

    Ich erwähnte diese Sachen, weil ffmpeg ja sagte die dann entsprechend so einzustellen. Das wird ja dann einen Grund haben warum das so gesagt wird? Weil normalerweise heißt das, das diese nicht zusammenarbeiten können, wenn man für eine Option eine andere ausschalten soll. Oder müsste ffmpeg dann die encoderhilfe aktualisieren? Ich habe ja nur zitiert was in ffmpeg stand zu den optionen.

    "-b_adapt 1" aktiviert Adaptive B-Frames, das einfügen von mehr oder weniger B-Frames als das limit

    Innerhalb von max b-frames. Drüber ist auch bei adaptiven b-frames nicht erlaubt. Aber mit adaptiven b-frames definierst du mit max b-frames nur das maximum, so das man keine Angst haben muss, dort mehr einzustellen.


    Das "High Performance" preset setzt nicht alle nutzlosen Funktionen für CQP/VQP außer kraft. Idealerweise sollte hier "Lossless High Performance" verwendet werden, da die bandbreite sehr heftig variiert.

    Lossless NVEnc Aufnahme ist bei mir aber auf jeden Fall langsamer. Trotz speicherung auf Samsung Pro SSD.


    Welches wäre denn für die Aufnahme am schnellsten?


    https://abload.de/img/screenshot2020-09-1506wkss.png


    Also dann das letzte statt Max. Leistung?

  • Hmm bist du da sicher? Weil P7 ist ja nun deutlich intensiver als slow.

    Die fps mit dem preset ist auch ziemlich langsam. Ist denn irgendwo gelistet was die presets beinhalten? Weil bei x264 ist ja angegeben was die presets an settings beinhalten.

    Die Presets und Tunings kommen aus der SDK. Tuning "HQ" und Preset "P7" aktiviert die meisten Optionen/Features, aber das heißt nicht das daraus das beste Ergebnis erzielt wird. Z.b. "Two Pass" (-2pass) verursacht einen messbaren Qualitätseinbruch um 0.0002/0.017/0.0099/0.0001 (PSNR/SSIM/MS-SSIM/VMAF).


    Diese Presets werden von NVIDIA festgelegt und sind nicht unbedingt die beste mögliche Qualität - weiteres kann ich allerdings erst in 1-2 Monaten sagen wenn alle Tests durchgelaufen sind.

    Doch das gibt es. der -cq switch. Da brauchts auch dann kein qmin, qmax. Aber bei H.265 NVEnc ist es sehr wichtig das man das Level auf 6.1 high tier stellt. Bei nur z.B. 5.1 würde es auf 40 Mbit limitiert sein. Und das würden den Sinn von CRF ja sprengen.

    CRF (Constant Rate Factor) und CQ (Constant Quality) sind komplett unterschiedliche Technologien, denn CRF ist ein vollständig eigenständiger Ratenkontrollmodus. CQ hingegeben funktioniert als extra zu VBR, und ist bei verschiedenen Encodern immernoch zu finden. Somit sind alle VBR optionen (qmin, qmax, minrate, maxrate, b:v, usw.) weiterhin aktiv und werden vom encoder beachtet.

    Ich erwähnte diese Sachen, weil ffmpeg ja sagte die dann entsprechend so einzustellen. Das wird ja dann einen Grund haben warum das so gesagt wird? Weil normalerweise heißt das, das diese nicht zusammenarbeiten können, wenn man für eine Option eine andere ausschalten soll. Oder müsste ffmpeg dann die encoderhilfe aktualisieren? Ich habe ja nur zitiert was in ffmpeg stand zu den optionen.

    Die Beschreibung hier ist schon richtig. Für "-no-scenecut" besagt diese das man den wert auf 1 setzen soll wenn man keine adaptiven I-Frames haben will bei Szenenänderungen (ähnlich wie libx264 -sc_threshold 25), und für "b_adapt" besagt diese das man den wert asuf 0 setzen soll wenn man keine adaptive B-Frames haben will. Dort steht nicht das du diese Option ausschalten sollst, sondern nur das du das kannst.

    Innerhalb von max b-frames. Drüber ist auch bei adaptiven b-frames nicht erlaubt. Aber mit adaptiven b-frames definierst du mit max b-frames nur das maximum, so das man keine Angst haben muss, dort mehr einzustellen.

    Leider nicht in der SDK definiert, aber es ist wahrscheinlich das hier entweder die frameIntervalP limits beachtet werden und/oder die limits vom gewählten H.264/H.265 level selbst.

    Lossless NVEnc Aufnahme ist bei mir aber auf jeden Fall langsamer. Trotz speicherung auf Samsung Pro SSD.


    Welches wäre denn für die Aufnahme am schnellsten?


    https://abload.de/img/screenshot2020-09-1506wkss.png


    Also dann das letzte statt Max. Leistung?

    Am "schnellsten" ist "Max. Leistung", dies ist aber dem "High Performance" (hp) Preset gleich. Leider hat OBS Studio die SDK noch nicht geupdatet, das dauert wahrscheinlich noch ein paar monate. In der neuen SDK wäre dann wahrscheinlich "Max. Leistung" dem "p0" Preset gleich, womit wirklich alles deaktiviert wird.


    Die beiden "Lossless" und "Lossless High Performance" presets verschwinden ebenfalls mit der neuen SDK. Beide sind nicht mehr vollständig erreichbar mit FFmpeg allein, was allerdings auch gut so ist da einige der Einstellungen anhand der Auflösung geändert wurden. Lossless ist aber dennoch möglich mit den Optionen "-tune lossless -preset p0 -g 30", was auch nun um einiges schneller sein sollte.

  • CRF (Constant Rate Factor) und CQ (Constant Quality) sind komplett unterschiedliche Technologien, denn CRF ist ein vollständig eigenständiger Ratenkontrollmodus. CQ hingegeben funktioniert als extra zu VBR, und ist bei verschiedenen Encodern immernoch zu finden. Somit sind alle VBR optionen (qmin, qmax, minrate, maxrate, b:v, usw.) weiterhin aktiv und werden vom encoder beachtet.

    Ok interessant. Naja ich hab -b:v 0. Also daran sollte es ja nicht scheitern. Und level halt 6.2 high tier. Witzigerweise fühlt es sich aber auch wie CRF an. Er benutzt variable Quantizer usw, ganz wie mans von CRF erwartet.

    Aber auch CRF kann man mit -maxrate limitieren. Das macht z.B. Youtube und Vimeo so.


    Code
    -b_adapt <boolean> E..V...... When lookahead is enabled, set this to 0 to disable adaptive B-frame decision (default true)

    Also ich weiß nicht, aber nach meiner Übersetzung steht da, das ich die adaptiven b-frames ausschalten soll, wenn lookahead an ist.

    Warum wird das denn dann vorgeschlagen oder aufgefordert? Wobei ich das selber komisch finde, denn eig. wird ja wirklich lookahead gebraucht um adaptive b-frames nutzen zu können :/



    Aber du scheinst ja an OBS zu arbeiten:


    - Warum zur verdammten Hölle ist Farbmatrix standardmäßig auf 601? :-(

    Ich hatte das im OBS Forum schon gefragt, aber da kamen total merkwürdige antworten so als ob die das mit der farb RANGE verwechselt haben oder so o.O

    - Warum kann ich bei der normal Ausgabe die Keyframeangabe nur in Sekunden machen? Frameangabe ist da besser.

    - Ich wäre trotzdem erfreut wenn man in OBS den CQ Switch einsetzen könnte, oder zumindest eine qmin, qmax kombo. Aber man kann leider nur 'nen komplett fixen CQP angeben, was ich bissl blöd finde, weil man dann einen von 10 schon fast nehmen muss, damit Dunkelheit nicht leidet :(

    Und wie verwende ich die ffmpeg Ausgabe mit NVEnc bei den Parametern? Geht das überhaupt? Weil das ist da ja leider im x264opts format. Aber das hab ich bei NVEnc ja nicht.

    -Warum hab ich bei der normal Ausgabe keine Möglichkeit PCM WAVE als Audio zu benutzen? In MKV kann ich das ja rein tun und es würde mir lieber sein da ich mein Mikrofon noch nachbearbeite, als auch FLAC auf Youtube hochladen möchte, sodass zumindest Audio nur einmalig zu lossy komprimiert wird (von Youtube)

  • Also ich weiß nicht, aber nach meiner Übersetzung steht da, das ich die adaptiven b-frames ausschalten soll, wenn lookahead an ist.

    "-b_adapt <boolean> E..V...... Sofern lookahead aktiviert ist, setze dies auf 0 um adaptive B-Frame entscheidungen zu deaktivieren (standardmäßig wahr)"

    Steht nichts von soll, sonder nur das du das kannst.

    Warum wird das denn dann vorgeschlagen oder aufgefordert? Wobei ich das selber komisch finde, denn eig. wird ja wirklich lookahead gebraucht um adaptive b-frames nutzen zu können

    Das wird vorgeschlagen weil die Option extrem viel Performance frisst. Adaptive entscheidungen werden pro frame getätigt, und bei z.B. 4 B-Frames hast du dann kosten von O(n^(2+m)) (n = Look Ahead, m = B-Frames). Teures feature, bringt aber Qualität wie sonstwas.

    Aber du scheinst ja an OBS zu arbeiten:

    Ich arbeite am StreamFX plugin, nicht an OBS.

    Warum zur verdammten Hölle ist Farbmatrix standardmäßig auf 601?

    Offizieller Grund: Größte Kompatiblität

    Inoffizieller Grund: Weil Google es bis heute nicht schafft sich an die standards zu halten und leider hat Google nun halt eben 99% des Marktes mal eben in der Hand. Also passt man sich an Google an, auch wenn die komplette scheiße bauen, diese dann wieder abreißen, und dann exakt dasselbe da nochmal hinbauen.


    Es soll wohl ab 26.0 Bt.709 zum standard werden - auch wenn Google das immernoch verkackt.

    Warum kann ich bei der normal Ausgabe die Keyframeangabe nur in Sekunden machen? Frameangabe ist da besser.

    Begeb dich mal in das r/obs subreddit, die obs foren, oder das obs discord. Wenn du die nutzer dort angetroffen hast, weißt du warum die einstellungen so einfach gehalten werden. StreamFX hat sowohl Sekunden als auch Frames, und erlaubt auch Kommazahlen.

    Ich wäre trotzdem erfreut wenn man in OBS den CQ Switch einsetzen könnte, oder zumindest eine qmin, qmax kombo. Aber man kann leider nur 'nen komplett fixen CQP angeben, was ich bissl blöd finde, weil man dann einen von 10 schon fast nehmen muss, damit Dunkelheit nicht leide

    Der eingebaute NVENC in OBS nutzt die SDK direkt, und Jim hat sich dagegen entschieden möglicherweise Optionen einzuführen die auf älteren GPUs nicht funktionieren. Selber Grund wie oben.

    Und wie verwende ich die ffmpeg Ausgabe mit NVEnc bei den Parametern? Geht das überhaupt? Weil das ist da ja leider im x264opts format. Aber das hab ich bei NVEnc ja nicht.

    Das format ist hier egal. Die optionen werden nur anders getrennt, hat nichts mit x264opts zu tun.

    Warum hab ich bei der normal Ausgabe keine Möglichkeit PCM WAVE als Audio zu benutzen? In MKV kann ich das ja rein tun und es würde mir lieber sein da ich mein Mikrofon noch nachbearbeite, als auch FLAC auf Youtube hochladen möchte, sodass zumindest Audio nur einmalig zu lossy komprimiert wird (von Youtube)

    Weil OBS eine Streaming app ist. Und RTMP kann halt nur 16-bit waveform, oder AAC. Und niemand hat das wirklich interressiert oder gestört, weshalb da auch keine änderung wirklich gemacht wurde.

  • Offizieller Grund: Größte Kompatiblität

    Inoffizieller Grund: Weil Google es bis heute nicht schafft sich an die standards zu halten und leider hat Google nun halt eben 99% des Marktes mal eben in der Hand. Also passt man sich an Google an, auch wenn die komplette scheiße bauen, diese dann wieder abreißen, und dann exakt dasselbe da nochmal hinbauen.

    Das musste mal genauer erklären. Youtube benutzt 709. und ich habe nie probleme mit 709 gehabt und ich nutze Chrome.

    Außerdem was für kompatibilität? Ihr scheint nach wie vor das ganze mit der range zu verwechseln. Also von wegen 16-235 vs 0-255 helligkeiten. Weil das hat ja nichts mit der Matrix zu tun.

    Da war tatsächlich 'ne Zeit lang YUV Video fälschlicherweise falsch dargestellt worden und die Videos waren dadurch zu hell und blasser. Konnte man aber in Nvidia Systemsteuerung beheben, da war 'nen Setting für den Monitor standardmäßig falsch so dass er von einem 16-235 Monitor aus ging. Scheint Nvidia aber mittlerweile behoben zu haben. VLC mit Hardwarebeschleunigung war somit ebenfalls betroffen.

    Ich habe den Eindruck das ihr es hiermit verwechselt? Weil das mit der Matrix macht mir jetzt nicht so viel Sinn von wegen Kompatibilität? Kannste da sonst mal aushelfen ? :D

    Weil OBS eine Streaming app ist

    Naja ist es das denn wirklich noch? Mittlerweile isses das doch klar beides. Es würde keinem weh tun ein/zwei audiocodecs mehr zu adden für den Aufnahme tab? Der Streaming Tab kann ja gut und gerne nur AAC beinhalten. Also das Argument versteh ich dann auch nicht so ganz

    Das wird vorgeschlagen weil die Option extrem viel Performance frisst.

    Ich hätte mir sehr gewünscht, das hätte mit bei gestanden. Weil so sieht es halt wirklich so aus, als würde es heißen die beiden Optionen können nicht beide zusammen arbeiten.

    Der eingebaute NVENC in OBS nutzt die SDK direkt, und Jim hat sich dagegen entschieden möglicherweise Optionen einzuführen die auf älteren GPUs nicht funktionieren. Selber Grund wie oben.

    Kann man nicht prüfen welche Grafikkarte im System steckt und dementsprechend die Optionen anbieten? Das sollte doch kein Problem sein.

    Das format ist hier egal. Die optionen werden nur anders getrennt, hat nichts mit x264opts zu tun.

    Achso?

    Also kann ich dann z.B.

    cq=20

    machen und es geht?

  • Das musste mal genauer erklären. Youtube benutzt 709. und ich habe nie probleme mit 709 gehabt und ich nutze Chrome.

    Chrome und YouTube kommen nicht mit Inhalten klar die dem Standard folgen. sRGB, sYCC, ACEScc, ACEScct, usw. sind alle davon betroffen - diese funktionieren in professioneller Software einwandfrei (und auch in MPC-HC einwandfrei), aber in Browsern und YouTube kannst das in die Tonne kloppen - funktioniert nicht oder nur begrenzt, meistens ist Apple hier sogar besser als der rest weil Apple sich im Videoqualität kümmert.

    Da war tatsächlich 'ne Zeit lang YUV Video fälschlicherweise falsch dargestellt worden und die Videos waren dadurch zu hell und blasser. Konnte man aber in Nvidia Systemsteuerung beheben, da war 'nen Setting für den Monitor standardmäßig falsch so dass er von einem 16-235 Monitor aus ging. Scheint Nvidia aber mittlerweile behoben zu haben. VLC mit Hardwarebeschleunigung war somit ebenfalls betroffen.

    Das was du beschreibst liegt an einer fehlkonfiguration der Browser-hersteller (und VLC), nicht an NVIDIA/AMD/Intel oder irgendeiner Color Range. Die Browser-hersteller haben dies mit modernen versionen behoben, oder sollte ich eher sagen "an dritte ausgelagert". Korrekt konfigurierte Farbkonvertierung war immer möglich, und hatte sehr wenig mit Treibern/GPUs zu tun - man hats einfach nur nicht getan.


    Für Desktop kann ich deshalb MPC-HC empfehlen, es basiert weniger auf "Auf gut Glück" ergebnissen wie VLC. Interessanterweise sind sowohl MPC-HC als auch VLC auf FFmpeg basierend, aber MPC-HC hat deutlich besseren support für Color Matrix, Transfer Characteristics und Matrix Coefficients. Sogar das deinterlacing ist deutlich besser.

    Außerdem was für kompatibilität? Ihr scheint nach wie vor das ganze mit der range zu verwechseln. Also von wegen 16-235 vs 0-255 helligkeiten. Weil das hat ja nichts mit der Matrix zu tun. Ich habe den Eindruck das ihr es hiermit verwechselt? Weil das mit der Matrix macht mir jetzt nicht so viel Sinn von wegen Kompatibilität? Kannste da sonst mal aushelfen ?

    Verwechselt wurde hier nichts. In der modernen Browser (und YouTube) welt sind immernoch nur 601 und 709, Partial und Full range unterstützt. Vor 7-8 Jahren war sogar nur Partial range unterstützt. Für RTMP ist sogar immernoch nur Partial-range unterstützt. Diese Diskussion läuft jetzt schon mehr als 5 Jahre, und hat leider zu nichts geführt. Browser-hersteller machen immernoch ihr eigenes ding, und irgendwann wird es dazu führen das gar nichts mehr vorwärts geht.

    Naja ist es das denn wirklich noch? Mittlerweile isses das doch klar beides. Es würde keinem weh tun ein/zwei audiocodecs mehr zu adden für den Aufnahme tab? Der Streaming Tab kann ja gut und gerne nur AAC beinhalten. Also das Argument versteh ich dann auch nicht so ganz

    Sofern dir PCM Audio wichtig ist, kann ich dir nur empfehlen entweder Programmieren zu lernen, oder jemanden dafür zu beauftragen das in OBS Studio einzufügen. Freiwillig macht das keiner für dich, da 1024k AAC genug ist für 48khz Stereo "effectively lossless" aufnahmen.

    Kann man nicht prüfen welche Grafikkarte im System steckt und dementsprechend die Optionen anbieten? Das sollte doch kein Problem sein.

    Das wäre die ideale Situation. Leider gibt es System-builder die absichtlich kaputte Chips verbauen, gerne auch in Laptops, wo dann ein Feature gemeldet wird das gar nicht existiert. Jetzt haste den Salat. Also setzt du dich auf bestimmte Features fest von denen du garantieren kannst das sogar die schlechteste GPU das noch hat.

    Achso?

    Also kann ich dann z.B.

    cq=20

    machen und es geht?

    Code
    key=value key=value key=value

    Ist das format dort. Für CQ musst halt b=0 minrate=0 maxrate=0 cq=20 setzen - allerdings kann ich dir da nicht garantieren das es dort nicht zum tearing führt, da OBS immer denselben frame buffer verwendet.

  • Chrome und YouTube kommen nicht mit Inhalten klar die dem Standard folgen. sRGB, sYCC, ACEScc, ACEScct, usw. sind alle davon betroffen - diese funktionieren in professioneller Software einwandfrei (und auch in MPC-HC einwandfrei), aber in Browsern und YouTube kannst das in die Tonne kloppen - funktioniert nicht oder nur begrenzt, meistens ist Apple hier sogar besser als der rest weil Apple sich im Videoqualität kümmert.

    Kapier ich nicht ganz. Bei mir sieht das ganz normal aus wie auch in MPC-BE. Ich empfehle MPC-BE da MPC-HC eingestellt wurde und MPC-BE weiter entwickelt wird. Der hat mittlerweile auch schon neuere Decoder und paar mehr Features.

    Ich kann daher nach wie vor dieses 601 nicht nachvollziehen. Es sieht einfach schlechter aus und das ist das allererste was ich jedem rate in OBS umzustellen auf 709.

    Das was du beschreibst liegt an einer fehlkonfiguration der Browser-hersteller (und VLC), nicht an NVIDIA/AMD/Intel oder irgendeiner Color Range. Die Browser-hersteller haben dies mit modernen versionen behoben, oder sollte ich eher sagen "an dritte ausgelagert". Korrekt konfigurierte Farbkonvertierung war immer möglich, und hatte sehr wenig mit Treibern/GPUs zu tun - man hats einfach nur nicht getan.

    Das lag an der Hardwarekonvertierung zu RGB. Das konnte man bei VLC ausschalten dann ging es, oder eben bei Nvidia von 16-235 auf Full Range umstellen bei den Video Optionen, damit der Monitor nicht als 16-235 fähig behandelt wird.

    Nun hat Nvidia aber zusätzlich in den 3D Einstellungen die Angabe für Farb Range und die steht nun auch standardmäßig auf RGB bzw full range. Seitdem gibt es das Problem auch nicht mehr. Als es das noch nicht gab, hat man halt in Nvidia einfach eben bei Video Einstellungen eben dort dann auf Voll gesetzt. Das war ganz easy zu fixen.


    Sofern dir PCM Audio wichtig ist, kann ich dir nur empfehlen entweder Programmieren zu lernen, oder jemanden dafür zu beauftragen das in OBS Studio einzufügen. Freiwillig macht das keiner für dich, da 1024k AAC genug ist für 48khz Stereo "effectively lossless" aufnahmen.

    Ich kann aber nur 320 kbit einstellen. Sicherlich ist das immer noch sehr gut. Aber für Nachbearbeitung und dann Youtube nochmal drüber - ne da ist es mir definitiv lieber wenn der Audio lossless bleibt und nur youtube es zu lossy komprimiert. Außerdem minimal weniger CPU Last ;D

    Aber das kann doch echt nicht weh tun Codecs zu adden :/

    Zumal ich ganz sicher nicht der einzige bin der WAV haben möchte. Ich bin mir ziemlich sicher, alleine hier im LPF würden sich das bereits einige mehr wünschen.


    Aber was mich am meisten traurig macht ist, das OBS nach wie vor kein Overlay hat (keine fps Anzeige, kein Aufnahmestatus, kein gar nichts. FPS anzeige kann ich mir natürlich auch mit Afterburner geben, aber da wäre halt der Chat. Und den overlayed auf das Spiel zu haben wäre halt einfach nur fantastisch.

    Gerade wenn man Rennspiele spielt, oder 'nen Shooter wie Quake, wäre das ideal. Dann kann man es direkt lesen, ohne das Handy erst schnappen zu müssen. Auch 'nen 2. Monitor würde da rein gar nicht helfen. Denn auch da müsste ich woanders hingucken als aufs Spiel zu bleiben. Würde also überhaupt nicht helfen. Außerdem fänd ich das auch 'ne ziemlich Geld- und Materialverschwendung sich nur wegen 'nem Chat 'nen 2. Monitor zu holen, nur weil OBS kein Overlay kann^^

  • Grade komme ich zeitlich nicht dazu viel zu testen... aber schon mal danke für die ganzen Antworten.

    Das "High Performance" preset setzt nicht alle nutzlosen Funktionen für CQP/VQP außer kraft. Idealerweise sollte hier "Lossless High Performance" verwendet werden, da die bandbreite sehr heftig variiert.

    Bei einen kurzen Test ist die Bitrate dadurch um einiges höher.

    Von Encoding habe ich bei weitem nicht das wissen wie Ihr beide, aber jetzt nur von rein praktischen funktioniert das "preset" von De-M-oN sehr gut für Aufnahmen, da es auf maximale performance ausgerichtet ist und noch mehr als genug puffer zur Verfügung stellt, um das Video später auch noch mal neu zu codieren bzw. erhält man nachdem neu codieren für YouTube kein Pixelmatch (Selbst wenn das Video stark von der Auflösung hochskaliert wurde).


    Mit dem Lossless High Performance Preset, waren die Bitraten um einiges höher, also kann man hier eventuell mit den qmax Wert dann höher gehen.

    Ein kurzer Clip wo nicht viel passiert war z.B 22MB groß und mit Lossless High Performance war er 124MB groß.


    Hast du hier noch mehr Infos was genau für nutzlose Funktionen bei High Performance nicht deaktiviert wird?


    Nicht vergessen alle Optionen die nicht genutzt werden auszustellen

    Standardmäßig sind diese auf Default. Gibt es irgendwo eine Liste welcher Wert entsprechend Default ist?


    Ich empfehle MPC-BE da MPC-HC eingestellt wurde und MPC-BE weiter entwickelt wird.

    Den MPC-HC den Xaymar empfohlen hat, kann ich auch nur empfehlen.

    Dieser wird auch weiterentwickelt und den Verwende ich mittlerweile schon sehr lange ohne Probleme.


    https://github.com/clsid2/mpc-hc

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!