MeGUI sehr langsam (Ordner übernehmbar?)

    Frage ist wie wurde aufgenommen und wie verarbeitet und in was Encodiert und hochgeladen?


    Zum anderen dein Video hat da nur 1080p60 und liegt nur in AVC vor. Noch nicht mal VP9.


    Und 1080p ist nicht grad das Gelbe vom Ei. Mach lieber 1152p60, dann "wabbelt" das auch nicht mehr.


    Weil dieses "wabbeln" entsteht durch eine recht magere Encodierungseinstellung seitens Youtube. Um höhere Encodierungsmodi von YT zu entlocken musst du höher skalieren. min. 1152p oder höher.


    Dieses "wabbeln" ist noch recht harmlos bei dir, ist aber auch ein Zeichen dafür das die Bitrate nicht ausreicht und er genau bei Bewegungen nun die Farben etwas hinterher zieht. Weil da spart er nämlich schon Bitrate.


    Um Bitrate zu sparen werden meist Farben verschmiert. Im Idealfall meist nur da wo Bewegungen auftauchen. Und im schlimmsten Fall bekommst du halt DCT-Blöcke zu Gesicht.


    Das ist bei deinem Video hier noch nicht so stark ausgeprägt.


    Man kann es natürlich mit einem Unschärferen Skalierer etwas entgegen wirken, ja. Aber dann lieber doch auf 1152p skalieren mit Spline36 und das Problem wäre für dieses Spiel schon gelöst. Und 1080 auf 1152 ist ja nun nicht die Welt. ^^

    Zitat von Sagaras

    Man kann es natürlich mit einem Unschärferen Skalierer etwas entgegen wirken, ja. Aber dann lieber doch auf 1152p skalieren mit Spline36 und das Problem wäre für dieses Spiel schon gelöst. Und 1080 auf 1152 ist ja nun nicht die Welt.

    Ich hab diese Folge auf 2048x1152 hochskaliert, das mach ich mit allen Folgen 8o
    Spline 36 wurde auch verwendet. Mir ist aber auch aufgefallen dass Youtube bei der Videostatistik nur 1920x1080 anzeigt.


    Mediainfo zu der Folge:


    Bitrate ist 2,1K laut Mediainfo. Zu der Frage wie alles aufgenommen wurde:


    Mit Dxtory und MagicYUV in .. ups, 4:2:2 und dann wohl zu 4:4:4 konvertiert. Eigentlich hatte ich 4:4:4 eingestellt, ich hab da wohl letztens beim rumklicken ausversehen übernommen :huh: Jedenfalls für gewöhnlich in 4:4:4, 60fps und 1920x1080 die Aufnahme, und dann halt in deinem SSM auf 1152p hochskalieren. Laut MI hat die Folge das ja auch..

    Du hast halt auf deinem Video, was du im Spoiler gepostet hast, halt noch kein VP9 Encode bekommen. Weil dann wäre dein Video in 1152p60 verfügbar und es würde auch in den "Statistiken für Computerfreaks" als VP9 aufgeführt.


    Entweder dauert das bei dir noch, oder solltest mal das Video auf YT kurz bearbeiten (nix ändern) und gleich wieder speichern oder oder oder...


    Wie und wodurch VP9 auf YT ausgelöst wird konkret wird leider noch spekuliert. Und YT wird da auch nix konkretes zu sagen. Also bleibt es vorläufig Spekulationen wie man VP9 bekommen kann. Da kann auch Abwarten und Tee trinken helfen. Denn ein VP9 Encode zu bekommen kann halt auch dauern. Zumal die Encodierung ganz schön viel Leistung zieht und ich mich generell immer wieder frage wo YT die her nimmt. ^^

    Ah, ich wusste nicht dass das mit VP9 zusammenhängt. Ja, ich hab früher auf vielen Videos VP9 bekommen, seit dem letzten Projekt nicht mehr.
    Wenn du in 1152p verfügbar schreibst meinst du aber nur in der Qualität, die auswählbare Auflösung bei Youtube ist Maximal immernoch 1080p oder? Denn meine 1152p VP9 Videos lassen sich auch nur in 1080p "auswählen".


    Also konkret heißt das, solange ich kein VP9 von Youtube bekomme kann ich nichts dagegen machen, und wenn ich VP9 bekommen sollte und sowas immernoch ist, kann ich dem mit höherer Auflösung und unschärferen Resizern entgegenwirken!

    Zitat von Chron

    Wenn du in 1152p verfügbar schreibst meinst du aber nur in der Qualität, die auswählbare Auflösung bei Youtube ist Maximal immernoch 1080p oder?

    Youtube macht es meist so:
    Dein Video wird auf YT zuerst als H264 encodiert. Wie die Einstellungen für jede Auflösungsstufen Encode sind, ist unbekannt.
    Und die h264 Encodes werden halt alle parallel durchgeführt bei YT.


    Dabei wird das hochgeladene Video als Referenzvideo genommen von dem codiert wird dann. Sprich das Original.


    Da 320p, 480p und alle kleineren Stufen eher fertig sind, ist klar. Die brauchen ja auch nicht lange.


    Und es werden auch immer zuerst die Non-Dash Variationen encodiert. Und dann die Dash Variationen.


    Das sind aber erst einmal alles AVC Streams (H264 encodierte Videos)


    Und mit sehr viel Glück werden diese dann auch noch überschrieben bzw. ausgetauscht und es werden auch mehrere Auflösungen möglich sein mit dem VP9 Encode.
    Das heißt dann das dein Video nicht nur H264 Support besitzt, sondern auch VP9. Und VP9 wird bevorzugt in den meisten Browsern beim YT Player.


    Und wenn du dann halt so eine Auflösung wie 1152p hast, bekommst du halt den Encode der für 1440p vorgesehen war, aber dein 1152p Video wird unter der Auswahl 1080p geführt.


    Beispiel:

    [IMG: http://fs5.directupload.net/images/160703/2azl65c6.png]

    Ok, ja so hab ich's mir auch gedacht und ich habe noch nie einen 1152p@60 Button gesehen, aber es klang so.. :D
    Dass man die höhere Bitrate mit 1152 abgreifen kann weiß ich, wusste nur bis heute nicht das dies nur der Fall ist wenn
    VP9 auf dem Video gewährt wurde.


    Ich blick' bei Youtube aber auch nicht durch, wonach die das vergeben. Meine kleinen Projekte wo ich so ~20-30 Clicks pro Folge bekommen habe haben vor einigen Wochen noch VP9 erhalten, seit meinem Projekt was alleine in zwei Wochen soviel "eingespielt" hat wie mein ganzer Kanal in einem halben Jahr, bekam dann kein VP9 mehr. Also fallen Dinge wie: Aufrufe, Watchtime, Anzahl der Kommentare oder positiven Bewertungen schonmal weg, ebenso die größe des Kanals.


    Ich denke, Youtube mach das vollkommen willkürlich, kann aber sein dass sie auch jetzt wirklich einfach hinter den Kulissen die Anforderungen verändert haben.. Auf jeden Fall bin ich jetzt etwas schlauer wegen den Resizern und dass VP9 erst hochskalierte Auflösungen freischaltet :)
    Und klar, das nachwabbeln fällt trotz allem bei meinen Videos derzeit zum Glück sehr gering aus, es stört mich im Moment nicht wirklich, ich wollte nur die Technik dahinter verstehen. Finde das alles mega interessant.

    Hallo miteinander,
    ich klinke mich hier mal eben mit ein.


    Bei mir war es bis jetzt immer so, dass ich meine Videos per MegicYUV im 4:2:2 Farbraum aufgenommen habe, es dann in den Sagaras Script Maker in YV12 (Spline 16) "gescript" habe, und es dann einfach mit MeGUI encodieren lassen habe.


    Nun habe ich aber raus gelesen, dass es nicht so Sinnvoll ist den Farbraum zu minimieren... Was genau muss ich dann im SSM Einstellen, damit die Farben in 4:2:2 bleiben? Die Option "Gleich" wählen?


    Bei MeGUI wäre es dann klar. Einfach

    Code
    --output-csp i422

    mit hinzufügen, wenn ich mich nicht täusche.



    LG

    Zitat von Malzzi

    Was genau muss ich dann im SSM Einstellen, damit die Farben in 4:2:2 bleiben? Die Option "Gleich" wählen?

    Die Option "Gleich" kannst du wählen, sofern du zu 100% sicher bist das der Farbraum YUY2 ist und dieser auch durch das AVISynth Skript erkannt wurde.


    Wenn du dir dessen nicht sicher bist wählst du natürlich YUY2 als Farbraum aus im SSM. Das ist der sicherste Weg dann.


    Und dann ist es bei YUY2 ganz wichtig das du den "avs4x264mod YUY2/YV16 Fix" anschaltest.


    Damit wird am Ende des Skriptes das YUY2 in YV16 umkonvertiert. Da passiert dann aber nix, da beide Farbräume 4:2:2 sind.


    YUY2 ist ein Interleaved Farbraum, während YV16 ein Planar ist. Das entsprechend zu erklären ist hier jetzt überflüssig, da wie gesagt beide vom Inhalt her identisch sind und mit den Informationen nix passiert.


    Das ist wichtig damit die Pipeline avs4x264mod die nur YV24 (YUV 4:4:4), YV16 (YUV 4:2:2) und YV12 (YUV 4:2:0) verstehen kann (sprich nur Planar Farbräume) die Information auch korrekt durchschleusen kann an den x264 Encoder.


    Den Rest kannst du im SSM aus der Hinweistafel entnehmen. ^^

    Zitat von Sagaras

    Die Option "Gleich" kannst du wählen, sofern du zu 100% sicher bist das der Farbraum YUY2 ist und dieser auch durch das AVISynth Skript erkannt wurde.

    *hust* bei mir steht im SSM immer wenn ich ein Video Qeue, dass ich keine Konvertierung zu YV12 hinzugefügt habe und ob ich das Farbraum-Problem selbst lösen will. Ist das eine Standard-Abfrage oder weißt mich dein Programm darauf hin, dass meine Einstellungen sich irgendwo beissen? Ich meine das kam auch, wenn ich 4:4:4 geliefert, YV24 ausgewählt und den csp 444 Befehl drin hatte.


    Und, bezüglich deines Zitates, heißt das wenn ich in YUV 4:4:4 aufnehme brauche ich gar nicht YV24 auszuwählen sondern kann's auf "gleich" lassen? Macht das einen Unterschied?

    Zitat von Chron

    *hust* bei mir steht im SSM immer wenn ich ein Video Qeue, dass ich keine Konvertierung zu YV12 hinzugefügt habe und ob ich das Farbraum-Problem selbst lösen will.

    Das fragt dich MeGUI. Nicht SSM.


    Zitat von Chron

    Ist das eine Standard-Abfrage oder weißt mich dein Programm darauf hin, dass meine Einstellungen sich irgendwo beissen?

    MeGUI weißt dich darauf hin das du einen unüblichen Farbraum nutzt und fragt dich halt ob du nicht lieber in YV12 encodieren willst. Was du mit nein beantwortest.
    Dann stellt MeGUI fest das kein YV12 anliegt und ob du dieses Problem selbst lösen willst. Das beantwortest du mit ja.


    Weil du willst A) kein YV12 und B) weißt du ja hoffentlich das du ein YV16 bzw. YV24 oder gar RGB Video an MeGUI gesendet hast.


    Wenn du die Fragen in der Reihenfolge so beantwortest, dann hast du dein entsprechenden Farbraum im Skript ungeändert anliegen an der Pipeline und Encoder.


    Musste nur noch für sorgen und überprüfen das A) die Pipeline nicht YV12 daraus macht (am besten in der Log nachschauen) und B) die richtige Einstellung beim x264 Encoder getroffen hast. Siehe dazu die Hinweistafel im SSM.


    Zitat von Chron

    Und, bezüglich deines Zitates, heißt das wenn ich in YUV 4:4:4 aufnehme brauche ich gar nicht YV24 auszuwählen sondern kann's auf "gleich" lassen? Macht das einen Unterschied?

    Das "gleich" ist nur wenn du zu 100% sicher bist das das Skript auch diesen Farbraum durchschleusen tut. Das heißt, du solltest ein wenig Ahnung von AVISynth haben. Ansonsten stellste YV24 ein. Da ändert sich dann nix dran und sicherer ist es auch.


    Bei "gleich" würden alle Farbkonvertierungen im Skript selbst entfallen.


    Wenn du YV24 eingestellt hast, würde das Skript versuchen die Videos auf YV24 zu konvertieren. Liegt ein YV24 Video vor und kommt durch diesen Konvertierungsfilter, passiert da 0. Da der Farbraum schon identisch ist. Ist jetzt aber dein Video ein RGB Video geworden, weil es nicht richtig von AVISynth eingelsen worden ist, dann würde es in YV24 konvertiert werden und würde trotzdem funktionieren. Das würde bei "gleich" nicht gehen.


    RGB würde auf die Pipeline dann treffen, die Pipeline kann das nicht lesen und konvertiert es in YV12 um und schickt das dann an den Encoder als YV12 Material. Und wenn der Encoder noch auf YV24 eingestellt ist für den Output, dann machst du YV12 zu YV24 und hast somit nix gekonnt. Da hätteste dann auch gleich YV12 aufnehmen können ^^

    Zitat von Sagaras

    Das fragt dich MeGUI. Nicht SSM.

    Ups, klar. War schon bisschen spät :P

    Zitat von Sagaras

    MeGUI weißt dich darauf hin das du einen unüblichen Farbraum nutzt und fragt dich halt ob du nicht lieber in YV12 encodieren willst. Was du mit nein beantwortest.
    Dann stellt MeGUI fest das kein YV12 anliegt und ob du dieses Problem selbst lösen willst. Das beantwortest du mit ja.


    Weil du willst A) kein YV12 und B) weißt du ja hoffentlich das du ein YV16 bzw. YV24 oder gar RGB Video an MeGUI gesendet hast.

    Klar weiß ich in welchem Farbraum ich aufgenommen habe. Abgesehen von letztem Mal wo ich ohne es mitzubekommen die Einstellungen beim experimentieren nicht zurückgeändert habe xD

    Zitat von Sagaras

    Musste nur noch für sorgen und überprüfen das A) die Pipeline nicht YV12 daraus macht (am besten in der Log nachschauen) und B) die richtige Einstellung beim x264 Encoder getroffen hast. Siehe dazu die Hinweistafel im SSM.

    Was genau ist die Pipeline? Das SSM script? Im x264 encoder ist das ja nur der csp Befehl.

    Zitat von Sagaras

    Das "gleich" ist nur wenn du zu 100% sicher bist das das Skript auch diesen Farbraum durchschleusen tut. Das heißt, du solltest ein wenig Ahnung von AVISynth haben. Ansonsten stellste YV24 ein. Da ändert sich dann nix dran und sicherer ist es auch.

    Ich benutze gar kein AVISynth, nur den SSM und MeGui. Aber mehr als zu wissen welche YVX welchem Farbraum entspricht muss ich nicht, wenn ich im SSM den Farbraum für den Ausgang festlege oder? Dann kann ich ja das passende zu meinem Quellvideo auswählen und brauche nur noch MeGUI anzupassen.

    Zitat von Chron

    Ich benutze gar kein AVISynth

    Doch benutzt du. SSM erstellt ein AVISynth Skript und AVISynth wird von MeGUI genutzt. Da kommst du nicht drum rum. Weil MeGUI nunmal mit AVISynth von Haus aus arbeitet.


    Zitat von Chron

    Was genau ist die Pipeline? Das SSM script? Im x264 encoder ist das ja nur der csp Befehl.

    AVISynth ist ein Frameserver. Video und/oder Audio kommt rein, wird decodiert und kommt als unkomprimiertes entschlüsseltes Material an den Ausgang an.


    Der Ausgang ist allerdings offen.


    Da kann man jetzt ein Encoder zum Beispiel anbringen.


    Da AVISynth ein 32Bit Prozess ist und nicht nativ mit einem 64Bit Prozess arbeiten kann, wird eine Pipeline dazwischen geschaltet.


    Bei MeGUI wird dazu avs4x264mod.exe verwendet.


    Die Pipeline sorgt dafür das ein Signal durchgeschleift wird. Stell dir einfach ein Verbindungsrohr vor das von Fabrik A über den Ozean mit Fabrik B verbunden ist und darin sich ein Fließband befindet.


    Also hast du folgendes Schema:


    Dein Video wird mittels dem SSM Skript (AVISynth 32Bit) decodiert und mittels einer Pipeline (avs4x264mod) an x264 64Bit geleitet, das dann wieder das Video encodieren kann.


    Simple:
    Video -> Decodierung -> Verarbeitung -> Zwischenergebnis -> Weiterleitung -> x264 (Encodierung) -> fertiges Video.


    Ein 32Bit x264 bräuchte keine Pipeline. Hier würden beide Fabriken sozusagen in zwei unterschiedlichen Abteilen sein und beide miteinander ohne Pipeline arbeiten können.

    Ich encodiere gerade ein Folge von einem Spiel, und es dauert fast 2h40min.. das ist praktisch doppelt soviel, wie z.B. Dex gebraucht hat.
    Das Spiel hat dafür allerdings die Unreal Engine 4, ist also wesentlich komplexeres Material viel mehr Beleuchtung und so, aber es soll eine 5,28GB große Datei rauskommen. Bei Dex kamen maximal 900MB Dateien raus.


    Ist so ein massiver Unterschied bei gleicher Spielzeit in Anbetracht von Pixel 2D-Sidescroller zu UE4 Engine Spiel aus der Egoperspektive natürlich,
    oder muss ich was an den Einstellungen verhunzt haben?

    Ok alles klar. Ich hab ne CRF von 17, ungeachtet dessen dass Demon mir schon öfter sagte dass ich glaube 21 rum reicht :P
    Vielleicht äußert sich das jetzt bei der Grafik erst richtig.. aber dafür wird es dann hoffentlich auch ordentlich hübsch.

    CRF so tief wie es zum Uploadgeduldsfaden passt.
    Ich persönlich nehm 15. Mit dem jetzigen 25 mbit Upload ist eine änderung meiner codierung möglich. mal sehen.


    Aber komplexeres Material brauch länger zum codieren - da isses egal ob CRF, QP oder bitrate. Weil es muss hier halt deutlich länger nach Bewegung und sonstige Kompressionsansätze gesucht werden. Da wird man bei komplexem Video halt nicht so schnell fündig.


    Und CRF = Konstante Qualität für's Auge. Da ist klar das komplexeres Material mit der Dateigröße nach oben geht.

    Upload dauert sonst so 10 Minuten für einen Gigabyte, der Upload diesmal wird es dann in sich haben sind zum Glück aber nur zwei Folgen :D Sollte ich in Zukunft grafisch so aufwendige Spiele aufzeichnen werd ich die CRF bisschen hochschrauben denke ich.


    Aber daran dass ich von MKV auf Rawavc umgestellt habe liegt es nicht, oder? Du meintest ja sogar dass der Encode so schneller ginge.

    Moment mal.. mir kommt gerade ein Gedanke *hust*. Ich mache das normalerweise nicht aber diesmal habe ich einen 10 Sekunden Ausschnitt aus dem Video vor dem Anfang gezeigt.


    Dafür habe ich in den SSM 2x das Video reingezogen und dann Schnitte angesetzt und ein Script erstellt. Es sollte angegeben werden, von wo bis wo ich behalten will, oder?


    Also in der Theorie hat SSM dann eine absolute Framezahl die der doppelten Menge des Videos entspricht, weil es ja zwei Mal im Script enthalten ist. Ich schneide einen kleinen Ausschnitt aus Video 1 heraus, und setze dann erst wieder von X bis Y da an wo das zweite Video anfängt und aufhört. So bekomme ich den Ausschnitt vor das gesamte Video. Ist das so korrekt oder ist es anders, und es dauert nun so lange weil ich behalte, was ich gar nicht behalten will?

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden