Beiträge von Sagaras

Wurde korrigiert und die Setup selbst wurde auch gefixed in Bezug auf Erstellung der Registry Einträge.

Zitat von Glurak

Btw bei OBS Studio kann man YUV Farb bereich einstellenm von Begrenzt bis voll bei Voll überladet der bei mir auch ziemlich oft sehe aber ehrlich gesagt keinen unterschied in qualy

Es gibt aber ein Qualitätsunterschied. Den wirst du vermutlich nicht mitbekommen.

Der Ausgabe Player ist auch entscheidend wie der ausgibt.

Kann dir aber anhand von 4 Bildern mal zeigen was der Unterschied ist:
:
Video -> Ausgabe Player

PC -> PC = neutral (1:1, 0 = absolutes Schwarz, 255 = absolutes Weiß)

PC -> TV = Dunkler

TV -> PC = matt

TV -> TV = neutral (Ist gleich dem von PC -> PC, 16 = absolutes Schwarz, 235 = absolutes Weiß)

PC Range = Vollbereich (0 - 255), das was RGB ausmacht
TV Range = Limitierter Bereich (16 - 235), das was YUV üblicherweise ausmacht.

Da Youtube jedoch eine TV Range nutzt, weil das nun mal Standard für YUV Formate ist die auch für Filme genutzt wird wie auf DVDs und BluRays, sollte man auch in TV aufnehmen. Einfach um das Ziel des letzten Bildes zu erreichen.

Das spart Speicher und hat im richtigen Player auch den gleichen Effekt wie PC -> PC

Einfach weil der Player dann 16 als absolut Schwarz ansieht und 235 als absolut weiß. Somit nutzt man einen Bereich von 219, statt üblich 255.

Kurz: Der Vollbereich (PC Range) speichert mehr Informationen als der Limitierte Bereich (TV Range). Daher kann man mit einer PC Range Aufnahme besser Color Keying betreiben.

Ideal für Color Keying ist aber natürlich RGB24 und RGB32 Quellen, sowie alle höheren YUV Formate.

Dafür ist das Äquivalent zu h265 auch vp9 oder besser gesagt libvpx-vp9.

Vp9 Encoding dauert aber im Gegensatz zum x264 Encoder länger.

Und x264 ist auch noch mal ein Unterschied zwischen Mainconcept, NVEC, etc. pp. die aber alle unter H264 fallen.

Es gibt gute H264 Encoder und schlechte. x264 gehört soweit zu den besten. Wird auch bei vielen BluRays angewendet, da die Effizienz 2006, glaub ich, gut etabliert hat.

@GrandFiredust
Für ein einzelnes Projekt mag es gehen, ja.

Aber viele wollen auch über dem Schnittprogramm mehrere Projekte als Stapelverarbeitung durchjagen. Und das geht nicht so schön mit x264vfw.

x264vfw kann über den File Output immer nur 1 File ansteuern. Das macht die Codierung von mehreren Projekten quasi nicht möglich. Da x264vfw nicht Bestandteil des Schnittprogrammes ist wird immer der zuletzt eingegebene Dateiname von x264vfw verwendet.

Als Beispiel:
3 Projekte mit z.B. Vegas mit folgenden Namen als Dateiausgabe:

"C:\temp\Video_1.avi"
"C:\temp2\video_2.avi"
"D:\video\video_3.avi"

Gibt man x264vfw jeweils den Dateinamen an bei jedem Projekt, würde immer der letztere Name für jedes File gelten. Somit würde laut dem Beispiel alle Files unter "D:\video\video_3.h264" gespeichert werden.

Weil x264vfw halt für sich alleine steht und an sich nix mit dem Schnittprogramm zu tun hat.

Das würde nur mit der VFW Funktion selbst gehen. Also bei x264vfw nicht als File ausgeben, sondern mit VFW das ganze wieder zum Schnittprogramm leiten und in die AVI stecken lassen.

Technisch Falsch und ziemlich unsauber gelöst.

