Beiträge von Sagaras

    @RealLiVe
    Du weißt schon das es Ironisch gemeint war wa ich sagte, ja? ^^


    Hast ja recht das es störend ist und einen auch Zeit raubt irgendwo. Aber man kann es halt nicht ändern. Wie du schon sagtest... es ist überall. Mobiltelefone, Internet und auch Software geben es ja vor und da wollen halt [lexicon]OS[/lexicon] Entwickler nicht zurückstehen.


    Auf dem Markt herrscht Krieg und derjenige der seine Produkte am besten vermarktet gewinnt.


    Wenn man so zurückblickt... Bei MSDOS gabs ja fast 0 Support. Es sei denn man hatte irgendwann ein Windows wie 3.1 und konnte mit Netscape über ein 56k Modem ins Internet.


    Win95/98/2000/Me sind auch alles [lexicon]OS[/lexicon] Systeme gewesen wo man halt Support bekommen konnte im Netz, aber aufgrund der Hardware die [lexicon]OS[/lexicon] Systeme nicht sonderlich zumüllte.


    Damals war man halt noch bedacht alles irgendwo Optimal zu gewährleisten.


    Und schau dir doch mal jetzige [lexicon]OS[/lexicon] Systeme an. Massig Support im Internet. Anfragen über Probleme und Lösungen werden halt jeden Tag gestellt oder gesucht.


    So nach dem Motto: Den Wald vor lauter Bäumen nicht sehen.


    Und dann gibt es halt Programme die es vormachen wie Skype, [lexicon]Steam[/lexicon] und der ganze Kram. Überall nur Werbung zu finden. Und die verdienen nicht mal schlecht dran. Ist halt eine Finanzquelle die sich bewährt hat. Oder bei Online Games hat sich dieses Prinzip ja auch bewährt. ^^ Ich sage da nur kostenlose MMORPGs.


    Oder schau dir das Schnittprogramm Premiere an. x264pro für 200 Mücken und kann weitaus weniger als das kostenlose [lexicon]x264[/lexicon]. Sollte einen mal zu denken geben ^^


    Und wenn Windows 10 da mitzieht, dann entspricht das auch nur dem was andere bereits vorgemacht haben. Es ist zwars irgendwo eine Verarsche an sich, aber mit dieser Masche ziehen sie den Leuten das Geld aus der Tasche. Ist einfach so.


    Eigentlich müsste man sowas unterbinden, aber es gibt nun mal kein Gesetz das Verbietet Werbung in oder an seine Produkte zu binden.


    Vielleicht kommen se ja noch irgendwann mal auf die Geniale Idee ein [lexicon]OS[/lexicon] zu entwickeln das nur dann gestartet werden kann wenn eine Internetverbindung besteht um erforderliche Benutzerrechte von der Seite des [lexicon]OS[/lexicon] Vertreibers zu verifizieren. ^^


    Gibt es ja schon bei Spiele, warum also nicht auch für [lexicon]OS[/lexicon] Systeme? xD


    Weißt doch selbst wie das ist... Dummheit kennt keine Grenzen ^^

    Aber der Nutzer schreit kurz auf und nimmt es hin und das haben die Unternehmen und die Politik begriffen.


    Genau das isses. Es wird sich kurz aufgeregt, dennoch aber tolleriert. Und später irgendwann so oder so als Normal abgestempelt. Immerhin... es ist ja kein Zwang xD


    Schließlich müssen die armen Leute von Microsoft ja von irgendwas leben. Ich meine... ein Eigenheim, ein Pool, ein Ferrari oder glänzenden PickUp... das klingt halt schon sehr ärmlich. Sowas müssen wir halt unterstützen. Nicht das die Leute da verhungern ;D

    Warum regt man sich denn so auf? Eigentlich sollte vor allem die deutsche Bevölkerung wissen was Kapitalismus ist ^^
    Aus allem und jedem Geld zu machen ist doch was ganz feines. ^^ Immerhin wollen einige von euch auf YT ja auch am liebsten Geld mit ihren Videos verdienen. Nun ja... Unternehmen wie Microsoft macht das halt auf diese Art und Weise ^^
    Und in der Industrie darf man sich als Leiharbeiter auch die Knochen kaputt machen für 8.20€ die Stunde und eventuall 7€ Prämie im Monat, wärend sich andere Leute die im Büro sitzen sich die Eier schaukeln.


    Sehe da nix schlimmes dran. Ist halt alles normal und rechtens ^^

    Den ganzen Aufwand kannst du dir auch sparen indem du einfach den Emulator snes9x statt [lexicon]zsnes[/lexicon] benutzt. Funktioniert einwandfrei und lässt sich einwandfrei aufnehmen.


    Der Snes9x steht hier aber nicht zur Diskusion. Ich hab den [lexicon]ZSnes[/lexicon] deswegen ausführlich beschrieben, weil jedesmal im Forum die gleichen blöden Fragen kommen wie z.B. "[lexicon]DxTory[/lexicon] erkennt [lexicon]zsnes[/lexicon] nicht? Was tun?", "Wieso geht Triplebuffering nicht, hab Win8?", "Wie kann ich den [lexicon]ZSnes[/lexicon] am besten aufnehmen?", "Problem beim aufnehmen von [lexicon]ZSNES[/lexicon] mit [lexicon]FRAPS[/lexicon]", usw.


    Somit kann man sich das Gerede darum sparen und die Geschichte mit diesem Emulator abkürzen.


    Finde den Snes9x an sich auch besser, vor allem deshalb da ich da kein Mencoder brauche und die Games gleich mit einem geeigneten VFW [lexicon]Codec[/lexicon] intern capturen kann. Auch das andere Aufnahmeprogramme das Ding hooken können dank der Direct3D oder OpenGL Geschichte. Auch das ich Pixel Shader verwenden kann intern und auch die Möglichkeit für Netzwerkgames habe.


    Ohne Worte.


    Edit:
    Und vor allem sollteste mal an deine eigene Nase fassen: DxTory erkennt zsnes nicht? Was tun?


    Weil ich nutz den Snes9x schon seit Jahren. Damals war der sogar noch in Entwicklung gewesen.


    Aber wie gesagt... Dieses Tutorial hier gilt für Leute die hier im Forum Threads eröffnen mit [lexicon]ZSnes[/lexicon] Emulator Aufnahmeproblemen kommen (so wie du z.B.) und biete somit Alternativen an Spiele an diesen Emulator dennoch aufnehmen zu können. Und genau das haste nicht gerafft wo du dein Beitrag geschrieben hast ;D Bzw. warst zu faul mal weiter zu lesen, weil dann hätteste dir dein Beitrag sogar sparen können ^^

    Das Interleave ist die Verzahnung zwischen Video und Audio in einem AVI [lexicon]Container[/lexicon].


    Sprich: Wieviel Samples werden einem [lexicon]Frame[/lexicon] zugeteilt.


    Bei einem Audio Interleave von 1.00 je Video [lexicon]Frame[/lexicon] sind keine Abweichungen vorhanden.


    Bei einem Interleave von 5.00 je Video [lexicon]Frame[/lexicon] ist da aber schon eine Abwechung vorhanden.


    Als Beispiel:
    Video hat 60 [lexicon]FPS[/lexicon], dann müsste der Interleave des Audios exakt 1/60sek betragen (~17ms)


    Wenn das Video 50 [lexicon]FPS[/lexicon] hat, dann müsste der Interleave des Audios exakt 1/50sek betragen (20ms)


    (müsste. ;D)


    Interleave, Dauer : 100 ms (5,00 Video-Frames)


    Bei dieser Angabe jedoch ist es schon 5/50sek die dann halt 100ms ergeben.



    Ist aber nicht so gravierend, denn das Video kann trotzdem dann Synchron sein. Das mit dem 1.00 video [lexicon]Frame[/lexicon] Interleave ist ein Idealwert, aber nicht zwingend erforderlich.


    Hab hier bei mir hier zig AVIs, darunter auch Filme bis zu 3h wo der Interleave mit der [lexicon]FPS[/lexicon] total aus der Bahn läuft beim Interleave. Da hab ich dann mal Werte von 7.13 oder 0.56 ^^


    Und trotzdem sind die Videos synchron. Also das ist wie gesagt nur eine Verzahnungsgeschichte zwischen Video und Audio im AVI [lexicon]Container[/lexicon].


    Vllt kann ich das ja mal mit zwei Videos verständlicher erklären:
    Wenn man 2 Videos mit unterschiedlicher [lexicon]FPS[/lexicon] in einem AVI Video [lexicon]Container[/lexicon] reinquetscht, die aber Zeitlich genau gleich lang sind, dann gibt es zwischen den beiden Videos ein Interleave Differenz.


    Trotzdem würden beide einwandfrei abgespielt werden.


    Durch das Interleaved Verfahren werden Video und Audio halt verzahnt/verschachtelt, damit daraus halt nur 1 Lesepfad wird. Darum können AVIs auch sehr schnell gelesen und verarbeitet werden.

    @TbMzockt
    Der Snes9x steht hier aber nicht zur Diskusion. Ich hab den [lexicon]ZSnes[/lexicon] deswegen ausführlich beschrieben, weil jedesmal im Forum die gleichen blöden Fragen kommen wie z.B. "[lexicon]DxTory[/lexicon] erkennt [lexicon]zsnes[/lexicon] nicht? Was tun?", "Wieso geht Triplebuffering nicht, hab Win8?", "Wie kann ich den [lexicon]ZSnes[/lexicon] am besten aufnehmen?", "Problem beim aufnehmen von [lexicon]ZSNES[/lexicon] mit [lexicon]FRAPS[/lexicon]", usw.


    Somit kann man sich das Gerede darum sparen und die Geschichte mit diesem Emulator abkürzen.


    Finde den Snes9x an sich auch besser, vor allem deshalb da ich da kein Mencoder brauche und die Games gleich mit einem geeigneten VFW [lexicon]Codec[/lexicon] intern capturen kann. Auch das andere Aufnahmeprogramme das Ding hooken können dank der Direct3D oder OpenGL Geschichte. Auch das ich Pixel Shader verwenden kann intern und auch die Möglichkeit für Netzwerkgames habe.


    Und trotzdem gibt es noch bessere Emulatoren für [lexicon]Famicom[/lexicon] Games als den Snes9x und [lexicon]ZSnes[/lexicon]. Die beiden bereits genannten sind ja nur die bekanntesten wo sogar die gleichen Entwickler beteiligt waren auch.


    Evtl. wär eine kurze Zusammenfassung für Leute die nicht die Hintergründe interessiert nützlich? So in etwa "5 Schritte zur fertigen AVI"?


    5 Schritte? ^^ Und dann noch kurz? xD


    Hmm...

    • Beigefügten Emulator downloaden
    • Emulator + Spiel starten
    • Makro aufzeichnen
    • Makro Aufzechnung als Video dumpen
    • Gedumptes Video und Audio via beigefügter [lexicon]Batch[/lexicon] zusammensetzen lassen und in UTVideo und [lexicon]PCM[/lexicon] signed 16bit little endian encoden

    Reicht das schon? ^^ Kurz und Bündig. Weiß nur nicht ob damit jemand was anfangen kann xD

    und das Bild Dunler mach weil Youtuber mach das heller das Bild


    Tut es nicht. Youtube nutzt TV Range (Begrenzten Farbbereich) und kein PC Range (Vollbereich)


    Für Videos ala [lexicon]VP9[/lexicon], [lexicon]MP4[/lexicon] (h264), FLV und auch viele andere die YV12 nutzen und [lexicon]lossy[/lexicon] sind nehmen für gewöhnlich immer TV Range.


    TV Range = 16 - 235
    PC Range = 0 - 255



    Sofern du Chrome nutzen solltest oder den [lexicon]VLC[/lexicon] Player, so sollte man die [lexicon]Grafikkarte[/lexicon] mal entsprechend einstellen das diese auf PC Range arbeitet bei Videos. Weil dann gibt es keine Komplikationen zwischen RGB (PC Range) Konvertern und richtigen YUV Ausgaben die oftmals dann in TV Range vorliegen.


    Bei NVIDIA sieht das entsprechend so aus:


    Bei ATI Grafikkarten gibt es auch sowas.


    Bitte die Videos nicht selbst dunkler machen via Kontrast und Helligkeit. Das Phänomen ist ein reinen PC vs TV Range Problem und kann via Grafikkarteneinstellung behoben werden.

    Einige Windows 8 User unter euch werden es gewiss schon mitbekommen haben das der [lexicon]Zsnes[/lexicon] nicht hookbar ist von Aufnahmeprogrammen, da Triple Buffering nicht seine Funktion erfüllt. Und einige andere Windows User wie Win7, WinVista und WinXP werden gemerkt haben das Triple Buffering den Emulator etwas ausbremsen tut.


    Ich zeige euch hier nun mehrere mögliche Alternativen, mitunter auch Triple Buffering als auch ohne, die Spiele im Emulator aufzuzeichnen.



    Weg #1: Triple Buffering (Nicht Nativ):


    Triple Buffering (deu. Dreifach Puffer/Speicher) beschreibt ein Konzept in der Computergrafik, bei dem der Framebuffer
    des Video-RAM bei Grafikkarten in drei Bereiche unterteilt wird. Ziel des Verfahrens ist es, die bei gleichzeitiger Verwendung von [lexicon]VSync[/lexicon] (vertikale Synchronisation) und Doppelpufferung (double buffering) auftretenden Nachteile während des Bildaufbaus zu kompensieren.
    Der Unterschied zwischen Doppel- und Dreifachpufferung liegt in der Einteilung des Framebuffers. Während bei der Doppelpufferung der Framebuffer aus zwei Pufferspeichern (Front- und Backbuffer) besteht, sind es derer drei bei der Dreifachpufferung (ein Frontbuffer und zwei Backbuffer).


    Also funktioniert hier der Hook von Aufnahmeprogramm deshalb da er hier den Backbuffer abgreifen kann, der vorher nicht vorhanden war. Im nun befindlichen 2ten Backbuffer kann nun gehookt und die Frames abgegriffen werden.


    Funktionieren tut dies im [lexicon]Zsnes[/lexicon] nur wenn man eine [lexicon]Auflösung[/lexicon] wählt wo Filter nutzbar sind.


    Dabei gibt es beim [lexicon]Zsnes[/lexicon] mehrere Abkürzungen:
    D - Allow Filter / Lasse Filter zu
    S - Stretch / Strecken
    R - Keep 8:7 Ratio / Behalte 8:7 Verhältnis bei
    W - Windowed / Im Windows Fenster
    F - Fullscreen / Im Vollbild


    Passend für jeden User sind die Custom Auflösungen die ganz unten in der Liste bei Video zu finden sind.


    Wichtig halt ist für Triple Buffering die Nutzung der Filter. Da die Filter bei einer Custom [lexicon]Auflösung[/lexicon] nur bei Vollbild nutzbar sind, wird automatisch halt auch eine Vollbildauflösung notwendig sein.


    Eine 8:7 Ratio (Seitenverhältnis) ist ein typisches Standard Seitenverhältnis für [lexicon]Snes[/lexicon] Games (Original). (Muss jeder für sich wissen ^^)


    Unter Filter ist dann Triple Biffering zu finden und kann dann aktiviert werden.


    Nun sollten Aufnahmeprogramme wie [lexicon]Fraps[/lexicon], [lexicon]DXTory[/lexicon], [lexicon]MSI Afterburner[/lexicon] und Co. den Znes aufnehmen können.




    Weg #2 Desktopaufnahme (Nicht Nativ):


    Klar, Weg Nummer 2 ist die Aufnahme via Desktop. Sprich ohne Hooking. Auch hierbei darf der [lexicon]Zsnes[/lexicon] im Vollbild laufen und mit Filter arbeiten.


    Desktopaufnahmen gehen z.B. mit:
    [lexicon]MSI Afterburner[/lexicon] (Riva Tuner = Application Detection Level auf None stellen)
    [lexicon]Fraps[/lexicon] (Nur via Windows Aero = DWM Mode)
    Virtual Dub (Screen Capture)
    [lexicon]Camtasia[/lexicon] Screen Recorder (Bitte hier geeigneten [lexicon]Codec[/lexicon] verwenden dann)



    Weg #3 Intern via Mencoder und FFV1 [BGR32] ([lexicon]Lossless[/lexicon]) (Nativ):


    Weg Nummer 3 ist schon kniffliger, dafür aber absolut Nativ. Was mein ich mit Nativ? Nativ ist wenn in der [lexicon]Auflösung[/lexicon] aufgenommen wird den die Romgrafiken hergeben. Nativ ist, wenn es im Original Seitenverhältnis auch ist. Und es ist auch die [lexicon]FPS[/lexicon] damit gemeint die bei [lexicon]Snes[/lexicon] Games bei 60/1,001 [lexicon]FPS[/lexicon] liegt. Sprich 59,94 [lexicon]FPS[/lexicon].


    Wenn diese native [lexicon]Auflösung[/lexicon] auch noch [lexicon]Lossless[/lexicon] in der Farbunterabtastung 4:4:4 aufzunehmen ist, dann hat man im Endeffekt ein hübsches Video was man sehr sehr schön hochpolieren kann und die Qualität somit der ersten beiden genannten Wege in den Schatten stellt.


    ACHTUNG!!! Leider hat dieser Weg nur einen Nachteil. Die Spiele müssten für ein [lexicon]Let's Play[/lexicon] nachkommentiert werden, da es bei dieser Art der Aufnahme keine Framedrops geben wird.


    Was ist zu tun?
    Als erstes werdet ihr ein paar Tools brauchen:

    • Mencoder (Zur interner Video-Aufzeichnung) [ACHTUNG: Es darf keine neuere Version sein]
      Download
    • [lexicon]AVISynth[/lexicon] (Entweder via dem [lexicon]SSM[/lexicon] installieren lassen oder auf http://avisynth.nl/index.php/Main_Page#Official_builds sich die passende Version runterladen und installieren)
    • [lexicon]MeGUI[/lexicon] wäre schön zu besitzen, da hier alle [lexicon]AVISynth[/lexicon] Filter dabei sind die gebraucht werden. (BassVideo und FFMS2)

    Ihr entpackt die mencoder.7z mit WinRar oder 7zip und kopiert die beiden Datein "mencoder.exe" und "pthreadGC2.dll" direkt in euer [lexicon]ZSnes[/lexicon] Verzechnis.



    Sind beide Files im [lexicon]Zsnes[/lexicon] Verzeichnis, so startet und beendet ihr den [lexicon]ZSnes[/lexicon] um folgende Datein erzeugen zu lassen:



    Hier öffnen wir nun mit dem normalen Windows Editor die Datei "zmovie.cfg" und ändern die Zeile
    md_ffv1="-ovc lavc -lavcopts vcodec=ffv1:vstrict=-2:aspect=4/3"
    in
    md_ffv1="-ovc lavc -lavcopts vcodec=ffv1:vstrict=-2:format=bgr32"




    Damit wird mencoder angeordnet, das er die Frames nicht in 4:3 strecken soll wie vorher angegeben war, sondern Original Seitenverhältnis beibehält und er speichert FFV1 nicht in YV12 ab, sondern in BGR32 alias RGB32. RGB24 gibt es leider nicht als Auswahlformat bei Mencoder.


    Nun öffnet ihr euren [lexicon]ZSnes[/lexicon] und stellt ihn wie gewohnt ein wie ihr es haben wollt.


    Als nächstes müsst ihr ein Spiel starten/laden um dann unter "Misc" in die "Movie Opt" zu gelangen




    Jetzt wirds interessant.
    Links (siehe letztes Bild oben) seht ihr den Tab "Control" und rechts den Tab "Dumping". Beides gehört zusammen, aber beides baut aufeinander auf.


    Im Tab "Control" könnt ihr für ein Spiel bis zu 10 Filme aufnehmen. Dies entspricht aber einer Makroaufzeichnung des Spieles. Das bedeutet: Sobald ihr unter Control ein Movie recorden tut, wird dies Makromäßig im Verzeichnis der Rom als zmv aufgezeichnet. Sprich die zmv wird am Ende der Aufnahme nur wenige KB besitzen. Beendet die Makroaufzeichnung, sobald ihr mit dem Dumpen beginnen wollt.


    Ist die Makroaufnahme erfolgt, könnt ihr diese Aufzeichnungen als richtiges Video dumpen lassen. Dafür ist dann der Tab "Dumping" da. Hier wählt ihr eure Makroaufzeichnung die ihr bei Control angelegt habt aus (0 - 9) und könnt dann das Video dumpen lassen.


    Da wir nun FFV1 eingestellt haben in der CFG, nutzen wir auch gleich die FFV1 Auswahl und lassen Audio nur an sich dumpen. (VORSICHT: Nicht mit Video mergen lassen, weil Mencoder dann eine MP3 daraus machen wird.)
    Stellt es am besten so ein wie auf dem rechten Bild gezeigt wird.


    Die Dumping Length sollte am besten so lang sein wie die Makroaufnahme der zmv Datei.


    Habt ihr alles so, könnt ihr das Video dumpen lassen. Dies kann dann einige Minuten in Anspruch nehmen, da die Makroaufzeichnung dann noch mal durchlaufen wird.
    Es sollten zwei Datein danach entstehen. Einmal die "Video.avi" und einmal die "Audio.[lexicon]wav[/lexicon]".


    - Ab hier kann auch ein Tool verwendet werden was ganz unten dieses Tutorials als Anhang zu finden ist -


    Nun müssen diese beiden Files noch entsprechend angepasst und zusammengesetzt werden. Weil ich glaube kaum das NLEs was mit FFV1 anfangen können. ^^ Darum machen wir nun aus dem Video ein UTVideo und reparieren auch gleich noch die falsch geschriebene [lexicon]WAV[/lexicon] Datei (32bit float).


    Das können wir mit [lexicon]AVISynth[/lexicon] und den Filtern von [lexicon]MeGUI[/lexicon] erledigen.


    Dazu erstellen wir uns ein AVS Skript:


    Dieses Skript kann dann mit FFMpeg in UTVideo und [lexicon]pcm[/lexicon] signed 16Bit little Endian gespeichert werden.
    FFMpeg Befehl dazu:
    ffmpeg.exe -i FFV1_merged.avs -c:v utvideo -c:a pcm_s16le -map 0 FFV1_to_UTVideo_merged.avi


    Damit hättet ihr ein natives komprimiertes [lexicon]Lossless[/lexicon] RGB24 UtVideo [lexicon]Zsnes[/lexicon] Aufnahme.



    Weg #4 Intern via Mencoder und RAWVideo [BGR24] ([lexicon]Lossless[/lexicon]) (Nativ):


    Die Aufnahme geschieht auf gleichen Weg wie der beschriebene Weg #3, nur das man jetzt statt FFV1, RAWVideo wählt.



    Dies erzeugt dann eine "rawvideo.bin", sowie eine "audio.[lexicon]wav[/lexicon]"


    Die rawvideo.bin ist nun so kodiert, das man Spezifische Angaben machen muss die zur Auslesung der Bildinformationen dienen. Diese RAW (deu. Roh) Speicherung erfolgt beim [lexicon]Zsnes[/lexicon] absolut unkomprimiert [lexicon]Lossless[/lexicon] statt.


    Aufgabe ist es nun dieses Video zu dekodieren. Auch hier hilft uns [lexicon]AVISynth[/lexicon] wieder weiter.


    - Ab hier kann auch ein Tool verwendet werden was ganz unten dieses Tutorials als Anhang zu finden ist -


    Um die zu dekodierenden spezifischen Informationen zu finden brauchen wir ledeglich nur die "zmovie.cfg" zu öffnen und werden dort fündig.



    Die spezifischen Angaben sind halt:
    Breite: 256
    Höhe: 224
    [lexicon]FPS[/lexicon]: NTSC: 59649/995 und PAL: 50/1 (Sehr Wichtig, da dies Nachjustiert werden muss)


    Ein zusätzliches [lexicon]AVISynth[/lexicon] Plugin wird nun Notwendig


    Das folgende [lexicon]AVISynth[/lexicon] Skript sieht dann so aus:


    NTSC Version:


    PAL Version:


    Dieses Skript kann dann mit FFMpeg in UTVideo und [lexicon]pcm[/lexicon] signed 16Bit little Endian gespeichert werden.
    FFMpeg Befehl dazu:
    ffmpeg.exe -i RAW_merged.avs -c:v utvideo -c:a pcm_s16le -map 0 FFV1_to_UTVideo_merged.avi



    PS: Wenn ihr die FFV1 Methode und die RAWMethode mit den gleichen Makrovideo austestet, werdet ihr zum Schlussstrich bei dem UTVideo absolut identische Files haben.



    Tools:


    Eine bereits fertig konfiguriertes zmovie.cfg + Mencoder + [lexicon]AVISynth[/lexicon] Plugins + FFMpeg + Batchdatein die automatisch dann via ffmpeg ein Video erstellen habe ich mal samt Emulator zusammengefasst und hochgeladen.


    HINWEIS: Bitte die Ordnerstrucktur des [lexicon]ZSnes[/lexicon] Verzeichnis so belassen nach dem entpacken, da sonst die Batchdatein nicht mehr funktionieren!

    • [lexicon]ZSnes[/lexicon] v1.5.1 MovieMod: Download

    Sobald in FFV1 oder RAWVideo aufgenommen wurde, kann mit den Batchdatein im Unterordner die Videos encodiert werden mit UTVideo.





    Wie ihr dann aufnehmen wollt, liegt ganz bei euch.


    Ein paar Beispiele die man dann mit den Nativen Videos dann anstellen kann mit den richtigen Resizern ^^ :


    Weil das Restbestände deines Vektorbildes sind.
    Die müssen raus.
    Das musste mit deinem Programm abspeichern am besten mit dem du das Bild erzeugt hast.


    Musst aber drauf achten das du dann in RGB24 speichern tust bzw. True Color 24Bit


    Halt ohne [lexicon]Alphakanal[/lexicon].


    PS: MSPaint würde dir das Bild auch so laden wie du es grad gepostet hast. xD

    Da kommen auch keine Zahlen rein ^^


    HQ4x ist ein Faktor 4 Skalierer und HQ2x ein Faktor 2 Skalierer. Da kommen keine Zahlen rein. ^^


    Bitte keine TIF Deiten nutzen. Entweder das Bild als BMP oder als PNG laden.
    Sprich das TIF Bild solltest du in BMP oder PNG noch mal abspeichern am besten.



    Bild lade ich jetzt nicht hoch, da das ganz schön groß wird ^^


    Plugin für PointSize hab ich dir ja gepostet gehabt. Brauchste nur im Skript einbinden. Und halt alles über den [lexicon]AVSPmod[/lexicon] Editor machen, da kannste dann halt das Bild speichern dann. Zoom für die Vorschau auf 100% dann aber stellen (Nicht vergessen.)

    Wenn ich das Seitenverhältnis des Bildes mit berücksichtige komme ich auf 36x46, wenn ich die Höhe als MAX ansehe:


    Code
    ImageReader("2qs74eu.jpg")
    fak = 21
    PointResize(last.width / fak, last.height / fak)


    Oder wenn ich die Breite als MAX nehme dann komme ich auf 51x65


    Code
    ImageReader("2qs74eu.jpg")
    fak = 15
    PointResize(last.width / fak, last.height / fak)

    Gib uns mal das Bild was du da hast. Kannst es hier hochladen: http://www.directupload.net/


    Musste uns nur den Hotlink/Directlink uns hier posten.


    Dann können wir schauen was sich machen lässt. Oder ob sich überhaupt was so machen lässt. Weil [lexicon]Gimp[/lexicon] hat auch verschiedene Skalierer drin.


    Bei [lexicon]Gimp[/lexicon] findet man unter Bild skalieren folgende Skalierer passend zu [lexicon]AVISynth[/lexicon] Skalierer:


    Qualität Interpolation:
    [lexicon]Gimp[/lexicon] - [lexicon]AVISynth[/lexicon]
    Keine - Nearest Neighbor (PointResize)
    Linear - BilinearResize
    Kubisch - BicubicResize
    Sinc (Lanczos3) - LanczosResize(tab=3) oder auch direct SincResize


    Links halt die [lexicon]Gimp[/lexicon] Resizer, rechts halt die passenden [lexicon]AVISynth[/lexicon] Resizer.
    Wenn... dann würde ich bei [lexicon]Gimp[/lexicon] "keine" Interpolation nutzen. Weil PointResize sieht mit ner guten Faktorenskalierung bei einem Bild immer gut aus. Ist allerdings recht scharf.


    Man kann auch HQx Skalierer nutzen für Bilder. Entweder via [lexicon]AVISynth[/lexicon] oder für Bilder allgemein mit dieser Anwendung dann: https://code.google.com/p/hqx/…in32-bin.zip.zip&can=2&q=
    Passendes [lexicon]AVISynth[/lexicon] Plugin dafür ist PointSize: http://forum.doom9.org/attachm…mentid=11076&d=1274312419


    Wie du das machen möchtest liegt bei dir.

    Selbiges Batchverfahren kann man ebenfalls mit dem NeroAAC [lexicon]Encoder[/lexicon] machen. Wenn man FFMpeg und NeroAAC via einer Pipeline verbindet, sorgt FFMpeg für den Decode und NeroAAC für den Encode.


    NeroAAC Audio Encode with FFMpeg [Pipe].bat

    Code
    @echo off
    set _ffmpeg_="D:\MeGUI_2308_x86\tools\ffmpeg\ffmpeg.exe"
    set _neroaac_="D:\MeGUI_2308_x86\tools\NeroAACCodec-1.5.1\win32\neroAacEnc.exe"
    set _input_=%1
    for /f "useback tokens=*" %%a in ('%_input_%') do set _input_=%%~a
    %_ffmpeg_% -i "%_input_%" -c:a pcm_s16le -map 0:a -f wav - | %_neroaac_% -ignorelength -lc -br 320000 -if - -of "%_input_:~0,-4%.m4a"


    Ebenfalls im SendTo Ordner kann man nun jeden Video mit Audio oder nur Audio Input den FFMpeg unterstützt direkt via dieser Funktion mit NeroAAC [lexicon]encodieren[/lexicon] lassen.


    Rausrippen und Encoden mit zwei Klicks halt. Kein [lexicon]MeGUI[/lexicon] mehr von nöten und auch kein X-MediaRecode.

    @GrandFiredust


    Vielleicht wäre es besser wenn du einige Punkte im Startpost ergänzt bzw. abänderst. Ich schreib dir mal auf was mit [lexicon]x264vfw[/lexicon] möglich ist und was nicht. Weil danach richtet sich ja schlussendlich der Encode auch.

    • Encode mit YUV444 (YV24) mit RGB Matrix


      Als Farbinput sollte folgende Einstellung verwendet werden: "Keep input colorspace"


      Zugleich muss aus der Extra command line alle Einträge bzgl. der Farbmatrix entfernt werden. Sprich "transfer", "colormatrix", "colorprim"


      Auch sollte der Eintrag "range" entfernt werden, da die RGB Matrix voraussetzt das das Video Vollbereich ist.


      Encode Schema sieht dann wie folgt aus:
      RGB Aufnahme -> [lexicon]NLE[/lexicon] (RGB) -> [lexicon]x264vfw[/lexicon] (YV24 with RGB Matrix)


      Es stellt die höste zu erreichende Ausgabe bzgl des Farbraumes dar.


      (Vorsicht!!! Das Video kann dann möglicherweise nicht mehr in die [lexicon]NLE[/lexicon] geladen werden, da sie nun den High 4:4:4 Profil hat)

    • [lexicon]x264vfw[/lexicon] kann ledeglich nur in 2 Farbräumen [lexicon]encodieren[/lexicon]. Einmal in YUV420 (YV12) und einmal in den Farbraum der als Input eingeht. Was bei einer [lexicon]NLE[/lexicon] oftmals RGB ist.


      Extra zu sagen das man in YUY2 encoden will geht nur mit der x264cli Version, da dort der Parameter "output-csp" und auch "input-csp" existiert

    • Ein YUV444 (YV24) Encode zu erzwingen indem man sagt "Keep input colorspace" und im Extra command line die Matrix noch angibt fürt zu einer Fehlerhaften Ausgabe des Videos.
      Das Video ist dann zwars in YUV444 (YV24 mit BT.709/BT.601), aber jedoch völlig falsch codiert. (Vorsichtig sein bei der Verwendung, da man den Farbraum Ausgang nicht selbst bestimmen kann außer in YUV420 und Input Farbraum)
    • Batchlisten/Joblisten funktionieren, wenn man bei [lexicon]x264vfw[/lexicon] den Modus VFW verwendet. Da dies via Hack dann geschehen muss ist es oftmals ungewiss ob der bereitgestellte AVI [lexicon]Container[/lexicon] und/oder der Hack den AVC Stream zerstören und somit das Video unbrauchbar machen.
      Grund dafür ist das die Fileangabe bei [lexicon]x264vfw[/lexicon] die alte Datei überschreiben würde. Weshalb dies nicht gehen würde so.

    Schlussbemerkung:
    An sich ist der [lexicon]x264vfw[/lexicon] [lexicon]Encoder[/lexicon] nicht schlecht, dennoch aber nur eine Notlösung für mich, da ich mit dem Teil keine absolute Kontrolle habe wie mit der [lexicon]CLI[/lexicon] Version. Ordentliche Joblisten Abarbeitungen seitens der [lexicon]NLE[/lexicon] mit [lexicon]x264vfw[/lexicon] sind nur mit Problemen verbunden.
    Keine selbstdefinierte Farbraumauswahl für den Output bis auf YUV420 (YV12) und Input Farbraum.



    Edit:
    Audio kann man für [lexicon]MKV[/lexicon] und ebenso für [lexicon]MP4[/lexicon] [lexicon]Container[/lexicon] [lexicon]Lossless[/lexicon] gestalten via ALAC (Apple [lexicon]Lossless[/lexicon] Audio [lexicon]Codec[/lexicon]).


    Dieser ist bei FFMpeg mit integriert und bei [lexicon]MeGUI[/lexicon] als Update verfügbar.


    Aufgerufen wird es via dem Commandbefehl dann:
    FFMpeg.exe -i "Input.avi/wav" -c:a alac -map 0:a "Test.m4a"


    Einfacher und Kompfortabler geht es via Batchdatei und der "Senden an" Funktion von Windows.


    Die Batchdatei kann mittels Notpad oder Notepad++ erzeugt werden.


    Die Batchdatei sollte dann so aussehen:

    Code
    @echo off
    set _ffmpeg_="D:\MeGUI_2308_x86\tools\ffmpeg\ffmpeg.exe"
    set _input_=%1
    for /f "useback tokens=*" %%a in ('%_input_%') do set _input_=%%~a
    %_ffmpeg_% -i "%_input_%" -c:a alac -map 0:a "%_input_:~0,-4%.m4a"


    Bitte den Pfad bei set _ffmpeg_ so angeben das er für euer System stimmt.


    Danach das ganze als "ALAC Audio Encode.bat" speichern.


    Als nächstes ruft man den Ordner "Senden an" auf mittels "Ausführen" oder der Eingabefunktion unter dem Start-Button von Windows. Dort wird dann mittels "shell:sendto" der Ordner für das "Senden an" geöffnet.


    Dorthin kopiert man nun die Batchdatei und kann nun sämtliche Audios in Videos und/oder Audio Datein allgemein die FFMpeg einlesen und Decodieren kann in ALAC umkonvertieren.


    Das gleiche kann auch mit [lexicon]FLAC[/lexicon] so gemacht werden, wer es will. Jedoch: [lexicon]FLAC[/lexicon] ist dann mit [lexicon]MKV[/lexicon] kompatibel, nicht mit [lexicon]MP4[/lexicon].


    Selbiges Batchverfahren kann man ebenfalls mit dem NeroAAC [lexicon]Encoder[/lexicon] machen. Wenn man FFMpeg und NeroAAC via einer Pipeline verbindet, sorgt FFMpeg für den Decode und NeroAAC für den Encode.

    1. Welcher [lexicon]Codec[/lexicon]? Immer noch UTVideo YUV420 BT.709? Oder ein anderer?


    5. YV12 oder YUY?


    Höste Qualität und auch am effektivsten für Skalierer ist RGB oder YUV444 (YV24, i444)


    Mittlere Qualität ist YUV422 (YUY2, YV16, i422)


    Niedriege Qualität ist YUV420 (YV12, i420)



    Am besten ist es immer eine Farbraumkonvertierung zu meiden. Eine [lexicon]NLE[/lexicon] wird egal um welches Video es sich handelt es in RGB umwandeln.


    Ideales Konvertierungsschema:
    RGB -> RGB
    YUY2 -> YUV2
    YV12 -> YV12
    ...


    Gutes Konvertierungsschema:
    RGB -> YUV444 -> YUV422 -> YUV420 -> YUV411 -> YUV400


    Schlechtes Konvertierungsschema:
    YUV400 -> YUV411 -> YUV420 -> YUV422 -> YUV444 -> RGB


    Einen niedriegen Farbraum in einen höheren zu konvertieren verschlechtert die Qualität wieder, da der höhere dann wieder runterberechnet werden muss. Daher ist es angeraten wenn möglich den Farbraum nicht zu ändern.
    Wenn er doch geändert werden soll, dann sollte man den Farbraum am besten immer in den nächst kleineren Farbraum konvertieren.


    Schlechtes Beispiel anhand einer [lexicon]NLE[/lexicon]:
    YUY2 oder YV12 Aufnhame -> [lexicon]NLE[/lexicon] (RGB) -> YV12 Ausgabe
    Resulatat = Farbverlust und Unsauberkeit beim Skalieren.


    Ideales Beispiel anhand [lexicon]AVISynth[/lexicon]:
    YV12 Aufnahme -> [lexicon]AVISynth[/lexicon] (YV12) -> YV12 Ausgabe


    Gutes Beispiel anhand [lexicon]AVISynth[/lexicon]:
    RGB Aufnahme -> [lexicon]AVISynth[/lexicon] (YV12) -> YV12 Ausgabe


    2. Mit wie viel [lexicon]FPS[/lexicon] wird aufgenommen? 60? 25? 50?


    3. Auf wie viel [lexicon]FPS[/lexicon] wird encodiert? Gleiche wie Aufnahme? 50? 41?


    Ideal wäre für Qualität:
    25 [lexicon]FPS[/lexicon] Aufnahme -> 41 [lexicon]FPS[/lexicon] Änderung (Aber bitte ohne [lexicon]Ghosting[/lexicon], sonst ist der Effekt so gut wie 0)


    Gut wäre:
    30 [lexicon]FPS[/lexicon] -> 41 [lexicon]FPS[/lexicon]


    Optimal für sauberen Bildwechsel:
    41 [lexicon]FPS[/lexicon] -> 41 [lexicon]FPS[/lexicon]
    50 [lexicon]FPS[/lexicon] -> 50 [lexicon]FPS[/lexicon]
    60 [lexicon]FPS[/lexicon] -> 60 [lexicon]FPS[/lexicon]


    Man sollte sich entscheiden was einem mehr Wert ist ^^


    4. Ich habe einen 2560x1440 Monitor. Sollte ich auch in der [lexicon]Auflösung[/lexicon] aufnehmen oder in 2048x1152 aufnehmen? Oder sollte ich in 1440p aufnehmen und mit Spline100 (oder einem anderen Resizer -> welchem?) auf 1152p bringen?


    Du hast eine Wide Quarter High Definition (WQHD) Monitor der eine max. Grafikauflösung von 1440p (16:9) gestattet.
    Du musst nicht in dieser [lexicon]Auflösung[/lexicon] aufnehmen. Du kannst.


    Mehr Qualität gibt es immer wenn man eine niedriegere [lexicon]Auflösung[/lexicon] in eine höhere Skaliert, statt eine höhere in eine niedriegere oder sie gleichwertig belässt.


    Der Sinn dahinter ist einfach:
    z.B. hat man mit 720p weit weniger Pixel im Bild zur Verfügung als bei 1080p. Würde ich beide Auflösungen [lexicon]hochskalieren[/lexicon] auf 1152p, so würde die 720p Version weit mehr Qualität haben auf YT als die 1080p [lexicon]Auflösung[/lexicon]. Einfach aus dem Grund das nur vorhandene Pixel entsprechend skaliert werden können. Das komprimiert die Datei zum einen (kleinere Datein für den Upload) und es sieht auf YT besser aus da weniger Bitratenverbrauch für die Frames verwendet werden muss.


    Eine Runterskalierung würde ich eher vermeiden, da es bei Skalierern halt der Fall eines Verlustes der Pixel bei den Frames verursachen kann.


    z.B. 1440p -> 1152p aka (16:9) ist ein Verlust von 1327104 Pixel. Bei solch einer Interpolation des Bildes können z.B. Dinge wie schmale Fadenkreuze oder dünne Schriften getilgt oder auch unleserlich gemacht werden. Und das schon wenn man RGB nutzt.


    6. 8bit Encode oder 10bit Encode?


    8Bit Encode geht schneller.
    10Bit Encode ist etwas langsamer, sorgt aber das [lexicon]Banding[/lexicon] nicht massiv zu sehen ist und schrumpft auch die Dateigröße etwas.


    7. Welche Dst im [lexicon]SSM[/lexicon]? tv.709?


    Youtube nutzt eine TV Skala mit einer BT.709 Farbmatrix. Daher sollte die Destination Abk. Dst. (deu. Ziel) auf TV.709 eingestellt sein.


    8. Welche MT Settings im [lexicon]SSM[/lexicon]? Sourcen 3 Trim 2?


    Ab der Skriptposition der Sourcen immer auf 3 belassen oder höher setzen auf 4, 5 oder gar 6. Niemals 2 oder 1 nutzen, da sonst der Encode fehlerhaft arbeiten würde.


    Ab der Skriptposition für Trim auf 2 stellen, damit alle nachfolgenden Filter mit 2 laufen. 1 wäre das schnellste aber auch gleichzeitig das instabilste MT Setting.


    9. Irgendwelche anderen [lexicon]SSM[/lexicon] Filter? MB?


    Das hängt von der Quelldatei ab.
    Ist das Video in BT.601 aufgenommen worden, so sollte eine Farbmatrixkonvertierung im [lexicon]SSM[/lexicon] angeschaltet werden.
    Liegt das Video in PC Range vor, so sollte es in TV Range konvertiert werden.


    Hatte das Spiel bei der Aufnahme kein eigenes [lexicon]Motion Blur[/lexicon] und ist auch sehr Komplex vom Bildmaterial, sollte [lexicon]Motion Blur[/lexicon] vom [lexicon]SSM[/lexicon] genutzt werden. Spiele wie [lexicon]Arma 3[/lexicon] z.B.


    Welche Filter man wann verwendet, hängt immer von der Quelle ab und sollte sich daher ein bisschen danach richten.


    10. aq-strength=1.25 und trellis=2?


    aq-strength oder auch Adaptive Quantizer Stärke bei dem 8Bit [lexicon]Encoder[/lexicon] am besten nur verwenden mit 1.25.
    Bei dem 10Bit [lexicon]Encoder[/lexicon] kann er auf Standard 1.0 belassen werden.


    trellis auf Standard lassen am besten. 1 ist standard und entspricht "Final MB" -> Sprich für den finalen Encode von einem Macro Block.


    11. bframes=?


    Hier am besten auch auf Standard lassen mit 3 BFrames und aktiviertem "Weighted Prediction for [lexicon]B-Frame[/lexicon]" mit normaler B-Pyramide.


    Für schnellen Encode kann man die BFrames auch auf 0 stellen.


    12. Irgendwelche anderen magischen [lexicon]x264[/lexicon] Settings für Qualität/Dateigröße?


    Max. [lexicon]GOP[/lexicon] Size = 0 (Infinite)
    Min [lexicon]GOP[/lexicon] Size = 1


    Damit spart man viel Dateigröße.
    Einziger Nachteil ist das das Video danach nur noch an bestimmten Stellen spulbar ist wo sich Frames in 45% voneinander unterscheiden. z.B. Menübild -> Spielbild (Übergang)


    Auf Youtube hochgeladen kann dann wieder auf YT ganz normal gespult werden.


    13. Noch irgendwas wichtig :D?


    Solange du keine weiteren Fragen hast und dir alles soweit klar ist ^^