OBS Studio - Mit NVENC effizient aufnehmen

Sehr interessant, hört sich ja fast nach einem CRF Mode auf NVENC an, werd ich bei Zeiten mal testen, danke.

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:

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.

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.

Zitat von Dream

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

Zitat von Dream

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.

Zitat von Xaymar

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.

Zitat von Xaymar

"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?

Zitat von Xaymar

"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?

Zitat von De-M-oN

-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.

Zitat von De-M-oN

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.

Zitat von De-M-oN

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.

Zitat von De-M-oN

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.

Zitat von De-M-oN

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.

Zitat von De-M-oN

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.

Zitat von Xaymar

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.

Zitat von Xaymar

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

Zitat von Xaymar

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.

-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.

Zitat von Xaymar

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.

Zitat von Xaymar

"-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.

Zitat von Xaymar

"-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.

Zitat von Xaymar

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?

Zitat von De-M-oN

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.

Zitat von De-M-oN

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.

Zitat von De-M-oN

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.

Encoder h264_nvenc [NVIDIA NVENC H.264 encoder]:
    General capabilities: delay hardware 
    Threading capabilities: none
    Supported pixel formats: yuv420p nv12 p010le yuv444p p016le yuv444p16le bgr0 rgb0 cuda d3d11
h264_nvenc AVOptions:
  -preset            <int>        E..V...... Set the encoding preset (from 0 to 11) (default medium)
     default         0            E..V...... 
     slow            1            E..V...... hq 2 passes
     medium          2            E..V...... hq 1 pass
     fast            3            E..V...... hp 1 pass
     hp              4            E..V...... 
     hq              5            E..V...... 
     bd              6            E..V...... 
     ll              7            E..V...... low latency
     llhq            8            E..V...... low latency hq
     llhp            9            E..V...... low latency hp
     lossless        10           E..V...... 
     losslesshp      11           E..V...... 
  -profile           <int>        E..V...... Set the encoding profile (from 0 to 3) (default main)
     baseline        0            E..V...... 
     main            1            E..V...... 
     high            2            E..V...... 
     high444p        3            E..V...... 
  -level             <int>        E..V...... Set the encoding level restriction (from 0 to 51) (default auto)
     auto            0            E..V...... 
     1               10           E..V...... 
     1.0             10           E..V...... 
     1b              9            E..V...... 
     1.0b            9            E..V...... 
     1.1             11           E..V...... 
     1.2             12           E..V...... 
     1.3             13           E..V...... 
     2               20           E..V...... 
     2.0             20           E..V...... 
     2.1             21           E..V...... 
     2.2             22           E..V...... 
     3               30           E..V...... 
     3.0             30           E..V...... 
     3.1             31           E..V...... 
     3.2             32           E..V...... 
     4               40           E..V...... 
     4.0             40           E..V...... 
     4.1             41           E..V...... 
     4.2             42           E..V...... 
     5               50           E..V...... 
     5.0             50           E..V...... 
     5.1             51           E..V...... 
  -rc                <int>        E..V...... Override the preset rate-control (from -1 to INT_MAX) (default -1)
     constqp         0            E..V...... Constant QP mode
     vbr             1            E..V...... Variable bitrate mode
     cbr             2            E..V...... Constant bitrate mode
     vbr_minqp       8388612      E..V...... Variable bitrate mode with MinQP (deprecated)
     ll_2pass_quality 8388616      E..V...... Multi-pass optimized for image quality (deprecated)
     ll_2pass_size   8388624      E..V...... Multi-pass optimized for constant frame size (deprecated)
     vbr_2pass       8388640      E..V...... Multi-pass variable bitrate mode (deprecated)
     cbr_ld_hq       8            E..V...... Constant bitrate low delay high quality mode
     cbr_hq          16           E..V...... Constant bitrate high quality mode
     vbr_hq          32           E..V...... Variable bitrate high quality mode
  -rc-lookahead      <int>        E..V...... Number of frames to look ahead for rate-control (from 0 to INT_MAX) (default 0)
  -surfaces          <int>        E..V...... Number of concurrent surfaces (from 0 to 64) (default 0)
  -cbr               <boolean>    E..V...... Use cbr encoding mode (default false)
  -2pass             <boolean>    E..V...... Use 2pass encoding mode (default auto)
  -gpu               <int>        E..V...... Selects which NVENC capable GPU to use. First GPU is 0, second is 1, and so on. (from -2 to INT_MAX) (default any)
     any             -1           E..V...... Pick the first device available
     list            -2           E..V...... List the available devices
  -delay             <int>        E..V...... Delay frame output by the given amount of frames (from 0 to INT_MAX) (default INT_MAX)
  -no-scenecut       <boolean>    E..V...... When lookahead is enabled, set this to 1 to disable adaptive I-frame insertion at scene cuts (default false)
  -forced-idr        <boolean>    E..V...... If forcing keyframes, force them as IDR frames. (default false)
  -b_adapt           <boolean>    E..V...... When lookahead is enabled, set this to 0 to disable adaptive B-frame decision (default true)
  -spatial-aq        <boolean>    E..V...... set to 1 to enable Spatial AQ (default false)
  -temporal-aq       <boolean>    E..V...... set to 1 to enable Temporal AQ (default false)
  -zerolatency       <boolean>    E..V...... Set 1 to indicate zero latency operation (no reordering delay) (default false)
  -nonref_p          <boolean>    E..V...... Set this to 1 to enable automatic insertion of non-reference P-frames (default false)
  -strict_gop        <boolean>    E..V...... Set 1 to minimize GOP-to-GOP rate fluctuations (default false)
  -aq-strength       <int>        E..V...... When Spatial AQ is enabled, this field is used to specify AQ strength. AQ strength scale is from 1 (low) - 15 (aggressive) (from 1 to 15) (default 8)
  -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)
  -aud               <boolean>    E..V...... Use access unit delimiters (default false)
  -bluray-compat     <boolean>    E..V...... Bluray compatibility workarounds (default false)
  -init_qpP          <int>        E..V...... Initial QP value for P frame (from -1 to 51) (default -1)
  -init_qpB          <int>        E..V...... Initial QP value for B frame (from -1 to 51) (default -1)
  -init_qpI          <int>        E..V...... Initial QP value for I frame (from -1 to 51) (default -1)
  -qp                <int>        E..V...... Constant quantization parameter rate control method (from -1 to 51) (default -1)
  -weighted_pred     <int>        E..V...... Set 1 to enable weighted prediction (from 0 to 1) (default 0)
  -coder             <int>        E..V...... Coder type (from -1 to 2) (default default)
     default         -1           E..V...... 
     auto            0            E..V...... 
     cabac           1            E..V...... 
     cavlc           2            E..V...... 
     ac              1            E..V...... 
     vlc             2            E..V...... 
  -b_ref_mode        <int>        E..V...... Use B frames as references (from 0 to 2) (default disabled)
     disabled        0            E..V...... B frames will not be used for reference
     each            1            E..V...... Each B frame will be used for reference
     middle          2            E..V...... Only (number of B frames)/2 will be used for reference
  -a53cc             <boolean>    E..V...... Use A53 Closed Captions (if available) (default true)
  -dpb_size          <int>        E..V...... Specifies the DPB size used for encoding (0 means automatic) (from 0 to INT_MAX) (default 0)

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.

Zitat von De-M-oN

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.

Zitat von De-M-oN

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.

Zitat von Xaymar

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.

-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

- 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)

Zitat von De-M-oN

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.

Zitat von De-M-oN

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.

Zitat von De-M-oN

Aber du scheinst ja an OBS zu arbeiten:

Ich arbeite am StreamFX plugin, nicht an OBS.

Zitat von De-M-oN

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.

Zitat von De-M-oN

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.

Zitat von De-M-oN

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.

Zitat von De-M-oN

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.

Zitat von De-M-oN

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.

Zitat von Xaymar

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 ?

Zitat von Xaymar

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

Zitat von Xaymar

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.

Zitat von Xaymar

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.

Zitat von Xaymar

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?

Zitat von De-M-oN

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.

Zitat von De-M-oN

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.

Zitat von De-M-oN

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.

Zitat von De-M-oN

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.

Zitat von De-M-oN

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.

Zitat von De-M-oN

Achso?

Also kann ich dann z.B.

cq=20

machen und es geht?

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.

Zitat von Xaymar

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.

Zitat von Xaymar

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.

Zitat von Xaymar

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^^

https://mpc-hc.org/

Da wurde er seit 2017 eingestellt. Hmm ka.

Ich bleib aber bei BE.

_

Lossless ist auch langsamer. Kostet deutlich mehr fps im Spiel. Und am Datenträger liegts nicht, da es 'ne Samsung Pro SSD ist.

Daher würd ich schon auf max. leistung preset bleiben