Häufige MeGui Abstürze - Ursache?

  • Hallo Zusammen,


    nach Aufnahme mit dem MSI Afterburner (MagicYUV) und Avisinth-Script Erstellung mittels Sagaras Script Maker encodiere ich meine Videos mit MeGui.
    Allerdings stürzt mir das Programm häufig während des Encodierens ab, allerdings nicht immer.
    Es ist dennoch ärgerlich einen längeren Encodierungs-Vorgang erneut starten zu müssen, daher wäre ich für jeden Tipp dankbar, der zur Behebung des Problems helfen könnte.


    Vielen Dank.


    Hier die Fehlermeldung:


  • Hier mal die Script-Settings


  • Mühsam ^^


    Wäre dreimal schneller ersichtlich wenn du ein Skript mit deinen Einstellungen postest.


    Und auch mal bitte deine x264 Einstellungen von MeGUI mal posten. Weil über 22h Encodierung bei einem 2h Video ist etwas arg viel.

  • Hier das aktuelle Script, das gerade läuft


    https://www.dropbox.com/s/9cux…_29_22_32_52_675.avs?dl=0


    Hier die x264 Settings:
    http://img5.fotos-hochladen.net/uploads/x2645kp694hxwy.jpg


    Und normalerweise dauert das encoding nicht so lange (zwar immer noch eine beachtliche Zeit), das kommt daher, dass nach der Fehlermeldung kein Frame mehr generiert wird und die remaining Time damit immer weiter steigt.


    http://img5.fotos-hochladen.ne…ds/encodingzigu9erlo8.jpg

    • Auflösung mal auf 2048x1152 stellen. Das ist wesentlich angenehmer für den Encoder, da es eine Modulo 8 Zahl ist. Noch schöner wäre eine Modulo 16 Auflösung.
      Deine jetzige mit 1170p ist eine Modulo 2 Auflösung. Da freut sich der Encoder nicht grad besonders drüber.
    • Dann solltest du unbedingt mal dein MeGUI updaten lassen auf 2695 Dev Update Server
    • Wenn es dann immer noch Probleme gibt, dann mal bitte Motion Blur ausschalten im SSM

    Dann noch eine Frage: Mit was nimmst du auf? MagicYUV oder UTVideo? Weil wenn du mit diesen Codecs aufnehmen solltest, kannst du direkt in BT.709 aufnehmen. Dann brauchst du sogar den ColorMatrix Filter nicht aktivieren.

  • @strohi
    Das mit der Mod16 Auflösung hat damit zu tun das beim Encodieren eine Fläche von 16x16 Pixel als ein Macroblock zusammengefasst wird.


    Entspricht eine Auflösung keine Mod16 Auflösung, so werden die letzten Flächen die nicht dem 16x16 Pixel Block entsprechen noch Leerdaten hinzugefügt um diese Restblöcke verarbeiten zu können. Sprich die Auflösung wird an sich künstlich vergrößert um auf diese 16x16 Block Größe zu kommen.


    Ein Decoder scheidet dann wieder diese Blöcke zurecht und gibt das Bild wieder fehlerfrei aus.


    Der niedrigste Macroblock besteht aus 2x2 und ist dem YUV 4:2:0 Farbraum zuzuordnen. Dieser Farbraum kann also keine Ungeraden Auflösungen besitzen.


    Der niedrigste Macroblock für YUV 4:2:2 ist 2x1.
    Und der niedrigste für YUV 4:4:4 ist 1x1


    Um Anfälligkeiten und Probleme durch sowas zu vermeiden, sollte man halt eine Mod16 Auflösung probieren, da dies eine Optimale Macroblock Größe entspricht.


    Der Effizienzverlust beim Encoding ist also geringer desto näher die Auflösung einer Mod16 Auflösung entspricht.


    Und rein theoretisch ist dies erst Relevant bei Hardware Player die auf bestimmte Kriterien geeicht sind.


    Daher kannst du kein Video unter 16x16 Pixel machen und abspielen und du kannst Farbraumspezifische Auflösungen wie bei YUV 4:2:0 keine ungeraden Auflösungen zuordnen, da die Mindest-Macroblock-Größe 2x2 beträgt.


    Also kannst du für YUV 4:2:0 jede durch 2 teilbare Auflösung nehmen die größer gleich als 16x16 ist.
    Und Ideal sind halt Auflösungen die in Höhe und Breite durch 16 Teilbar sind, da dies der Macroblockgröße entspricht.

  • Ah, danke für den Hinweis.
    Das mit den Makro-Blöcken wusste ich sogar schon. Du hattest da glaube ich mal encodingwissen.de oder so genannt und da wurde das erklärt.
    Danke für den link, der hat geholfen. :)


    Mir ging es aber eigentlich nur darum, dass du gesagt hast, dass 1152 im Endeffekt Modulo 8 ist. Allerdings ist 1152 durch 128 und damit auch glatt durch 16 teilbar, womit es ja für die Makro-Blöcke passen müsste, oder? Weil 128 * 16 = 2048 sowie 72 * 16 = 1152 und damit wären das 128 Makro-Blöcke in der Breite und 72 in der Höhe mit je 16 x 16 Pixeln, also glatte zahlen, ohne dass eine Reihe aufgefüllt werden muss.
    Oder täusche ich mich da?


    Aber 2048 x 1152 ist auf jeden Fall Modulo 16. Das kann sogar bis insgesamt 128 hoch gehen. :)



    Wollte es halt nur anmerken, weil du oben geschrieben hast, dass 1152p nur Modulo 8 sei und Modulo 16 noch besser sei. Es ist aber auch Modulo 16. :)
    @Sagaras

  • Aber 2048 x 1152 ist auf jeden Fall Modulo 16. Das kann sogar bis insgesamt 128 hoch gehen

    Joa. Modulo 128 sagt man aber nicht, weil das ganz schön begrenzt an Auflösungen wäre. ^^


    Bis Modulo 16 macht man eigentlich, weil max. 16x16 Pixel ein Macroblock ergeben. Nicht mehr und nicht weniger.


    Daraus ergibt sich ja diese Schreibweise mit Mod16, Mod8, Mod4, Mod2 und Mod1


    Daraus lassen sich halt alle Auflösungen entsprechend ansprechen bis hin zur optimalen Lösung das die Auflösung nur aus 16x16 Blöcken besteht.


    Modulo 128 würde an sich heißen das es 128x128 Blöcke gibt. Gibt es aber nicht.
    Denn: 128x128 wäre Ideal, aber 16x16 nicht, weil Modulo 128. Demzufolge würden viele Auflösungen gar akzeptabel sein.
    Um aber alle Auflösungen des 16ten Teilers einzuschließen sagt man halt Mod16


    Sprich alle Auflösungen die durch 16 in Höhe und Breite teilbar sind, sind optimale Auflösungen für En- und Decoder, weil ein Macroblock aus 16x16 Blöcken besteht. Darum Mod16


    Wollte es halt nur anmerken, weil du oben geschrieben hast, dass 1152p nur Modulo 8 sei und Modulo 16 noch besser sei.

    Joa, das kannste gern machen. Aber wenn du mich schon korrigieren tust, dann tue das am besten auch bei anderen Usern im Technik Bereich. Die schreiben manchmal ein noch gewaltigeren Blödsinn ^^ Und die korrigiert komischerweise keiner. ^^ Aber das finden die Leute bestimmt ganz ok ^^
    Den blöden AVISynth Idioten und den dummen MeGUI Deppen die muss man ja ständig korrigieren oder anpöbeln, weil sie der Abschaum des Forums sind ^^


    Aber hey... ist OK ^^ Julien liked das bestimmt ^^


    Will damit nur sagen das ich dir zwars dankbar bin für den Hinweis und kann dir nur sagen das ich da im Kopf auf schnelle nur eine Mod8 Zahl ersehen habe bei 1152. Weil 1000 + 80 + 72 = 1152
    1000 ist durch 8 teilbar, 80 und 72 auch. Macht ein Modulo 8


    Macht sich auch schön im Kopf ^^

    • Auflösung mal auf 2048x1152 stellen. Das ist wesentlich angenehmer für den Encoder, da es eine Modulo 8 Zahl ist. Noch schöner wäre eine Modulo 16 Auflösung.
      Deine jetzige mit 1170p ist eine Modulo 2 Auflösung. Da freut sich der Encoder nicht grad besonders drüber.
    • Dann solltest du unbedingt mal dein MeGUI updaten lassen auf 2695 Dev Update Server
    • Wenn es dann immer noch Probleme gibt, dann mal bitte Motion Blur ausschalten im SSM

    Dann noch eine Frage: Mit was nimmst du auf? MagicYUV oder UTVideo? Weil wenn du mit diesen Codecs aufnehmen solltest, kannst du direkt in BT.709 aufnehmen. Dann brauchst du sogar den ColorMatrix Filter nicht aktivieren.

    Punkt 1 und 2 hatte ich gemacht, MeGui hat nach ca. 2 Stunden trotzdem wieder mit Fehlermeldung abgebrochen.


    Also Motion Blur abgeschaltet, dann ging es. Ich weiß zwar nicht ob das einmalig gewesen ist, oder wirklich der Problemverursacher (MEGui ist ja sonst auch durchgelaufen, mal beim ersten Mal, mal musste man mehrfach starten bis es sauber durch lief). Aber das wird die Zeit zeigen. Aber na ja, zumindest ist die encoding Performance ohne Motion Blut ca. 80-100 % besser ;)


    Ich nehme mit MagicYUV auf. Daher habe ich dann den ColorMatrix Filter deaktiviert.


    Eine Frage hätte ich noch, was sind eigentlich die sinnvollsten Einstellungen für Multithreading?
    So sehen meine aktuell aus:



    Und natürlich nochmal vielen Dank für die Unterstützung ;)

Jetzt mitmachen!

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