Ansonsten hier die Batch für ein einzelnes Projekt:

@ECHO OFF
SET _ffmpeg_="G:\FFmpeg\FFmpeg.exe"
SET _flac_="G:\Lets Play Aufnahmen\MeGUI\tools\flac\flac.exe"
SET _mkvmerge_="G:\Lets Play Aufnahmen\MeGUI\tools\mkvmerge\mkvmerge.exe"
SET _iaudio_="audio.avi"
SET _ivideo_="video.h264"


FOR /f "useback tokens=*" %%a IN ('%_iaudio_%') DO SET _iaudio_=%%~a
FOR /f "useback tokens=*" %%a IN ('%_ivideo_%') DO SET _ivideo_=%%~a




%_ffmpeg_% -i "%_iaudio_%" -c:a copy -map 0:a -f wav - | %_flac_% --ignore-chunk-sizes --best - -f -o "%_iaudio_:~0,-4%.flac"
%_mkvmerge_% -o "%_ivideo_:~0,-5%.mkv" "--compression" "0:none" -d "0" --no-chapters -A -S "%_ivideo_%" "--compression" "0:none" -a 0 --no-chapters -D -S "%_iaudio_:~0,-4%.flac" --engage no_cue_duration --engage no_cue_relative_position --ui-language de


REM *** Löschen der Flac Datei (Mit REM kann es heraus kommentiert werden) ***
DEL "%_iaudio_:~0,-4%.flac"


PAUSE

Und warum nimmst du was schlechteres wieder? pcm_alaw ist kein Lossless, sondern ein Lossy Format. Bei FFmpeg wird das übliche G.711 A-Law verwendet.

Telefone arbeiten damit noch. Bzw. alle ISDN Geräte. Das ist recht unterirdisch

G.711 bezeichnet ein max. 8000Hz und 8Bit spezifischen Audiotkanal.

Das will man eigentlich nicht haben xD

Du sollst pcm_s16le nutzen.

Damit du auch die gewohnten Frequenzen und Bittiefen Verlustfrei aufnehmen kannst.
z.B. 48000Hz, 16Bit, stereo

Und das absolut mit mit Verlustfreien Samples/ Klängen.

Zumal pcm_s16le (Signed 16Bit little Endian) eine sehr hohe Kompatibilität aufweist zu jedem Programm was WAV PCM laden kann.

Als gutes Beispiel nehme ich mal eine Apfelsortiermaschine an einem Fließband.

Das Fließband soll jetzt mal die Geschwindigkeit darstellen. Der Sortierer die Qualität.

Stell dir vor auf dem Fließband sind allerlei Äpfel in Formen und Farben. Darunter Schlechte wie gammlig, mit Würmern bestückt, schrumplig, usw...

Der Sortierer hat nun die Aufgabe in der Zeit mit dem das Fließband läuft, diese schlechten Äpfel aus zu sortieren.

Der Sortierer macht seine Arbeit, hinterlässt aber hin und wieder mal ein paar schlechte die nicht erfasst wurden.

Würde das Band nun schneller laufen, würden noch mehr schlechte Äpfel vorhanden sein. Was natürlich die Qualität der Ware mindert.

Würde das Band langsamer laufen, würden noch mehr schlechte Äpfel aussortiert werden. Was dann natürlich die Qualität der Ware steigert.

Anderes Beispiel:
Du hast als Chef x Arbeiter zur Verfügung und willst Qualitativ ein als Bauleiter ein Haus errichten in einer bestimmten Zeit.

Die Arbeiter symbolisieren hier mal deine CPU. Das Haus die Qualität und die Zeit für den Werdegang der benötigt wird.

Je mehr Leute, desto schneller. Denkt man meist. Nehmen wir mal an du hast 100 Arbeiter. Glaube nicht das 100 Arbeiter zusammen das Fundament legen oder das Dach bauen.

