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

    Zitat von fr0st

    Ich könnte doch trotzdem Level 5.2 auswählen, mkv + flac bevorzugen und später die mkv-Datei in mp4 remuxen. In der Theorie müsste das nach Adam und Eva funktionieren.

    Könntest du. FLAC passt zwar nicht im MP4, das kannst aber dann halt als "normale" Audiodatei importieren. Sehe da aber keinen allzu großen Vorteil darin. Hast zwar verlustfreies Audio, aber auch AAC mit hoher Bitrate gilt als transparenz.


    Zitat von UndiscoveredLP

    Habe ich die selbe Qualität dann wenn ich in Vegas mit x264vfw rendere wie mit Frameserver + meGUI

    Nein. Gerade wenn du Zero Latency benutzen musst, dann deaktivierst du dir viele sehr gewichtige Funktionen von x.264, die sich massivst auf die Kompressionseffizienz auswirken.

    @RealLiVe
    Danke. Hab ich denn gravierende Nachteile, wenn ich MP4 und AAC nutze außer den Verlust der (besseren) Audiospur?


    Könntest du den Punkt mit Zero Latency genauer erläutern? Hab ich im Endeffekt dadurch nur eine etwas größere Datei zum Hochladen oder muss ich dadurch auf besondere, mir nicht bekannte, Feature verzichten? :/

    Zitat von fr0st

    Danke. Hab ich denn gravierende Nachteile, wenn ich MP4 und AAC nutze außer den Verlust der (besseren) Audiospur?

    Nein, in dem Fall nicht.

    Zitat von fr0st

    Könntest du den Punkt mit Zero Latency genauer erläutern? Hab ich im Endeffekt dadurch nur eine etwas größere Datei zum Hochladen oder muss ich dadurch auf besondere, mir nicht bekannte, Feature verzichten?

    Ich sag mal nein. Du deaktivierst mit der Vorlage halt quasi alles, was die Latenz in die Höhe treiben kann. Da fallen halt einige Features von x.264 darunter, die die Kompressionseffizienz deutlich erhöhen, beispielsweise die ganze B-Frame - Geschichte. Für die gleiche Qualität wirst du deutlich mehr Speicher brauchen. Wenn du wissen willst, was da genau darunter fällt: Das kannst du beispielsweise hier nachlesen.


    Falls du nur auf Speed aus bist, könnte das aber trotzdem passabel für dich sein.

    Zitat von Schauerland

    Wenn du kein 10 bit verwendest ja, da es der gleiche x264 encoder ist (weiß gar nicht ob 10 bit überhaupt die quali beeinflussen oder nur die Dateigröße? @De-M-oN )

    Beides.

    Mal eben dazwischen geworfen: Hat irgendwer allgemein mal probiert, ob zerolatency überhaupt notwendig ist, um Asynchronitäten via x264vfw zu verhindern oder ob lediglich die Option --force-cfr reichen würde, wie sie bei zerolatency standardmäßig genutzt wird?
    Würde der Diskussion um zerolatency schnell ein Ende bereiten, wenn Synchronität so bereits gewährleistet wäre.

    Zitat von Schauerland

    weiß gar nicht ob 10 bit überhaupt die quali beeinflussen

    Naja klar und vor allem bei deinen dunklen Horrorspielen profitierste davon. 10Bit Quantisierung haste kein sichtbares Banding mehr. Bei 8bit schon.
    _
    Naja MeGUI wäre natürlich kompressionseffizienter als vfw. Das sollte einem immer klar sein. Und das Encoding in AVI fand natürlich dann auch mit den üblichen Biegen und Brechen für den AVI Container statt, ein nachträgliches ummuxen kann diesen Umstand ja nicht fixen, das es weit ineffizienter encodiert wurde.

    Zitat von Kayten

    Mal eben dazwischen geworfen: Hat irgendwer allgemein mal probiert, ob zerolatency überhaupt notwendig ist, um Asynchronitäten via x264vfw zu verhindern oder ob lediglich die Option --force-cfr reichen würde, wie sie bei zerolatency standardmäßig genutzt wird?
    Würde der Diskussion um zerolatency schnell ein Ende bereiten, wenn Synchronität so bereits gewährleistet wäre.

    danke, kann ich mal testen, so ganz wohl fühle ich mich auch nicht dabei.
    Ich meine aber die Option mit dem virutaldub hack reichte nicht...

    Zitat von Kayten

    Hat irgendwer allgemein mal probiert, ob zerolatency überhaupt notwendig ist, um Asynchronitäten via x264vfw zu verhindern oder ob lediglich die Option --force-cfr reichen würde

    Mal so nebenbei als Gedanke:


    Asynchronität kommt doch entweder durch das Dekodieren der Videodatei in das Schnittprogramm, weil vllt. A) falsch eingelesen wurde bzw. Format nicht 100% unterstützt wird oder B) das Video in VFR vorliegt und das Schnittprogramm damit gar nicht umgehen kann beim Dekodieren mit seinen internen Dekodern.


    Oder es wird durch das Nicht Einhalten der FPS verursacht. Sprich das Projekt läuft im Schnittprogramm mit z.B. 60 FPS. Beim VFW Übergang wird vllt. auch noch 60 angegeben, aber x264vfw macht daraus 30 FPS, weil beim Encoder der entsprechende Parameter "--fps 60/1" vergessen wurde anzugeben. Folglich wird das Video dann asynchron.


    Das sind so die häufigsten Fälle die die User nicht beachten und vor einem Asynchronen Video stehen.


    Die Option "--force-cfr" erstellt nur für MP4 und MKV Dateien die entsprechenden Timestamps. Das bringt dir aber auch nix, wenn das Problem schon ganz woanders liegt.
    Weil was bringt dir diese Option schon, wenn dein Video bereits zwischen VFW vom Schnittprogramm und x264vfw selbst asynchron wird, weil die FPS nicht eingehalten wurde?


    Und "zerolatency" ist nicht grade empfehlenswert. Es werden dabei keine B-Frames erstellt. Auch der Puffer für Folge Berechnungen von Algorithmen wird auf 0 gesetzt. Der gesamte Macroblock Baum wird erst gar nicht verwendet. Also Effizienz sinkt bei der Verwendung von "zerolatency" extrem ab schon. Sollte man vermeiden, es sei denn man hat nen sehr schäbigen und extrem lahmarschigen Rechner wo man damit noch einiges an Geschwindigkeit rausholen kann. Aber für Dateigröße und Bildqualität schadet es eigentlich nur. Da sollte man eigentlich umsichtiger bei sein, als diese Option blind zu nutzen.



    Zitat von De-M-oN

    Und das Encoding in AVI fand natürlich dann auch mit den üblichen Biegen und Brechen für den AVI Container statt, ein nachträgliches ummuxen kann diesen Umstand ja nicht fixen, das es weit ineffizienter encodiert wurde.

    Jein. Man kann die Videos schon damit in den AVI Container schreiben lassen, aber es sollte ohne den VirtualDub Hack geschehen der beim x264vfw angeboten wird. Im Nachhinein kann man die Files wieder in MP4 oder MKV ummuxen. Die Streams haben ja dadurch keine Schäden. Das einzige ist der AVI Container der nicht für den Stream ausgelegt ist.
    Die x264vfw Entwickler haben das in ihren Decoder ja schon so gelöst das man diese AVIs ja abspielen kann, weil eigentlich geht es ja nicht.


    Die Streams werden nicht anders encodiert als würde man es in Roh oder in MKV encodieren lassen. Das einzige was dabei entscheidend ist, ist das der Stream halt in AVI ist. Und AVI unterstützt nicht alle Features con h264. Nicht umgekehrt ;D


    Darum sage ich ja auch immer das ein H264 Stream nicht in ein AVI Container gehört. Man kann aber getrost den h264 Stream aus einer AVI in z.B. ein MKV File stecken. Das einzige was damit passiert ist das dein Rechner nun statt den AVI Splitter und eventuelle Filter für AVI nicht mehr anspricht und somit nun der H264 Decoder bzw. Matroska Filter / MP4 Filter und oder Splitter angesprochen werden. Die sind wesentlich effizienter für das H264 Format.


    Darum dreht sich das ganze eigentlich.


    Der VirtualDub Hack den du bei x264vfw findest ist der eigentlich Hack dafür. Damit werden H264 Streams AVI Kompatible gemacht. Das heißt das jedes bescheuerte Programm was AVI öffnen kann, nun auch diese Dateien öffnen kann. Und da kommen dann deine Befürchtungen hinzu.






    Nebenbei für die anderen als Info noch:
    x264vfw ist mit der Entwicklung weit hinter der Konsolen Anwendung. Sprich das x264 das z.B. bei MeGUI verwendet wird ist extrem weiter schon von der Version her.


    Unterschiede gibt es von der Bitversion. Denn für x264vfw gibt es einzig und allein die 8Bit Variante. Wobei die 10Bit Version um einiges besser ist. Der 10Bit Encoder ist vor allem bei Banding Sachen extrem Bonitätsfördernd. Auch was die Kompression von 8zu10Bit angeht steht dieser Encoder weit vorn.
    Bei Profis wird der 10Bit Encoder vor allem für Filme angewendet wie z.B. Animes, Trickfilm, Spielfilme, Serien, etc.
    Auch bei Spielen kann sich das schon für YT bemerkbar machen. Auf jedenfall kann man damit die Qualität noch mal sehr leicht ansteigen lassen. Selbst für YT Videos.


    Dafür ist die 8Bit Version schneller. Erst recht die 32Bit Anwendung der 8Bit Version von x264. Das ist die schnellste Version.
    Die langsamste ist die 64Bit Anwendung der 10Bit Version.


    Bei der 64Bit steht einem aber mehr Speicher zur Verfügung. Das heißt: Wenn man nicht gerade mit 4K Schießmichtot arbeitet, würde die 32Bit Anwendung von x264 komplett ausreichen.

    So, jetzt mal ne doofe Frage vielleicht, aber wie schon mal gesagt habe ich keine 200+-Seiten gelesen.


    Ich habe jetzt mal Testweise eine kurze Aufnahme durch SSM und meGUI gejagt und mich an die jeweiligen tutorial gehalten.
    An sich gefällt mir das Ergebnis und die Größe....ABER:


    Über SSM habe ich einen Export von 2 Audio-Tracks (1xMikro, 1xIngame) wenn ich nun bei meGUI bei Audio über Rechtsklick einen weiteren Track hinzufüge und dort die zweite Audiospur als Input wähle habe ich im gemuxden Video nur Spur 1.


    Was mache ich falsch? bzw. wo könnte der Fehler liegen?


    Aufnahme über OBS
    x264

    Zitat von QuinsWorld

    Über SSM habe ich einen Export von 2 Audio-Tracks (1xMikro, 1xIngame) wenn ich nun bei meGUI bei Audio über Rechtsklick einen weiteren Track hinzufüge und dort die zweite Audiospur als Input wähle habe ich im gemuxden Video nur Spur 1.

    Normalerweise ist es dann als separate Spur drin. Um das zu verifizieren, wäre eine MediaInfo hilfreich, wenn du das überhaupt willst.


    Ich nehme an, dass du bei der fertigen Datei beide Spuren gleichzeitig abspielen willst, oder? Wenn dem so ist, dann musst du die beiden exportierten Spuren vorher abmischen, beispielsweise in Audacity.

    Zitat von RealLiVe

    Normalerweise ist es dann als separate Spur drin. Um das zu verifizieren, wäre eine MediaInfo hilfreich, wenn du das überhaupt willst.
    Ich nehme an, dass du bei der fertigen Datei beide Spuren gleichzeitig abspielen willst, oder? Wenn dem so ist, dann musst du die beiden exportierten Spuren vorher abmischen, beispielsweise in Audacity.

    Das mit dem abmischen in Audacity wäre mein Plan B
    Ich pack mal den ganzen QUST den MediaInfo ausgespruckt hat in den Spoiler, vielleicht erkennt jemand den fehler.
    Beide AudioTracks lassen sich ganz regulär abspielen und beinhalten den entsprechenden Ton

    [IMG: https://www.letsplayforum.de/wcf/images/smilies/smile.png]

    )



    Auch wenn jemand andere schwerwiegende Fehler erkennt gerne ein Hinweis, ich übe ja noch

    [IMG: https://www.letsplayforum.de/wcf/images/smilies/smile.png]
    Zitat von RealLiVe

    Okay, und was ist dann das Problem? Wie gesagt, falls du beide gleichzeitig abspielen lassen willst, kommst du um's Mischen nicht herum.

    Okay, die Anfangsfrage habe ich dann vielleicht falsch formuliert:


    Muss ich die Audiospuren aus SSM zwingend VOR meGUI mischen (z.B. Audacity) oder kann meGUI das auch?
    Da ich bei meGUI ja einen zweiten Audiotrack anlegen kann bin ich davon ausgegangen dass die Spuren dort importiert und gemischt werden. Wenn das nicht geht finde ich es irritierend dass man eine zweite Spur anlegen/importieren kann :) Oder verstehe ich den Sinn der zweiten Spur in meGUI falsch?

    Zitat von QuinsWorld

    Muss ich die Audiospuren aus SSM zwingend VOR meGUI mischen (z.B. Audacity) oder kann meGUI das auch?

    Du musst es zwingend vor MeGUI mischen. Der SSM kann das (glaube ich) beim Export machen, wenn du es so einstellst, ich würde dir aber empfehlen, es in Audacity zu machen, um sicherzustellen, dass die Lautstärke und das Mischverhältnis passt.

    Zitat von QuinsWorld

    Wenn das nicht geht finde ich es irritierend dass man eine zweite Spur anlegen/importieren kann Oder verstehe ich den Sinn der zweiten Spur in meGUI falsch?

    Um eine weitere, separate Audiospur dazu zu muxen. Wenn du beispielsweise ... was weiß ich ... eine deutsche Audiospur haben willst und eine englische. Macht Sinn, bringt dir aber für YouTube nichts.

    Okay, danke, jetzt hab ich den Punkt verstanden :)


    Habe aber schon die nächste Frage, ich habe das Gefühl dass die Farben nach meGUI deutlich kräftiger sind als in der eigentlichen Aufnahme. Also so als wenn ich irgendwo angehakt hätte: "Leg bissl Farbe nach"....
    Ich kann das nicht wirklich belegen, es ist kaum wahrnehmbar, aber kann das sein oder bin ich verwirrt? :)

    Einer eine Idee wieso Megui urplötzlich immer alles 2mal encodieren will? o_O


    Neuerdings encodiert MeGui das Video vollkommen normal, fängt dann aber sofort noch mal an das selbe Video zu encodieren und ich habe keine Ahnung wieso. Einstellungen sind seit Jahren die selbe, .avs auch.

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden