Beiträge von Sagaras

    Wurde das hier schon getan?

    Und Motion Blur würde sich auch komplett abschalten lassen.
    Einfach in der Datei system.cfg oder Game.cfg den Eintrag r_MotionBlur auf 0 setzen. Fertig.


    Theoretisch gehört Motion Blur zum SFX Einstellung im Spiel unter Optionen. Aber diese Option ist noch ein wenig mit anderen Optionen verbunden.
    Um halt nur Motion Blur abzuschalten muss nur der Eintrag in eines der CFG Dateien abgeändert werden.

    Und die Festplattengeschwindigkeit sollte ausreichen für 1080p60.



    Mit welchen Programm nimmst du denn auf? Einstellungen wären dazu interessant und eventuell mal auch mal andere Aufnahmeprogramme probieren.

    Also wenn die Aufnahme mit YUV422 deiner Meinung nach noch schwammig aussieht, dann nimmste halt einfach in RGB auf. Das ist dann exakt 1:1 Qualität wie das Spiel auch. Weil das Spiel liegt ja schon in RGB vor.


    Und dann haste schon mal absolut gutes Basis Material. Damit kannste dann nach belieben rumschludern ;D

    Aber Teil der Sound Optionen wirds wohl nicht sein ? Ich denke da haste gerad GFX gemeint und nicht SFX ;D

    Die Option von SFX ist nicht nur Audio bekanntermaßen gemeint. Das ist bei Far Cry 1 generell eine ganz bescheuerte Angelegenheit. Es beeinflusst unter anderem auch die Sache mit Motion Blur. Es fallen auch einige andere Settings über die Option an die man damit regeln kann. Und mit der SFX Option sind bei FC1 halt die GFX Sachen gemeint.
    Immerhin... warum sollte die SFX Option unter Grafik stehen, wenn sie doch bei Sound viel besser aufgehoben wäre? ;D


    Von daher lieber die CFG Dateien abändern.

    Diesen Ghosting- bzw. Motion Blur Effekt habe ich auch in Game, habe es auch angesprochen und stört mich selber. Allerdings habe ich keine Option gefunden um diese Einstellung zu deaktivieren... Leider.

    Motion Blur gehört zum Spiel. Ghosting definitiv nicht.


    Und Motion Blur würde sich auch komplett abschalten lassen.
    Einfach in der Datei system.cfg oder Game.cfg den Eintrag r_MotionBlur auf 0 setzen. Fertig.


    Theoretisch gehört Motion Blur zum SFX Einstellung im Spiel unter Optionen. Aber diese Option ist noch ein wenig mit anderen Optionen verbunden.
    Um halt nur Motion Blur abzuschalten muss nur der Eintrag in eines der CFG Dateien abgeändert werden.


    EDIT: Und wegen der zu geringen FPS einfach mal bevor du das eigentliche Spiel startest, im Spielmenü Vsync deaktivieren. Das ist bei dir noch an.



    Noch dazu haste Ghosting drin.

    Das ist kein Ghosting, sondern gehört wirklich zum Motion Blur Filter vom Spiel. Das sieht wirklich so aus ^^



    Naja kann mich aber nicht erinnern das Spiel mit Motion Blur gespielt zu haben

    Ehrlich nicht? ^^ Das ist eigentlich standardmäßig aktiviert bei FarCry 1 und ist Teil der SFX Option.



    Nun stelle ich mir aber die Frage: Ist mein Prozessor wirklich so schlecht? Ich meine, früher, und das weiß ich noch ganz genau, hatte ich NIE Probleme mit FRAPS.

    Wenn ich richtig gelesen habe war es eine AMD-FX 6300 ? Die sollte eigentlich locker reichen. Immerhin über 3Ghz bei 6 Kernen. Das ist mehr als Far Cry 1 überhaupt braucht. FarCry 1 wurde damals noch für 1 Kern Prozessoren entwickelt.


    Wenn die Aufnahme mit 1080p60 nicht funktioniert, dann ist es wohl eher Vsync das dich da völlig ausbremsen tut. Das sollte bei der Grafikkarteneinstellung als auch im Spiel deaktiviert werden.


    Und mal die Festplatten-Schreib-Geschwindigkeit überprüfen auf der du aufnimmst mit CristalDiskMark http://crystalmark.info/softwa…stalDiskMark/index-e.html



    @RealLiVe @De-M-oN
    Eigentlich habe ich gedacht das ich schon schlimm bin ^^ Aber ihr beide macht auch irgendwie Nägel ohne Köpfe xD


    Weil, wenn man sich das Video anschaut, kann es unmöglich Ghosting sein, weil die typischen Ghosting Charakteristika fehlen. Es müsste halt im gesamten Video Verlauf auffallen. Darunter die Cutscenes + das Menü. Das ist aber nicht der Fall. Und auch im Spiel selbst sind es nicht die typischen Ghosting Charakteristika.


    Motion Blur entsteht schlicht und einfach durch längere Belichtungszeiten. Das heißt das bestimmte Sachen sich verzerren wie Licht, Texturen etc. Bei FarCry 1 ist das noch gegenüber heutigen Spielen eine noch recht Sichtbare Angelegenheit und sieht man halt auch an den Objekten.


    Für FarCry 1 gibt es daher auch ein paar Mods die bestimmte Sachen verbessern:
    z.B.: http://www.moddb.com/mods/farcry-2010


    Und wie gesagt, wenn man in den CFG Dateien Motion Blur abschaltet, treten auch diese Ghosting-Ähnlichen Verläufe im Bild nicht mehr auf.

    @De-M-oN
    Das ist ja dann auch Mistig xD Aber dann brauch er sich auch nicht beklagen das YT seine Videos mistig macht, wenn man solche alten Encodes bekommt + nicht mal die Vorteile von höheren FPS nutzt was ja mit min.41 FPS anfängt + die Shadowplayaufnahme.


    Das ist ja an sich schon ne miese Kombination.


    Dann wundere ich mich eigentlich auch nicht das immer wieder Leute kommen die sich dann über schlechte Qualität aufregen. xD

    @TbMzockt
    Wieso kann man bei deinen Videos nur 720p auf YT auswählen, wenn du sie doch mit 1152p hochlädst?


    Ich hab auf deinem Kanal nur die Non-Dash Varianten zur Verfügung.
    Bei @De-M-oN sein Kanal habe ich alle Varianten zur Auswahl.


    Und dann auch alles nur die AVC Varianten. Nirgendwo VP9.


    Da brauchst du dich doch dann gar nicht beklagen das es scheiße auf YT aussieht.
    Siehe selbst:
    http://fs5.directupload.net/images/160816/7a4czi9o.png


    So sehen alle deine Videos aus bei mir.



    Bei @De-M-oN hab ich mehr auswahl:
    http://fs5.directupload.net/images/160816/9vagf8uj.png


    Da hab ich dann auch die 1080p Marke. Aber bei dir fehlen die ganzen Non-Dash Varianten.

    Erst mal würde ich vorschlagen das du dir MagicYUV v1.2 dir zulegst. Weil v.1.1 hat einen Farbraum Bug drin wo nicht Interpoliert wird. Das ist schon mal schlecht für die Aufnahme.


    Desweiteren mal die Einstellungen von DXTory vom Reiter "Advanced" posten.


    Und am besten auch mal deine Festplatte durchchecken lassen mit CrystalDiskMark
    http://crystalmark.info/softwa…stalDiskMark/index-e.html


    Es kann nämlich auch sein das deine Festplatte bereits einen Verschleiß aufweist.


    Interessant wäre natürlich auch was für eine Festplatte es ist und auch wieviel darauf Belegt ist schon.


    Kann nämlich auch sein das wenn zuviel auf der Platte drauf ist, diese an Effizienz verliert da sie womöglich massiv Fragmentiert ist.

    @UndiscoveredLP
    Die Frage ist jetzt was der Fehler genau ist? Woran scheitert es denn?
    Weil das Skript sieht ok aus, sofern du die Pfade zu den Dateien richtig angegeben hast für das Plugin, als auch für das Video.


    Bedenke halt das ColorMatrix ein YV12 oder YUY2 Input haben möchte.


    Wenn du YV24 hast, wäre die Nutzung von ManualColorMatrix Plugin vllt. eine bessere Option.


    Auf jedenfall sind Farbmatrix Werte nur für einen YUV Farbraum bestimmt und nicht für einen RGB Farbraum. RGB besitzt keine Farbmatrix.


    Den letzten Fehler den du mir in der Konversation gepostet hast war wie folgt:

    Code
    -[Error] MediaInfo
    --[Error] [05.08.2016 02:16:14] Error parsing media file D:\Downloads\Xur.avs
    ---[NoImage] ColorMatrix: input to filter must be YV12 or YUY2!
    ---[NoImage] (D:\Downloads\Xur.avs, line 3)


    Das Skript dazu haste ja etwas weiter oben gepostet:

    Code
    LoadPlugin("C:\xxx\xxx\MeGUI\tools\avisynth_plugin\ColorMatrix.dll")
    AVISource("D:\x\xxx.avi", audio=true).AssumeFPS(60000, 1001)
    ColorMatrix(mode="Rec.601->Rec.709")
    ConvertToYV12()
    Spline36Resize(2048,1152)


    Und jetzt vergleich mal. Zeile 3 und 4 in der Fehlermeldung von MeGUI weißt dich darauf hin was los ist und in welcher Zeile es ist im Skript.


    In Zeile 3 im Skript steht der ColorMatrix Filter. Der kann aber nur ein YV12 oder YUY2 Signal verarbeiten. Das heißt das in Zeile 2 wo du dein Video laden tust, es bereits in einem ganz anderem Farbraum vorliegt. RGB24/RGB32 oder YV24 vllt. Und schon haut das nicht hin.


    Du musst dem DebugMode oder Advanced Frameserver sagen das er in YUY2 oder YV12 ausgeben soll, damit das Ganze funktioniert im Skript.


    An deiner Stelle hätte ich aber vllt. noch mal einen anderen Weg eingeschlagen wo du im Endeffekt mehr raus bekommst.
    Hätte da 3 Varianten anzubieten.


    Variante 1:


    Code
    LoadPlugin("C:\xxx\xxx\MeGUI\tools\avisynth_plugin\ManualColorMatrix.dll")
    AVISource("D:\x\xxx.avi", audio=true).AssumeFPS(60000, 1001)
    Spline36Resize(2048,1152)
    ManualColorMatrix(2, 0.182586, 0.614231, 0.062007, -0.098397, -0.331015, 0.429412, 0.429412, -0.390037, -0.039375, 16, 128, 128)

    ManualColorMatrix müssteste dir dann erst noch downloaden dann.


    Aber dieser Weg ist um Längen besser, denn nun haste die Möglichkeit deine Videos in RGB vom Frameserver auszusenden, dann wird mit dem RGB Material skaliert, was weitaus effizienter ist als ein YUV Farbraum zu skalieren und erst dann in Zeile 4 wird auf YV12 mit BT.709 geändert.
    Das heißt das du somit mehr Möglichkeiten hast.


    Beachte das wenn du bereits in BT.709 aufnimmst, das Skript dir die Farben verfälscht, da es für eine RGB -> BT.709 Konversation gedacht ist.


    Variante 2:


    Code
    LoadPlugin("C:\xxx\xxx\MeGUI\tools\avisynth_plugin\ColorMatrix.dll")
    AVISource("D:\x\xxx.avi", audio=true).AssumeFPS(60000, 1001)
    Spline36Resize(2048,1152)
    ConvertToYV12() # <- Standard BT.601 conversion without parameters
    ColorMatrix(mode="Rec.601->Rec.709")

    Sieht deinem jetzigen nicht unähnlich aus, nur das die Reihenfolge optimiert ist. Immer erst Skalieren und dann den Farbraum ändern.


    Der Rest dürfte Klar sein denk ich.


    Beachte hier das die Farbmatrix bei der Aufnahme schon BT.601 sein muss, damit überhaupt auf BT.709 geändert werden kann. Ansonsten werden Farben verfälscht.
    Obwohl sie schon dank des TimeLine Programmes verfälscht werden könnten.


    Variante 3:


    Währe natürlich die Beste mitunter. Hier wäre aber der Verzicht auf das Timeline Programm erforderlich.
    Denn du hast folgende Ausgangs Situation mit deinem Timeline Programm:


    Aufnahme sei jetzt mal mit YV12 in BT.709


    Dann würde dein Timeline Programm es auf RGB umkonvertieren, da RGB einfacher zu Handhaben ist, genauer ist und vor allem viele Effekte somit anwendbar sind, da sie auf RGB geeicht wurden.


    Das heißt das die Information der Farbmatrix erlischt. Wenn du es jetzt wieder nach AVISynth schicken tust werden die Farben schon daher verfälscht, weil AVISynth, als auch der DebugMode Frameserver in BT.601 ausgibt (sofern YUV Übertragung ausgewählt worden ist), da es ja vorher eine RGB RAW Quelle ist im Timeline Programm.


    Ich weiß das ist recht verzwickt mit den Dingern und eigentlich kann man da nicht mal was ändern.


    Aber wenn du ohne ein Timeline Programm direkt das Video in AVISynth laden würdest, würdest du sowas halt vermeiden.
    Dann müssteste dir nur die Mediainfo von deinem Video zu Rate ziehen und passt das Skript explizit darauf an.



    Das Problem was du und wir hier momentan haben ist:
    A) wir haben noch keine Mediainfo deiner jetzigen Aufnahmen gesehen
    B) Wir wissen nicht was du im DebugMode Frameserver einstellst als Farbraum, denn darauf muss dann auch das Skript angepasst werden.
    C) Sofern das die einzige Fehlermeldung war, wäre halt nur noch A und B zu klären. Wenn nicht, solltest du uns eine komplette Log von MeGUI posten wo sich auch der Eintrag des Fehlers befindet. Ansonsten raten wir hier rum und wissen nicht was los ist.

    Beim N64 gibt es kein Komponentenkabel, da ist S-Video ungemoddet das beste.

    Habe ja extra geschrieben: ohne zuviel Modding zu betreiben ^^


    Möglich ist es. Musst mal nach VC Component suchen. Und das ist weit mehr dann als S-Video kann.
    Auch das Ergebnis eines RGB Mods an der Konsole bewirkt bereits schon extreme Besserungen an der Qualität.


    Klar, es ist nun mal eine Konsole die man ohne Modding nicht viel entlocken kann. Es ist aber halt möglich.


    Beim Gamecube kostet ein Komponentenkabel eine Unsumme und muss meistens noch aus Amerika oder Japan importiert werden.

    Die kosten soviel weil der Kabelkopf den man an der Konsole anschließt einen kleinen Chip enthält der dies ermöglicht.


    An sich ist die Konsole selbst fähig YCbCr zu senden, aber durch den üblichen Standard Kabel wird daraus ein niedriges Signal gemacht was zur der Zeit des GameCubes weit verbreitet halt war. Sprich FBAS und SCART.


    Der Chip + neue Verkabelung für YCbCr sorgt dafür das das Signal von der Konsole ein analoges YUV4:2:0 Signal wird.


    Und an sich kostet nicht mal das Kabel soviel, sondern der Ansteck-Kopf zur Konsole.


    An sich gibt es aber ein Preiswerteren Weg. Denn die Wii selbst besitzt ja einen Komponenten Ausgang und sollte auch in der Lage sein GameCube Spiele abzuspielen (jedenfalls die Erstmodelle). Das Ganze ist dann natürlich billiger in Betracht das man zusätzlich Wii und GameCube Spiele zocken kann, als auch die Möglichkeit eines Komponenten Kabels zu nutzen was dann obendrein Progressiv ausgibt.
    Dafür ist eigentlich nur gut zu wissen welches Wii Modell das kann. Das Modell RVL-001 (EUR) sollte dazu komplett in Stande sein.

    Mal auf den Beep Ton achten beim starten des PCs. Wichtig dabei ist zu wissen wie lang die Beep Töne sind.
    z.B.: einmal kurz und zwei mal lang


    Das wäre Hilfreich um irgendwie einen Anhaltspunkt zu bekommen wo in der Hardware der Wurm drin ist.


    ASRock müsste ein AMI BIOS drin haben.


    Da du sagst das der Monitor aus geht und sogar ein Flimmern da ist, solltet ihr mal auf folgende Beep Codes achten:

    • 1 long, 2 short - Failure in video system
      An error was encountered in the video BIOS ROM, or a horizontal retrace failure has been encountered
    • 8 short - Display memory read/write error
      The system video adapter is missing or defective
    • 2 short - Memory parity error
      A memory parity error has occurred in the first 64K of RAM. The RAM IC is probably bad
    • 1 short - DRAM refresh failure
      The programmable interrupt timer or programmable interrupt controller has probably failed



    Auch prüfen könnte man den Speicher mit memtest86
    Am besten dafür wäre eine CD. Man lade sich dieses Image runter von memtest86: http://www.memtest86.com/downloads/memtest86-iso.zip
    und brennt es auf eine leere CD oder DVD. Wie auch immer. Wichtig dabei ist: Sie sollte Bootfähig sein. Sollte die ISO an sich schon alles enthalten.


    CD dann ins Laufwerk rein und PC neu starten und von der CD starten lassen. Danach wird memtest86 ausgeführt und die Speicherbänke überprüft. Sollten irgendwo Fehler innerhalb der Speicherbänke sein (Mit ERRORs gekennzeichnet bzw. sogar Warnungen), dann sollte man das Speichermodul identifizieren nach dem Ausschlussverfahren indem man eine nach der anderen auf die gleiche Art und weise testet. Hat man den DIMM Baustein der als Übeltäter in Frage kommt, sollten keine Fehler mehr bezüglich des Speichers auftreten.



    Das wären erst mal die üblichen Dinge die man erst mal tun könnte um das Problem zu identifizieren.

    Ohne jetzt alle Seiten gesamt gelesen zu haben, kann ich mal ein paar technische Daten liefern die schon von der Konsole herrühren und die man gewiss nicht mit einem 0815 Tool wie Premiere Elements oder Vegas oder sonst irgendwas retten kann.


    Die PAL Varianten von Games als auch Konsolen wie bei der PS2, GameCube als auch N64 liefern vorwiegend Interlacing Material. Bei dem Versuch eines falschem Deinterlacing Verfahren kann es zu unangenehmen Ghosting Effekten führen die deine Videos soweit ich es sehen konnte beinhalten.
    Auch extrem Achtsam sollte man mit der Aufnahme FPS sein und diese stehts einhalten und nie versuchen vor dem Deinterlacing zu ändern. Bzw. in einer Software wie Vegas oder Premiere oder sostiges mit einer ganz anderen FPS einzulesen. Das ist absolut der falsche Schritt.


    Das Ziel was angestrebt werden sollte ist der Konsole bzw. der Aufnahme schon Progressiv (Vollbilder) zu entlocken. Und das ist der Knackpunkt an der ganzen Geschichte.


    Wenn du Progressiv Bilder hast die kein Ghosting aufweisen, kannst du das Material hoch skalieren lassen auf min. 1152p und vllt. auch noch mit 41 FPS. Dann hast du auf YT im Endeffekt auch ein viel sauberes Bild.


    Der User @strohi hatte sich extra eine japanische GameCube bestellt, da diese anders als die europäische GameCube ein Progressiv Modus hatte. Und dann sehen auch die Spiele ganz anders aus. Viel sauberer halt.


    Die letzte europäische PS2 Slim kann so gut wie alle PS2 Spiele egal aus welchen Land sie kommen abspielen.


    Dabei sollte man anmerken das es hier an den Spielen liegt wie das Ausgangsmaterial ist.
    Als Beispiel:
    Die PAL Version von FFXII (Deutsche Version) ist Interlaced und läuft auf 50Hz Basis
    Eine bestimmte NTSC Varianten aus Amerika und die Japanische NTSC Fassung von FFXII laufen in Progressiv bei einer 60Hz Basis


    Das heißt das FFXII bis jetzt nur in der Japanischen und Amerikanischen Fassung wirklich Progressiv dargestellt wird.


    Das gilt auch für viele andere Games.



    Bei N64 ist es wieder mehr die Konsole die einen falschen Output erzeugt.



    Und vor allem sei gesagt das man niemals mit einem FBAS Kabel bzw. SCART das ganze aufnehmen sollte. Das wird sonst immer schlimmer.
    Am besten für die 3 genannten Konsolen ist ohne zuviel Modding betreiben zu müssen der Anschluss eines Komponenten Kabels der dann ein sauberes YUV4:2:0 Bild übertragen kann.


    Richtige Modder haben da schon HDMI und solche Scherze an der Konsole rangebastelt.



    Fazit also: Der Anfang muss schon korrekt ablaufen, bevor man überhaupt an eine Verarbeitung denken sollte. In deinem Falle erst einmal ganz wichtig: Einhaltung der FPS von Anfang bis Ende und vor allem, wenn das Video bei der Aufnahme schon Interlacing aufweisen sollte, stehts ein passenden Deinterlacer verwenden.


    Und erst dann kann man an der Schönheit feilen. Eventuell ein kleines Facelifting der Aufnahme.


    An eine reine Native Aufnahme wirst du nie ran kommen. Jedenfalls nicht wenn du kein Modding an Konsolen betreibst.


    Hier hatte ich mal für @strohi versucht via AVISynth seine Aufnahme von der Avermedia seines Interlaced GameCubes an die Native Variante des Emulators anzugleichen:


    Sah Anfangs echt übel aus. Hier kannste das auch gerne noch mal lesen wenn das Interesse bestehen sollte: Encoding-Talk


    Zusätzlich kann man noch einige andere Features dann nutzen um die Aufnahme aufzupolieren. Denn wenn ich bei deinen Aufnahmen auf YT diese Verlustartefakte sehe, die aber schon von der Konsole herrühren, dann kann man eventuell noch mal drüber nachdenken spezielle angepasste Verfahren zu nutzen um z.B. unerwünschte Kräuselungen an harte Kanten zu reduzieren.
    Das hier wäre so ein Beispiel wo ich sowas bei einem PS1 Game mal angewendet habe + zusätzlich ein wenig mehr Sättigung gegeben:

    (links das Original, rechts die Nachbearbeitung)


    Hier auch noch mal mit nur der Nachbearbeitung:


    Wirkt gleich viel besser. Und das ist aus einem PS1 Game ohne Interlacing auf einer Auflösung von 1440p



    Und tja... was soll ich noch sagen? Ich denke wer nicht allzuviel neues anwenden will, weil er der Meinung ist das alles viel zu kompliziert sei, dann muss ich leider sagen das der Lernfaktor nicht all zu hoch ist überhaupt etwas ändern zu wollen. Weil so hockt man immer nur auf den Kram den man kennt ohne jemals über den Tellerrand zu schauen.

    Naja, weil es eigentlich ein Amiga Game ist und keiner es großartig in DOS zockt im Netz. ^^


    Scheint auch mehrere Episoden zu geben dazu. 30 Stück wenn ich richtig gezählt habe.


    Jede Episode scheint auf eine andere Disk zu laufen.


    Und es scheint auch recht schwer es für DOS zu finden. Für Amiga solltest du es aber finden können.

    Eventuell das Game Time Runners - The Nightmare Prince?


    Da geht es auch um Roboter, Dinosaurier, einen Mann mittleren Alters der die Hauptfigur bildet und seine Freundin.


    Und es gibt es für DOS.

    @Peacemaker666
    Wenn in der Intro1.avi und in der 01.avi die Tonspuren drin sein sollten, dann ist der Rattenschwanz unten im Skript überflüssig (Zeile 44 bis 50)


    Das was du da hast ist das Video Skript, nicht das Audio Skript ;D


    Ich weiß das du beides in einen Skript haben willst, aber das ist ineffizient und vermüllt die Übertragung des AVISynth Frameservers nur. Daher wird es entlastet, wenn Video und Audio seperat gemacht werden. Immerhin wird es in MeGUI ja wieder aufgespaltet und wieder zusammen gemuxt. Dann kann man es auch gleich getrennt lassen und MeGUI macht es dann zusammen.


    Ich hab das nicht umsonst getrennt voneinander ^^



    Und dann... nicht von dem Skriptinhalt vom SSM irritieren lassen. Ich weiß das da sehr viel steht, aber im Endeffekt kommt da nicht viel raus.
    Warum es so groß ist liegt an den Funktionen die eine Multifunktionale Geschichte spielen.
    z.B. mehrere Videos verschiedener Kodierter Varianten können zusammen gesetzt werden.
    Mehrere Videos unterschiedlicher Auflösungen, Farben, usw. werden auf einen Nenner gebracht, damit sie zusammen passen.


    Dafür sind die Funktionen da.
    AutoFPS wird z.B. verwendet um die FPS über AVISource zu korrigieren. Halt damit bei einem 60 FPS Video nicht 59,9999999 ankommen, sondern exakt 60, da AVISource gerne mal ungenau ist.


    Farbmatrix Beachtung bei Konvertierungen usw.


    Das meiste was da steht ist für die Aspect Ratio Geschichte wo jedes Video sein Seitenverhältnis beibehält und einen schwarzen Rahmen oder Hintergrundbild bekommt die der Zielauflösung entspricht.


    Daher steht da soviel.



    Das was in Zeile 44 bis 50 passiert kann wieder zu Asynchronisation führen.
    Das was @De-M-oN bei sein Descent vorher gemacht hat indem er alle Audiospuren zusammen gepappt hat und überall ein paar ms gefehlt haben. ^^
    Daher wurde ja dann der SSM entwickelt, damit man sowas halt nicht mehr macht.

    DVI besitzt eine schnellere Reaktionszeit, als HDMI.

    Eigentlich nicht.
    Kommt drauf an welche HDMI Version du da verwendest.


    Als Beispiel:
    DVI-A ist z.B. für Analog Übertragungen und kommt z.B. für VGA Adapter zum Einsatz
    DVI-D kann max. 1920x1080 bei 60Hz übertragen, bei einem DVI-D Dual-Link kann man max. 4K bei 60Hz übertragen
    DVI-I ist ein Universelles Modell des DVIs. Es vereint DVI-A als auch DVI-D und ist auch als Dual-Link verfügbar.


    Single-Link erkennst man wenn die DVI Verbindung 2 seperate PIN Haufen hat.
    Dual-Link erkennt man wenn die DVI Verbindung die Volle Pin Belegung innerhalb des Pin-Haufens hat.
    DVI-D hat zusätzlich einen Schlitz-Pin an der Seite
    DVI-I hat zu dem Schlitz-Pin 4 weitere Pin-Belegungen um sich.


    Und DVI-A hat den Schlitz-Pin + die 4 Pins um den Schlitz-Pin + 8 Pins als 1 Pin Haufen + 4 Seperate Pins neben dem Pin-Haufen.


    Halten wir also fest: Bei Grafikkarten kommt DVI-D zum Einsatz als Dual-Link Variante. Daher sind 4K mit 60Hz möglich.



    Bei HDMI kann das schon ganz anders laufen.
    Ab 2013 gibt es HDMI 2.0 was eine maximal Auflösung von 4K 60Hz erlaubt.
    Mit HDMI 1.0 bis HDMI 1.2a waren nur 1080p bei 60Hz drin.


    4K war bereits schon mit HDMI 1.4 schon möglich, jedoch lediglich mit 30Hz



    Und jetzt muss man nur noch wissen das die Hertz Zahl die FPS entspricht die du am Monitor siehst.


    Der Monitor selbst hat eine eigene Reaktionszeit. Den kannst du auf 120Hz oder was weiß ich stellen, mehr als das was durch das Kabel kommt, würdest du optisch gar nicht sehen.


    Jetzt kann es aber auch sein das mit HDMI 2.0 als auch DVI-D (Dual-Link) die ja beide 4K 60Hz Unterstützen mit einer Einstellung von 1080p auf 120Hz kommen.


    Fazit: HDMI und DVI bauen auf eine gleiche Technologie auf. Von der Übertragung und Qualität unterscheiden sie sich nicht. Sofern man 2 Modelle mit ähnlicher Charakteristika vergleicht.




    Edit:
    Bei einem DisplayPort v1.3 sind Übertragungen von max. 7680×4320 (mit Kompression) und 5120×2880 (ohne Kompression) möglich bei 60Hz
    Die Bandbreitenübertragung entspricht mehr als das doppelte eines HDMI 2.0
    Es kann ebenfalls Ton übertragen
    Es ist Abwärtskompatibel zu anderen Übertragungsvarianten
    3D Übertragung ist auch möglich wie bei HDMI 2.0, was DVI schon gar nicht kann
    Und man kann mehrere Monitore damit ansteuern, was HDMI und DVI nicht mal können. (Daisy Chaining)

    Fehlerliste:

    • Warum wird in CBR aufgenommen? VBR ist viel effizienter und sollte zudem auch noch die CPU entlasten.
    • Wenn man nicht streamt, warum OBS nutzen und nicht OBS Studio oder eine andere Aufnahme Software? Denn bei OBS Studio kann man neben der Stream Funktion und den Standard x264 was OBS von Natur aus drin hat auch auf andere FFmpeg Codecs gehen wie schon angesprochen UTVideo, was weitaus weniger CPU verbraucht, da du mit dem jetzigen x264 ein Preset fährst das deutlich mehr CPU verbraucht.
      Auch das Profile main ist völlig überholt.
      Du nutzt quasi von x264 nur den Mainconcept Anteil was der Codec bietet und das auch noch total uneffizient die CBR Nutzung.
    • Dann noch mal wegen der CBR. Du gibst dort eine feste Bitrate von 80mbit/s an. Die wird durchgängig gehalten. Das heißt ob Standbild oder nicht, es werden in einer Sekunde knallhart 80mbit verballert. Würde dir wie gesagt bei VBR nicht passieren und hättest sogar noch Luft.
      Je mehr du speicherst, auslagerst und und und kostet das nicht nur CPU, sondern auch Festplattenspeicher die unnötig hochgetrieben wird mit CBR.
    • Dann die Frage warum du während der Aufnahme skalieren musst, wenn du es eh nicht streamst? Irgend ein Grund dafür? Sehe ich momentan nicht wirklich. Die Skalierung, auch wenn es mit einem Bilinear Filter relativ schnell geht, ist während einer Aufnahme immer negativ zu sehen. Nicht nur das du dir damit sogar noch die Aufnahme schlechter machst, sondern es kostet auch CPU Leistung, da es ja während der Aufnahme neben dem Spiel mit läuft. Sowas macht man einfach nicht. Für Streaming mag das eine ganz andere Sache sein, aber für Lokale Aufnahmen ist das Gift.
    • Und von x264 als Aufnahme Codec würde ich ohnehin abraten. Weil A) die Decodierung benötigt recht viel CPU Leistung, was beim Bearbeiten und der Neu-Encodierung in einem Schnittprogramm auf die Zeit auswirkt wie lange das Teil braucht bis es fertig ist und B). x264 ist ein recht komplexer Lossy Codec, den man zwars auf Lossless stellen kann, aber eigentlich nicht Sinn und Zweck dessen ist.
      Zumal bei einer Lossless Aufnahme mit x264 viele der Bearbeitungsprogramme versagen bei der Decodierung.

    Effizient und recht CPU Schonend sind daher Lossless Codecs. Die brauchen nur die CPU für die Kompression, der Rest wird von der Festplatte abverlangt wie schnell sie schreiben kann. Und es wird bei einem Lossless Codec in der Regel immer soviel Bitrate genommen wie nötig ist.


    Die Bitrate ist von mehreren Faktoren abhängig:

    • Auflösung: Höhe * Breite
    • Lauflänge des Videos
    • FPS
    • Farbtiefe
    • Komplexität des Videos (Bewegungen wie Vegetation oder Blickänderungen, Texturendichte wie z.B. hochaufgelöste und sehr Detailreiche Wände oder Böden im Spiel selbst)
    • Kompressionverfahren


    Bei CBR wird 1, 2, 3, 4, 5 und 6 komplett ignoriert ^^ Weil die 80mbit stehen fest für jede Auflösung die du nimmst, jede FPS die du einstellst, jede Lauflänge des Videos die du ja denk ich mal individuell gestaltest, selbst bei der Farbtiefe und den Rest bis 6 runter wird alles an deiner Qualität zehren und natürlich auch an deiner CPU. Die Qualität dabei ist schlichtweg total variable.
    Bei einem Extrembeispiel hättest du bei einem simplen GBA Spiel noch tolle und einwandfreie Ergebnisse, und wenn du dann ARC Survival oder ähnliches zockst nur noch Blöcke und Geschmiere in der Aufnahme, weil die 80mbit/s gar nicht mehr ausreichen an einigen Stellen.


    Daher immer VBR nutzen. Das machen selbst die Lossless Codecs.


    CBR wird so gut wie nie genutzt eigentlich. Höstens zum Streamen vllt. Aber selbst dort erscheint es völlig Bescheuert dies zu nutzen. Damit macht man einfach die Dateien unnötig groß auf kosten der CPU.


    Ganz einfacher Vorschlag von mir:
    Wenn x264 schon genutzt wird bei der Aufnahme (was ich so nicht empfehlen würde für lokale Aufnahmen), dann bitte über eine Constant Rate Faktor aufnehmen um das Potential von x264 auch zu nutzen, ein High Profile unbedingt dann auch nutzen und vor allem in VBR aufnehmen.


    Noch besser ist die Aufnahme mit einem richtigen Lossless Codec wie MagicYUV oder UtVideo. Das sollte CPU schonender sein, da hier mehr die Schreibgeschwindigkeit der Festplatte gefragt ist. Weil bei Lossless muss die CPU nix weiter machen als Kompressionsmechanismen der Lossless Codecs anzuwenden. Und das ist in der Regel weit weniger als wenn ich mit x264 aufnehmen mit einem voreingestellten Preset und einer festen Bitrate.


    Bei Lossless wird nicht viel gemacht. Bei x264 ohne das man Lossless aufnimmt wird viel CPU verwendet da es zur Laufzeit encodieren muss. Und das kann einfach nicht jeder Rechner stemmen. Da ist es dann schon angenehmer gleich einen Lossless Codec zu verwenden.


    Habe selbst eine alte Kamelle hier von einem Rechner zu stehen. Core Duo mit 2Ghz und 2GB Ram. Was soll ich sagen... 720p30 in RGB und Lossless mit MagicYUV waren drin ^^ Flüssig. x264 ist mir da eher abgeraucht ^^


    Edit:

    Also ich habe meine Bitrate bei OBS auf 5000 und läuft einwandfrei. Also sprich 1080p und 60 FPS ohne Lags oder weiteres.

    5000 kbit/s ? Ernsthaft bei 1080p60 ? Ohje...


    Entweder machen es die Leute extrem zu hoch von den Anforderungen oder extrem zu niedrig wie hier gerade.


    Leute... eine fixe Bitrate ist Scheiße. Es ist nix was man pauschal raushauen kann. Keine Lösung.


    5000 kbit/s ist gar nix für 1080p. Für Star Wars Racer in 720p41 habe ich im Durchschnitt über 8500 kbit/s gebraucht mit x264 bei einem CRF von 23


    Beim gleichem CRF in 1080p41 benötigt es schon durchschnittlich 15mbit/s


    Und schon sieht man das CRF Qualitätsbasierend ist und nicht Bitratenbasierend.


    Die Werte können je nach Spiel komplett andere sein, weil wie gesagt das hängt von einigen Faktoren ab.


    Mit einer fixen Bitrate aufzunehmen, selbst mit VBR kommt im Endeffekt nix gutes bei raus. Es ist recht ineffizient, da es mehr einem Mainconcept Encoder Entspricht wie man ihn in jedem Schnittprogramm findet. Und sowas bei der Aufnahme schon... na dann gute Nacht oder besser gesagt: Viel Spaß beim Rate Spiel ;D

    Nummer 1: Hier in diesem Bild werde ich gefragt, ob ich den progressiven Modus aktivieren will und der gelbe Text heißt "Ja".
    Stimmt das so?

    はい heißt ja und いいえ heißt nein.


    Mein Japanisch ist ohnehin etwas schlecht. Die Frage müsste aber in etwa so heißen: Progressiv modus aktivieren?


    Hier müsste dann bestätigt werden, dass ich in den progressiven Modus wechsle.
    Wieder die Frage: Stimmt das so?

    Genau. Einfach eine Bestätigung ist das.



    Letzte Frage:
    In diesem Bild müssten drei Wörter zu finden sein:
    "Normal", "weich" und "scharf".
    Welches davon ist welches?

    ソフト heißt Weich (erstes Bild [1])
    ノーマル heißt Normal (mittleres Bild [2])
    シャープ heißt Scharf (letztes Bild [3])

    Dann bringen mir meine bisherigen Programme allerdings trotzdem mehr. Ich muss sowieso Video- und Audiodatei zusammenfügen und die Ränder entfernen. Das kann ich mit SSM und MeGUI nicht so machen wie ich es gerne hätte. Oder wahrscheinlich geht es schon, nur ist das einfach viel zu kompliziert für mich.

    ?(


    Wow.


    Das nenn ich mal einen DAU ^^