Unperformantes Verarbeiten von x264-OBS Aufnahme

  • Seit längerem mal wieder ein erfrischendes "Moin" von mir ... Ich nehme derzeit testweise mit OBS Studio auf, alles läuft derzeit nach den EInstellungen aus dem Sammelfred...
    Jedoch ist es merkwürdig: Schon bei der Scripterstellung mithilfe des SSM dauert es gefühlt Ewigkeiten, bis die Extrahierung der Audio-Files abgeschlossen ist. Das gleiche bei megui: Nach Hinzufügen des Scriptes dauert es ewig, bis die Dateiausgabe ausgefüllt ist und ich starten kann, was sich hinzieht bis zum Encoding selbst: Dieses läuft mit allerhöchstens 10 FPS durch, wo ich bei jeglichen anderen (DxTory-)Aufnahmen, auch wenn nicht hundertrprozentig vergleichbar aber doch eine grobe Richtung vorgebend, jedes Encoding MINDESTENS mit 20fps druchläuft...


    Warum ist die Verarbeitung der x264 Files so unperformant?
    Anbei mein Script... dazu noch die Frage: Ist der gewählte Farbraum YV12 für Nv12 Aufnahmen korrekt?




    so jetzt hoff ich auf eure Fähigkeiten - MfG, TimBourbon

  • Warum ist die Verarbeitung der x264 Files so unperformant?


    Weil die H.264 Dateien erst mal dekodiert werden müssen, um weiterverarbeitet werden zu können. Und das dauert leider seine Zeit. :/ Dxtory-Aufnahmen sind ja meistens mit einem verlustfreien Codec, der einfach viel schneller eingelesen werden kann.

  • Im SSM wird via FFMS2 so ein h264 Video erst einmal indexiert und dann auch noch nur mit einem Thread betrieben, aufgrund von Fehlermarge.
    Sprich Prozentual kann es passieren bei einer Nutzung mehrerer Threads in Bezug zur Nutzung von FFMS2 das sich Fehler im Bild zeigen. Um dies nicht zu produzieren und vorzubeugen ist der Thread Wert auf 1 gesetzt.


    Effektiv schneller wäre die Nutzung von L-Smash unter Verwendung von LibAV. Das kann man im SSM umstellen. LibAV wäre ungefähr das gleiche wie das was FFMS2 auch macht. Nur L-Smash braucht keine Thread Limitierung.


    Noch schneller, aber unter der höheren Gefahr einer Fehlermage am Video kann man auch L-Smash auch ohne LibAV verwenden. Das würde noch mal wesentlich schneller gehen, sofern man für die Quellen oder generell für das Skript Multithreading abschaltet.


    Denn L-Smash hat an sich schon Multithreading intern. Daher auch wesentlich schneller. Ob nun mit oder ohne LibAV.



    h264 oder generell Lossy kodierte Videos brauchen oft mehr Speicher zur Dekodierung als z.B. Lossless kodierte Videos. Das ist an sich ganz normal.


    Aber hier jetzt hast du über FFMS2 im SSM halt nur ein Thread genutzt, und das bremst dich extrem aus.

  • rechts aufklappen und dann l-smash anhaken. Änder den Pfad noch auf den von MeGUI. Das darfst du jedes Mal machen weil SSM nen bug hat, das er sich den Pfad nicht merkt :D
    Oder du kopierst die von megui in SSM rein, dann kanns dir ja egal sein.
    Rufe aber vorher den Updater von MeGUI auf und gucke ob l-smash aktiviert ist und wenn nich mach es und drück auf update.


    Nimm l-smash mit l-smashvideosource - kann man das überhaupt bestimmen ob libav oder lsmash @Sagaras ? Weil ich hab das nur im VFR-CFR Konverter gesehen!

  • kann man das einstellen dass der das eine so das andere so rauszieht?


    oder müsste ich erst bspw. das videoscript mit lsmash speichern und dann in nem zweiten schritt den audioexport machen?
    geht auf jedenfall, kann ja evtl auch schneller gehen :p

Jetzt mitmachen!

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