Von MSI Afterburner zu OBS Studio: Erbitte Hilfe bei Aufnahmeproblemen :(

Edit weil Video:
Das Video ruckelt aus meiner Sicht aber schon ziemlich. Mit wie vielen FPS spielst du? Das sieht spontan eher nach 20 als nach 50 aus. Das kann nicht ganz korrekt sein.

Edit Ende.

Wenn ich nicht völlig blind bin, scheinst du genau 0 verworfene Frames gehabt zu haben, da die betreffenden Zeilen schlichtweg nicht vorhanden sind. Mal hoffen, dass die nicht einfach so wegen NVENC weggelassen wurden, sondern dass es tatsächlich keine verworfenen Frames gibt.
Bleibst du hierbei, solltest du dir noch CoreAudio zulegen, wie Schauerland bereits schrieb.

Wenn du ganz sichergehen möchtest, postest du noch eine >MediaInfo< einer Testaufnahme. Danach wirst du eh jedes Mal gefragt werden, wenn es irgendein Problem mit einer Aufnahme gibt, also gleich angewöhnen.

Zitat von Schauerland

Umgekehrt bietet das Einstellen von I420 keinen Mehrwert oder?

Technisch nicht. Dann warte ich aber nur auf die nächste Person, >die versehentlich UtVideo und NV12 zusammen nutzt<.

Zitat von Kayten

Edit weil Video:
Das Video ruckelt aus meiner Sicht aber schon ziemlich. Mit wie vielen FPS spielst du? Das sieht spontan eher nach 20 als nach 50 aus. Das kann nicht ganz korrekt sein

Jau das Problem kenn ich mit NVEnc und OBS.
Das einzige was bei mir vernünftig geht ist der interne x264 von OBS. Alles andere grottenlangsam.

Zitat von Rick

Und da kann ich dann aber wieder den MagicYuv Lossless benutzen? Zumindest im Afterburner hat der bei mir - nach Einweisung durch De-M-oN und den Gelben Drachen - perfekte Aufnahmen produziert. Wenn ich mir die angeschaut habe, konnte ich nicht mehr zwischen dem echten Spiel und der Aufnahme unterscheiden. So gut war das!

Wär auch schlimm wenn nicht bei einem Lossless Codec

Ja VfW geht da wieder und DXTory kann auch den Mauszeiger aufnehmen. Würde es aber vorher testen wie es bei deinem System läuft. und auch hier nach Tipps gucken, zb Direct3D9 Spiele scheinen ja bei Advanced gewisse Haken benötigen.

Zitat von Rick

Aber laut der Media Info ist dem nicht so.

Naja du siehst die FPS des Videos, aber nicht wieviel Frames davon Dropped Frames sind, sprich dummy/leere Frames.

Zitat von Rick

Dxtory muss man kaufen, oder?

Jup. Schätzungsweise 35€, hast aber keinerlei Einschränkungen deine Lizenz betreffend. Testversion runterladen und ausprobieren.

Zitat von Rick

Und da kann ich dann aber wieder den MagicYuv Lossless benutzen?

In Dxtory kannst du alle Codecs nutzen wie auch beim MSI AB, da beide die selbe Schnittstelle verwenden: VfW - Video for Windows.

Zitat von Rick

Das ist jetzt aber rein für die Audioqualität, oder?

Audioqualiät und/oder Performance.

Wenn x264 bei dir eine zu hohe CPU Last erzeugt und NVENC nur ruckelt, würde ich noch die Variante mit UtVideo austesten, falls du kein Geld für Dxtory ausgeben möchtest.

Kannst dich bei mir über Skype melden

Zitat von Kayten

"Das musst du so nutzen weil Grafikkarte" ist nun mal keine Begründung mit der ich mich begnüge. Das hat für mich die Aussagekraft des Wahrheitsgehalts eines Perpetuum Mobiles auf YouTube.
Ich hätte gerne einen praxisnahen Test der zeigt, dass die Nutzung von NV12 tatsächlich einen spürbaren oder zumindest messbaren Vorteil bietet. Wüsste ich, wie sich das am besten umsetzen ließe, würde ich mich selbst daran setzen.
Wer sich bei x264 aus Performancegründen bereits mit i420 und NV12 befassen muss, dem wird der (falls überhaupt existente) Performancevorteil nicht weiterhelfen und hat aus meiner Sicht gänzlich andere Probleme. Gehört bisher aus meiner Sicht in die Kategorie "nett zu wissen, aber in der Praxis unwichtig".

Performanter im Sinne wie es gespeichert wird.

Schließlich wird der Informationsgehalt ja nicht anders nur weil man von einem 4:2:0 auf ein anders 4:2:0 wechselt.

Kurze Erklärung:
NV12 ist besser performanter gegliedert und baut sich daher schneller auf und lässt sich besser auch wieder abspeichern.
Reihenfolge der Speicherung:
Y Register
gefolgt von den UV Registern (Bund)
Sprich Y1 Y2 Y3 Y4 Y5 Y6 U1 V1 U2 V2 U3 V3 U4 V4 ...

Bei YV12 hast du die typische MPEG Basis noch die wesentlich langsamer ist.
Erst erfolgen die Y Register
gefolgt vom U Register
und erst zum Schluss kommt der V Register
Sprich Y1 Y2 Y3 Y4 Y5 Y6 U1 U2 U3 U4 U5 U6 V1 V2 V3 V4 V5 V6 ...

So bauen sich dann die Matrizen auch auf.
Daher hast du mittels NV12 das Bild nicht nur schneller, sondern es wird dir die Ebene gleich komplett mitgeliefert beim UV Durchgang. Bei YV12 nicht.

Bei NV12 wird der U Bit als least significant bit und der V Bit als most significant bit gehandhabt. So teilen sich beide ein Byte.
Und YV12 nutzt für U und V jeweils ein Byte separat.

Während also NV12 Sparsam ist und 2 Byte verwendet, verwendet YV12 schon 3 Byte. Und das für den gleichen Pixel.

Den Unterschied zwischen beiden kann man so nicht gleich ersehen, weil gerade NV12 meist in Kompressions Codecs verwendet wird.
Ansonsten würde man zwischen NV12 und YV12 einen Dateigrößen Unterschied feststellen.

Da aber gleicher Informationsgehalt unterschiedlicher Größe mit Kompression auf gleiche Größe komprimiert wird ersieht man den Vorteil nicht.

Wie gesagt: NV12 muss mit weniger auskommen Daten auskommen, weil U und V sich ein Byte teilen. Somit reduziert sich natürlich auch die Datenmenge die durchgejagt werden muss.

Ich hoffe ich konnte dich damit wenigstens etwas weiter helfen.

In der Praxis ist man mit NV12 weit schneller fertig als mit YV12, es sei denn man dekodiert es wieder in RGB um, dann verfällt natürlich der ganze Schmarrn.
NV12 ist aber vor allem beim Streaming sehr gefragt aufgrund dessen was ich dir versucht habe zu erklären. Daher wird es in OBS ja auch verwendet. Theoretisch wird es eigentlich schon in jedem Streaming Tool verwendet. Selten das es mal bei einem Streaming Tool fehlt.

Finde zwar, dass das besser in deinen Thread zu Farbräumen passt, aber gut. Vielleicht verschiebt @sem diesen und deinen Beitrag ja dort hin.

Zitat von Sagaras

Während also NV12 Sparsam ist und 2 Byte verwendet, verwendet YV12 schon 3 Byte. Und das für den gleichen Pixel.

Entweder war das sehr unglücklich ausgedrückt oder du liegst in dem Fall schlicht falsch. In 3 Byte, also 24bit könntest du schon einen RGB24 Pixel stecken, daher 8bit pro Kanal. YUV420 benötigt exakt die Hälfte, daher 1,5Bytes pro Pixel, oder auch 12bit pro Pixel. FFmpeg stimmt mir da zu.

FLAGS NAME            NB_COMPONENTS BITS_PER_PIXEL
-----
IO... yuv420p                3            12
IO... nv12                   3            12

Lässt sich auch recht einfach nachvollziehen, 4 Pixel (2x2) teilen sich die Farbinfos. Heißt auf die 4 Pixel bezogen:

• 4 Helligkeitswerte je 8 bit (Luminanz)
• 2 Farbwerte je 8 bit (Chrominanz)

Was in 4x8bit + 2x8bit = 48bit resultiert. Da es jedoch 4 Pixel sind, muss durch 4 geteilt werden, um die Bitzahl pro Pixel zu bestimmen: 48bit / 4 = 12bit. Jeder Pixel in YUV420 benötigt daher 12bit.
Unkomprimiertes I420 Material hat demnach die exakt gleiche Größe wie unkomprimiertes NV12 Material.

Hast du gut nachgewiesen das der Informationsgehalt gleich bleibt zwischen YV12 und NV12. Den Rest lassen wir einfach mal unter den Tisch fallen. Reicht ja wenn du dich da vollkommen auskennst

Es geht ja nicht um die Menge der Information, sondern was sich besser komprimieren lässt *hust*
Aber, who cares....

Zitat von GelberDrache92

Es geht ja nicht um die Menge der Information, sondern was sich besser komprimieren lässt *hust*
Aber, who cares....

Zitat von Sagaras

Da aber gleicher Informationsgehalt unterschiedlicher Größe mit Kompression auf gleiche Größe komprimiert wird ersieht man den Vorteil nicht.

nochmal on-topic.

dass das video ruckelt könnte auch an der art des captures ligen und deinem monitor.

hast du zB einen 120 hz monitor ist das recht fucked... das hängt alles irgenwie zusammen.

also was man generell tun sollte: vsync an bzw den halben wenn du mit 60 aufnimmst (würde auch mit 60 statt 50 aufnehmen immer so wie es das spiel liefert da sonst solche effekte auftreten können) - ein weiterer nachteil von obs.

dann game capture verwenden, nicht desktop und bei game capture die haken setzen bei
- Limitiere FPS der aufnahme (OBS versucht dann die fps des game captures auf die ser szene anzupassen)
- mauszeiger aufnhemen (wenn du das willst aber ich gehe davon aus, da afterburner es ja nicht tut ;))
- anti cheat hook (hab ich immer drin ist aber nur für online games wichtiger - kannst du rausmachen aber dann nicht vergessen falls du mal online spielst da du evtl gebannt werden kannst wenn der obs hook als cheat erkannt wird)
- aufnahme von drittanbieter overlays (braucht nur rein wenn die die notifications von steam mit aufnehmen willst)

Aber vsync verursacht so brutal viel Input Lag
Bei meiner Capture Karte müsste das halt auch an, aber auch nur damit die Aufnahme kein Tearing hat. Flüssig isses mit CC eig. auch ohne vsync gewesen. Bei OBS keine Ahnung. Ich hab's eine ganze Weile mit Vsync ausgehalten, aber mittlerweile wo man dann doch mal wieder gesehen hat wie es ist ohne diesen Input Knoten, dann mag man irgendwie doch nicht mehr

Was ich komisch finde, dein Mauszeiger bewegt sich flüssig durch das bild. Das game ist aber choppy.
Hast du einen 2. monitor? lieg da obs drauf? hat der auch 60 Hz?