SagaraS Scriptmaker (GUI)

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Anzeige
    Übergänge erfordern ein Encode
    Schneiden würde nur an i-frames gehen ohne Re-Encode.

    TMPGEnc Smart Renderer kann's ohne Re-encode, da würde dann nur der GOP Bereich neu codiert werden.

    Wenn du mitm CRF aber auf Nummer sicher gehst (so richtung 18 oder tiefer) dürfte der re-encode aber nich all zu schlimm sein.

    Wichtig bei Shadowplay: 4k wählen. Nicht spielintern, nicht 1080p, oder sonstwas. 4k. Er nimmt weiterhin in deiner Spielauflösung auf, jedoch verhält sich Shadowplay halt wie Youtube. Nur auf 4k gibts nämlich tatsächlich auch die 130 mbit. Stellst du zb auf spielintern und spielst nur in 1440p, nimmter nur in 100mbit auf, auch wenn der Regler auf 130 steht. spielst du sogar nur in 1080 würde er gar nur in 50 mbit aufnehmen. Die 130 mbit kommen nur auf 4k an. Daher 4k wählen.

    Dann noch ganz wichtig wegen der VFR:

    Bei SSM unter sonstiges beim VFR - CFR Converter das Video rein, 60 als fps angeben (ich gehe mal von aus das du 60 fps nehmen willst, macht ja sinn) und dann auf l-smash oben klicken, dann auf libav klicken, so das im Scriptfenster LSMASHVideoSource benutzt wird und nicht LWLibav.

    Das Script dann speichern und dann in SSM Videoliste das Video mit dem Script tauschen. Dies ist halt nötig, weil du sonst kein synchrones Video zu CFR erhältst.

    Aber vllt findest du ja den Grund warum dein AB nicht will. Vllt wird ja was unerwünschtes mitgehookt. Das ist meistens das Problem.





    Seit etlichen Monaten komplett veraltete Signatur, wie ihr sicherlich schon bemerkt habt. Habe mittlerweile mehr als 4 Projekte, weshalb die Signatur leider momentan gesprengt ist xD
    Notdürftig die Liste was aktuell läuft: Unreal | DooM 2: Project Brutality | Complex DooM (LPT) | DooM 2016 | Need For Speed III: Hot Pursuit | Dirt 4 | WRC 7
  • De-M-oN schrieb:

    Wichtig bei Shadowplay: 4k wählen. Nicht spielintern, nicht 1080p, oder sonstwas. 4k. Er nimmt weiterhin in deiner Spielauflösung auf, jedoch verhält sich Shadowplay halt wie Youtube. Nur auf 4k gibts nämlich tatsächlich auch die 130 mbit. Stellst du zb auf spielintern und spielst nur in 1440p, nimmter nur in 100mbit auf, auch wenn der Regler auf 130 steht. spielst du sogar nur in 1080 würde er gar nur in 50 mbit aufnehmen. Die 130 mbit kommen nur auf 4k an. Daher 4k wählen.
    Danke, das wusste ich nicht.
    [IMG:http://fs5.directupload.net/images/160520/vljqhpgc.jpg]
    *tschiep* Fallout 4 / Dragon Age: Inquisition (Hakkons Fänge) *tschiep*
  • Wo genau muss ich die Übergänge platzieren? Ich bekomme immer "Clip is shorter than overlap". Dabei hab ich Framelänge 60 und den Übergang beginnend 60 Frames, bevor das Einzelvideo Ende ist, gesetzt.

    Also quasi an Frame 192 endet das eine Video und direkt danach fängt das andere an. Dazwischen will ich einen TransWipe 3 - e mit 60 Frames als Dauer.
    Was muss ich dann in SSM angeben? Wenn ich Frame 192 angebe, kriege ich halt "Clip is shorter than overlap". Wenn ich 60 Frames zurückrechne und es für Frame 132 setze, bekomme ich den Fehler trotzdem.

    Kriege zudem beim Skript abspeichern immer "Acces Violation: attempting to read from avisynth.exe" ..

    Hab wieder die alte SSM-Version genommen. Mit der ging es jetzt.

    Also irgendwie ist TransWipe verbuggt. Das erste TransWipe fügt er gar nicht ein, das zweite ist genau passend und alle Weiteren sind zeitlich verschoben.
    [IMG:http://fs5.directupload.net/images/160520/vljqhpgc.jpg]
    *tschiep* Fallout 4 / Dragon Age: Inquisition (Hakkons Fänge) *tschiep*

    Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von Spieluin ()

  • Spieluin schrieb:

    Also irgendwie ist TransWipe verbuggt. Das erste TransWipe fügt er gar nicht ein, das zweite ist genau passend und alle Weiteren sind zeitlich verschoben.
    Die sind nicht Zeitlich verschoben, sondern bauen sich vom vorherigen auf.

    Beispiel:
    Dein Video hat 1800 Frames bei 60 FPS. Das sind also insgesamt 30sek

    Du baust dann 2 Übergänge ein mit jeweils 60 Frames.

    Das bedeutet das der Übergang bei Clip A und Clip B sich über 60 Frames ergibt. Sprich der Punkt wo sie miteinander verschmelzen und der Übergangseffekt sitzt dann.
    Logischerweise wird das Video somit auch kürzer.
    Sieht ja auch doof aus wenn so ein Übergangseffekt kein Effekt erzielt, oder ? Und irgendwie muss man das ja aufbauen. Macht auch jedes Schnittprogramm leider so ^^

    Also hast du nach 2 Übergängen eine Gesamtlänge des Videos von 1680 Frames

    Wenn du also die Übergänge von Hinten anfängst zu setzen, stimmen deine Positionen halt später nicht mehr.


    Spieluin schrieb:

    Wo genau muss ich die Übergänge platzieren? Ich bekomme immer "Clip is shorter than overlap". Dabei hab ich Framelänge 60 und den Übergang beginnend 60 Frames, bevor das Einzelvideo Ende ist, gesetzt.
    Die Meldung erscheint nur wenn die Übergangsdauer länger ist als die Länge eines der Clips am Trennpunkt.

    Beispiel:
    Dein Video hat 1800 Frames

    Du setzt jetzt an Frame 1740 ein Übergangseffekt hin mit 60 Frames Länge.
    Das bedeutet:
    Clip A ist 1740 Frames lang und Clip B ist 60 Frames lang

    Funktioniert nicht, weil Clip B genauso lang ist dann wie die Übergangsdauer.

    Er hätte also 0 Frames übrig um die Clips wieder zusammen zu setzen.

    Gleiches würde auch bei Frame > 1740 passieren bei diesem Beispiel.
    Ab Frame 1739 würde der Effekt laufen.

    Gleiches auch am Anfang für Clip A.
    Sprich Frames < 60 Frames würden auch nicht klappen. Erst ab Frame 61 würde es funktionieren.

    Sprich der Übergangseffekt mit einer Länge von 60 Frames kann bei einem Video mit 1800 Frames genau zwischen Frame 61 und Frame 1739 gesetzt werden ohne Fehlermeldung ;D



    Funktioniert alles auch einwandfrei mit der aktuell verfügbaren SSM Version 6.1
    Also da gibt es noch keine Probleme.


    Spieluin schrieb:

    Kriege zudem beim Skript abspeichern immer "Acces Violation: attempting to read from avisynth.exe" ..
    Bezweifle ich das der Fehler es so hieß.

    Der hieß wenn dann schon:
    "Access Violation: attempting to read from avisynth.dll"

    Es gibt nämlich keine avisynth.exe ;D

    Und dann sagst du das du den Fehler explizit nur bekommst wenn du es abspeichern willst? Beim Text abspeichern bekommst du also schon Fehlermeldungen? Oder wie jetzt?
  • Anzeige
    Ich habe die Übergänge von vorne aufgebaut. Der erste TransWipe war nie sichtbar, obwohl das ja der wäre, der auf jeden Fall richtig sitzt. Die anderen waren halt alle verschoben, obwohl ich bei jedem TransWipe 60 Frames weiter zurückgegangen bin. Sie waren irgendwann viel zu früh, obwohl ich beim ersten -60 Frames gesetzt habe, beim zweiten -120 Frames usw.
    [IMG:http://fs5.directupload.net/images/160520/vljqhpgc.jpg]
    *tschiep* Fallout 4 / Dragon Age: Inquisition (Hakkons Fänge) *tschiep*
  • Darüber können wir lange spekulieren wie du das nun gemacht hast. Eventuell hast du auch etwas falsch gemacht. Kann auch sein. Vllt. das du den ersten vergessen hast in die Liste zu adden?

    Bedienen aber viele falsch das Feature. Wäre also nicht mal so abwegig.

    Weil ich hab das nun mit 3 verschiedenen Video Typen vollzogen. Überall funzte es wie es soll.
    Vllt. haste dich selbst nur etwas vertan?
  • Wenn du den Workflow nicht gerade gefilmt hast, lässt sich das schlecht nachweisen. Weil ich kann es halt nicht reproduzieren was du da gemacht hast, womit diese Fehlermeldungen die du da hast provoziert wurden.

    Ich kann die Fehlermeldung nur reproduzieren wie ich beschrieben hatte. Alle anderen Schritte haben bei mir funktioniert.

    Wenn dich da eine Lösung halt interessiert dann machste entweder ein Video vom Workflow oder wir machen das über TeamViewer oder Skype oder belassen es einfach, sofern es dir egal ist. ^^
  • Die Meldung mit dem zu kurzen Clip, das war meine Schuld, ja. Das hab ich dann durch zurückrechnen der Frames behoben.

    Aber die Meldung mit der VirtualDub.exe (das war es) konnte ich nur beheben, indem ich eine alte Version des SSM installiert hab und nicht die neuste.

    An sich ist es jetzt egal, ich habe es gestern noch mit einem anderen Programm fertiggestellt, da mir die Zeit weglief.
    [IMG:http://fs5.directupload.net/images/160520/vljqhpgc.jpg]
    *tschiep* Fallout 4 / Dragon Age: Inquisition (Hakkons Fänge) *tschiep*
  • Wie ist inzwischen der Stand der Dinge? Leider finde ich hier keine Funktion, um diesen Thread zu durchsuchen ...
    Ich nutze meist Spline 36 oder 100, vor allem bei Arma ist das ja doch immer knifflig, eine gute Balance zu finden.
    Aber: Chrome Resample an? Resample HQ an? ColorMatrix?
    Als Farbraum habe ich den YV12 eingestellt, aufgenommen wird mit dem Dxtory Codec in 422 oder 420.

    Und den YUY2/YV16 Fix einschalten?
    Ich wäre euch sehr dankbar, könnte sich jemand die Mühe machen, kurz zu antworten. Insbesondere bei Chroma und der ColorMatrix bin ich immer etwas unsicher. In der Vorschau erkenne ich nie einen Unterschied ...
  • Also ich weiß nur das man Chroma und ColorMatrix aus lassen kann/sollte. Von den YUY2/YV16 Fix habe ich bisher noch nichts gesehen oder gehört!? Oder ich sollte mal meine Brille putzen, zumindest habe ich das nicht bei SSM!!!

    Ich benutze NUR Spline36.

    Aber andere könnten dir da bestimmt besser Helfen als ich, da ich mich immer selber verwirre :D
    Mein Channel.

    Derzeitige Projekte:

    Alien: Isolation "DLCs"
    Green Hell
  • Den AssumeFPS nur auf den einen Clip anwenden und ChangeFPS als globaländerung (neue Zeile)
    oder
    ApplyRange oder Trim verwenden (kann man machen, wenn innerhalb eines Clips was verändert werden soll)





    Seit etlichen Monaten komplett veraltete Signatur, wie ihr sicherlich schon bemerkt habt. Habe mittlerweile mehr als 4 Projekte, weshalb die Signatur leider momentan gesprengt ist xD
    Notdürftig die Liste was aktuell läuft: Unreal | DooM 2: Project Brutality | Complex DooM (LPT) | DooM 2016 | Need For Speed III: Hot Pursuit | Dirt 4 | WRC 7
  • Ich habe da einige Varianten ausprobiert.
    Was "prinzipiell" funktioniert, ist hinter jeden Videoteil (beim Trim) einzeln eine AssumeFPS().ChangeFPS() zu packen; dabei eben beim ersten video 60 und beim rest dann immer 120 - Das scheint aber MeGUI eher probleme zu bereiten da es beim encodieren dann fast immer irgendwann stecken bleibt.

    Alles andere führt aber entweder zum "Clips haben unterschiedliche Framerates" Error oder die Globale Änderung überschreibt die Änderungen für einzelne clips.

    ApplyRange habe ich auch ausprobiert, aber die Änderung hält sich nicht an die range sondern wirkt sich auch auf das gesamte Video aus.
  • Smokie schrieb:

    ApplyRange habe ich auch ausprobiert, aber die Änderung hält sich nicht an die range sondern wirkt sich auch auf das gesamte Video aus.
    Sollte es eig. nicht. Vllt falsch angewendet.





    Seit etlichen Monaten komplett veraltete Signatur, wie ihr sicherlich schon bemerkt habt. Habe mittlerweile mehr als 4 Projekte, weshalb die Signatur leider momentan gesprengt ist xD
    Notdürftig die Liste was aktuell läuft: Unreal | DooM 2: Project Brutality | Complex DooM (LPT) | DooM 2016 | Need For Speed III: Hot Pursuit | Dirt 4 | WRC 7
  • Wie stelle ich denn den PointSize am Besten ein wenn die Quelle 640x480 hat ? (4:3)
    geht das auch wenn man kein rgb aufgezeichnet hat eventuell sondern 4:4:4 mit magicyuv ?

    Scaler in dosbox svn daum hab ich momentan auf "advinterp3x" stehen.

    Edit:
    Ich kann auch in 1920x1080 aufnehmen, dann brauche ich nur bei "neue Auflösung" 2560x1440 eingeben oder brauch ich nen Resizer Factor zum ändern oder ähnliches ?
    DSR ist halt nicht so toll aufm Desktop nicht, schrift ist halt Mist und DosBox z.B. läuft dann nicht vernünftig und so Sachen.


    Gruss Dennis

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Dennis_50300 ()

  • Dennis_50300 schrieb:

    geht das auch wenn man kein rgb aufgezeichnet hat eventuell sondern 4:4:4 mit magicyuv ?
    MagicYUV kann RGB aufnehmen. Dafür musst du einfach bei MagicYUV unter Mode (Conversion) auf "Compress-as-is (no conversion)" einstellen.
    Da dein Input von der DOSBox RGB24 bzw. RGB32 ist, kannst du so in RGB auch aufnehmen.

    Und ja, YV24 alias YUV444 geht auch. Es muss für eine Punktskalierung der Farbraum ein Subsampling von 4:4:4 haben. 4:2:0, 4:2:2 oder anderes würde dir Buchstäblich sonst das Video ruinieren.

    Dennis_50300 schrieb:

    Wie stelle ich denn den PointSize am Besten ein wenn die Quelle 640x480 hat ? (4:3)
    geht das auch wenn man kein rgb aufgezeichnet hat eventuell sondern 4:4:4 mit magicyuv ?

    Scaler in dosbox svn daum hab ich momentan auf "advinterp3x" stehen.
    Das eine ist zum anderem suboptimal für dein Vorhaben.

    Eigentlich nimmt man wenn schon die DOSBox ohne irgendein Scaler auf und das in einer 1:1 Auflösung die das Spiel vorgibt. Nicht die DOSBox. Weil dann kannst du vom PointSize Filter mit xBRZ etc. auch ein optimales Ergebnis erwarten.
    So beißt sich das jetzt aber mit dem Scaler den die DOSBox schon vollführt hat und dem Scaler den du beim SSM nutzen willst.

    Ist halt Suboptimal. Zum einen wirst du vermutlich mehr Dateigröße bei der Aufnahme haben und zum anderen dank dem Scaler von der DOSBox schon ein modifiziertes Bild.

    Denn PointSize funktioniert anhand der Pixel. Darum auch Punkt-Skalierer. Und bei deiner Aufnahme ist da halt schon was geändert worden.
    Das nur mal als Hinweis, das du da noch mehr rausholen könntest.

    Hier mal Bildlich erklärt an HQ3x
    Wenn das Bild deine Basis ist:
    Wo du halt dann auch jeden Pixel der Formen erkennen kannst, weil Niedrigauflösung ...
    [IMG:https://upload.wikimedia.org/wikipedia/commons/c/cb/Test_nn.png]

    ..., dann kannst du mit HQ3x dieses Bild erzeugen in 3x vergrößerten Ausgabe:
    [IMG:https://upload.wikimedia.org/wikipedia/commons/f/f5/Test_hq3x.png]


    Die feinen Abstufungen können erst erzeugt werden, sofern aus der Basis die Pixel erkannt werden. Daher heißen die Dinger halt Punkt-Skalierer.
    Bei dir wäre dann halt die Basis das mit dem Filter behandelte "advinterp3x" und skalierte DOSBox Bild was du zusätzlich noch mit einem Punkt-Skalierer behandelst. Und da ist oft schon der meiste Effekt der dahinter steht verpufft. ^^





    Zu deiner Frage aber:
    Im SSM PointSize aktivieren.

    Dann wählst du unter dem PointSize Fenster ein Skalierer aus. z.B. xBRZ und wählst dann den Faktor aus.
    Breite * Faktor x Höhe * Faktor
    640 * 3 x 480 * 3 = 1920 x 1440

    Im normalen Auflösungs Fenster siehst du unter der DAR Anzeige den Punkt "Resize Factor". Den setzt du dann ebenfalls auf 3 dann, sofern 3 dein Faktor ist den du bei PointSize angegeben hast.
    Damit wird dann nur noch xBRZ angesprochen.

    Du kannst aber auch die ausgerechnete Auflösung manuell reinschreiben, bzw. aus der Preset Liste wählen, sofern vorhanden. Damit hast du dann die Möglichkeit ein Video das nicht der Auflösung entspricht mit Faktor 3 mit einzubinden.
    z.B. wenn ein Video 320x200 hat, das nächste 640x480 und noch eins vllt. mit 1920x1080. Dann werden diese zwars alle um den Faktor 3 mit dem PointSize skaliert, aber zum Schluss auf die Zielauflösung gebracht die du eingestellt hast.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Sagaras ()

  • also bei "original" mit passender aspect belassen in der dosbox, mindestens 444 aufnehmen und dann kann ich Point resize machen ja ?

    Ich Blick das noch nicht so 100% aber ich kann ja Mal Screenshots schicken wie ich mir das denke wenn ich wieder daheim bin.
    Bevor ich mir da was zergeigrendere :)

    Danke erstmal

    Gruss Dennis
  • Dann also so ja ?
    [IMG:http://fs5.directupload.net/images/170502/temp/iz65y9mz.jpg]

    Ausgehend davon das Wc3 640x480 fährt in der DosBox, ich möchte ja schicke 2560x1440 erreichen nachher.
    Da ich in 4:4:4 aufnehme, muss ich sicherlich den Haken rausnehmen bei rgb input conversion ?

    Edit:
    Hatte mal eben ne Aufnahme gemacht und testgerendert, wenn ich den Haken rausnehme gibt MeGUI ne fehlermeldung, wenn der Haken drin ist funktionierts aber mit dem Rendern und sieht auch anständig aus :)

    Edit2:
    Also so an sich krieg ich's wohl hin, nur komischerweise kommt mir das Bild nicht so flüssig vor wie es eigentlich sein sollte, kann aber auch daran liegen das ich bevor ich das fertig gerenderte angeschaut habe, ich rtcw gedaddelt hab was an sich deutlich mehr fps hat und zwar immer :D
    Hab erstmal nur das Intro aufgenommen gehabt und gerendert, also 444 geht wohl, Seitenverhältnis beibehalten muss ich nur unbedingt anhaken sonst zieht er mir das Bild nachher im Video in die Breite.

    Ich hoffe das das so nun passt, das er die 640x480, auf 2560x1440 hochskaliert beim Rendern.

    Wenn ich das sonst nun mache mit 1920x1080 zu spielen (meine native Auflösung ohne mit DSR aufzunehmen) und im SSM 2560x1440 einstelle das passt dann eig. schon.


    Gruss Dennis

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Dennis_50300 ()

  • Dennis_50300 schrieb:

    Hatte mal eben ne Aufnahme gemacht und testgerendert, wenn ich den Haken rausnehme gibt MeGUI ne fehlermeldung, wenn der Haken drin ist funktionierts aber mit dem Rendern und sieht auch anständig aus
    Der Filter läuft nur mit RGB32. Darum wird beim SSM die Videos auf RGB32 konvertiert, bevor der PointSize Filter arbeiten kann.
    RGB24 wird dann halt auch auf RGB32 geändert. Da passiert gar nix, da kommt nur ein leerer Farbkanal (Alphakanal) hinzu.
    Beide haben ein Subsampling von 4:4:4, da jeder Pixel aus seinen eigenen Rot, Grün und Blau Anteil besteht.
    Zusätzlich wird der Alphakanal mit berücksichtigt, was natürlich sehr genial an diesem Filter ist, sofern man z.B. Bilder skalieren will damit. Also mehr macht als der SSM das bietet ^^

    Genauso wie YUV444 (YV24) jeder Kanal ein Pixel beschreibt. Daher ist dieser Farbraum noch Kompatibel mit PointSize. Der einzige Verlust da ist das das Video minimale kaum bzw gar nicht sichtbare Farbverluste erleidet, da zwischen YUV und RGB Rundungsfehler entstehen.

    YUV420 oder YUV422 würden dir das Bild total zerstören mit PointSize. Da das Subsampling total anders ist wo halt der UV 2 oder gar 4 Y Kanalpixel anspricht.


    Dennis_50300 schrieb:

    Ausgehend davon das Wc3 640x480 fährt in der DosBox, ich möchte ja schicke 2560x1440 erreichen nachher.
    Da ich in 4:4:4 aufnehme, muss ich sicherlich den Haken rausnehmen bei rgb input conversion ?

    Kenne deine DOSBox Einstellungen leider nicht.

    Aber die DOS Spiele haben meist ihre eigenen Auflösungen. z.B. Wolfenstein3D läuft nativ mit einer Game Auflösung von 320x200. Das hast du bei dutzende von DOS Spielen.
    Das ist die native Auflösung, weil das Pixelverhältnis 1:1 ist.

    Gibt auch viele anamorphe DOS Spiele. Das heißt das das Spiel z.B. mit 320x200 programmiert wurde, aber für 320x240 ausgelegt ist. Da stimmt dann das Pixelverhältnis von 1:1 nicht mehr. Sondern weicht ab.

    Jetzt hast du aber bei der DOSBox die Möglichkeit Auflösungen einzustellen. Da die DOSBox über eigene Skallierungsfilter besitzt, weicht das manchmal dann auch von der nativen Game Auflösung ab.
    Die Aspect Ratio Einstellung in der DOSBox versucht die Spiele anamorph wieder in das 4:3 Verhältnis zu bringen, bzw. was das Spiel gerne vorgibt. Das bedeutet das du bei einer anamorphen Game Aufnahme schon ein völlig falsches Pixelverhältnis hast.

    Das Pixelverhältnis sollte aber 1:1 sein die vom Game aus kommt, sonst verwirkst du einiges was du mit xBRZ rausholen könntest. Und vor allem brauchst du die Spiel Grundauflösung.

    z.B. Wolfenstein3D läuft in 320x200
    Oder Blood läuft in mehreren Auflösungsstufen, dank Vesa Treiber.

    Bei Wolfenstein3D dann diese Auflösung nutzen die das Spiel von Grundauf vorgibt (Nicht die DOSBox entscheiden lassen)
    Bei Blood nimmste dann halt die dir optimalste Auflösung. z.B. 800x600 + xBRZ 3x im SSM = 2400x1800 ODER 1024x768 + xBRZ 2x = 2048x1536

    Bei 320x200 kannste auch wieder auf 4:3 nach dem PointSize morphen lassen.

    320x200 + xBRZ 6x = 1920x1200

    Beachte das es immer noch eine 16:10 Auflösung ist. Die kann man dann zu 4:3 morphen lassen. Am besten die Höhe auf die Breite anpassen, um mehr Auflösungshöhe zu bekommen für YT. Anamorph am besten dann mit Spline36 oder Spline16 auffüllen lassen.

    höhe = breite / 4 * 3
    höhe = 1440
    Gesamtauflösung 1920x1440 (4:3)

    Oder du passt die Breite auf die Höhe an. Selbes Verfahren, nur auf die Breite halt.

    breite = höhe / 3 * 4
    breite = 1600
    Gesamtauflösung 1600x1200 (4:3)

    Damit morphst du das Bild wieder so wie es sein sollte.

    Das musst du dann aber abschätzen können. So bekommst du auf jedenfall ein optimales Ergebnis, da der PointSize Filter so auch optimal arbeiten kann.

    Und am besten halt KEINE Filter in der DOSBox verwenden. Nix darf das Bild verändern. Absolut gar nix.

    Du kannst bei der DOSBox auch mal die interne Aufnahmefunktion nutzen. Die greift das Spiel nativ ab. Immer mit einem Pixelseitenverhältnis von 1:1
    Daran kannst du dich dann orientieren wie die Aufnahme dann auszusehen hat von der Bildqualität, der Auflösung und dem Seitenverhältnis.

    Gleiches Verfahren mit den PointSize Filter kannst du bei jedem Emulator nutzen. Für optimale Bildergebnisse.

    Alles was du danach machst ist dir dann überlassen.



    Dennis_50300 schrieb:

    Hab erstmal nur das Intro aufgenommen gehabt und gerendert, also 444 geht wohl, Seitenverhältnis beibehalten muss ich nur unbedingt anhaken sonst zieht er mir das Bild nachher im Video in die Breite.
    Bei vielen DOS-Game-Intros und Cutscenes kann es sein das diese mit einem anderen Farbraum stattgefunden haben oder schon Verlustbehaftet mitgeliefert werden.
    z.B. im Bink oder Smacker Format oder gar integriert in den Spieldateien irgendwo.
    Blood 1 hat z.B. Videos die schon mit Verlust kodiert wurden. Weiß jetzt gar nicht ob das in CVID sogar war.
    Bei BluByte Games haben sie meist Smacker genutzt.
    LucasArts hat Smush Formate genutzt für Videos.
    Andere wieder Bink Videos.

    Das ist eigentlich recht Kunterbunt gehalten. Also Intros und Cutscenes können, auch wenn du sie in 444 aufgenommen haben solltest, trotzdem ein Original Farbraum von 4:2:0 oder 4:2:2 besessen haben. Meist aber das es bescheidene 256 Farb-Videos waren wo irgendwo noch die Palette dran hing.

    Variiert halt von Spiel zu Spiel wie die Original Daten Vorliegen zum Intro.

    Ist das Intro oder die Cutscene schon im Original kein 4:4:4 geeignetes Bild, sondern hast es nur in 4:4:4 aufgenommen, kann es unter Umständen nach dem PointSize auch wieder schlecht aussehen.
    Da muss man dann eventuell Kompromisse ziehen. ^^

    Zum Theme Seitenverhältnis hatte ich ein Zitat zuvor was geschrieben ;D


    Bedenke das du das alles nicht so machen musst wie ich dir das erklärt habe. Ich habe dir nur den Weg aufgezeigt um ein optimales qualitatives Bild dem Ganzen zu entlocken.
    Andere Herangehensweisen wären Suboptimal und man müsste sich dann überlegen ob der Einsatz von einem PointSize Filter angebracht währe. Weil gerade die DOSBox bietet ja auch schon einige Filter an.

    Aber je kleiner das Bild bei der Aufnahme, desto schneller wird der im SSM und MeGUI durchgejagt sein. Gerade was Auflösungen unter 600p angeht. Das läuft dann später recht flott. Die Aufnahme ist dann auch nicht so groß, FPS hat man dann vllt. sogar in 60 bei der Aufnahme und joa. Ist halt ein schickes Verfahren. ^^ Bei so alten Games sollte man das schon ausnutzen.