Jetzt sagst du, das müsse zügig gehen und innerhalb von 1 oder 2 Wochen fertig sein. Qualitativ gesehen wurde dann aber gewiss geschlampt. Denn Qualität braucht Zeit. Und somit wäre das Haus in 6 Monaten qualitativ sehr hochwertig aufgebaut.

So muss man bei Verlustbehafteten Codecs denken.

Bei Lossless müsste man sich ein Fertighaus vorstellen das einfach mit nem Helikopter abgeworfen wird und perfekt auf dem Grundstück steht

Genauso bei den Äpfeln. Lossless wäre hinsichtlich der Äpfel das es keine Sortierung gibt und das Band in vollen Maße durchrauschen kann.

Lossless = 1:1, Input = Output

gute Qualität und kleine Dateigrößen brauchen also Zeit.

Das Dreieck was Julien gepostet hat hat also seine Daseinsberechtigung.

In der Wirtschaft setzt sich das Dreieck meist aus Kosten, Zeit und Qualität zusammen.

Daher ist es utopisch mit wenig Zeit (ideal ist 1 zu 1) ein Video zu encodieren das hohe Qualität hat und dabei noch sehr klein in der Dateigröße ist.

Daher hier mal ein erweitertes Dreieck von mir wo die Bereiche sind, in der man sich so üblicherweise bewegt:

@GelberDrache92 habe ich das Ding schon mal erklärt. Es sieht auf den ersten Blick für den ein oder anderen vllt. nicht gleich verständlich aus. So sieht aber das Dreieck korrekt aus, wenn man ihn Bereiche zuteilt.

Das neutrale Lossy bildet das Zentrum aus ausgewogener Encodierungsdauer, Qualität und Dateigröße

Zitat von MrPanda

Mit UTVideo und I420 Farbraum geht es, die Dateien werden wieder bei paar Sekunden 1 GB groß aber das bin ich ja gewohnt von FIFA XDD

Edit: Zu früh gefreut, hab jetzt keine Sounddatei mehr die bei Sony Vegas Pro 13 hinzugefügt wird..

Audiocodec bei FFmpeg sollte sein: pcm_s16le (Pulse Code Modulation Signed 16bit Little Endian) (Das was üblicherweise in ein WAV Container kommt.)
Wird dann zusammen mit UTvideo in ein AVI Container gespeichert.

AC3 ist so ziemlich das schlechteste und ist auch nicht grad AVI Compatible glaub ich.

Zitat von MrPanda

Mit dem Streamencoder gibt es weiter probleme, die Kodierung ist bei I420 Farbraum nicht ausgelastet aber dafür ist das Bild nicht vorhanden..

Zum Streamen selbst sollst du auch NV12 nutzen und nicht i420.

Die unterscheiden sich nicht in der Qualität, sondern in ihrem Aufbau als Farbraum. NV12 ist einfach schneller und performanter beim Aufbau, als i420.

Die Kodierung überlastet, weil x264 eigentlich gar nicht für lokale Aufnahmen gedacht ist. OBS ist in erster Linie eine Streaming Software.
Und entsprechend so stellt man auch den x264 Encoder auch ein.

Habe dir auch geschrieben was sich alles anhängt. Wenn du da eine 1080p Aufnahme mit 60FPS machen willst mit einer recht Kodierungslastigen Einstellung, ist das klar das die CPU zusammenbricht. Das würde sie ja schon bei einer normalen Encodierung mit MeGUI. xD

Und OBS Studio wäre denke ich mal das bessere was du suchst: https://github.com/jp9000/obs-…udio-0.14.2-Installer.exe

Da kannst du dann auch UTVideo nutzen als Aufnahme Codec über FFmpeg. Das wäre Verlustfrei und CPU schonender.

Oder du nimmst weiter Verlustbehaftet auf, reduzierst die Bitrate mehr, hast am Ende eigentlich nur noch ein ekelhaftes Video, Encodierst es noch mal über Vegas und lädst das Ergebnis auf YT und hast am finalen Ende nur noch Brei.

Mehr CPU Aufwand bei mieser Qualität. Kann man machen, muss man aber nicht.

Warum nimmst du x264 über FFmpeg, wenn OBS x264 intern hat? Die Logik erschließt sich mir grad nicht. OBS's x264 ist doch viel schneller.

Wenn man Verlustbehaftet aufnehmen will z.B. für Streaming, dann sollte man in OBS den Farbraum NV12 nutzen mit der Farbmatrix BT.709 und für Gewöhnlich nutzt man dann auch einen limitierten Farbbereich (TV Range).

Da Streaming relativ CPU lastig sind, hängt damit zusammen das während der Aufnahme die Aufnahme selbst live encodiert wird.

Für x264 ist daher sehr relevant: Auflösung, FPS, Farbraum. Je größer diese Werte, desto Wahrscheinlicher ist es das die CPU zusammenbricht.

Auch die Einstellung von x264 kann die CPU Nutzung überfordern. Immerhin muss die komplette Encodierung Live geschehen, während der Aufnahme.

Zumal 20Mbit für Streaming ganz schön schon ist. Und das für eine Live Encodierung.

Also x264 sollte bei einer Live Encodierung auf Ultrafast gestellt werden und die Bitrate entsprechend des Uploads entsprechen.

Weil Kompressionsmechanismen benötigen CPU und dazu verbrauchen sie Zeit, die du einfach nicht hast. Kannst ja dein Speicher nicht voll laufen lassen wegen sowas. Vllt. kann man noch geringe Kompressionen verwenden wie mit Einstellungen von Superfast, etc.
Aber auch das muss dein Rechner schaffen.

Ideal wäre, wenn es dann lokale Aufnahmen sein sollen, diese Verlustfrei aufzunehmen. Halt wenn keine Live Aufnahmen sein sollen.
Dazu kann man mit OBS Studio z.B. via FFmpeg auch Lossless aufnehmen. z.B. mit UTVideo oder Lagarith.

Um das dann in Vegas laden zu können muss man sich die entsprechenden Codecs installieren.

Lossless hat den Vorteil das es kaum Kompressionen nutzt. Daher sind Lossless Codecs auch ziemlich schnell und benötigen so gut wie gar keine CPU. Denn der geringe Teil an CPU der da einfließen tut, wird für die kleine Kompression genutzt. Und da es schnelle Kompressionstechniken sind, geht das sehr rasant.

x264 kann ja auch Lossless aufnehmen. Dazu wird auch kaum CPU genutzt. Einstellung auf das Preset Ultrafast + eine Angabe in die Custom CommandLine mit qp=0.

Das wird dein Vegas nur nicht lesen können, weil Vegas das High 4:4:4 Profile nicht einlesen kann von h264. Einfach weil dein Vegas mit den Codecs im Mittelalter von Win2000 noch lebt

Aber ich sag mal, auch dann wäre die Decodierung solch einer Aufnahme mit x264 extrem langsam.

Daher der Rat, bei richtigen Aufnahmen einen entsprechend schnellen Encoder zu verwenden. Wenn du dann noch Qualität haben willst ist und bleibt ein Lossless Codec unabdingbar.

Für Ein Lossless Encoder wie UTVideo oder Lagarith, stellt man bei OBS Studio den Farbraum min auf YV12. Denn NV12 kann UTVideo nicht erkennen und würde das Glatt als RGB aufnehmen. Farbmatrix ist klar mit BT.709. Also die gleiche wie YT auch. Und dann in TV Range aufnehmen am besten.

Zitat von PaxDeLux

Ganz besonders für Aufnahmen im 30 fps bereich (ich denke da ganz besonders an ältere titel und Emulatoren etc.) ist es super angenehm.

Meines Wissens läuft so ziemlich jeder Emulator mit min. 50Hz / 50 FPS. bzw. 60Hz / 60 FPS. Kann ich auch gerne Belegen und wenn es denn sein muss auch anhand der Frames sowas auch nachweisen.

Die Frage hier ist vielmehr: Erkennst du Wirklich den Unterschied zwischen 30 und 60 FPS? Wenn ja, dann sollte das selbst bei Emulatoren auffallen.

Zitat von PaxDeLux

Es sei allerdings vermerkt: Gegen Ende des Jahres werde ich ohnehin upgraden und mir ein neues System zusammenstellen, will erstmal die Berichte über die GTX 1080 und die neue von ATI abwarten, also ist alles bis dahin nur eine Frage der Kompatibilität mit meinen Komponenten

Wenn du dir damit ein schnelleres Encoding versprichst, dann wirst du damit leider enttäuscht. Selbst bei Aufnahmen wird das nicht viel bringen, außer das die Game FPS stabiler bleibt. Die Aufnahme selbst geschieht durch das Hooking der Aufnahmesoftware und hat absolut nix mit der Grafikkartenleistung zu tun.

Zitat von PaxDeLux

Ich hab jetzt MGSV in 1080p mit stabilen 60 fps per OBS Studio auf CRF15 aufgenommen

Den Sinn hinter Lossless (Verlustfreie) Aufnahmen haste leider noch nicht verstanden. Du Bearbeitest das Video doch eh.

Was soll denn da raus kommen? CRF15 und dann noch mal mit CRF21 im Nachhinein. Hättest dann auch gleich in CRF35 aufnehmen können. Wäre der selbe Effekt gewesen nur ohne Bearbeitung xD

Das ist wie als würdest du ein Rauschsignal aufnehmen und es dann noch mal senden und noch mal aufnehmen. Was bekommt man zurück? Richtig, ein noch stärkeres Rauschen. Genau das machste mit Verlustbehafteten Aufnahmen. Das was du eigentlich vermeiden möchtest

Zitat von PaxDeLux

das ganze dann in Vegas lediglich zugeschnitten und farblich ein klein wenig aufgebessert weil es nach meinem Ermessen ein wenig ausgeblichen war (kein Qualitätsverlust zum originalen, lediglich die farben etwas weniger knackig gewesen)

Hier sollteste dich mal mit Farbmatrizen des YUV Farbraumes auseinandersetzen und auch den Unterschied zwischen TV vs PC Bereich von YUV Farbräumen.

Du manipulierst an den Farben rum, hast aber keine Ahnung warum das so ist im Video.

Stell dir vor: Du denkst jetzt, weil du dein Video matt siehst, das du die Farben sättigen musst. Einfach damit das Bild knackiger aussieht. Du lädst das Video hoch und es sieht für dich vllt normal aus, aber diejenigen die es sich nun mit anderen Browsern anschauen oder mit nem Handy oder mit ner Playstation oder was auch immer, für die wird das Video recht dunkel sein, bzw. übersättigt. Und das nur, weil du nicht wusstest das YUV Farbräume immer eine spezifische Farbmatrix haben + das ein YUV Farbraum in TV oder PC Bereich sein kann. TV = Begrenzter Bereich, PC = Vollbereich.

Daraus setzt sich ja der YUV Farbraum zusammen ;D

Und das sollte man bei der Aufnahme schon berücksichtigen: BT.709 TV Range
Das sollte man im Schnittprogramm berücksichtigen.
Das sollte man auch beim finalen Encoder berücksichtigen.
Und man sollte es auch bei der Grafikkarte und Player berücksichtigen.

Fazit für YT:
YT benutzt BT.709 + TV Range für alle Videos, demnach sollten auch die Videos encodiert werden.

Dabei kann nun resultieren wenn man jeweils ein Video auf YT läd:
PC -> TV = dunkel
TV -> TV = neutral

Hat die Grafikkarte einen Einfluss auf den Player im Browser (Chrome z.B.), dann kann folgendes passieren, wenn die Player Einstellung in der Grafikkarten Einstellung auf TV Bereich steht:
PC -> TV -> TV = neutral
TV -> TV -> TV = matt

Stellt man diese Player Einstellung auf PC Bereich, entsteht wieder das normale Muster:
PC -> PC -> TV = dunkel
TV -> PC -> TV = neutral

Und die Farbmatrix ist beschreibt die Farbintensität. Dabei verwendet man:
BT.601 für SD Auflösungen
BT.709 für HD Auflösungen (ab 720p aufwärts)
Und ab 4K nutzt man eigentlich BT.2020 für UHD Auflösungen (ab 2160p aufwärts)

Letzteres wird YT vermutlich nicht supporten.

BT.601 sieht etwas lascher aus, während BT.709 kräftiger daherkommt. BT.2020 liegt so zwischen BT.601 und BT.709. Bei BT.2020 kommen die Farben mehr von der Gesamtauflösung besser zur Geltung, weshalb man da etwas entgegen gesetzt wirkt.

Das zu diesem Punkt.

PS: Habe dir ja angeboten das ich dir das auch gerne via TS3 das ganze Aufnahme, Encoding, Verarbeitung, etc. pp. erklären kann. Da musst du jetzt nicht immer Stück für Stück den Thread A) in die Länge ziehen und B) ein Fehler nach dem anderen wieder machen.

Lass es mich anders ausdrücken: Ich weiß das keiner perfekt ist, und ich weiß das diese dämliche Theorie vllt. sogar nervt. Aber im Endeffekt möchte man ja gute Videos abliefern. Und das geht eigentlich auch nur dann, wenn man ein gewissen Grad an Theorie und Praxis kennt und weiß wie man es nutzen kann.
Aber diese graue Theorie und die Praxis, werden dir hier nur wenige ausführlich eine Antwort geben. Ich bin immer der Meinung: Sehen und Verstehen.
Daher könnte ich dir auch via TeamViewer die Theorie in der Praxis zeigen und auch erklären, wenn du es möchtest. Ich denke das du dann vllt. auch eine ganz andere Sichtweise bekommen wirst.

Ich kann dir das Ganze nur Zeigen und Erklären. Was du dann im Endeffekt danach machst mit diesem Thread hier und auch Persönlich ist mir dann eigentlich egal. Das ist dir dann überlassen

Ich schreibe das, weil ich genau weiß das sich dieser Thread mit Beitragen füllen wird, wo jeder seine persönlichen Einstellungen und Meinungen dazu gibt. Ist ja auch nicht verkehrt. Aber man sollte schon wissen welcher Hebel was bewirkt und nicht einfach nur Einstellungen kopieren.

Kopieren kann jeder. Kapieren fällt in diesem Forum den Usern meist schwer. Entweder ist es zu Uninteressant oder zu Kompliziert oder einfach nur zu Zeitaufwendig. Und das ist eigentlich das was im Internet mit diversen Tutorials passiert. Zu wenig Infos, zu wenig Fachwissen, und vor allem Bullshit Einstellungen und Bullshit Vergleiche oft. Youtube ist schließlich voll davon mit solchen Videos wo User nur Kopiert haben, aber 0 Wissen was sie da eigentlich machen.

Das schnellste wäre Lossless. Der Kontra wäre große Dateien.

Geschwindigkeit von 1 zu 1 wäre so ganz pauschal: Preset: superfast oder ultrafast und einen beliebigen CRF.
Hier sei erwähnt das sowas Qualitätsmäßig nach hinten gehen kann. Daher hier bitte einen CRF von min 15 oder niedrieger angeben. Folge wäre immernoch eine riesige Datei.
Oder man nimmt ein gutes Preset wie medium oder fast und nimmt dafür Bitraten statt CRF die weit Jenseits von akzeptabler Qualität liegt. In diesem Falle würde die Codierung auch ziemlich rasch gehen. Halt auf kosten der Qualität. Hast aber entsprechend kleine Dateien.

Weil einen sehr schnellen Encode bekommst du nur, wenn du eines der dreien nimmst.

