Um schreiben oder kommentieren zu können, benötigst du ein Benutzerkonto.
Du hast schon ein Benutzerkonto? Melde dich hier hier an.
Jetzt anmeldenHier kannst du ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellen
@De-M-oN
Danke für den Hinweis mit dem Frameserver + MeGUI + SSM. Das Schneiden über 'CUT' funktioniert soweit ganz gut. Auch kann ich mir eine Preview von dem Bereich ansehen. Der Ton wird auch abgespielt.
Leider hab ich ein Problem, sobald ich den Ton über den Reiter 'Audio' exportiere. Es hört sich an als würde der Sound hängen und nur die ersten Millisekunden abspielen. Oder es ist kein Ton zu hören. In der Preview, wie oben geschrieben, ist alles okay. Liegt das an VirtualDub?
@UndiscoveredLP kann dir statt frameserver + megui x264vfw empfehlen - die hatten neulich sogar ein neues release.
Ist ne Ecke schneller und du kannst mit batching arbeiten oder so tools wie vegasaur
Ist nur etwas tricky wegen avi container.
Das audio encodiere ich mir dann hinterher mit ffmpeg
zB aac im mp4 container mit faststart
ffmpeg -i input.avi -c:v copy -c:a aac -ab 320k -movflags +faststart out.mp4
oder flac + mkv
ffmpeg -i input.avi -c:v copy -c:a flac out.mkv
fallst du die genauen Einstelluneg für x264vfw willst (damit das avi nicht async wird) sag bescheid
@Schauerland
Gestern hab ich noch im x264vfw Tutorial nach einer Möglichkeit gesucht mehrere Videos inkl. Audio zu rendern. Das heißt mit der neuen Version des x264vfw funktioniert es nun? Falls ja, wäre ich sehr interessiert an dem Thema um für mich selbst rauszufinden, ob ich besser mitr x264vfw oder SSM + MeGUI arbeiten möchte.
Kannst du mich da etwas aufklären? Würde mich auch freuen, wenn du mir die Einstellungen sagen könntest, sodass das *.avi file nicht async wird 
@De-M-oN
Nein, da ich mir nicht sicher war, ob ich das tatsächlich anhaken musste. Werde ich gleich ausprobieren, da ein Rendervorgang noch am Gange ist.
Gestern hab ich noch im x264vfw Tutorial nach einer Möglichkeit gesucht mehrere Videos inkl. Audio zu rendern. Das heißt mit der neuen Version des x264vfw funktioniert es nun? Falls ja, wäre ich sehr interessiert an dem Thema um für mich selbst rauszufinden, ob ich besser mitr x264vfw oder SSM + MeGUI arbeiten möchte.
Es funktionierte immer. Du musst den Output-Mode anders wählen. Statt "File", wie im Tutorial angegeben, nimmst du VfW. Dann bekommst du eine AVI-Datei incl. Ton heraus. Das was da raus kommt ist nicht ganz unproblematisch, deshalb hat Schauerland noch einen abschließenden Schritt, indem er von FFmpeg die Videospur kopieren, Audiospur kodieren und alles in einen MP4-Container stecken lässt.
@fr0st
wichtig sind die zwei Haken bei Zero Latency und VirtualDub Hack
wie gesagt, audio musst du dann noch encodieren und beides muxen - ich mache es mit einem ffmpeg script in einem schritt
falls du größer als 1920x1080 renderst, musst du Level kleiner 6 manuell setzen, da sonst Vegas 14 das nicht mehr einlesen kann (falls du die fertigen dateien nochmal in vegas brauchst)
@RealLiVe
Gestern noch den ganzen Abend nach einer Lösung gesucht. Wäre ich im Leben nicht drauf gekommen. Man lern nie aus.
@Schauerland
Apropo man lernt nie aus. Auch hier hab ich wieder was dazu gelernt. Gibt es bei den Level etwas zu beachten? Vor- und Nachteile der einzelnen Level? Ab und an macht es sicherlich Sinn alte Projekte in Vegas weiter verarbeiten zu können.
Ich hab die Erfahrung gemacht, dass Vegas meine *.mkv Dateien aus OBS nicht in das Projekt importieren kann. Ist das nach dem muxen durch dein obiges Script unter Berücksichtung des Levels immer noch so? Würde flac + mkv gegenüber aac + mp4 vorziehen.
Noch eine kleine Rückfrage zu deinem Script:
Ich erstelle eine Batch, kopiere die Zeilen rein und starte das Script im selben Verzeichnis wo die *.avi-Datei liegt. Am Ende erhalte ich meine gemuxte *.mkv / *.mp4 Datei, die ich auf YT hochladen kann. Verstehe ich das richtig?
ffmpeg runterladen (statisch gelinkt) und entpacken https://ffmpeg.zeranoe.com/builds/
path variable des ffmpeg ordners hinzufügen
in .bat Datei kopieren und diese ins Ausgaveverzeichnis der avis legen. mit doppelklick werden alle avis in mp4 gemuxt und das audio in aac convertiert
alternativ als mkv
Vegas kann kein mkv importieren und scheinbar kein h264 mit level 6
Hier einige Infos zu den levels:
https://de.wikipedia.org/wiki/H.264#Level
Habe ich die selbe Qualität dann wenn ich in Vegas mit x264vfw rendere wie mit Frameserver + meGUI
Vegas kann kein mkv importieren und scheinbar kein h264 mit level 6
Hier einige Infos zu den levels:
https://de.wikipedia.org/wiki/H.264#Level
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. Außer du wiedersprichst mir jetzt. Mit der Auflösung 2048x1152 bekomme ich aber keine Probleme - oder?
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.
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.
Habe ich die selbe Qualität dann wenn ich in Vegas mit x264vfw rendere wie mit Frameserver + meGUI
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 )
@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? 
Danke. Hab ich denn gravierende Nachteile, wenn ich MP4 und AAC nutze außer den Verlust der (besseren) Audiospur?
Nein, in dem Fall nicht.
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.
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.
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...
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.
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
Ü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.
Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!