Beiträge von De-M-oN

  • MeGUI [2015] -- x264 - bester Encoder, beste Videoqualität auf Youtube ;-)

    Zitat von Blackfury

    Entweder versteh ich dich falsch oder wir reden aneinander vorbei. Das gerenderte Video ist im MP4 (ohne Ton), das und das Flac werf ich in den Merger und raus kommt das fertige [lexicon]MKV[/lexicon]. Wenn nun sämtliche Files in einem Ordner sind, weiss ich halt direkt was die Video.mp4 und was Video.mkv ist und ich muss nicht einer der beiden Dateien einen anderen Namen geben.


    MKVMerge gibt automatisch einen anderen Namen, kannst ja schlecht die Quelle ersetzen. Die fertige ist dann also die mit einer (1) hinter.



    Und da ist eben dein Problem. Das muss auch beim erneuten Muxen fehlerfrei bleiben.


    Das Problem hatte Meduselchen auch schonmal, aber leider weiß ich nicht mehr worans liegt, oder ob es überhaupt eine Lösung dafür gab. Leider komplett vergessen.
    Ich meine mich aber ganz dunkel zu erinnern das es an einer externen [lexicon]Festplatte[/lexicon] lag. Versuch mal auf eine interne zu encodieren, falls du zurzeit auf eine externe encodierst.

  • Phantasmagoria 1

    Warum nicht sofort? ;)


    Bei der Komprimierbarkeit sollte auch 2048x1152 @ [lexicon]CRF[/lexicon] 19 eig. drin sein ...


    Sieht zig tausend mal besser aus, als deren 720p encode..


    "Original" ist am saubersten encodiert.

  • Phantasmagoria 1

    Zitat von Tyerell

    ich habe wiederrum gehört das resizen auf 1080p macht kein sinn.


    jaja das übliche ..


    Natürlich machts Sinn. Vor allem bei Youtube ... Youtubes 1080er Encode ist nunmal in deutlich höherer Qualität encodiert und nicht nur höhere Auflösung..

  • MeGUI [2015] -- x264 - bester Encoder, beste Videoqualität auf Youtube ;-)

    Zitat von Blackfury

    Um die Endung gehts mir ja grad ;)
    Bei MP4 seh ich direkt, dass es das encodierte Video ohne Ton ist und bei [lexicon]MKV[/lexicon], dass es das fertig gemergte Video ist. Wenn beide [lexicon]MKV[/lexicon] als Endung hätten, müsste ich ja eins der beiden anders benennen.


    Wieso sollte sich der Container des Audios ändern, wenn du nur den Container des Videos änderst?


    Ob du nun MP4 oder [lexicon]MKV[/lexicon] als Container nimmst, das ändert doch nichts am Audio Container.


    Zitat

    Nein, hat gemeldet, dass alles glatt gelaufen sei.


    Auch wenn du es erneut muxt? Also die gemuxte [lexicon]MKV[/lexicon] nochmal [lexicon]muxen[/lexicon]. Geht das dann noch immer glatt?.


    Zitat

    Aber auf Youtube hat es auf Orginal immernoch ziemliche Makroblöcke.


    Komplexes Material sieht auf Youtube halt schlechter aus als inkomplexeres. Youtube benutzt halt kein CRF.

  • MeGUI [2015] -- x264 - bester Encoder, beste Videoqualität auf Youtube ;-)

    Nachteil nicht, da du ja ummuxt in [lexicon]MKV[/lexicon], aber es macht halt auch nicht wirklich Sinn, wenn du eh auf [lexicon]MKV[/lexicon] gehst.


    Wenn du die Dateien unterscheiden willst, dann gucke auf die Dateiendungen, dafür sind sie nunmal da. Das 1. was man nach Windows Installation tut ist diese unsinnige Option auszuschalten das Dateiendungen nicht angezeigt werden.



    Gibt MKVMerge einen Fehler/Warnung aus?

  • MeGUI [2015] -- x264 - bester Encoder, beste Videoqualität auf Youtube ;-)

    [lexicon]DXTory[/lexicon] ist einfach sehr viel besser in allen Belangen. Den einzigen Vorteil den ich bei [lexicon]FRAPS[/lexicon] noch sehe ist die Desktopaufnahme ^^


    Zitat

    Ich merke gerade das ich keinen Haken bei "Lock framerate while recording" drinne hab.


    Wenn du das anhakst wird deine ingame FPS auf die Aufnahme FPS gesperrt. In deinem Fall also 30.
    Dann fallen die Sprünge weg, aber 30 fps könnten dir zum Spielen zu wenig sein.


    Daher lass den Haken lieber weg und nimm in 25fps auf.


    Dann haste mehr IngameFPS und vllt auch keine Sprünge mehr.

  • MeGUI [2015] -- x264 - bester Encoder, beste Videoqualität auf Youtube ;-)

    Zitat

    Das is ja schon auf Ultra Fast xD Obwohl ich das nur zum testen drin hab. Aber da ich gerade lese dass das die Dateigröße noch mehr in die Höhe treibt lass ichs mal auf Medium ;)


    Mit ultrafast isses kein Wunder das du auf keine [lexicon]CPU[/lexicon] Last kommst. Damit sind ja auch sämtliche Encodingmechanismen die gut komprimieren abgeschaltet^^.
    Und Encoding ist schwer parallelisierbar. [lexicon]x264[/lexicon] kriegts excellent hin trotzdem vieles zu parallelisieren. Aber bestimmte Aufgaben wie das konstruieren von b-frames usw geht einfach nicht zu parallelisieren. Musst dir wie ein Koch vorstellen, der auf die Speise des Beikochs warten muss, bis er weiter machen kann. B-Frames bremsen am meisten aus, da diese nicht parallelisierbar sind.


    Zitat

    Damit müsste doch auch die bearbeitungszeit geringer werden? Vorallem weil das Renderprog nicht mehr an den FPS rumschrauben muss.


    :thumbup:



    Die Gesamtanzahl der Frames ist beim Verabeitungsfenster schon umgerechnet.


    Zitat

    Sprich in der .avs Datei anstatt
    "Lanczos4Resize(1920,1080)"
    z.B.
    "BicubicResize(1920,1080)"


    Und ist Cubic oder Linear besser? (In Bezug auf Quali und Encodierzeit)


    Bicubic ist hübscher.


    Wie die Resizer arbeiten kannste gut hier nachsehen:


    http://hermidownloads.craqstar…oresizefiltercomparasion/


    Gab da nochn Link mit normalen Bildern, aber geht irgendwie gerad nicht zu laden leider.

  • MeGUI [2015] -- x264 - bester Encoder, beste Videoqualität auf Youtube ;-)

    Es ist halt genauso ein Skalierungsprozess. Ob nun hoch oder runter.


    Beim [lexicon]Hochskalieren[/lexicon] müssen die neuen Pixel berechnet werden, beim Runterskalieren müssen Pixel entfernt werden. Und das muss nunmal auch berechnet werden und sieht mit Lanczos4 besser aus, als wenn einfach benachbarte Pixel entfernt werden.


    Am verlustfreiesten bleibt ein Resize im Übrigen, wenn man die doppelte Auflösungsbreite und Höhe benutzt (oder eben die Hälfte beim Downscale).

  • MeGUI [2015] -- x264 - bester Encoder, beste Videoqualität auf Youtube ;-)

    Zitat von L1FeMaKeR

    __film = last
    __t0 = __film.trim(0, 53885)
    __t1 = __film.trim(53886, 109217)
    __t2 = __film.trim(109218, 162857)
    __t3 = __film.trim(162858, 212382)
    __t0 ++ __t1 ++ __t2 ++ __t3


    Kann ja so auch schlecht gehen. Ist doch klar, wenn du angibst, das du all diese Bereiche behalten willst, diese auch behalten werden ^^


    Die CLT Datei bitte NUR DANN benutzen, wenn du NICHT die AVS Datei als Audio Input benutzt. Das tust du nämlich mit audio=true.


    Oder hast du nachträglich externen Audio Input eingesetzt.


    Wenn die AVS Datei der Audio Input ist. Dann NICHT die CLT Datei benutzen. Der Trim Filter berücksichtigt auch Audio und es wäre dann doppelt gemoppelt und kann sogar zu Encodingfehlern kommen dadurch.


    Zitat

    Die 60 Frames kommen von der [lexicon]FRAPS[/lexicon] aufnahme


    Nächstes Mal in 30fps aufnehmen.


    Zitat

    Statt AssumeFPS(60.000) dann ChangeFPS(30.000)


    Nein das AssumeFPS kann bleiben. ChangeFPS(30) als neue Zeile weiter unten ergänzen.

    Zitat


    Müsste der dann nicht bedeutent schneller bei der Arbeit sein?
    der gurkt bei 7,2 FPS Processing Rate rum und brauch 2 Stunden zu rendern.


    Preset auf Medium statt slow stellen, falls du slow benutzt.


    Zitat

    Klar Quali geht dann runter aber so ein Qualiverrückt bin ich dann auch nicht ;)


    Nö geht sie nicht beim [lexicon]CRF[/lexicon] Encodingmodus. Lies dazu den Lexikon Artikel.


    Zitat

    Könnte die langsame Geschwindigkeit auch daran liegen, dass ich bei diesem Test die Rohdatei auf einer Externen gespeichert habe? Der Altbekannte Flaschenhals?


    Eher weniger. Das Verarbeiten geht sehr viel langsamer als die [lexicon]HDD[/lexicon] Schreibrate.


    Zitat

    Resize frisst extrem! Da ist es auch egal, ob du Fast, Medium oder Slow eingestellt hast. Der Resizer zieht einfach extrem Leistung.


    Das stimmt nicht. Klar Lanczos4 braucht [lexicon]CPU[/lexicon], aber das es egal ist ob medium, slow oder fast ist kompletter Schwachsinn. Hat man eine einigermaßen dezente [lexicon]CPU[/lexicon] fällt die Absenkung durch Lanczos4 auch entsprechend geringer aus.


    Zitat

    Ohne Resize komm ich auf 11,5 FPS Processing Rate und auf ein bischen mehr als 1 Stunde. Wäre dem Ziel schon näher.


    Das liegt aber nicht nur am Wegfall des Filters, sondern auch, weil [lexicon]x264[/lexicon] ja nun kleinere Frames encodieren muss. Das macht verdammt viel aus und ist der Hauptflaschenhals, statt der eigentliche Resizefilter. Ich glaube manche verwechseln das ziemlich krass.


    Zitat

    Was mich wirklich wundert, dass die Anzeige "Current/TotalFrames" in diesem Beispiel immer um 12,5 Frames pro Sekunde weiterläuft. Hab ich ihm aber nicht gesagt, dass aus den 60 Frames die er von der Rohdatei zur Verfügung bekommen hat nur die Hälfte in der Ausgabe zu sehen ist? Diese ist ja dann 30 Frames. Für mich klingt das ziemlich bescheuert, etwas zu rendern, was nicht in der fertigen Datei angezeigt wird, aber ich kenne mich nicht wirklich mit der Arbeitsweise von so etwas aus.


    Meinst du die Anzeige der Processing Rate? Das ist natürlich die Angabe wie viele Frames / sek encodiert werden. Das hat nix mit der FPS Rate des Videos zu tun.


    Zitat

    Was auch seltsam ist, ist dass er von den Vorhandenen Systemressourcen des PC's Gerademal <45% CPU-Last und nur knapp 1/8 Arbeitsspeicher nutzt. Kann ich dem Programm nicht noch mehr Ressourcen zur Verfügung stellen? (Priorität ist schon auf "Hoch"). Da der PC dann eh Nachts durchlaufen soll kann das Programm alles haben was es kriegen kann.


    Resizefilter und FPS Change Filter. Es laufen 2 Filter auf die [lexicon]x264[/lexicon] warten muss. Eventuell hilft dir ein schnellerer Resizefilter, zb BicubicResize oder BilinearResize. Diese sind deutlich schneller, aber auch etwas gemindertere Qualität (nicht zu ernst nehmen, es ist kein Weltuntergang).


    Zitat

    Also ich spiele meine Spiele normalerweise in meiner Monitorauflösung 1440x900 (16:10), also nicht grade die Beste.. Mit [lexicon]DXTory[/lexicon] nehme ich Percent 100%, also 1:1 in dieser Auflösung auf, dannach resize ich es in [lexicon]MeGUI[/lexicon] mit Lanczos4 zu 1280x720 (16:9), also HD. Kann ich nicht auch in 1280x720 (16:9) auf meinem 1440x900 (16:10) Bildschirm spielen und mit [lexicon]DXTory[/lexicon] immer noch mit 1:1 aufnehmen, also nimmt [lexicon]DXTory[/lexicon] ja gleich 1280x720 (16:10) auf, was bedeuet, ich brauche keinen resize mehr..


    1280x720 ist 16:9. Und wenn du in 1280x720 aufnimmst, wird auch 1280x720 im Video sein. Ob 16:9 nun von deinem 16:10 Monitor gestreckt wird interessiert ja nur deinem Monitor.


    Zitat

    Demon, schlag mich wenn ich falsch liegen sollte, aber beim RUNTERskalieren kannst du getrost linear skalieren, das Ergebnis ist das gleiche. Nur beim HOCHskalieren macht das einen Unterschied.


    Falsch.


    Zitat

    Was würde Youtube machen, wenn ich ein Video mit Auflösung: 1600 * 900 hochlade? (Für Youtube muss es ja 16:9 sein oder?)


    Dann wird der 720p Encode in 1600x900 encodiert.

  • MeGUI [2015] -- x264 - bester Encoder, beste Videoqualität auf Youtube ;-)

    [lexicon]FRAPS[/lexicon] Videos kannst du normal per AVISource decodieren. Normal kann FFMPEGSource aber auch [lexicon]FRAPS[/lexicon] Videos, ist aber nicht nötig und wenn du AVISource benutzt fällt das indexen auch weg.


    __


    Warum produzierst du 60fps Videos? ..


    Das ist a) ziemlich unnötig und b) Wenn du die FPS beim Encoden nicht auf 30 änderst, haste eine doppelte Dateigröße für Sinnlosigkeit. Und das 60fps nicht synchron abgespielt werden, liegt nicht daran das [lexicon]MeGUI[/lexicon] asynchron encodiert, sondern die Decodierleistung des Decoders deines Videoplayers nicht schnell genug das Video abspielt und somit der Ton hinterher hinkt.