Beiträge von Xaymar

    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.

    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.

    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.

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

    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"