Beiträge von Sagaras

Zitat von Dennis_50300

wenn irgendwas mehr als 16-tatsächlich nutzen sollte würde man sich eh die Ohren zerstören...

Wie kommst du denn dadrauf?
Was hat bei dir die Audio Bittiefe damit zu tun das deine Ohren geschädigt werden? xD

Um deine Ohren zu schädigen reichen auch 8Bit Audio Tiefe aus oder gar noch weniger. Die Frage ist nur wie du deine Boxen und oder Verstärker einstellst.
Wenn du dir fette Boxen mit ordentlich viel Bass hinstellst die fett Druck in deinen Ohren erzeugen oder dich anderweitig 90 - 110 dB aussetzen tust, ob Kopfhörer oder was auch immer, dann kannst du von Gehörschaden reden. Und das mit einer 8Bit Audiodatei.

Es kann dir rein gar nix passieren wenn du eine geregelte Lautstärke hast. Da kannst du auch 32Bit Audio haben. Da passiert mit den Ohren gar nix.

Zitat von Dennis_50300

Du mal ne Frage, kann man im Scriptmaker nicht auch bei Audio, bei der Abtastrate und der Abtasttiefe das ganz eleganter gestalten "wie Quelle" oder so auf die Art ?
Wenn ich ne 44100Hz Quelle hab und da warum auch immer 48kHz eingestellt sind zuletzt wird ja wohl sicherlich resampelt oder ?

Werde ich nicht weiter ändern. Einfach aus 2 Gründe:

• Wenn mehrere Videos in der Liste sind und alle haben Audio mit unterschiedlicher Abtastrate, so könnten diese Videos nicht zusammengesetzt werden. Also muss eine Basis dafür herhalten. Und die gibt man am besten selbst ein
• Wenn ich das umändern sollte, würde genau das auftreten was du gerade für so "Elegant" bezeichnest. Stell dir vor der User hat ein Intro mit 44100Hz. Seine LPs macht er aber mit 48000Hz.
  Da das Intro zuerst in der Liste wäre, würde die Einstellung "wie Quelle" die Abtastrate des Intros nehmen. Und Boom, ist dein Gameplay auch mit 44100Hz. Wodurch seine Mühe es mit 48kHz es aufzunehmen und zu bearbeiten vergebens waren.
  Genauso blöd wenn es umgekehrt wäre. Weil dann steigt ja die Dateigröße.
  

  
  

  So wie es jetzt ist, weiß jeder was er da tut.

  
  

  
  

Eine niedrigere Abtastrate in eine höhere zu konvertieren ist akzeptabel und zerstört nix an der Audiodatei. Im Grunde wird die Abtastrate dank Interpolation neuer Samples (Deswegen heißt es auch Resample) auf eine höhere gebracht. Bedeutet wenn du 44100Hz hast, hast du genau 44100 Samples pro Sekunde. Diese werden ergänzt, sofern du sie auf 48000Hz hochdrehst beim SSM. Also werden genau 3900 Samples passgenau hinzugefügt und gleichmäßig verteilt für diese eine Sekunde. Ergo passiert dem Audio nix. Da die Informationen ja alle noch vorhanden sind. Die Kurven werden dann halt nur weicher, sauberer.

Andersrum passiert da auch relativ wenig. Wenn du 48kHz auf 44,1kHz hinunter resamplen tust. Da werden halt genauso in einer Sekunde genau 3900 Samples entfernt und die verbleibenden werden sorgfältig und gleichmäßig über die Sekunde verteilt.

Solange man da nicht übertreibt mit, passiert selbst mit dem Hinunter Samplen nicht sonderlich viel. Würde man es übertreiben würde das sich das dadurch zeigen das sich die Amplituden einengen und der Ton dumpfer wirkt. Weil ist ja dann klar, die Abstände zwischen zwei Samples werden z.B. bei 8000Hz und niedriger immer größer. Wichtige Samples die vllt. vorher noch da waren bei 44100Hz sind auf einmal weg. Und so verblasst das ganze

Hochsamplen kannst du das aber bis ins unendliche. Dein 44100Hz Audio wird dadurch nicht genauer. Es wird dann halt nur weiter aufgebläht.

Das ist wie mit der FPS beim Video. Du siehst ja auch einen Unterschied zwischen 60 FPS Videos und 10 FPS Videos
Aber ebensogut kannste 10 FPS in 60 FPS hochrechnen lassen. Das Video ist dann zwars in 60 FPS, aber optisch haste dann immer noch die 10 FPS. Also auch nur aufgebläht. xD

Und die Audiotiefe ist wie mit der Farbtiefe beim Video vergleichbar. Je höher, desto klarer der Klang. Je niedriger, desto unsauberer wird er. Daher hast du mit 8Bit Audio ja auch einen Effekt der wie ein alter Radiosender sich anhört.
Bedeutet wenn du 24Bit Audiotiefe hast, dann hast du einfach nur ein größeren Raum für deine Samples / Töne. Mehr nicht. Meist werden 24Bit und 32Bit ohnehin eher von Musik Studios verwendet oder in Film Studios. Der normale Otto Normal Youtuber bräuchte es nicht. Es sei denn er ist Tontechniker und weiß was er da tut.

Ich würde dir vorschlagen du liest erst mal was es mit DC und DCT auf sich hat, und warum man da auch 9 und 11 Bit nutzen kann. Das hat nix mit der Bittiefe vom Encoder zu tun. Du kannst genausogut die DC Präzision beim 8Bit Encoder auf 9bit stellen. Dein Video wird dadurch trotzdem immer noch 8Bit anzeigen, aber die Präzision ist höher.
Das ist wie als würdest du dem Video mehr Schärfe verleihen.

Wie gesagt: http://www.burosch.de/technik/…eorie-und-grundlagen.html
Lese dir das durch, dann weißte eventuell auch was das ist.

Und würdest du deinen Thread den du mir da verlinkt hast aufmerksamer gelesen haben, dann würdest du auch lesen können das selbst einige DVDs mit einem 11Bit DCT Koeffizienten encodiert worden sind. Dadurch sind sie aber immer noch 8Bit in der Farbtiefe. Und das wird dir auch Mediainfo so bestätigen. Denn MPEG2 kann keine höheren Farbtiefen als 8Bit verarbeiten. Du kannst aber die Tiefe des DCT höher legen, damit du mehr Schärfe ins Video bekommst.

Lese dir bitte die Grundlagen durch. Und dann rede ich gerne noch mal mit dir über DC und DCT.

Wenn du möchtest kannste auch das hier nutzen: https://de.wikipedia.org/wiki/Diskrete_Kosinustransformation

Zitat von De-M-oN

Ja. Ich meinte ja auch nicht UTVideo...
_
Jo. Nur schrieb ich nichts von RGB.

Ob nun bei RGB 10Bit Farbtiefe verwendet wird oder bei x264, ist total wurscht, weil es durch die meisten Player wieder auf 8Bit gedithert wird.
Und es wird in der Tat die Farbtiefe damit beschrieben.

Weil in deinem Link wird eher der Prozess von 8Bit zu 10Bit beschrieben und die Effizienz dahinter warum die Komprimierbarkeit besser ist. Und das hat dann in der Tat was mit dem DC und DCT wie ich schon in meinem letzten Beitrag gesagt habe zu tun. Und da gebe ich dir dann auch recht das bei einem 10Bit Encoder die Präzision höher ist. Das ist absolut korrekt. Jedoch ist auch der Farbraum höher.

Sonst würde es auch kein 10Bit RGB existieren, wenn es nur eine YUV basierende DC Präzisions Steigerung ist. Siehe UtVideo.
DC und DCT sind für die Verlustbehaftete Encodierung hauptsächlich interessant.

Und ich will dich damit auch nicht runterziehen oder sonstwas, sondern einfach dir mal sagen das du dich vorher mal richtig damit auseinander setzen solltest.

Schau dir Bilder an wie PNG. Die können Farbtiefen von bis zu 16bit erreichen. Bedeutet MPNG könnte theoretisch ein 16Bit RGB Video beinhalten. Kannste dir ja dann ausrechnen: 3 * 16 = 48bit. Das doppelte von einem RGB24
Und da es nicht dargestellt werden kann auf der Ausgabe eines PCs, weil nur 8Bit Tiefe ala 24Bit + Alpha, werden diese Bilder gedithert.

Bei einem 10Bit Monitor würdest du aber noch mehr feinheiten beim Bild selbst sehen.

Du musst das unbedingt mal trennen. Farbtiefe und DC/DCT Präzision sind 2 verschiedene Dinge. Beide arbeiten aber mit einer bestimmten Bit Tiefe. Die kannste bei MPEG2 wie gesagt sogar auf 9 stellen. Und trotzdem ist und bleibt es 8Bit.
Und genauso kannste bei H264 das die DC/DCT Präzision auf 8bit stellen, hast aber trotzdem 10Bit Farbtiefe. Macht man nur nicht, weil sonst hättest du ja auch kaum Gewinn daraus, weil dann hätteste auch gleich 8Bit nutzen können.
Die Verteilung der Pixel im DCT wird durch eine höhere Präzision bei Verlustvideo besser verteilt. Darum hast du auch bei gleicher Bitrate ein besseres Bild. Das zeigt sich dann halt im auch teils im Banding.

Bei UTVideo gibt es aber 10Bit RGB. Und die beschreiben in der Tat die Farbtiefe.

http://board.gulli.com/thread/…7&p=14388645#post14388645

Zitat von De-M-oN

Die 10bit beim 10bit x264 encoder beziehen sich jedoch auf die DC Präzision, nicht auf die Farbkanäle. Die sind weiterhin 8bit pro kanal minus chroma downsampling.

Jain. In der Tat wird die DCT Präzision angehoben aufgrund das mehr Platz da ist. Sonst würdest du schon mal kein besseres Banding bekommen.
Sprich die DCT Präzision wird feiner durchgeführt gedithert und dadurch, aufgrund das der Farbraum eine höhere Farbtiefe erlaubt. Sonst würde der Spaß schon mal gar nicht gehen.
Für die Ausgabe jedoch wird von 10Bit auf 8Bit wieder herunter gedithert. Da aber die Informationen viel genauer sind, können auch mit recht niedrigeren Bitraten bei einer 10 zu 8 Farbtiefenkonvertierung bessere Ergebnisse erzielt werden. Das siehste ja entsprechend jedesmal auch auf YT.

Aber eine DC Präzision von 10 kannste auch schon bei MPEG2 finden auf DVDs z.B. max. konnten die auch bis 11bit gehen.

Bei der 10Bit Angabe vom Video aber ist die Farbtiefe gemeint, denn MPEG2 kann ja ebenfalls mit 11bit DC umgehen. Ist aber trotzdem immernoch ein 8Bit Video.

DC = Direct Current
DCT = Diskrete Cosinus Transformation

Also... Y, U und V werden in kleinere Quadrate aufgeteilt. 8x8 z.B.

Das Ergebnis daraus ist ein DC

Hinzukommt nun der AC Anteil der mehrere solcher DC's beinhaltet. Je größer der AC, desto feiner wird das Bild.
Da hast du dann Sachen wie 1x1 (DC only), 2x2, 4x4 oder 8x8
Je größer, desto feiner die Frequenzanteile. Also desto feiner wird das Bild. Und desto weniger Klötze hast du im Bild.

Sollteste dir vllt. mal durchlesen: http://www.burosch.de/technik/…eorie-und-grundlagen.html
Punkt: Überführung in den Frequenzbereich.

Ist zwars für JPEG, aber YUV Bilder haben ja alle was mit DC und DCT zu tun.

Der nächste Sachverhalt der deine falsche Annahme zum Wanken bringt ist der das du bei RGB nix mehr mit DC und DCT zu tun hast, da es an sich nur YUV Material betrifft der nun mal bei x264 hauptsächlich zum Einsatz kommt.

--fps 30000/1001 = 29.97 FPS
--fps 30000/1000 = 30 FPS
--fps 30/1 = 30 FPS
--fps 30.000 = 30 FPS
--fps 30 = 30 FPS
--fps 60/2 = 30 FPS

Ist alles Wumpe. Halt nur drauf Achten das Zähler und Nenner auf die gewünschte FPS kommen.
30000/1001 ist für NTSC
Kann auch schreiben 30/1,001, aber die Angaben verabscheuen Kommastellen bei Bruchrechnung. Daher Ganzzahlig mit 30000/1001

Und für exakt 30 ist kann man das angeben wie man möchte. Hauptsache es kommt später die FPS da rein die man im Schnittprogramm für dieses Video auch vorgesehen hatte.

Und der CRF ist mit 10 recht hoch angesetzt. Empfehlen würde sich da Werte zwischen 18 und 23 für ein gutes Ergebnis.
Bei 10 pumpst du zwars mehr Bitrate und somit auch Qualität rein. Aber das ist schon in einem Bereich wo du mit ner Lupe die Pixel vergleichst langsam und das bei nem Standbild.

Auf YT bewegen sich die Bilder und ein Zuschauer wird da rein gar nix erkennen wenn du das Video mit CRF 10 oder CRF 18 hochgeladen hast. Außer wenn man es dem Zuschauer sagt.

Und den Level würde ich mal auf Auto lassen bei x264vfw. Da brauchst du nix dran schrauben.
Zero Latency ebenfalls nicht anhaken. Weg mit dem Haken ;D

Den Rest kannste dann so lassen wenn du magst.

Zitat von Glurak

okay sieht man denn den farb unterschied von YUV 4:4:4:4 zu 4:2:2 da ich hier schon irgendwie am festplatten speed limit hänge hab das gefühl 4;4;4;4 schaffen nur meine ssds

Solange du da nicht sonstwas skalierst ist alles noch recht im neutralen Bereich.

Aber sobald du um den Faktor 2 skalieren willst, bieten sich Aufnahmen mit Farbunterabtastungen von 4:4:4 an.

z.B. bei Emulatoren Aufnahmen.

Statt die Festplatte zu belasten bei einer Emulatoren Aufnahme, nimmt man die Auflösung die für die jeweilige Konsole auch gültig war.
z.B.
GB/GBC mit einer Auflösung von 160 × 144
GBA = 240×160 (16:10)
NDS = 2 x 256 × 192
NES = 256×224 (NTSC), 256×240 (PAL)
SNES = Hat ein 8:7 Seiten-Verhältnis. Emulatoren nutzen da die HighRes Auflösung mit 512x448. Das wäre die native SNES Auflösung für die ROMS
PSX = 512 × 384 (PAL), 640x480 (NTSC Interlaced), 320x240 (NTSC). Also 4:3
PS2 = 480i, 480p bei den meisten Games. 512p ala DVD, 720p und auch 1080i konnte es unterstützen. Alle mit 4:3
Einziges Spiel was mir einfällt das 1080i bei der PS2 Konsole unterstützt hat war GT4 im Einzelrennen.
FFXII und einige andere Games hatten einen 16:9 Modus. Allerdings wurde das Bild nur gezerrt entsprechend. 4:3 blieb das Bild trotzdem.
FFX und FFX2 haben bei ihrer PS2 Fassung sogar eine 16:10 Auflösung gehabt. Ebenfalls im 4:3 Rahmen.
Heißt: 4:3 war das gesammte Bild. Darauf wurde die Spielszene dargestellt.
Der PCSX2 Emulator muss man das dann entsprechend auch einstellen, sofern man das ändert.

DOSBox = Ohne SVGA oder Glide haben die meisten Spiele 320x200 (16:10). Oft auch Anamorph (4:3).
z.B. WOLF3D oder Blake Stone sind richtige 16:10 Spiele.

Mit SVGA und Glide war bei den meisten Games in der DOSBox bis zu 1024p (4:3) möglich. Spezielle konnten auch mehr.

PSP = 480 × 272 (fast 16:9, eigentlich 30:17)

Das sind Original Auflösungen.
Würde man die Spiele auch so aufnehmen in RGB auch noch, so kann man sie entsprechend auch ohne Verluste auf höhere Auflösungen trimmen. z.B. mit dem SSM und der Punktskalierung.

240x160 * 5 * 2 = 2400x1600 für GBA und das noch mit einem xBRZ Filter.

Vorteil an dieser Methode: Festplatte wird enorm geschont. Hohe Frameraten problemlos machbar. Meisten Konsolen haben eh nur bis 60FPS unterstützt. Und mit einem Punktskalierer wie xBRZ sieht das Ganze auch noch ganz schick aus. Weil die Kanten dadurch geglättet werden.
Je näher du an der Original Auflösung der ROMs bist, desto besser wird der Filter.

Manko ist dann aber: Du musst die Emulatoren ohne Bild Filter betreiben. Sprich das Spiel so spielen wie es auch sein müsste. Sonst funktioniert der Spaß nicht und man hat am Ende nur noch Brei.

Auf jeden Fall kann man damit enorm viel Festplatten Platz sparen. Hat alles in RGB und 60FPS und auch die Verarbeitung geht recht flott.
Und das I-Tüpfelchen ist halt das man auf YT dann ein super sauberes bis zu 8K großes Video haben kann mit dem Verfahren. ;D

Ich sage dir das, weil ich ja weiß das du auch sehr viel mit Emulatoren hantierst. Und ich weiß nicht wann ihr da euer Suikoden Projekt starten wollt. Weil ist ja PSX dann.

Zitat von Kayten

Du brauchst kein 4:4:4:4. Der Alpha-Kanal ist völlig sinnfrei.

Sinnfrei ja. Aber bei Aufnahmeprogrammen passiert im Alphakanal rein gar nix. Die sind leer und können super komprimiert werden. Daher sind sie nicht sonderlich größer als ihre 24Bit Partner Farbräume. Daher auch völlig irrelevant.
Wenn also AYUV oder RGB32 schon nicht bei der Aufnahme klappt, klappt es mit YV24 oder RGB24 auch nicht.

Zitat von Glurak

achja und die 10 bit versionen scheinen gar nicht zu funktionieren ich will aufnehmen damit er startet nicht mögliche lösungs vorschläge ?

Bringt dir bei der Aufnahme ohnehin nix. Zum einen ist dafür Rechenaufwand nötig um 8Bit auf 10Bit zu heben. Zum anderen läuft dein Rechner und deine Spiele jeweils nur mit 8Bit. 3 x 8Bit + 8Bit Alphakanal = 32Bit
Und das hast du gewiss auch bei deiner Grafikkarte angeschaltet bzw. unter Anzeige->Auflösung

Bei 10Bit müsste dein Rechner folglich mit 40Bit arbeiten. Tut er aber nicht.

In der Videoverarbeitung später nutzt man eine 8zu10 Bit Konvertierung aus (z.B.: Aufnahme -> x264_10bit) um A) die Dateigröße damit etwas zu senken und B) Banding zu reduzieren.
Bei einer Aufnahme mit 10Bit verschleuderst du aber Performance dabei.

Zumal dir, wenn du überhaupt 10Bit aufnehmen könntest, spätestens die Schnittprogramme oder andere Tools dir ein Strich durch die Rechnung machen. Weil die sind meist alle auf 8Bit ausgelegt. Heißt: max. 32Bit. Also RGB32 oder AYUV.

Zitat von De-M-oN

Slices schonmal nich nehmen, statt 4 auf 1, 0 wäre besser, aber geht ja bei dem programm nich

Das ist recht uninteressant und hat keine Relevanz auf die Qualität der Bilder. Das hat was mit Hardware Player zu tun. Daher sollte auch auf BluRays 4 Slices verwendet werden, um die Frames entsprechend zu zerlegen. Hat also eher was mit Speicherverarbeitung zu tun. Für die Qualität irrelevant. Trotzdem auf 1 stellen, weil das setzen von Slices kann die Encodier Dauer erhöhen und senken somit natürlich Effizienz.

Zitat von MegaJaniX

Aber die Bitrate sind so von YT vorgeschrieben gewesen deshalb

Das sind recht fantastische Richtangaben. Die kann man getrost ignorieren. Man muss also nicht 30 oder 50mbit irgendwo reinballern, obwohl das Video optimal mit weit weniger bei gleicher Qualität auskommt. Das Überflüssig und Ineffizient. Weil du somit einen erheblichen höheren Zeitaufwand betreibst.

Fixe Bitraten zu nutzen entpuppt sich bei jedem Spiel und Video als reines Ratespiel. Es gibt keine heilige feste Bitrate die Top ist. Höstens wenn man wirklich soviel wie möglich rein pumpt. Aber das ist ja wie gesagt Ineffizient.

Daher sollte man zwecks Qualität entweder mit Quantizer Angaben encodieren oder mit durchgängiger gleichbleibender Qualität. Weil dann werden die Bitraten optimierter für jedes Video und die Qualität ist bestens.

Sprich z.B. für Tetris z.B. hast du dann bei 1080p später nur 3000kbit/s und für Battlefront 1 geht es dann in die 40mbit oder whatever.
Nur du selbst musst keine Bitraten mehr angeben.

Wenn man mit fixen Bitraten encodieren sollte, sollte man unbedingt 2pass Encoding verwenden. Weil das die Qualität steigert. Hast damit aber relativ höheren Zeitaufwand und die Frage ob die Qualität top genug ist steht auch im Raum, je nachdem wie hoch die Bitrate eingestellt war.

Daher würde ich dir einen Encoder empfehlen der dir dieses Bitraten Gerate abnimmt. x264 kann z.B. in CRF kodieren. Da gibst du nur noch ein Faktor an. Das ist dann ein konstanter qualitätsbasierender Encode.
Oder wenn du es finden solltest: konstante Quantisierung. Das würde auch schon besser sein.

Zitat von MegaJaniX

Ich habe in FULL HD gerendert mit den YouTube angegebenen bit raten.
Aber das Video sieht nicht FULL HD aus. Habt ihr irgendwelche Ideen?

Hier auch mal das Video -> klick

Das Video ist auf YT auch nur in 720p verfügbar. Sprich die Non-Dash Versionen. Verwende, sofern du wirklich 1080p hochgeladen hast, die Bildverbesserung auf YT. Ändere aber nix dran, sondern speicher es einfach nur neu. Das Video wird dann von YT neu verarbeitet und sollte dann mit etwas Glück auch in 1080p verfügbar sein. Dann sollte es auch etwas besser aussehen.

Zitat von Glurak

Was ist denn Performance Technisch und Qualitäts technisch da am besten ? von den ganzen farb dingern null ahnung

Je niedriger der Farbraum, desto besser die Performance, aber desto schlechter die Qualität.
Je höher der Farbraum, desto schlechter die Performance, aber desto besser die Qualität.
Je lockerer die Kompression, desto besser die Performance, aber umso stärker die Festplatten-Last.
Je stärker die Kompression, desto schlechter die Performance, aber umso besser die Festplatten-Last.

Soviel zu Lossless Codecs.

Weil dann kann man einteilen:
YUV wird mit einer Farbmatrix errechnet aus RGB und besitzt Rundungsfehler:

YUV 4:0:0 - Keine Farben, sehr schnell speicherbar (sehr, sehr niedrige Qualität)
YUV 4:1:1 - Stark verwaschende Farben, dank Interpolation (sehr niedrige Qualität)
YUV 4:2:0 - Verwaschende Farben, dank interpolation (niedrige Qualität)
YUV 4:2:2 - Vertikal verwaschende Farben, dank interpolation, Horizontal sauber (mittlere Qualität)
YUV 4:4:4 - Vertikal und Horizontal sauber (hohe Qualität)

RGB / RGB24 und RGBA / RGB32 sind native Farbräume wie der PC und somit die Spiele es auch haben.
Das heißt die Farben sind dem vom Spiel identisch:

RGB 4:4:4 - Sehr sauber (sehr hohe Qualität)

Kommt während der Aufnahme ein Farbraum mit Alphakanal zum Einsatz so ist er leer und hat die gleiche Gewichtung wie der gleiche Farbraum ohne Alphakanal. Sprich RGB24 = RGB32 oder YV24 = AYUV

Je höher die Qualität, desto stärker ist die Last auf Festplatten. Weil die Festplatten die Mengen an Daten speichern müssen.
Je kleiner also die Menge ist beim Aufnehmen (Verlust Codecs z.B. mit Bitraten), desto besser ist die Performance.

Das kann auch durch Kompression erreicht werden. ABER... je stärker die CPU oder GPU damit beschäftigt ist Daten zu komprimieren oder neu zu berechnen (z.B. Verlust Codecs), desto schlechter wird die Performance. Die Festplatte jedoch wird damit entlastet. Und sollte eine Verlust Encodierung bei der Aufnahme erfolgt sein, ist somit auch gleichzeitig Qualität weg.

Bei YUV 4:2:2 hat man nur noch die Hälfte an Farbinformationen. Ein 1920x1080 Bild würde sich bei diesem Farbraum so aufspalten lassen:
Y Kanal (Luma): 1920x1080
U Kanal (Blau Anteil): 1920x720
V Kanal (Rot Anteil): 1920x720

UV würde dann auf dem Y Kanal auf jede 2te Zeile aufliegen. Die Lücken würden dann Interpoliert werden, sofern vorher angegeben.
Denn eine Interpolation kann nur dann erfolgen, wenn von einem höheren Farbraum in einen niedrigeren geformt wird.

Bei DxTory wird RGB32 abgegriffen und zum Encoder geschickt. Der Encoder wird dann die Bilder auf den Wunsch Farbraum konvertieren.
Also entsprechend Abzüge machen.

Das ist Farbraumtechnisch und Qualitäts Technisch der Hintergrund. Sehr kurz halt.

Performance Technisch beim Aufnehmen spielen noch andere Faktoren eine Rolle. Und zwars Sachen wie:
- Hooking. Kann das Hooking der Aufnahme Software sich gut oder eher schlecht in das Spiel einklinken um die Bilder abzugreifen. Das hängt dann auch von der Spiel Entwicklung ab, welche Engine verwendet wird und welche Ausgabe. z.B. DirectDraw, Direct3D, Surface, Overlay, Glide, OpenGL, usw.
Gibt ja auch Spiele die lassen sich nicht hooken, aufgrund das der Ausgabe Renderer nicht unterstützt wird. Wie z.B. Surface
Bei DirectX wird dabei noch unterschieden welche Versionen supportet werden.

- Einstellungen zwecks Speicherverwaltung. Die im Aufnahmeprogrammen befindlichen Einstellungen zur Aufnahme sind auch wichtig. Einige Aufnahmeprogramme lassen sich einstellen wie sie arbeiten sollen. Soll auf verfügbaren Speicher gewartet werden oder voll durchgejagt werden. Oder Sachen wie VSync usw.
VSync. bremst bei vielen Aufnahmen die Spiele extrem aus. Statt also 60 FPS Ingame, hat man z.B. nur noch 45 - 30 FPS. Schaltet man im Spiel und im Aufnahmeprogramm VSync ab, kann man höhere Ingame FPS Raten erzielen. Aber auf der Gefahr hin Tearing im Bild zu haben. Sprich das einige Frames aussehen als ob es zerissen worden ist. Meist durch einen Horizontalen Versatz in einem Frame zu erkennen.

- Synchronität ist auch eine wichtige Performance Technische Angelegenheit. Da die Frames von einem Spiel so schnell wie möglich vom Rechner bereitgestellt werden und je nach Rechenaufwand somit auch die FPS schwankt, laufen Spiele mit einer VFR. Und da gibt es dann auch wieder zig Möglichkeiten wie das Aufnahmeprogramm arbeitet und anbietet an Optionen. Fraps, DxTory und MSI AB nehmen in der Regel in CFR auf, indem einfach nur mit einen Takgeber die FPS aus dem Speicher entnommen werden.

z.B. 30 FPS Aufnahme CFR. Der Taktgeber hat nun die Aufgabe alle 33ms ein Frame aus dem Spiecher zu speichern. Bei 60 FPS sind das schon ca. alle 16ms.

Performace Technisch gesehen wäre es daher sogar besser in VFR aufzunehmen. Dann würden nur die Frames genommen die sich ändern. Aber mit VFR haben sehr viele Programme große Probleme. Vor allem bei Lossless Codecs wie MagicYUV oder UTVideo die in einer AVI Datei keinen Zeitstempel mit sich führen können.

Daher sind VFR Aufnahmen meist bei einem AVC geeigneten Codec und Container zu finden. z.B. H264 in MP4 oder MKV oder M2TS oder oder oder....

RipBot ist von den Tools her fast genauso ausgestattet wie MeGUI. An sich ist es total egal was du nimmst. Die nehmen sich beide nix. Weil sie gleichwertig arbeiten vom Workflow her.
Stellste noch den Encoder gleich ein wie in MeGUI, dann sind sie von der Geschwindigkeit her identisch.

Zitat von Handicapped Gaming

Also ich meine welches Programm sollte ich eher nehmen von beiden als 1 PC Renderer?

Zitat von Handicapped Gaming

Aber ist es egal welches Programm ich nehme es kommt das selbe am Ende Raus. Ich dachte Ripbot ist vielleicht schneller.

Wenn es dir um Schnelligkeit geht dann sollte so wenig wie möglich zwischen Quellvideo und Encoder liegen.

Bei MeGUI hast du AVISynth und avs4x264mod als Frameserver dazwischen die es ausbremsen.

Ansonsten richtet sich die Geschwindigkeit an das Quellvideo was du verarbeiten willst und die Encoder Einstellungen die du einstellst.

Das heißt: gleiches Quellvideo durch den gleichen Encoder (egal in welchem Programm) ist die Geschwindigkeit identisch.
Heißt das du auch x264 so als EXE Encoder nehmen könntest und hättest die gleiche Geschwindigkeit wie bei RipBot, sofern nur ein PC.

Verlagerst du eine Encodierung auf mehrere Rechner kann die Geschwindigkeit durchaus gesteigert werden. Sofern du auch mehrere Rechner hast und das Tool dies auch erlaubt.

Aber so wie es aussieht arbeitet RipBot genauso wie MeGUI mit AVISynth und den ganzen Kram. Und so wirklich auf mehrere Rechner verteilen kannst du da auch nix.

Bild

Hat sogar irgendwie weniger Einstellungsmöglichkeiten von der GUI her.

Also ist egal was du nimmst. Das eine wird nicht viel schneller sein als das andere, sofern beide gleich moderat konfiguriert werden.

Zitat von Handicapped Gaming

1. Ist Ripbot genauso gut wie Megui von der Geschwindigkeit?

Jup

Zitat von Handicapped Gaming

2. Was würdet ihr mir als 1 PC renderer raten zu nehmen?

Du meinst den Encoder? Nimm x264. Sollte er drin haben.

Zitat von Handicapped Gaming

3. Kann mir jemand das Prinzip erklären?

Welches Prinzip? Encoding? Arbeitsverteilung? Oder möchtest du nur Einstellungen erklärt haben, damit du weißt wie das Programm zu bedienen ist?

Ich würde auf sein Mischpult tippen.

Sein Mikrofon überträgt in Mono, da nur ein Kabel durchgeht bis hin zum Klinkenkopf.

Der Windows Mixer jedoch macht aus einem Mono Signal (Eingang) ein Stereo Signal (Ausgang)

Ist ein Mischpult dazwischen wird aber vom Mischpult ausgegangen. Das Mischpult überträgt in Stereo. Da braucht der Windows Mixer nix mehr zu tun, weil ist ja schon Stereo.

Was aber das Mischpult macht ist das das Mono Signal nur auf ein Seitenkanal gelegt wird. Weil kommt ja nicht mehr an. Also wird das Stereosignal so erstellt das Links der Ton ist und Rechts einfach nur Stumm ist.

Entweder das Mischpult kann den Ausgang auf Mono ändern oder der Eingang lässt sich so auf Mono schalten das der Output wenigstens auf beiden Kanälen des Stereo Signals zu hören ist.
Oder man hat einen Balance Regler auf dem Mischpult oder Softwaremäßig zum Gerät selbst.

Weil die Mischpulte haben meist Stereo-In und sind an sich für Instrumente ausgelegt wie z.B. Keyboards, Gitarre und andere Synthesizer um den Klang des eigentlichen Instruments als Welle wieder zu geben. Das Mischpult soll dann an sich verschiedene einzelne Instrumente wie z.B. die einer Musikband zusammenmischen. Weil kann ja mal sein das der eine zu laut ist, der nächste zu leise oder oder oder. So ist es am besten auch Nachbearbeitungs Korrekturen durchzuführen. z.B. Effektzuordnung einzelner Instrumente und usw.

Nur für ein Mikro ist ein Mischpult etwas übertrieben denk ich.

Oder man nutzt Linux oder MacOS, da ist kein Windows Mixer dazwischen. xD

Einige Schnittprogramme können das Profil high444p nicht korrekt verarbeiten bzw. überhaupt verstehen.
Lossless bei H264 wird immer in ein high444p Profil geschrieben, weil dieses Profil dafür gedacht war.

Du darfst, wenn du mit H264 aufnimmst nicht Lossless aufnehmen und nicht im high444p Profile. Erst dann kann dein Schnittprogramm es auch verarbeiten.

Zitat von letheia

Ich bin mir nicht sicher, ob ich mir das einbilde oder ob es wirklich so ist: Sollte es mit 4:4:4 schärfer aussehen als mit 4:2:0?

Das ist die Farbunterabtastung (Subsampling)
4:4:4 heißt das jeder Pixel mit einem Y, U und V Kanal ausgestattet ist. Also Vollwertig. RGB ist z.B. immer ein reiner 4:4:4 Farbraum.

4:2:0 heißt das jeder 2te Pixel in Reihe und Spalte mit Farbe ausgestattet ist.
4:2:2 heißt das jede 2te Spalte Farbe hat.
Der Rest ist Farblos. Nur der Y Kanal hat dann den Helligkeitsanteil.

Farbräume (Tutorial) - erweiterte Erklärung und Zusammenhänge
Such dir dort mal das Bild mit der Sonne. Dort kannst du sehen wie die Subsampling Stufen aussehen.

Zitat von letheia

Was bedeutet "Full range YUV"?

Das bedeutet das der Farbbereich von 0 - 255 geht. Also Vollbereich. Man spricht auch von PC Range oder Computer Range.
Der begrenzte Bereich geht von 16 - 235. Hier spricht man von TV Range oder Studio Range.

Zitat von letheia

Was bedeutet "interlace" und "interpolate"?

Interlaced bedeutet das ein Video Zeilensprungbilder besitzt. Das heißt statt 1080p z.B. wird 1080i draus.

1080i besteht dann, wenn man es zerlegen würde aus 2x 1920x720 Bildern

Diese 1920x720 Bilder werden via einem bestimmten Wave Muster verwebt, sodass ein Zeilensprung entsteht. Resultat ist dann halt 1080i

Interlaced Videos müssen um sie Progrssiv (also Vollwertig) anzeigen zu können Deinterlaced werden. Sprich das Entflechten dieses Wave Musters.

Interpolate ist für für das Aufnehmen in unteren Subsampling Bereich. z.B. in 4:2:0 oder 4:2:2.
Farbunterabtastungen mit 4:4:4 brauchen keine Interpolation mehr.
Damit werden die Farblosen Zwischenräume (Pixel) rechnerisch durch die benachbarten Pixel ergänzt. Sprich die Farblichen Abstufungen werden hinzugefügt. Somit sehen YUV Farbräume unterer Subsampling Bereiche Farblich sehr gut aus, als wenn sie Farblos wären.
Siehe dazu im Farbraumtutorial (Link hab ich dir schon gegeben) die Bilder mit "Ungerade" und "Gerade" an.

Zitat von letheia

Was bringt die "Compression method"? Ich vermute, ich möchte die höchste Encode-Geschwindigkeit erreichen. - Ist "Median" dann am besten?

Das hat was mit Entropie zu tun und dem was du damit später vorhast. Wenn du eh schon ein Lossless Encoder nimmst der große Dateien produziert, glaube ich fast kaum daran das du da das Video ein wenig mehr komprimieren willst und es dabei sehr langsam ist. Lieber weniger Kompression und schnellere Verarbeitung beim Encoding.

Wenn dich das aber doch noch mehr interessieren sollte, suche nach HuffYUV
https://wiki.multimedia.cx/index.php/HuffYUV

Dort wird erklärt wie das ganze funktioniert.

Ansonsten findest du bei MagicYUV in der Hilfe (Mauszeiger drüber halten) eine recht pauschale und Laiengerechte Antwort auf deine Frage.

Dem ist so.

In Vegas kann man die Farben auch verhauen. So wie in jedem Schnittprogramm auch.

Man kann RGB auf limitierte Farb Werte einstellen oder auf Vollbereich Werte. RGB bleibt aber immer im PC Range Bereich. Das wirst selbst du nicht ändern können.

Das eine nennt sich Studio RGB, das andere Computer RGB meist in Schnittprogrammen.
StudioRGB ist nix anderes als den Farbwert zu limitieren. Sprich diesen auf 16 - 235 zu bringen. Die Skala jedoch vom RGB bleibt bei 0 - 255 Vollbereich. StudioRGB ist dafür da, da mit YUV Farbräumen standardmäßig im TV Bereich gearbeitet wird. Somit hat man Banding besser in Griff beim Neuberechnen der Frames.

ComputerRGB jedoch deckt den kompletten Farbspektrum ab. Auch diese RGB Skala ist von 0 - 255 wie die vom StudioRGB. Nur das hier die Höhen und Tiefen der Farben nicht terminiert wurden.

x264vfw hat einen eigenen Farbbereich Wandler drin. Zusammen mit der Farbmatrixangabe ist diese TV Bereich Umrechnung viel besser als das man es hätte im Schnittprogramm angeben können.

Die Farben werden nur dann verfälscht wenn man nicht drauf achtet was man tut. Dafür hat er ja 3 Stationen.

• Den Farbbereich + Farbraum mit dem er aufgenommen hat
• Den Farbbereich + Farbraum in was sein Schnittprogramm das jeweilige Video bringt (Die konvertieren oft gerne mal, also Einstellungen beachten)
  RGB ist in den meisten Fällen aller Schnittprogramme bei VFW als Ausgabe zu erwarten. Kann geprüft werden mit MagicYUV.
• Und den Farbbereich + Farbraum bei dem Encoder

Kennt man diese Stationen, kann man sich seine Szenarien am Video ausmalen:
TV -> PC -> TV (matt)
PC -> TV -> TV (dunkel)
TV -> TV -> PC (matt)
TV -> TV -> TV (neutral)
PC -> PC -> PC (neutral)

Die neutralen sehen dann von den Farben her so aus wie die Aufnahme auch. Siehe dazu auch Farbräume (Tutorial) - erweiterte Erklärung und Zusammenhänge
Besonders am Ende von Beitrag 11, da habe ich es dir versucht sogar mit Bildern zu erklären.

Zitat von RealLiVe

Ist ein PC-/TV-Range Problem. Korrigier's vor'm Rendern in Vegas mit dem Filter Levels, Preset "Studio RGB in Computer RGB", das sollte das Problem beheben.

Eher ein x264vfw fehlender Eintrag, denn:
Das Video wird von Vegas aus über VFW als RGB Material übertragen. RGB = PC Range.
Um dafür zu sorgen das x264vfw das Video vernünftig in TV.709 bringt gehört in der "Extra command line" folgende Einträge:
--range tv --colorprim bt709 --transfer bt709 --colormatrix bt709

Und dann stimmen die Farben auch wieder.

So ziemlich jede VFW Schnittstelle eines Schnittprogrammes überträgt RGB Frames an den Encoder.

Gibt aber auch Außnahmen was dies angeht. z.B. bei Bandicam. Das ist aber nicht mal die Schuld von der VFW Schnittstelle. Bandicam nimmt von sich aus bei Aufnahmen über VFW Codecs in YUV420 auf und überträgt die Frames bereits über die VFW Schnittstelle mit einem YUV Farbraum.
Dem VFW interessiert das ja nicht was übertragen wird. Dem ist das schnurz

@AndiK
Abgesehen von dem was ich @RealLiVe grad schrieb, musst du darauf achten das du ebenfalls in der "Extra command line" die FPS deines Videos mit angibst, die du bereits in deinem Vegas Projekt verwendest. Sonst passiert es mal ganz schnell das Sachen Asynchron werden, da der x264vfw nicht direkt mit anderen Programmen arbeiten kann. Sprich dein Vegas ist ein Programm und x264vfw ist ein Programm. Die sind beide separat. Der eine weiß also nicht was der andere tut.
Also gibt man dem Encoder auch noch die FPS Info mit in die "Extra command line"
--fps 50/1
Steht z.B. für 50 FPS. Jeweils der Zähler und Nenner.
Wenn ein Video 29.97 FPS haben soll, gibt man dies so an:
--fps 30000/1001 oder so --fps 30/1.001

Das ist ganz wichtig.

Ein weiterer Punkt ist das Video was du mit x264vfw erstellst nicht in einen AVI Container ballerst. Du hast unter dem Punkt File die Möglichkeit auch MP4, MKV oder H264 auszuwählen, wenn du auf das "..." Symbol klickst. Diese Container sind besser dafür geeignet.

Und den CRF nicht auf 1 stellen. Das ist total überzogen. Bleibe bitte bei einem CRF Encode zwischen 18 - 26 (Standard ist 23)
18 für top Qualität
23 für normale
26, wenn dir der Schuh drücken sollte und deine Finger schon krabblig sind das Video hochladen zu wollen. Qualität ist dann immer noch gut.

Den Rest belässt du einfach so wie es auf deinem Bild abgebildet war.

Und dann kannst du loslegen.

Die 2013er Version ist ja auch für:
Windows 7 Service Pack 1; Windows 8; Windows 8.1; Windows Server 2003; Windows Server 2008 R2 SP1; Windows Server 2008 Service Pack 2; Windows Server 2012; Windows Server 2012 R2; Windows Vista Service Pack 2; Windows XP

benötigt auch weniger Leistung.

Die neuere Versionen für das Studio Paket sollten aber auch klappen und mit Win10 arbeiten. Richtig.

Die 2013er Version ist das Minimum.

Es muss aber trotzdem drauf geachtet werden das für LSmash, wenn er SSM verwendet die x86 (32Bit) Version des Paketes installiert, sonst gibt es Fehlermeldungen.

Sofern du x86 Version davon installiert hast, ja. Die wird auch zum Plugin angeboten optional. Normalerweise hat jeder Rechner ab Win8 oder höher diese DLL Dateien drauf.

Die Files sollten dann entsprechend auch im SYSWOW64 Ordner zu finden sein dann.

Und wieso macht ihr das über eine VM? Nicht das nachher noch die VM aufgrund einiger Beschränkungen da ein Strich durch die Rechnung macht.

Die LSMASHSource.dll ist von folgenden Modulen abhängig:

• avutil-55.dll
• avcodec-57.dll
• avformat-57.dll
• swscale-4.dll
• avresample-3.dll
• VCRUNTIME140.dll
• api-ms-win-crt-stdio-11-1-0.dll
• api-ms-win-crt-heap-11-1-0.dll
• api-ms-win-crt-utility-11-1-0.dll
• api-ms-win-crt-string-11-1-0.dll
• api-ms-win-crt-runtime-11-1-0.dll
• api-ms-win-crt-math-11-1-0.dll
• KERNEL32.dll (Ist auf jeden Windowssystem vorhanden)

Die "api-ms-win-crt-..." DLL Dateien gehören zum großen MS Visual C++ Packet
Genauso die VCRUNTIME140.dll

Die DLLs zu avutil, avcodec, avformat, swscale und avresample sind in der LSMASHSource.dll integriert und sind Teil des FFMpegs "LibAVcodec", was zum dekodieren der Videos benötigt wird.

Also benötigt man nur die richtige VCRUNTIME um das Plugin zu nutzen.
https://www.microsoft.com/de-D…oad/details.aspx?id=40784

Diese sollte alle fehlenden Module zum MS Visual C++ Packetes drin haben die für dieses Plugin notwendig sind.
PS: Bitte die 32Bit Version nutzen, da AVISynth und auch die Plugins 32Bit Versionen sind.

Fehlermeldungen können vorgebeugt werden indem LSmash auch korrekt benutzt wird.
Für AVI Dateien die kein AVC Material in sich bergen sollte LSmash nicht genutzt werden. Sprich Videos die z.B. mit UTVideo oder MagicYUV etc. aufgenommen wurden sind dafür nicht gedacht.

Da bis jetzt noch nicht beschrieben wurde wie der Fehler verursacht wird und wie die Mediainfo des Videos aussieht, kann ein Fehler mit LSmash auch durch zig andere Sachen verursacht werden.
Wie schon angedeutet durch falsche Video Formate. Oder durch die Verwendung von LSmash in Kombination mit AVISynths internen Multithreading. Fazit ist dann oft das es zu Crashs kommt und die DLL als Fehlermodul angezeigt wird.

Erzähl keinen Müll Julien. YT ist nur bei dir VFR Fähig.

YT ließt VFR Videos genauso als CFR Videos ein wie andere Schnittprogramme auch. Darum gibt es auch zig User auf YT die asynchrone Videos haben aufgrund von Shadowplay und anderweitigen VFR Aufnahmen die dann auch so hochgeladen wurden.

Von 10 Shadowplayaufnahmen aka 32min wie du vorgeschlagen hast, sind gerade mal wenn überhaupt 7 synchron und der Rest asynchron.

Und das lässt sich nicht Vorhersagen wann es so ist, das ist reiner Zufall und hängt davon ab wie die FPS Raten bei der Aufnahme waren. Waren sie relativ Konstant geschieht zwischen VFR und CFR nicht viel. Treten aber massive Unterschiede auf, wird man da auch asynchronität feststellen.

Bevor du also irgendwas raushaust, was nicht stimmt, würde ich das mal nicht nur mit deinen Tests prüfen von deinem PC, sondern auch mal von anderen Usern.

Zitat von Schauerland

YouTube sollte doch mit VFR klar kommen oder?

Youtube und VFR Der war gut xD