Ist davon auszugehen dass VLC aufgrund der Dateigröße nicht hinterherkommt oder ist das definitiv beim encodieren entstanden?
Probiere mal lieber MPC-HC.
Bildbrüche
Die sehen wie genau aus?
Beiträge von Kayten
-
-
Ohne genauen Überblick kann man da nur raten. Folgendes würde mir aktuell einfallen:
- CPU-Auslastung im Auge gehabt und nicht bei 100%?
- Komplette MSI AB Einstellungen überprüft, besonders die des RTSS?
- VSync versehentlich aktiviert?
-
Also hebt die Auswahl von x264 das Farbformat RGB in den Einstellungen auf, oder hat das ohnehin eine andere Bedeutung als der Farbraum, in dem aufgezeichnet wird?
Für das interne x264 hat die Wahl des Farbformats quasi keine Bedeutung und lediglich NV12 und i420 sind von Belang. Wenn du nun aber genauere Informationen hierüber möchtest, müsstest du im Forum schauen, Sagaras hat das schon irgendwo niedergeschrieben.
Erst wenn über FFmpeg kodiert wird, wird dem jeweiligen Encoder das Material direkt übergeben, welcher es dann entsprechend verarbeitet.Ähm welchen von den Encodern würdest du jetzt persönlich empfehlen, falls ich fragen darf?
Die Tutorials sollten dir diese Frage eigentlich schon beantworten, aber in OBS würde ich entweder x264 nutzen oder UtVideo über FFmpeg.
Und (verzeih meine Unwissenheit) Encoder sorgen ja dafür, dass das Video auf entsprechenden Playern läuft.
Nein. Wenn der jeweilige Player nicht in der Lage ist Codec Y zu dekodieren (hängt daher mit einem Decoder zusammen), dann kann der Encoder nichts dafür. Ist auch der Grund warum es (generell) nicht die "Schuld" des Aufnahmeprogramms (bspw. OBS) ist, wenn ein Verarbeitungsprogramm (wie Premiere) nicht mit dem Material klar kommt.
Heißt das, das sowohl Qualität als auch Dateigröße unberührt bleiben oder?
Das hängt vom Encoder bzw. darüber stehendem Codec ab.
UtVideo und MagicYUV sind beispielsweise verlustfrei und geben das eingespeiste Material 1:1 wieder, erzeugen aber sehr große Dateien. Diese sind daher zum Aufnehmen sehr gut geeignet, da die Qualität erhalten bleibt. Zum Hochladen bieten sich diese allerdings nicht an, dafür muss es aber komprimiert werden, damit das Material auch in annehmbarer Zeit bei YouTube landet. In dem Fall nun mal verlustbehaftet. Wichtig ist bei verlustbehafteter Kodierung nun, dass sie so effizient wie möglich gemacht (x264) und nicht mehrfach hintereinander angewandt wird, sonst greift der Generationsverlust mit jeder weiteren Anwendung.Außerdem ich hab mal gehört
Keine gute Grundlage. Die meisten Tutorials auf YouTube sind generell eher unbrauchbar.
reicht das dann oder eher nicht?
Nein. Sonst würden sich nicht so viele damit beschäftigen, wie man die bestmögliche Qualität erreicht.
was genau soll ich denn alles angeben, damit es dir leichter geht?
Das, womit du auf jeden Fall weiterarbeiten willst. Wenn du offen genug für neue Programme bist, ist das nicht so wichtig.
-
Ist das nicht korrekt, wenn er in RGB aufzeichnet und dann in YUV beim konvertieren encodiert?
Es heißt "YUV Farbbereich" und hat genau keinen Einfluss auf RGB. Mit seinen aktuellen Einstellungen nimmt er außerdem nicht in RGB auf, sondern in YUV420, da das OBS-Interne x264 nur in YUV420 kodiert.
Dxtory sagt zum Häkchen wo man Full Range YUV einstellen kann folgendes:
Das kommt mit Sicherheit nicht von Dxtory, sondern von MagicYUV.
Bin noch ziemlich frisch dabei hier
Dann müssten wir genau erfahren, was du möchtest, ob du bei deinem aktuellen Workflow bleiben willst oder nicht und so weiter. Ansonsten bekommst du die generelle Empfehlung vorgesetzt.
Aufnahme
Da stehen dir aus meiner Sicht folgende Programme zur Auswahl:
- MSI Afterburner (Tutorial, kostenlos)
- OBS Studio (Kein Tutorial bisher, kostenlos)
- Dxtory (Tutorial, kostenpflichtig)
Für die Verarbeitung wird hier allgemein empfohlen:
Desweiteren noch hilfreich könnte dies sein:
- AutoEncode - Automatisches Muxen in MeGUI
- Besseren Codec (VP9) von YouTube erhalten
- Farbräume (Tutorial) - erweiterte Erklärung und Zusammenhänge
Viele Informationen, aber ohne Grundlage ist es schwierig konkret etwas angeben zu können.
-
Ich hab hier nur mal gehört, dass Leute teils direkt uploaden
Sicher, ist auch gut möglich mit OBS und vernünftigen x264 Einstellungen samt nicht zu schnell gewähltem CPU-Preset. Jemand anderes wird das bestimmt besser beantworten können, aber bei deinen aktuellen Einstellungen wird das nicht wirklich funktionieren.
Und nach dem hochskalieren dann mit welchem Codec? Wieder der H.264 oder?
H.264 als Codec ist korrekt, sagt aber rein gar nichts aus letztlich. Einen vernünftigen Encoder zu wählen ist wichtig und da kommt nur x264 in Frage. Für genaueres müssten wir deinen Workflow kennen.
-
Deine Aufnahmen werden erstens abartig groß werden, sodass du ohne enorm guten Upload definitiv keinen Spaß daran haben wirst und zweitens steht der YUV Farbbereich auf Voll, was falsch ist. Von der Qualität her ist es bei den Einstellungen quasi das gleiche, als würdest du eine verlustfreie Aufnahme mit Dxtory oder MSI Afterburner ohne weitere Verarbeitung direkt hochladen wollen.
Eigentlich recht sinnlos, da wäre es sinniger das Material noch hoch zu skalieren auf 1152p oder 1800p und vernünftig zu kodieren (Uploadzeit sparen), um über YouTubes VP9 Codec nochmal deutlich bessere Qualität abzugreifen, als mit der reinen 1080p Aufnahme. -
Ist so ein massiver Unterschied bei gleicher Spielzeit in Anbetracht von Pixel 2D-Sidescroller zu UE4 Engine Spiel aus der Egoperspektive natürlich
Ist durchaus möglich. Das ist schließlich die Eigenart eines CRF Encodes.
-
Beliebige Fehlermeldung allein bringt recht wenig. Am besten schreiben was du vorher gemacht hast und den jeweiligen Log dazu posten.
-
Wird von YouTube meines Wissens nach aber nicht unterstützt und braucht auch deutlich länger beim Kodieren.
-
Wie hast du den Windows-Sound eingestellt? MSI AB nimmt mit der Anzahl an Kanälen auf, wie sie das System vorgibt.
Solltest du 5.1 Sound eingestellt haben, ist es mehr als nachvollziehbar, dass du 6 Kanäle erhältst. -
Welcher codec wäre für 444 notwendig?
MagicYUV 1.2 samt YUV444 Einstellung.
RGB (über UtVideo oder MagicYUV) würde natürlich auch funktionieren, würde aber auch mehr Speicherplatz brauchen.Aber eigentlich reicht mir die Quali so bisher, da ja dann auch die größe der Datei zunimmt, oder vertuhe ich mich da?
Bei der Aufnahme schon, da mehr Informationen gespeichert werden müssen. Die durchs Kodieren entstehende Datei wird aber keine sonderlichen Differenzen in der Dateigröße aufweisen und sonst eine leicht höhere Qualität haben.
-
Also ich nehme mit UtVideo 422 auf und encodiere das dann in x264 .MKV.
Dann verschwendest du letztlich ein paar Informationen. MKV ist übrigens nur ein Container und hat nichts mit x264 zu tun. Vielleicht wird es anhand dieses Bildes etwas deutlicher:
Jeder Pixel hat seinen eigenen Helligkeitswert (Y), teilt sich aber bei YUV422 mit dem jeweilig rechten bzw. linken die Farbinformationen (U+V).
Nun kodiert x264 aber standardmäßig mit YUV420, wo sich 4 Pixel (2x2) jeweils die Farbinformationen teilen, bedeutet du musst entweder dein YUV422 Material in YUV420 konvertieren oder x264 umstellen, dass es in YUV422 kodiert.
Solltest du dich für ersteres entscheiden, so "verwirfst" du quasi jede zweite Zeile an Farbinformationen und hättest sie von vornherein nicht aufnehmen brauchen (Wechsel von UtVideo zu MagicYUV 1.2 mit YUV420), außer du skalierst das Quellmaterial vor dem Kodieren noch. Je mehr Informationen beim Skalieren vorliegen, desto höher qualitativ wird das Ergebnis. Dann wäre sogar YUV444 sinnvoll, falls der PC das schafft, natürlich. -
müsste dann also auf YUY2 einstellen damit alles ok ist?
Wenn du das Material auch von x264 in YUV422 kodieren lässt, ist das korrekt. Ansonsten kannst du es auch gleich in YV12 konvertieren lassen.
-
Also ich nehme mit UtVideo 444 auf.
UtVideo beherrscht kein YUV444. Nur YUV420, YUV422 und RGB. Inkompatible Formate werden in der FFmpeg Variante (OBS Studio) direkt in RGB umgewandelt, was Verschwendung ist.
Zum Farbraum
Dort sollte man das einstellen, womit man am Ende auch kodiert, aber allerhöchstens das, womit man aufgenommen hat. Standardmäßig kodiert x264 (MeGUI) in YUV420 (YV12). Alternativ dazu wären YUV422 (YUY2), YUV444 (YV24) und RGB, je nachdem, wie man nun x264 kodieren lässt.
-
Da ja meine CPU 4 Kerne und 4Threats hat
Der 6700K unterstützt Hyperthreading, daher stehen diesem 2 Threads pro CPU-Kern zur Verfügung, dementsprechend insgesamt 8. Solange es keinen speziellen Grund gibt, würde ich die Threadangabe einfach direkt im SSM auslassen.
Ich nehme eigentlich keine RGB Spiele auf
Alles was du auf deinem Monitor siehst, wird von der Grafikkarte in RGB ausgegeben und intern auch in RGB dargestellt.
Es geht mir eher um Codec und Farbraum im jeweiligen Aufnahmeprogramm. Üblich sind YUV420, YUV422, YUV444 und RGB. Wobei ich eine RGB Aufnahme inzwischen als unnötig ansehe, wenn man Zugriff auf YUV444 mit MagicYUV hat.Habe immer gedacht das er dann den gleichen Farbraum nimmt welches das Rohmaterial hat!
Das ist generell richtig, aber nicht immer gewollt und manchmal auch einfach falsch. Gerade wenn man beispielsweise zwei verschiedene Videos hat, die in unterschiedlichen Farbräumen vorliegen. Diese müssen erst auf einen Nenner gebracht werden.
-
Es gibt keine allgemein gültigen richtigen Einstellungen, genau deswegen gibt es schließlich die Möglichkeit für unterschiedliche Profile.
Ohne zu wissen wie das Grundmaterial ausschaut (MediaInfo), lässt sich auch nicht sagen was sich verbessern lässt.
Folgendes fällt mir allerdings auf:SetMTMode(3,2)
Warum limitierst du das auf 2 Threads? Hat das einen speziellen Grund? Im Regelfall verlangsamst du so nur den Encode.
SameColorAs
"Gleich" im SSM auszuwählen ist nicht zwangsweise richtig. Gerade wenn in RGB aufgenommen und mit MeGUI verarbeitet wird. Ich würde da immer direkt den gewünschten Farbraum angeben.
ResampleHQ
Deaktiviere das am besten gleich wieder. Verlängert in den allermeisten Fällen nur unnötig den Encode.
-
Ich habe letztens einen Stream gehabt und wollte dies dann mit MSI A. Aufnehmen (habe mit OBS Studio gestreamt)
Lass' MSI AB weg und mach beides mit OBS Studio gleichzeitig. Das ist deutlich Performance schonender als ein Spiel mit zwei Hooks (zwei Programmen die das Bild abgreifen) gleichzeitig zu belasten.
-
Tippe stark auf Lagarith. Wird sowieso schon seit einiger Zeit nicht mehr empfohlen.
Wechsel am besten zu UtVideo oder MagicYUV 1.2 und lass das Video dann von VirtualDub umkodieren. -
Ich wollte wissen warum sie identisch kodiert sein müssen, um die Technik dahinter zu verstehen.
-
Die Videos müssen identisch kodiert worden sein, damit zu sie zusammenfügen kannst, siehe MKVToolNix bzw. mkvmerge.
Es wurde nicht umsonst schon früher mal dazu geraten Intro und Outro einmalig zu kodieren und hinterher immer mit den identisch kodierten Videos zusammenzufügen. So spart man sich die immer gleiche wiederholende Kodierung von In-/Outro.