Eine Bremse liegt meist auch im Schnittprogramm. Denn ein Schnittprogramm berechnet die Frames komplett neu. Je höher die Auflösung, die FPS und auch die Anzahl an Filter im Schnittprogramm (Effekte), können den Encode ausbremsen.

Das Ganze ist natürlich immer abhängig von der CPU die man hat. Und wenn das Schnittprogramm die Frame Neuberechnungen (Rendervorgang)
via GPU noch macht, könnte man den Vorgang auch noch etwas beschleunigen.

Flaschenhälse wurden ja schon genannt. Mein Rat wäre an dieser Stelle ja das du x264vfw nimmst. Da würden schon mal alle Frameserver wegfallen und könntest x264 gleich über dein Schnittprogramm nutzen.

Aber alles hat seine Vor- und auch Nachteile.

Es gibt halt keine perfekte Lösung Höstens eine akzeptable

Mal so am Rande: Wie schnell sollte es denn nach deiner Meinung sein?

Zitat von stefan_wayne

Was gibt den Farbraum vor? Das Spiel oder die Einstellungen von Afterburner beispielsweise?

Dein Betriebssystem läuft für Gewöhnlich mit RGB32 (32Bit)

Früher gab es noch RGB24 (Kann man bei bestimmten PCs/OS immer noch einstellen) (24Bit)

RGB16 (Wäre eine Palette von Farben mit 65.536 Farben) (16Bit)

Und MS-DOS lief mit VGA mit 256 Farben die zusammen eine Palette bildeten.

Auf jedenfall läuft erstmal jedes neuartige Spiel auf deinem Rechner immer mit RGB32.

Bei der Aufnahme kann man das schon runter brechen. Denn RGB32 und RGB24 wären 1:1 Aufnahmen deines Games/Bildes was du am Monitor sehen würdest.

Schlechter wird es mit YV24 (alias YUV 4:4:4) wo an sich die Farben nun auf eine Matrix aufbauen und nicht mehr dem RGB entsprechen. Die RGB -> YUV Konvertierung die bei einer Aufnahme laufen kann, sparrt Speicherplatz auf der Festplatte, da YUV kompakter ist wie es die Informationen speichert.

Dann gibt es noch YUY2 (alias YUV 4:2:2) und YV12 (alias YUV 4:2:0). Die beiden Farbräume sparen Speicherplatz indem sie die Chromabilder (Farben) einfach verkleinern. Sprich sieht es im Endeffekt mehr verschmiert aus.

Je besser also der Farbraum ist (RGB z.B.), desto besser kann nachbearbeitet werden mit Skalierer und anderen Filtern, ohne die eigentliche Qualität des Bildes noch mal zu verschlechtern.

Je schlechter der Farbraum ist (YV12 z.B.), desto schlimmer können Nachbearbeitungen enden. Skalierer z.B. können dann nicht effektiv arbeiten und verschmieren halt noch mehr als es schon ist.

Das zur grauen Theorie.

Mit welchen Farbraum du aufnimmst, ist aber dir überlassen. Fest steht, deine Spiele werden vermutlich alle mit RGB32 laufen. Wie du aber dieses RGB aufnimmst, bestimmst du im Aufnahmeprogramm mit dem Codec selbst.

Edit:
Im SSM, kann der Farbraum eigentlich auf YV12 gelassen werden. Sollte eigentlich auch Standard gewesen sein. Denn zum einen braucht es für höhere Farbräume A) Videos die ebenfalls höhere Farbräume aufweisen und B) muss der Encoder z.B. x264 in MeGUI entsprechend auf den neuen Farbraum abgeändert werden. Standard nutzt x264 immer YV12.

Und an sich reicht das eigentlich auch. Es sei denn man will noch mehr rausbekommen als üblich. Dann muss man den Workflow beim Encoding etwas abändern ;D

Zitat von stefan_wayne

Edit: Die Fehlermeldung ist: "Splice: Video formats don't match (Dateipfad, line 13)
Der Fehler erscheint bei virtual dub und bei megui, der scriptmaker sieht das entspannt.

