Richtige Einstellungen für Recording in Open Brodcaster Studio

    Pauschal lässt sich das nicht sagen, ohne dein System, deinen Workflow und deine Anforderungen zu kennen. ;) Insofern würde ich einfach mal sagen: Für Nachbearbeitung so hochwertig wie möglich, für direktes Hochladen reicht auch Begrenzt.

    Ich mach das Video dann hald noch mit Sagaras Scriptmaker und Megui also encoden etc


    Dann mach ich Color Range noch auf Full und dann sollte es für meine Anforderungen eigentlich passen.
    RGB ist hald der einzigste Farbraum mit dem ich halbwegs was anfangen kann.


    Sonst stehen noch NV12, I444 und I420 zur Auswahl.
    Standardgemäß ist es in OBS auf NV12 und Farbmatrix 601
    Bei der Farbmatrix meinte Demon in seinem Sagaras Scriptmaker Tutorial, man solle gleich in Tv.709 aufnehmen, damit man es in SGM nicht von 601 auf 709 umwandeln muss, soweit ich das richtig verstanden habe.

    Also 709 ist als Farbraum korrekt, hab da gestern noch mit Demon drüber geschrieben :P


    Wenn du in RGB aufnimmst musst du glaube ich den YUV-Farbraum auf Full setzen, so sagt es jedenfalls mein Tooltip in Dxtory zu der Einstellung.


    Ich gehe davon aus, dass das wichtig ist damit wenn zu YUV konvertiert wird der gleiche unlimitierte Farbraum wie bei RGB vorliegt, aber ob das so stimmt..

    Entspricht glaube ich dem YUV 4:2:0 Format und dürfte dann etwas schlechter als RGB sein, aber da warten wir lieber auf die Antwort eines experten :P


    Mich würde interessieren ob es qualitativ besser ist, in NV12 aufzunehmen und dann im SSM und Megui 4:2:0 auszuwählen als in RGB aufzuzeichnen und dann zu YUV zu konvertieren.

    Hab das zu NV12 in doom9 gefunden:


    The difference between NV12 and YV12 is just how the bytes are arranged in memory, the image information is otherwise 100% the same.


    Dann nehm ich RGB und Full und 709 falls kein Experte anderer Meinung ist :)

    Diese Einstellung entscheidet erstmal überhaupt gar nichts, solange nicht bekannt ist welcher Codec nun bei der Aufnahme verwendet wird.
    UtVideo kennt kein NV12 oder I444, nur I420 und RGB. Bei einem nicht unterstütztem Format wird automatisch eine Konvertierung nach RGB vorgenommen, also am besten gleich den richtigen Farbraum auswählen.
    Lässt du hingegen mit x264 kodieren hat es letztlich überhaupt keinen Einfluss, ob du dem nun RGB oder I444 Material lieferst, kommt am Ende eh nur YUV420 raus, also kann man hier auch gleich NV12 oder I420 nutzen. YUV-Farbmatrix auf 709 und YUV-Farbbereich auf Teilweise ist in dem Fall richtig. Bei RGB haben diese beiden Einstellungen keinen Einfluss. Über FFmpeg kann x264 auch in RGB aufnehmen.

    OBS nutz als Encoder den x264 soweit ich es in den Einstellungen sehe, aber ich kann auch auf NVENC H.264 umstellen.


    Dann nutze ich weiterhin die Standardeinstellungen, danke :)

    Zitat von Kayten
    Zitat von Kayten

    Lässt du hingegen mit x264 kodieren hat es letztlich überhaupt keinen Einfluss, ob du dem nun RGB oder I444 Material lieferst, kommt am Ende eh nur YUV420 raus, also kann man hier auch gleich NV12 oder I420 nutzen.


    Seit wann das? Dafür gibt es doch die output csp befehle. Wenn ich dort 444 einstelle, wieso sollte 420 rauskommen?

    Zitat von Kayten

    Nicht in OBS. x264 in OBS liefert immer nur YUV420. Hat nichts mit x264 in MeGUI zu tun.

    Er hat doch nur nach den Aufnahme-Einstellungen gefragt und encodieren tut er mit dem SSM und Megui.


    Edit: Ahso, du meinst wenn x264 als Codec verwendet wird? Gehen die gängigen in OBS nicht oder wieso nutzt man x264,
    als ich damals als Frischling hier reinkam und erzählt habe, dass ich x264 als Codec benutze wurde mir erstmal gesagt, dass
    man das nicht tun solle weil dabei bereits verlustbehaftet aufgezeichnet wird.

    Die Ausgabe über ffmpeg solltest Du dann nutzen, wenn Du nicht über x264 oder VCE oder NVENC aufnehmen möchtest (oder doch mit denjenigen aber verlustfreiem Audio) :)


    Die Frage, welchen Encoder Du benutzt/benutzen möchtest (+ deine Hardware) und welche Qualität es ergeben soll (Nachbearbeitung/keine Nachbearbeitung?) steht allerdings noch im Raum und somit auch jedwede Antwort, welche Einstellungen getroffen werden sollten ^^


    Am besten mal deinen gesamten geplanten Workflow beschreiben :)

    Werde mir DxTroy kaufen und den MagicYUV verwenden, hab grad mit der Demo ne aufnahme gemacht und die Qualität gefällt mir so viel besser als mit den vorherigen aufnahmen mit OBS.
    Und Dxtroy gefällt mir von den Einstellungen und der Übersicht auch besser. OBS wirft mir so alles vor mit der Erwartung das ich weiß was das alles ist und bedeutet.


    Will die Videos aufnehmen, also dann mit DxTroy und MagicYUV, dann das Video in SSM, Spielton und Video voneinander trennen, ein fertiges Preset, welche man mitinstallieren konnte anwenden, also diesen hier: 1800p-Spline100-MT-src_tv709_no_motionblur
    (oder besser Spline 16 mit 1800 p?)


    Und dann das Script in Megui und als Encoder x264 auswälen mit dem Tuning : "Animation" und Quality 21.


    So hätte ich mir das gedacht .

    Zitat von Ancrion

    Dann nehm ich RGB und Full und 709 falls kein Experte anderer Meinung ist

    Bei RGB sind selbst bei OBS der Farbbereich als auch die Farbmatrix total irrelevant. Weil RGB besitzt weder ein Farbbereich außer den vollen von 0 - 255. Und die Farbmatrix ist nur für YUV Farbräume. Die hat mit dem RGB nix zu tun.


    Als Hinweis:
    Stellt man in OBS den Farbraum auf RGB und nimmt mit dem eingebauten x264 auf, so nimmt OBS das Video stets in YV12 (YUV 4:2:0) auf. Und dann sind lediglich der Farbbereich und die Farbmatrix relevant von den Einstellungen her. RGB jedoch wird dann als Einstellung verworfen.
    Grund ist: x264 kann kein RGB an sich.


    x264 könnte RGB identisch sein mit YV24 (YUV 4:4:4) + Vollbereich + BGR (RGB) Matrix


    Könnte x264. Wird aber bei OBS nicht klappen, weil sich OBS mit der RGB Einstellung an den richtigen RGB Farbraum hält.


    RGB ist mit OBS also nur mit den dafür vorgesehenden Codecs möglich. z.B. über FFmpeg mit UTVideo oder mit Lagarith oder oder oder....



    Zitat von Ancrion

    The difference between NV12 and YV12 is just how the bytes are arranged in memory, the image information is otherwise 100% the same.

    NV12 ist gegenüber den normalen YV12 schneller, da bei NV12 besser mit dem Speicher umgegangen wird. Die Bildinformationen der beiden jedoch sind absolut identisch. Und fürs Streamen sollte man daher auch NV12 setzen. ^^



    Zitat von Ancrion

    Kann jedoch bei Video-Encoder nichts auswählen.

    Du musst vorher den Container Format bestimmen. Wenn du UTVideo nutzen willst, was RGB z.B. erlaubt, dann am besten als Container Format AVI nutzen.


    Und dann solltest du auch den Encoder auswählen können.


    Für Audio dann am besten pcm_s16le nutzen. Steht für Pulse-Code-Modulation (kurz PCM) - signed 16bit little endian.


    Alle weiteren Angaben von wegen Bitrate für Video und Audio sind dann total irrelevant, weil du mit diesen Settings Verlustfrei aufnimmst. Das sind alles Lossless Codecs. Selbst Audio.

    Sofern du kein Lossless aufnimmst sind diese von Relevanz, ja. Aber wenn du Lossless aufnimmst über x264 via qp=0 oder via FFmpeg mit UTVideo, spielt die Bitrate keine Rolle.


    Bei Lossless wird soviel Bitrate genommen damit es ausreicht um ein 1:1 Verhältnis bei den Frames zu erzielen.


    Sprich wenn du in RGB aufnimmst, dann ist das Ergebnis 1:1 dem was du aufgenommen hast.
    Die Spiele laufen alle in RGB32


    Den Alphakanal braucht man bei der Aufnahme ja nicht wodurch sich ein RGB24 Video ergibt der das gesamte Bild enthält.


    Unkomprimiert würde somit ein RGB Frame bei z.B. 640x480 sich folgendermaßen rechen:
    640 * 480 * (24 Bit / 8 )= 921600 Bytes = 900 KB


    Bei einer Länge von 30min bei 60 FPS sind das dann:
    900 KB * (30 * 60)sek * 60 FPS = 97200000 KB = 94921,875 MB = 92,7 GB


    Das wäre RGB unkomprimiert. Natürlich nimmste nicht unkomprimiert auf, sondern komprimiert und kommst somit auf einen Wert der Weit unter diesem Ergebnis ist. Nur größer kann dann dein Video mit diesen Angaben nicht werden. ^^


    Bei YUV verhält sich das auch so, nur ist bei YUV der U und V Channel limitiert. Sprich der Chroma (Farbanteil).


    Unkomprimiert YUV 4:2:0 würde mit 12Bit speichern. 8Bit für Y (Luma), 2Bit jeweils für U und V.


    Das macht dann pro Frame:
    640 * 480 * (12 Bit / 8 ) = 460800 Bytes = 450 KB


    Und für 30min bei 60 FPS sind das dann:
    450 KB * (30 * 60)sek * 60 FPS = 48600000 KB = 47460,938 MB = 46,35 GB


    Da du das aber auch nicht unkomprimiert aufnimmst, wird das bei einem Verlustfreien Kompression Codec wie UTVideo, MagicYUV, Lagarith, und wie sie alle heißen noch komprimiert. Um wieviel es komprimiert wird hängt von den Frames ab wie gut sie sich komprimieren lassen.


    Und das ist Verlustfrei.



    Bei einem Verlustbehafteten Codec bzw. Aufnahme nutzt man Bitraten um die Qualität eines Frames zu senken um sie so kleiner zu machen. Das hast du bei einem Lossless Codec nicht.


    Ein Lossy Codec braucht eine Bitraten Angabe in welcher Form auch immer. Sei es mit CBR, ABR oder VBR.


    Es gibt nur diese 3 Bitraten.
    VBR ist eine varable Bitrate. Sie könnte somit jedem Frame eine andere Bitrate und somit jeden Frame unterschiedlich groß machen. Wenn man dies optimal nutzt wie bei dem CRF Verfahren bei x264, dann kann man eine Datei ziemlich klein machen bei optimaler Qualität noch. (Hinweis: Optimal ist hier nicht 1:1, da der Codec ja ein Verlustbehafteter ist.)


    CBR stellt mitunter das schlimmste dar. Man gibt eine Bitrate an und diese ändert sich nicht für das gesamte Video. Das heißt das jeder Frame die gleiche Bitrate besitzt. Damit werden unkomplexe Stellen im Video sehr schön dargestellt, aber sobald komplexere Sachen auftauchen, kann es sein das die Bitrate nicht ausreicht und das Bild verschmiert bzw. schmeißt DCT Blöcke.


    ABR ist eine Mischung aus beiden. Ziel ist es hier die Bitrate sehr nah an die angegebene Dateigröße zu richten. Je mehr Durchgänge man macht wie z.B. 2pass oder 3pass (2pass reicht in der Regel meist), so kann man sich der gewünschten Dateigröße so weit nähern das die Bitrate für die angegebene Dateigröße optimal ist.


    Das sind die 3 Verfahren.
    In der Regel rechnet man Bitraten nach dem ABR Prinzip:


    Sprich Wieviel Bits pro (Pixel * Frame) sollen vergeben werden?


    Wir haben die Pixel und auch die Anzahl der Frames und wir möchten daraus eine Datei mit 400MB erzeugen. Wieviel Bitrate ist notwendig dafür?


    Also rechnet man:


    400MB * 1024 = 409600 KB
    409600 KB / (30 * 60)sek = ~227,6 KByte/sek (KB/s)
    227,6 KBytes/s * 8 = 1820 KBit/sek (Kb/s)


    Den Weg kann man auch anders herum rechnen.


    Hier würde ich z.B. sehen das 400 MB nicht sonderlich ausreicht. Aber für ein 640x480 Video reicht das eigentlich locker ^^


    Sprich 1820 Kb/s würde ausreichen für dieses Video.


    Jetzt kommt aber das ABER... ich wüsste nicht wie die Qualität am Ende wird, einfach weil es in einem Video unkomplexe und auch komplexe Frames sind. Das heißt die ABR Angabe ist nur ein geschätzter Wert, denn wenn nach VBR encodiert wird trifft dieses Berechnungsergebnis nicht mehr zu. Da diese Berechnung lediglich auf ein CBR Basierendes Video zurückführt. Denn VBR kann man nicht in Vorfeld zu 100% berechnen.


    Dann kommt noch der Overhead hinzu + die Dateigröße des Containers + Header und dann müssten man schon 410MB einplanen bei 1820 Kb/s


    Und im Grunde wirkt sich das natürlich entsprechend auf die Qualität aus alles. Denn man hat nun nicht mehr volle Bits die man nutzt, sondern gebrochene Bits.


    Und die Bit pro Pixel stellen die Qualität dar. Kurz: bpp


    Als Vergleich YV12:
    unkomprimiert Lossless: 640 * 480 * (12bpp / 8 ) = 460800 Bytes = 450 KB


    Um jetzt die Byte für 1 Frame zu bekommen nutzen wir nun die 1820 kb/s und nehmen den Kehrwert von unserer Video FPS. Sprich 1/60 und erhalten somit die Dateigröße für ein Frame des Videos:
    1820 kb/s = 1820000b/s * 1/60 = 30333,333333333333333333333333333 Bit * 8 = 242667 Byte = 237 KB


    ABR Berechnung: 242667 Bytes / (640 * 480) = 0,789931640625 * 8 = ~6,32 bpp


    Und das ist die Hälfte fast. Bei YUV 4:2:0 wäre 12 bpp max. Mit der Bitrate lässt sich dies aber beeinflussen. Die Bitrate ist sozusagen der Qualitätswert. Unter die Hälfte des max. bpp Wertes wäre es schon fast ne Videokatastrophe ^^ 6,32 bpp sind für dieses Beispielvideo hier zu wenig. Der Wert müsste min. bei 8 oder 9 bpp liegen, damit noch was anständiges raus kommt.


    Und wie gesagt die ABR Durchschittsberechnung hier ist nur ein ungefährer Wert. Wenn du mit VBR encodieren solltest, wird das wesentlich effektiver ausfallen.


    Arten der VBR Encodierung sind z.B. die ABR mit 2pass, oder die konstante Qualität via CRF (x264) oder konstante Quantisierung (CQ).
    Das letztere ist eine vereinfachte Form des konstanten Qualitäts Verfahrens.


    Die letzten beiden genannten Verfahren brauchen keine Bitraten Angabe, sondern ermessen diese durch einen bestimmten Faktor. Quantisierungsfaktor bzw. Qualitätsfaktor.


    Und bei der ABR Variante wird nach der Bitrate gegangen bzw. nach der Dateigröße. Je nach dem was man will.



    Für Lossless Aufnahmen sind Bitraten also völlig uninteressant.

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden