MeGui Geschwindigkeitsprobleme

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • MeGui Geschwindigkeitsprobleme

    Anzeige
    Tach

    Nur mal als Frage.
    Ich habe bei einen I7-3930k nur 3 Fps beim Encoding.
    Ich weiß das mein Skript sehr aufwendig ist und das viel Geschwindigkeit frisst, aber so extrem viel? O.O
    Ich muss auch 3 Worker laufen lassen damit ich die Auslastung meiner CPU dauerhaft bei 100% halten kann.
    Meine Presets sind CRF 18 und Slow.

    Skript:

    Spoiler anzeigen
    ​### Lade Plugins und setze die globalen Variablen ###
    LoadPlugin("C:\Program Files (x86)\SagaraS Scriptmaker\Plugins\SplineResize.dll")
    LoadPlugin("C:\Program Files (x86)\SagaraS Scriptmaker\Plugins\mvtools2.dll")
    Global breite = 3200
    Global hoehe = 1800
    Global AR = 0

    ### Lade Videoquellen ###
    SetMTMode(3,2)
    AVIload("A:\Dungeon Defenders\Aufnahme\DunDefGame 2014-07-08 18-49-54-809.avi", 0, 0, 0, -0, -0)

    ### Filter Verarbeitungszone ###
    SetMTMode(2)
    sum = MSuper(pel = 2)
    MFlowBlur(sum, MAnalyse(sum, isb = true), MAnalyse(sum, isb = false), blur = 5.0)

    ### Funktion für Video-Laderoutine ###
    Function AVIload (String file, int loading, int cl, int co, int cr, int cu) {
    (loading == 1) ? FFIndex(file) : nop()
    clip0 = (loading == 3) ? LWLibavVideoSource(file) : (loading == 2) ? Import(file).KillAudio() : (loading == 1) ? FFVideoSource(file, threads=1) : AVISource(file, false)
    rate1 = (Round(Float(clip0.framerate * 1000)) / 1000) / 2
    rate2 = Round(clip0.framerate) / 2
    rate = (rate1 == rate2) ? 1 : 1001
    ratefaktor = (rate == 1001) ? 1000 : 1
    clip1 = (rate == 1001) ? clip0.AssumeFPS(Round(clip0.Framerate) * 1000, rate) : clip0.AssumeFPS(round(clip0.framerate), rate)
    clip1 = clip1.Crop(cl, co, cr, cu)
    clip1 = (clip1.width == breite && clip1.height == hoehe) ? clip1 : (AR == 1) ? ((float(Clip1.height * breite) / clip1.width) / 2 == round((float(Clip1.height * breite) / clip1.width) / 2)) ? ((float(Clip1.width * hoehe) / clip1.height) / 2 == round((float(Clip1.width * hoehe) / clip1.height) / 2)) ? clip1 : clip1.ConvertToRGB24(matrix = "Rec601") : clip1.ConvertToRGB24(matrix = "Rec601") : clip1
    clip1 = (clip1.width == breite && clip1.height == hoehe) ? clip1 : (AR == 1) ? (((clip1.width * hoehe) / clip1.height > breite) ? Clip1.Spline100Resize(breite, ceil(float(Clip1.height * breite) / clip1.width)) : Clip1.Spline100Resize(ceil(float(clip1.width * hoehe) / clip1.height), hoehe)) : clip1.Spline100Resize(breite, hoehe).ConvertToYV12(matrix = "Rec601", ChromaResample = "Spline16")
    back = (clip1.width == breite && clip1.height == hoehe) ? clip1 : (AR == 1) ? (0 == 1) ? ImageReader("", 0, clip1.framecount, clip1.framerate).ChangeFPS(round(clip1.framerate) * ratefaktor, rate).Spline100Resize(breite, hoehe).ConvertToYV12(matrix = "Rec601", ChromaResample = "Spline16") : BlankClip(clip1.framecount, breite, hoehe, "YV12", round(Clip1.framerate) * ratefaktor, rate).KillAudio() : clip1
    Return (clip1.width == breite && clip1.height == hoehe) ? clip1.ConvertToYV12(matrix = "Rec601", ChromaResample = "Spline16") : (AR == 1) ? Overlay(back, clip1, (back.width - clip1.width) / 2, (back.height - clip1.height) / 2) : clip1
    }

    __film = last
    __t0 = __film.trim(3825, 32275)
    __t0
  • Dein Skript ist in wirklichkeit sehr klein. Es wirkt nur groß.

    Da steht eigentlich nix weiter als:

    Quellcode

    1. LoadPlugin("C:\Program Files (x86)\SagaraS Scriptmaker\Plugins\SplineResize.dll")
    2. LoadPlugin("C:\Program Files (x86)\SagaraS Scriptmaker\Plugins\mvtools2.dll")
    3. SetMTMode(3,2)
    4. AVISource("A:\Dungeon Defenders\Aufnahme\DunDefGame 2014-07-08 18-49-54-809.avi").AssumeFPS(30, 1)
    5. Crop(0,0,0,0).Spline100Resize(3200, 1800)
    6. ConvertToYV12(matrix = "Rec601", ChromaResample = "Spline16")
    7. SetMTMode(2)
    8. sum = MSuper(pel = 2)
    9. MFlowBlur(sum, MAnalyse(sum, isb = true), MAnalyse(sum, isb = false), blur = 5.0)
    10. __film = last
    11. __t0 = __film.trim(3825, 32275)
    12. __t0
    Alles anzeigen


    So sieht dein Skript momentan aus. Bis bei AssumeFPS. Da hab ich jetzt 30 reingeschrieben, weil ich das aus dem SSM Skript nicht entnehmen kann, da er sich das via Variable selbst dingfest macht.

    Das was am meisten Leistung zieht und dein Encode ausbremsen tut ist das Motion Blur selbst.

    Das soll auch nur dann angewendet werden, sollte das Spiel über keinerlei Motion Blur verfügen und recht komplex sein. z.B. bei Minecraft ohne passenden PixelShader oder bei Arma.

    Die Zeit zur Berechnung dauern damit etwas länger, da aus einer reihe von Frames die Bewegungen ermittelt werden müssen. Sprich Bewegungsvektoren. Alles was sich dann bewegt wird geblurt. Das ist recht Rechenintensiv. Genauso die Oberen Resizeauflösungen die du verwendest.

    Du musst bedenken... auf das neue skalierte Bild mit 3200x1800 wirkt nun der Motion Blur, der Rechenintensiv ist. Er muss A) Die Frames mit ihrer Auflösung bewältigen und er muss B) das Bild entsprechend der Berechnung umändern, damit Motion Blur entstehen kann.

    Noch langsamer wäre es wenn das ganze von einer NLE via DebugMode Frameserver durch diese Filter zusätzlich gejagt wird. Dann findet nicht nur im Skript die Berechnung statt, sondern auch die NLE selbst berechnet von Natur aus. Bedeutet im Endeffekt das es mehr Rechenarbeit leistet.


    Zu deinem anderen Problem: Wenn deine CPU nicht zu 100% ausgelastet wird, wäre ein Versuch mit AVISynth+ 64Bit vllt zu empfehlen. Einziges Problem... AVISynth+ 64Bit besitzt kein Multithreading. Genauso weiß ich nicht wie dort die Filter wirken oder halt nicht wirken. Müsstes es also ausprobieren.

    Getestet habe ich aber AVISynth+ 32Bit. Erheblich schnellere Verarbeitung und somit auch schnellerer Encode. Das lief auch alles, da die Filter wie Spline oder Blockbuster etc. 32Bit Basierend sind. Ob sie aber bei dem 64Bit AVISynth auch laufen, müsstest du testen.

    Und wie gesagt: AVISynth+ hat kein Multithreading.

    Und der Skript vom SSM sieht nur groß aus, ist aber wie schon erklärt recht klein. Beim SSM wird halt sehr viel mit berücksichtigt. Das sieht beim SSM nur nach viel aus, ist aber ledeglich so angepasst, das mehrere Videos verknüpft werden können.
  • GelberDrache92 schrieb:

    ch weiß das mein Skript sehr aufwendig ist und das viel Geschwindigkeit frisst, aber so extrem viel? O.O


    Das war dadrauf bezogen das die Hochskalierung und der Motion Blur viel Zeit kosten.
    Aber gut wenn das normal mit der Geschwindigkeit ist, ist das Ok.

    Sagaras schrieb:

    Zu deinem anderen Problem: Wenn deine CPU nicht zu 100% ausgelastet wird, wäre ein Versuch mit AVISynth+ 64Bit vllt zu empfehlen. Einziges Problem... AVISynth+ 64Bit besitzt kein Multithreading. Genauso weiß ich nicht wie dort die Filter wirken oder halt nicht wirken. Müsstes es also ausprobieren.


    Ich hab damit kein Problem das ich 3 Worker aufmachen muss um meine CPU auf 100% zu bringen.
    War halt nur als Zusatz, falls es damit zusammen hängen sollte.

    Ich hatte jetzt auch noch mal auf Medium gestellt, wobei das aber keinen Fps zuwachs gegeben hatte.
  • x264 kann erst encodieren, wenn das AVISynth Skript mit den Filtern die Berechnung fertig hat.

    Die Frames aus deinem Video durchlaufen im AVS Skript ja die Filter der Reihenfolge nach ab. Dabei muss das Bild neu berechnet werden ("rendern auch genannt :S ") durch neue Skalierung des Bildes + YV12 Konvertierung + MotionBlur.

    Dauert der Vorgang lange (Kann man ja selbst testen wie schnell die AVS beim abspielen ist in VDub z.B.), so können die Frames auch nur langsam zum Encoder geschickt werden.

    Der Encoder wiederum kann nur so schnell verarbeiten wie er die Frames bekommen kann.

    Sprich AVISynth ist mit seinen Filtern ein Ventil das den Durchlauf der Frames reguliert. Je mehr Filter, desto mehr staucht es. Als ob man den Wasserhahn langsam zudreht. Ist nur die AVISource + AssumeFPS vorhanden im AVS Skript, so ist der Wasserhahn komplett geöffnet und alles fließt schneller durch.

    Das Multithreading kann man wie einen zusätzlichen Druck des Wassers bezeichnen der dann durch die Leitung jagt.

    AVISynth+ 64Bit würde die Rohre etwas erweitern sozusagen, damit mehr Wasser durchfließen kann. Jedoch kann es sein das einige Filter dann nicht mehr passen.


    So kann man sich das eventuell auch mal Bildlich vorstellen. kA ob man das so verstehen konnte jetzt ^^
  • Anzeige
    Gut beschrieben, aber ich wusste das schon vorher xD
    Ich war halt nur am überlegen da die CPU ja auf 100% läuft und die einzelnen Worker ja zwischen durch unterschiedlich viel Leistung brauchen durch die Filter, das es durch denn Leistungswechsel zwischen denn einzelnen Worker zu einer Reduzierung der CPU Leistung kommen könnte.

    Das gleiche kennt man ja auch wenn man ein Video encoded und dabei am Zocken ist und man dann zwischen durch Fps Einbrüche hat, weil die CPU nicht schnell genug dem Spiel genug Leistung zur Verfügung stellen konnte.
  • Berechnung sowie Encode des Videos ziehen, wie bei jeder Software die CPU brauch, unterschiedlich viel Leistung.

    Das kann dann der Moment sein wo das Bild Flächenfarbig ist und die Filter kaum oder gar nix machen müssen. Der Durchfluss wird schneller, da das Wasser (Bleiben wir mal bei dem Rohrbeispiel :D) kein Kalk oder andere Meneralien mit sich führt. Sprich es ist komplett sauber. Der Durchfluss geschieht schneller durch die Filter.

    Jetzt ist das Video aber sehr Komplex. Sprich viele Details, viel Bewegung, sehr viel Schärfe. Mit anderen Worten: Das Wasser führt nun jedemenge Meneralien mit sich. Kalk, Bakterien etc.

    Da dauert das Filtern auch länger.
    Bei dem Wasserbeispiel kann man sich auch gern ein Wasserfilter vorstellen der dann durch diese Meneralien blockiert wird und nicht mehr so schnell das Wasser durchfließen lässt.