Kann nur darauf deuten das der Farbraum unterschiedlich ist. Beim SSM unter Farbe den Farbraum bitte angeben und nicht auf Gleich stellen.

Bei unterschiedlicher Framerate kommt diese Fehlermeldung:
Splice: Video framerate doesn't match
Lösung: Im SSM den Haken unter Video -> FPS ändern anhaken und eine neue manuelle FPS für beide Videos angeben. Können schließlich nicht beide mit unterschiedlicher FPS in einem Video sein. Vor allem nicht wenn AVISynth nur CFR kann ;D

Bei einem Auflösungsproblem zweier Videos würde diese Fehlermeldung kommen:
Splice: Frame sizes don't match
Lösung: Im SSM wird vermutlich eine Faktorenskalierung vorliegen, aber die Basis beider Videos in der Liste haben schon unterschiedliche Auflösungen. Folge ist das nach einer Faktorenskalierung die Auflösungen beider Videos auch ungleich bleibt. Daher bei 2 Video mit unterschiedlicher Basis von Auflösungen immer eine fixe Auflösung wählen für alle.

Und wenn es ein Problem mit dem Farbraum gibt, gibt es diese Fehlermeldung:
Splice: Video formats don't match
Lösung #1: Im SSM unter Farbe den Farbraum nicht auf gleich stellen, sofern beide Videos unterschiedliche Basis Farbräume haben.
Lösung #2: Den Pixel Type unter Video für das markierte Video in der Liste auf einen Farbraum stellen der A) der Codec unterstützt und B) muss es dem anderen Video entsprechen. Dieser Weg ist aber erst dann relevant, sollte das eingelesene Video ein Fehlverhalten von Farben darstellen. z.B. einen Grünschleier aufweisen.

Ganz simple

Ich sehe in den Projekteinstellungen (Also in den Bildern) das der Audio Track immer mit 44100Hz behandelt wird. Auch die Aufnahme ist ja 44100Hz. Warum ist dann das fertige File mit 48000Hz? Diesen Schritt kann ich leider nirgends nachvollziehen. Kann also unter anderem daran auch liegen.

Bei 10min Länge z.B.

600s * 44100Hz = 26460000 Samples

26460000 Samples / 48000Hz = 551,25s = 9min und 18sek 750ms

Wäre schon eine erhebliche Abweichung.

Das ist nur dann so, wenn der Sound neu resamplt wurde ohne Samples rausgeworfen zu haben.

Noch besser sieht es dann halt aus, wenn man nicht ausgerechnet mit OBS skaliert, sondern mit was anderem, neutralerem.

@PaxDeLux
Wenn du jemanden brauchen solltest um etwas tiefer in die Materie zu kommen, wie, warum und weshalb es so und so am besten wäre, kannst du einige von uns oder mich auch privat anschreiben. Dann machen wir ein Termin aus für TS3, Skype oder was weiß ich. Eventuell auch noch unter Einsatz von TeamViewer. Und dann können einige von uns auch das sehr Detailiert wiedergeben und zeigen. Oder man kann das Ganze auch sehr kurz fassen und vernachlässigt halt das Verständnis dahinter. Man weiß dann wie es geht, aber nicht warum es so am besten ist.

Wäre dann deine Entscheidung.

Und ich denke das du erst einmal eine Basis brauchst worauf du aufbauen tust.

Was wird denn aufgenommen? Emulator, irgend ein Windows Game?

Sicher das die Aufnahmedatei beschädigt ist oder Premiere das nur nicht korrekt laden kann?

Ich würde einfach mal bitten Einstellungen von den Aufnahmeprogrammen zu posten und natürlich auch Infos zu den Aufnahmefestplatten.

Erst letztens gab es ein Thread wo die Festplatte einfach die Verbindung getrennt hat und wieder aufgebaut hat. Ergo würde bei sowas die Aufnahme abbrechen oder Fehler verursachen.