MSI Afterburner - Kostenlose Alternative zu FRAPS und DxTory!

    @Vrall
    Einstellungen von De-M-oN übernommen? Wenn ja:
    Klick im AB mal auf das i-Symbol und scroll dort herunter, bis du bei Aktive 3D Prozesse ankommst ohne das Spiel gestartet zu haben.
    Steht dort etwas anderes als "nicht entdeckt", so musst du die jeweilige exe-Datei in RTSS hinzufügen und das Application Detection Level auf None stellen, denn sonst versucht der AB etwas zu hooken, was er nicht soll. Dementsprechend funktioniert die Aufnahme dann nicht.
    Um welches Spiel handelt es sich überhaupt?


    Edit: Hab deinen Edit nicht rechtzeitig gesehen.

    Um The Witcher 2, das bei jeder durchschrittenen Tür eine Münze wirft ob es mich gleich wieder auf den Desktop befördert oder nicht. An der PC-Leistung liegt es nicht, sondern an der Zusatzbelastung durch die Aufnahme. Da scheint der virtuelle Speicher an seine Grenzen zu gelangen. Aber irgendwie geht es schon :)


    Ich werd mir deinen Tipp mal merken für zukünftige Problemchen.

    Da ich das Thema leider zu früh geschlossen habe und dadurch keiner Antwort gegeben hat, hier nochmal:


    Ich lpe derzeit Thief und das Spiel hat bisher wunderbar mit dem [lexicon]Afterburner[/lexicon] zusammengearbeitet.
    Nach Installation des HD Texture Packs geht die Aufnahme nicht mehr.


    Der Kreis beginnt sich zu drehen, aber ich kann sie nicht mehr stoppen und eine Datei wird dabei auch nicht erstellt.
    Ich habe schon alle Mods deinstalliert und das Rohspiel gestartet, aber es geht nicht.


    Jemand bitte eine rettende Idee?

    Leider nein, aber ich habe da auch gerade ein Problem :)


    Ich habe gestern testweise mal mit dem [lexicon]Afterburner[/lexicon] aufgenommen. Nach 46 Sekunden war die Mikrospur dann quasi tot.
    Ich habe das 3 mal versucht, jedes mal mit demselben Ergebnis. Am [lexicon]Mikro[/lexicon] liegt's nicht, mit [lexicon]OBS[/lexicon] oder im TS habe ich das Problem auch nicht.


    Irgendwelche Ideen? Wüsste nicht, wo das eine Einstellung sein könnte. Allerdings muss ich sagen, dass das Spiel eh rumzickt.
    [lexicon]OBS[/lexicon] kann es nicht abgreifen und der [lexicon]Afterburner[/lexicon] kann dort kein Overlay darstellen. Obwohl's Unity ist.

    Kann es sein dass der [lexicon]MSI Afterburner[/lexicon] ziemlich empfindlich ist und schnell mal nicht mehr mag? Mit [lexicon]Fraps[/lexicon] hatte ich nie Probleme, dass die Aufnahme nicht ging.


    Ich glaube ich schau mich mal nach einem anderen Recorder um. Dass es alle paar Tage solche Probleme bereitet ist für mich ein No-Go.

    Ah, ich hab mir nochmal das erste Tutorial angeschaut und er sagte dort dass bei ihm bei WASPI-Mikrophon nach etwas über 1 Minute schluss mit der Aufnahme ist.
    Denn gucke ich mal mit Direct Sound.


    Vielleicth siehst Du in dem Video ja auch noch was für Dich. Habe mir nur einen Teil angeschaut.

    Booyakasha! Ich weiß es endlich! Der [lexicon]Encoder[/lexicon]-Server hängt sich auf.
    Ich habe das "use dedicated [lexicon]encoder[/lexicon] server" beim [lexicon]Afterburner[/lexicon] für Thief jetzt deaktiviert und voilà: es funktioniert.

    Zitat von ValcryTV

    und der [lexicon]Afterburner[/lexicon] kann dort kein Overlay darstellen. Obwohl's Unity ist.


    Vllt braucht das Spiel andere RTSS Settings. zb andere Vectormethode etc.


    Zitat von Vrall

    Kann es sein dass der [lexicon]MSI Afterburner[/lexicon] ziemlich empfindlich ist und schnell mal nicht mehr mag?


    In meinem Falle: nein.


    Zitat von ValcryTV

    Ah, ich hab mir nochmal das erste Tutorial angeschaut und er sagte dort dass bei ihm bei WASPI-Mikrophon nach etwas über 1 Minute schluss mit der Aufnahme ist.
    Denn gucke ich mal mit Direct Sound.


    WASAPI ist halt die hardwarenahe Methode, DirectSound seit Vista nicht mehr.
    Bei mir bricht mit WASAPI auch nichts ab. Weder mit [lexicon]Soundkarte[/lexicon], noch mitm [lexicon]Audiointerface[/lexicon].
    Onboardsound, USB Headsets, in Windows kein HPET an etc sind alles keine optimalen Voraussetzungen.


    Zitat von Vrall

    Booyakasha! Ich weiß es endlich! Der [lexicon]Encoder[/lexicon]-Server hängt sich auf.
    Ich habe das "use dedicated [lexicon]encoder[/lexicon] server" beim [lexicon]Afterburner[/lexicon] für Thief jetzt deaktiviert und voilà: es funktioniert.


    Ist dann aber nur mit den 32bit Encodern, statt 64bit und es ist langsamer.


    Hast du bei [lexicon]MagicYUV[/lexicon] eventuell den Adaptive Coding Haken entfernt? Der muss drin bleiben.

    So, jetzt reichts mir langsam mit dem AB, schade nur, dass es keine wirkliche Alternative gibt bisher.
    Wieder mal hat mir der [lexicon]Afterburner[/lexicon] Teile einer Aufnahme zerfetzt.
    Nicht nur, dass ich erst den AVI-Header reparieren musste (obwohl ich die Aufnahme ganz gewöhnlich beendet habe), was Stunden gedauert hat, nein, der AB muss auch noch manchmal mittendrin irgendwelche vergangenen oder zukünftigen Frames aufblitzen lassen, wodurch das Video teils am flackern ist wie sonstwas! X/
    Was soll das denn? Wenn der nicht in der Lage ist vernünftig aufzunehmen, soll er einfach abstürzen, damit könnte ich leben, aber nicht mit sowas.


    Und somit zur Frage: Warum tritt das auf und wie lässt sich das verhindern?

    Es handelt sich um Half-Life. Also ein OpenGL Spiel.
    Hier die Gallerie mit so ziemlich allem, was irgendwie relevant sein könnte.


    Hier noch die [lexicon]MediaInfo[/lexicon] der Ursprungsdatei:


    Man sollte sofort sehen, das dort etwas nicht stimmt. [lexicon]MPC[/lexicon]-HC kann die Datei zwar problemlos abspielen, aber [lexicon]VirtualDub[/lexicon] streckt Arme und Beine von sich und meldet nur, dass der main "movi" Block fehlt. Die [lexicon]Auflösung[/lexicon] ist mir bewusst. Wurde über Nvidia DSR so gewählt, damit ich das Video nicht skalieren muss. Kann auch mit normaler 1080p [lexicon]Auflösung[/lexicon] auftreten und ist demnach davon unabhängig. Ich weiß das 1152p reichen würde, steht über DSR aber nicht zur Auswahl.
    Habe dann den Header einer funktionierenden und identischen Aufnahme rüberkopiert und mit Vdub repariert, wie @De-M-oN es mal in einem Tutorial beschrieben hat.


    Das behebt allerdings die Fehler im Video an sich nicht.
    Hier mal ein Beispiel eines Frames aus dem fehlerhaften Bereich:


    Wie ist das möglich, dass der AB zwei Teile von unterschiedlichen Bildern in einem [lexicon]Frame[/lexicon] speichert?

    Zitat von De-M-oN

    Hast du bei [lexicon]MagicYUV[/lexicon] eventuell den Adaptive Coding Haken entfernt? Der muss drin bleiben.


    Hmm das muss ich am Montag überprüfen, wenn ich wieder daheim bin. Bisher hat es keine Macken gemacht, nur jetzt auf einmal mit dem dedizierten Encoderserver.

    Wie lang war die Aufnahme? Ich rate dir 30min parts zu machen. Länger hab ich und Honki Tonk diesen Bug gehabt:


    http://forums.guru3d.com/showp…?p=5013356&postcount=2016


    edit: ahja also auch bei dir der selbe bug.


    Wie gesagt: Nicht länger als 30min aufnehmen und dann passiert das nicht mehr.


    edit2: Dein anderes Problem ist das dein [lexicon]Half Life[/lexicon] teart.


    Tut der Dosbox renderer übrigens auch. [lexicon]Afterburner[/lexicon] tut nur das aufnehmen was der Renderer macht. Und das [lexicon]Tearing[/lexicon] solltest du eig. beim Spielen auch bemerken.

    Edit: Das Problem mit dem Header hatte ich bisher nur bei OpenGL Spielen, ist aber wahrscheinlich davon unabhängig.
    Wie lang die Aufnahme dafür laufen muss kann ich nicht sagen. Tritt auch nicht immer auf, sondern nur manchmal.
    Hatte auch schon viele Aufnahmen über eine Stunde die einwandfrei waren.


    @De-M-oN
    Anhand der Dateigröße sieht man wahrscheinlich schon, dass die Aufnahme etwas länger ging.
    Ungefähr 80 Minuten. Dann gibt's halt in Zukunft kürzere Aufnahmen.
    Wenn es nur der Header gewesen wäre, könnte ich aber damit leben.
    Das Korrigieren kostet zwar Zeit, zerstört aber kein Videomaterial.


    Aber genau das schafft der [lexicon]Afterburner[/lexicon] ja scheinbar auch.
    [lexicon]Tearing[/lexicon] in Videos? Es ist mir unerklärlich, wie sowas zustande kommt. Die Bilder kommen so aus dem [lexicon]Quellvideo[/lexicon] vom [lexicon]Afterburner[/lexicon].
    Wenn man das Video sich aber anschaut, sieht man dass es nicht nur [lexicon]Tearing[/lexicon] ist, sondern wildes Aufflackern von unterschiedlichen Frames.
    Ich könnte die betreffenden Stellen auch mal kodieren und hochladen, falls man sich darunter noch nichts vorstellen kann?

    Da Empire Earth ein Direct3D Spiel ist und GZDoom OpenGL - jap mit allem.


    Ab wann die Gefahr besteht kann ich nicht sagen, aber ich hatte glaub 45min oder so bei gzdoom gehabt und das wurd mit dem bug geschlossen.
    Aber ich bevorzuge eh 20min eigencuts - ist nur in dem Fall 'ne Ausnahme gewesen. Also es passiert nicht immer - aber ich sage mal ab >30min irgendwann ist mit der Gefahr zu rechnen. Unterhalb passiert nichts.



    Und wie gesagt @Kayten : Dein [lexicon]Half Life[/lexicon] teart. Das hast du auch schon beim Spielen - jede Wette.


    Zumindest seh ich auf deinem Screenshot lediglich [lexicon]Tearing[/lexicon].

    @De-M-oN
    Sicher sieht man darauf nur [lexicon]Tearing[/lexicon], was anderes kann ich ohne Video auch nicht zeigen.
    Aber selbst das [lexicon]Tearing[/lexicon] ist nicht normal. Ich hatte noch nie [lexicon]Tearing[/lexicon] in Videos.
    Schau mal in die Gallerie, auf mindestens einem [lexicon]Frame[/lexicon] sollte man sehen können, dass es kein simples [lexicon]Tearing[/lexicon] ist.


    Edit: Auf dem hier.

    Probier ma [lexicon]vsync[/lexicon] / Framelimiter auf 60fps (falls framelimiter vorzugsweise einer vom Spiel falls vorhanden, ansonsten RTSS)
    Wird es mit anderem Programm denn anders aufgenommen?



    Wenn der Renderer selber tearen sollte, liegts aber halt daran. Dosbox via vesa_nolfb hat auch [lexicon]tearing[/lexicon] und entsprechend wird das auch aufgenommen.


    Triple Buffering in Spiel (falls es option gibt) unbedingt anschalten


    und ganz wichtig ist, das Triple Buffering auch im Treiber aktiviert ist - bei Nvidia Systemsteuerung als Dreifach Puffer zu finden - ist standardmäßig aus absolut nicht nachvollziehbaren Gründen aus.

    Das [lexicon]Tearing[/lexicon] ist nur ein Nebeneffekt, nicht das eigentliche Problem.
    Und da es nur sporadisch auftritt, kann ich auch nicht sagen, ob es mit [lexicon]Dxtory[/lexicon] besser wäre.
    Abgesehen davon, dass es ein OpenGL Spiel ist und [lexicon]Dxtory[/lexicon] das immer noch nicht so gut packt wie der AB.
    Wenn ich mal Testaufnahmen mit [lexicon]Dxtory[/lexicon] gemacht habe, waren die immer einwandrei, bis auf Performance Probleme natürlich.
    Ich könnte die selbe Stelle im Spiel jetzt noch mal aufnehmen und es würde wahrscheinlich nicht auftreten.


    Hier mal ein Beispielvideo dazu. Verarbeitet gerade noch, aber das Problem sollte deutlich erkennbar sein. Und ja, das kommt nicht vom Kodieren, das war bereits im Rohvideo so!


    Triple Buffering ist aktiviert im Treiber, Half-Life selbst bietet da keine Option für.
    Wobei ich bisher auch keine Argumente für Triple Buffering gefunden habe, wenn man [lexicon]VSync[/lexicon] nicht nutzt.

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden