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

  • Vor allem wie lang das schon so ist. Seit 2536 XD


    Und das stimmt! Ich hab in Log geguckt und er hat tatsächlich -0 an den [lexicon]FLAC[/lexicon] [lexicon]Encoder[/lexicon] übergeben, statt 8 XD


    Das erklärt dann natürlich auch, warum [lexicon]FLAC[/lexicon] in letzter Zeit so schwach komprimiert hat haha :D

  • [lexicon]MeGUI[/lexicon] mal als Administrator gestartet?


    Wenn ich mich recht entsinne, forced das [lexicon]MeGUI[/lexicon] eh schon.


    Über die ...-Buttons kann ichs einfügen aber nicht mehr reinziehen. Macht halt für mich als Laie 0 Sinn.


    Rechteproblem. Wenn nicht von windows, dann vllt von einer Antivirensoftware, oder verschiedene Benutzerkonten in Windows oder whatever.

  • vielleicht weis jemand wie man das lösen kann. Neu installieren kann ich ned, weil ich die einstellungen die mir darky damals zeigte nimmer auswendig weis und ich kann mit garantie sagen, dass ich von vorgestern (alles problemlos) bis heute nichts geändert habe, was ein antivirenprogramm oder win10 betrifft.

  • Einstellungen stehen in settings.xml
    jobliste in joblists.xml


    Ein neues [lexicon]MeGUI[/lexicon] wird aber dein Problem vermutlich nicht lösen.


    Ach und zu dem Warum:


    Drag&Drop ist halt ein Zugriff von einer externen Anwendung auf [lexicon]MeGUI[/lexicon]. Und die Buttons von [lexicon]MeGUI[/lexicon] eben nur intern. Extern darf nur drauf zugreifen wenn es keine Probleme mit Rechte gibt.

  • Hab mal eine Frage bzg. [lexicon]Megui[/lexicon]. Manche Videos die ich ohne Effekte hochlade (alles davor per [lexicon]SSM[/lexicon]), rendert er mit einer Processing rate von knapp 12 [lexicon]FpS[/lexicon]. Wenn ich ein Video bei [lexicon]Adobe[/lexicon] Premiere übern [lexicon]FrameServer[/lexicon] laufen lasse, sind es meistens nur noch 5-6 [lexicon]FpS[/lexicon]. Macht der [lexicon]FrameServer[/lexicon] soviel aus oder liegt da ein anderes Problem vor?

  • Hab mal eine Frage bzg. [lexicon]Megui[/lexicon]. Manche Videos die ich ohne Effekte hochlade (alles davor per [lexicon]SSM[/lexicon]), rendert er mit einer Processing rate von knapp 12 [lexicon]FpS[/lexicon]. Wenn ich ein Video bei [lexicon]Adobe[/lexicon] Premiere übern [lexicon]FrameServer[/lexicon] laufen lasse, sind es meistens nur noch 5-6 [lexicon]FpS[/lexicon]. Macht der [lexicon]FrameServer[/lexicon] soviel aus oder liegt da ein anderes Problem vor?


    Nimmst du den [lexicon]Frameserver[/lexicon] oder den Advanced [lexicon]Frameserver[/lexicon]?
    http://sourceforge.net/projects/advancedfs/


    der ist deutlich schneller ;)

  • Ein [lexicon]Frameserver[/lexicon] dauert immer etwas länger. Das liegt daran das das Video in deinem Beispiel über die [lexicon]NLE[/lexicon] erst berechnet werden muss und dann erst können die Frames übertragen werden. Bei der Übertragung müssen die Frames jedoch in einem bestimmten Format kodiert werden. [lexicon]MeGUI[/lexicon] dekodiert dann dieses Format mit [lexicon]AVISynth[/lexicon] und kann somit über den 2ten [lexicon]Frameserver[/lexicon] an [lexicon]x264[/lexicon] senden, der dann das Video richtig enkodieren tut.


    Sprich: Es wird zum einen durch deine [lexicon]NLE[/lexicon] Berechnung der Frames schon etwas länger dauern und zusätzlich das es durch 2 weitere [lexicon]Frameserver[/lexicon] läuft.


    Das ist normal und eigentlich auch eine logische Schlussfolgerung.


    Bei direktem Verwenden von [lexicon]SSM[/lexicon] entfällt jegliche Berechnung der [lexicon]NLE[/lexicon] und dem ersten [lexicon]Frameserver[/lexicon] (DebugMode oder Advanced [lexicon]Frameserver[/lexicon]). Es wird ledeglich nur noch der [lexicon]AVISynth[/lexicon] [lexicon]Frameserver[/lexicon] verwendet der dann auch gleich anschluss an den Finalen [lexicon]Encoder[/lexicon] hat. Das läuft dann deutlich schneller. Zumal wenn man dann noch MT verwendet ^^


    1. Dein Weg über die [lexicon]NLE[/lexicon] sieht so aus:
    Video -> Premiere (Decode) -> [lexicon]Rendern[/lexicon] (Neu Berechnung der Frames) -> Advanced [lexicon]Frameserver[/lexicon] ([lexicon]Lossless[/lexicon] Übertragung (Encode)) -> [lexicon]AVISynth[/lexicon] (Via [lexicon]SSM[/lexicon], 2ter [lexicon]Frameserver[/lexicon], Neu Berechnung der Frames (Beim [lexicon]hochskalieren[/lexicon] z.B.), Decode und Encode) -> [lexicon]x264[/lexicon] ([lexicon]MeGUI[/lexicon], Decode und Encode) -> finales Video.


    2. Der Weg über [lexicon]SSM[/lexicon]:
    Video -> [lexicon]AVISynth[/lexicon] (1ter [lexicon]Frameserver[/lexicon], Neu Berechnung der Frames (Beim [lexicon]hochskalieren[/lexicon] z.B.), Decode und Encode) -> [lexicon]x264[/lexicon] (Decode und Encode) -> finales Video


    3. Der Weg über [lexicon]x264vfw[/lexicon]:
    Video -> Premiere (Decode) -> [lexicon]Rendern[/lexicon] (Neu Berechnung der Frames) -> VFW Schnittstelle (Rohdatenübertragung RAW) -> [lexicon]x264vfw[/lexicon] (Decode und Encode) -> finales Video



    1 = langsam
    2 = schnell
    3 = sehr schnell


    Warum?
    Der 3te Weg ist der schnellste, weil über die [lexicon]NLE[/lexicon] selbst soviele Threads genommen werden kann die es gibt, auch das [lexicon]Rendern[/lexicon] (Neuberechnung der Frames) geht auch so viel schneller, da NLEs dies auch via [lexicon]GPU[/lexicon] machen können und der Encode voll die [lexicon]CPU[/lexicon] nutzen kann.


    Der 2te Weg ist schnell, wenn man Multithreading in [lexicon]AVISynth[/lexicon] nutzt. Dennoch langsamer als die [lexicon]x264vfw[/lexicon] Variante. Denn ein [lexicon]Frameserver[/lexicon] decodiert die Frames erst dann, wenn sie angefordert werden, wärend eine [lexicon]NLE[/lexicon] Frames vorberechnen kann, weshalb man beim [lexicon]Rendern[/lexicon] in einer [lexicon]NLE[/lexicon] auch Wunderbar die [lexicon]GPU[/lexicon] nutzen kann. Bei [lexicon]AVISynth[/lexicon] jedoch und auch dem Encode via [lexicon]x264[/lexicon] von [lexicon]MeGUI[/lexicon] wird alles ausschließlich die [lexicon]CPU[/lexicon] genutzt.


    Und der 1te Weg ist der langsamste, weil er alle Stadien durchlaufen muss. Und das kostet Zeit.



    Bitte beachtet das ich mich Ausschließlich auf die Geschwindigkeitsübertragung beschränke hier, nicht über die Qualität.


    Qualitativ ist der [lexicon]x264[/lexicon] von [lexicon]MeGUI[/lexicon] besser, da die 10Bit Version [lexicon]Banding[/lexicon] minimieren kann. Und auch [lexicon]AVISynth[/lexicon] (wo [lexicon]SSM[/lexicon] die Skripte erstellt) auch viel sorgfältiger mit den Frames umgeht. z.B. in Sachen von verschiedenen Resizern und Co.



    Man kann über die 3 Wege aber selbst entscheiden. Jeder Weg führt zu einem [lexicon]x264[/lexicon] Encode, was qualitativ sowieso angestrebt werden sollte. Jedoch ist der jeweilige Rendervorgang, sprich die Neuberechnung der Frames, auch sehr wichtig und ein entscheidener Faktor vor dem [lexicon]Encodieren[/lexicon].

  • Einfach nur stark, wie du soviel Wissen hast und es auch teilen kannst, sodass es jeder versteht. Wenn man logisch überlegt, ist es eig. eh klar, dass es über [lexicon]NLE[/lexicon] viel länger dauert, aber oftmals zweifel ich dann doch dran, wer weiß, vlt. bin ich ja einfach nur inkompetent ^^
    VIelen lieben Dank für die ausführliche Erklärung

  • Also, so langsam verzweifle ich an allem (seis Einstellungen, oder irgendwelche Programme, wo die Aufnahme dann laggt, oder gleich das ganze Spiel..).
    Ich hab grad ein Video aufgenommen ([lexicon]Minecraft[/lexicon]), sofort in den [lexicon]SSM[/lexicon] gepackt und dadurch ein Skript erstellen lassen.
    Hab nun auch die BFrames auf 0 gesetzt und siehe da.. 6.09 Frames Processing rate (obwohl MC offen ist droppt es höchstens so auf 5,5 runter). (obwohl ich sogar das [lexicon]NLE[/lexicon] weggelassen hab :c)
    Und das Preset ist nun auch schon auf fast ._.


    Für ein 3 Minuten Video bräucht ich also kleines bisschen mehr wie ne Halbe Stunde und da kann doch was nicht stimmen?

  • Komischerweise ändert sich kaum was, wenn ich [lexicon]Minecraft[/lexicon] offen habe oder nicht.
    Das mit der [lexicon]CPU[/lexicon] hab ich am ehesten befürchtet, das wird wohl auch der Hauptgrund sein weswegen MSI und [lexicon]Dxtory[/lexicon] immer hart [lexicon]laggen[/lexicon] und sowas wie [lexicon]Bandicam[/lexicon] nicht.


    Danke euch beiden, dann werd ich mal schauen, wie sich das Problem am einfachsten beheben lässt

  • So nach langer Zeit habe ich dann auch mal wieder eine Frage wegen [lexicon]Rendern[/lexicon] mit [lexicon]MeGui[/lexicon].


    Ich benutze den [lexicon]Debugmode Frameserver[/lexicon] (hatte Advanced [lexicon]Frameserver[/lexicon] auch für kurze Zeit, hat aber nur Probleme gemacht) um das Video von [lexicon]Adobe[/lexicon] Premiere Pro zu [lexicon]MeGui[/lexicon] schicken zu können.
    Habe natürlich den [lexicon]x264[/lexicon] [lexicon]Encoder[/lexicon]: [lexicon]CRF[/lexicon] 16.


    Nun meine Frage bezüglich Preset: Habe bisher immer Medium gewählt, da dauert das [lexicon]Rendern[/lexicon] von einem 25 Minuten Video circa 2 Stunden und ein bisschen was. Wäre es da sinnvoller ein schnelleres Preset zu wählen, also Fast oder vielleicht sogar Faster? Mir ist schon klar das die Datei dabei ein wenig größer wird, es geht mir aber in erster Linie um die Qualität (deswegen auch übertriebenermaßen [lexicon]CRF[/lexicon] Faktor 16) und die Renderdauer.


    Hat das Preset eigentlich eine Auswirkung auf Qualität oder nur auf die Renderdauer und Videogröße?

  • Die Akkuratheit von [lexicon]CRF[/lexicon] leidet unter schnellen Presets, da halt weniger nach Detail gesucht wird. ggf den [lexicon]CRF[/lexicon] eine Stufe senken.


    Viel speed holst du raus, wenn du die b-frames auf 0 machst und die ref frames auf 2.


    Dürfte dann doppelt so schnell encoden.


    Und natürlich zieht Skalierung Leistung - daher unbedingt wenn genutzt mit Multithreading ([lexicon]SSM[/lexicon]) arbeiten.


    Premiere bremst natürlich zusätzlich.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!