MSI Afterburner - Kostenlose Alternative zu FRAPS und DxTory!

    Steht auf Framebuffer und Vector 3D. Kann es gerne mal mit Vector 2D probieren, aber warum sollte das etwas ändern?
    Es ist ja nicht so, dass es dauerhaft auftritt. Ganz im Gegenteil, es passiert nur seehr selten, aber häufig genug für mich um den AB nicht mehr nutzen zu wollen.
    Wir sind uns aber schon einig, dass das kein normales Verhalten vom [lexicon]Afterburner[/lexicon] sein sollte, was völlig zufällig auftreten kann, oder? ^^

    Zitat von Kayten

    Wir sind uns aber schon einig, dass das kein normales Verhalten vom [lexicon]Afterburner[/lexicon] sein sollte, was völlig zufällig auftreten kann, oder?


    Ist kein [lexicon]Tearing[/lexicon] auf diese weise, ja.


    Naja wenn dann passiert das ja aber nur mit dem Spiel oder?^^ Also woanders sollte es nicht auftreten xD


    Zitat

    Kann es gerne mal mit Vector 2D probieren, aber warum sollte das etwas ändern?


    Einfach mal die Quickinfo zu den Sachen lesen. Steht jede Option im Quickinfo erklärt und somit auch diese.


    Bei GZDoom 2 (OpenGL 4.4 - kann [lexicon]dxtory[/lexicon] .128 nicht mal hooken, weil zu neu) muss ich zb ebenso vector 2D nehmen, mit Vector 3D sieht es nämlich sonst aus wie hier : http://s14.directupload.net/images/140925/zoyr2n4v.jpg

    Zitat von De-M-oN

    Naja wenn dann passiert das ja aber nur mit dem Spiel oder?^^ Also woanders sollte es nicht auftreten xD


    Oh doch, das hatte ich schon in unterschiedlichen Spielen.


    Half-Life (OpenGL)
    [lexicon]Deus Ex: Human Revolution[/lexicon] (DirectX 11)
    The Binding of Isaac: Rebirth (OpenGL)


    Gerade DX:HR war besonders anfällig dafür. Brauch auch am meisten [lexicon]CPU[/lexicon] Power. Keine Ahnung ob da ein direkter Zusammenhang besteht.


    Bei Desktopaufnahmen ist das übrigens noch nie passiert.

    Wenn es bei mehreren Spielen passiert, wirds nicht an dem Spielrenderer liegen, zumal du es ja sogar API übergreifend hast (Direct3D als auch OpenGL)
    Und dann liegts auch nicht mehr am [lexicon]Afterburner[/lexicon].


    Irgendwas löst es aus das [lexicon]Afterburner[/lexicon] nicht korrekt aufnehmen kann. Vllt irgendwelche erzwungene Anti Aliasing Modis oder was auch immer.

    Zitat von De-M-oN

    Irgendwas löst es aus das [lexicon]Afterburner[/lexicon] nicht korrekt aufnehmen kann. Vllt irgendwelche erzwungene Anti Aliasing Modis oder was auch immer.


    Plötzlich und grundlos? In beiden Szenen passiert noch nicht einmal wirklich etwas.
    Ich schiebe dem [lexicon]Afterburner[/lexicon] so lange die Schuld zu, bis ich es mit [lexicon]Dxtory[/lexicon] reproduzieren kann.
    Was bisher nicht möglich war, da es entweder OpenGL Spiele waren oder es einfach nicht aufgetreten ist im Fall von DX:HR.

    also spieleübergreifend klingt mir weniger nach AB.


    Und OpenGL läuft eig. sowieso einwandfrei. Und mit GZDoom hab ich ständig mit OpenGL zu tun. Ich habe extrem oft mit OpenGL zu tun.



    Nicht reproduzierbar für mich bisher.

    Deine [lexicon]CPU[/lexicon] ist auch weder 6 Jahre alt, noch kommt sie von AMD.
    Ich habe es gerade noch einmal getestet in DX:HR mit jeweils identischen [lexicon]MagicYUV[/lexicon] Einstellungen, 50 FPS, Predict Left.
    Sowohl in [lexicon]Dxtory[/lexicon] als auch im AB keine Probleme beim Spielen an sich.
    Während die Aufnahme von [lexicon]Dxtory[/lexicon] keinerlei Probleme aufzeigt, ist die des Afterburners völlig unbrauchbar.
    Das von mir gezeigte Phänomen tritt dauerhaft in der gesamten Aufnahme auf.
    Für mich deutet das darauf hin, dass der AB nicht damit zurecht kommt, wenn die jeweilige [lexicon]CPU[/lexicon] zu 100% ausgelastet ist bzw. die FPS des Spiels unter die Aufnahme-FPS sinken.

    Gerade ausprobiert, ja passiert auch mit UTVideo.
    Und es ist definitiv abhängig von der [lexicon]CPU[/lexicon] Auslastung, nicht von den FPS des Spiels.
    Sobald die Auslastung auf manchen Kernen auf 100% steigt beginnt das Rumgeflackere.
    Das bei 100% Auslastung auch die FPS meist unter 50 lagen ist nicht relevant bei einer 50 FPS Aufnahme.


    Edit: Ach vergesst es, es passiert auch ohne 100% Auslastung und mit mehr als 50FPS in einer 50FPS Aufnahme.


    Edit2: 100% [lexicon]CPU[/lexicon]-Auslastung auf allen Kernen scheint es zu begünstigen, mehr kann ich aber auch nicht sagen.
    Ich mach mal eine Aufnahme mit HUD des AB, dann kann jemand anderes sich das vielleicht anschauen.


    Edit3: Hier eine Aufnahme von DX:HR mit HUD vom AB, die ebenfalls Probleme macht.

    Wo ich in den letzten Seiten etwas gelesen habe.
    Bei mir hat [lexicon]Afterburner[/lexicon] offenbar auch eine längere Aufnahme gefressen.


    3 1/2 Stunden lang und 512 GB groß, weil man zwischendurch nicht speichern kann...
    Der Header scheint teilweise im Eimer zu sein, die zweite Audiospur wird gar nicht mehr erkannt, obwohl er die eigentlich müsste korrekt aufgezeichnet haben... und bis auf [lexicon]MPC[/lexicon]-HC kann kein Videoprogramm irgendwas mit der Datei anfangen. Selbst die erkannte Audiospur bekomme ich nicht einmal irgendwie extrahiert.


    Zeit verschwendet oder irgendwie doch noch alles rettbar?



    Zitat von Deepstar

    Zeit verschwendet oder irgendwie doch noch alles rettbar?


    Dafür gibt es ein Tutorial von @De-M-oN.
    Ganz bis zum Ende anschauen, wenn du wissen willst, wie du beide Audiospuren retten kannst!
    Sollte er dir am Ende bei [lexicon]Virtualdub[/lexicon] einen Fehler nach der Extrahierung ausgeben, dass er nur 256 Indexblöcke hat, aber mehr braucht, dann schreib mich an, das lässt sich lösen.

    Zitat von Strohi


    Dafür gibt es ein Tutorial von @De-M-oN.
    Ganz bis zum Ende anschauen, wenn du wissen willst, wie du beide Audiospuren retten kannst!
    Sollte er dir am Ende bei [lexicon]Virtualdub[/lexicon] einen Fehler nach der Extrahierung ausgeben, dass er nur 256 Indexblöcke hat, aber mehr braucht, dann schreib mich an, das lässt sich lösen.


    Ah danke schon. War mir mal so, dass es so ein Thread gibt. Habe den aber irgendwie nicht mehr so gefunden und im Tutorial Bereich natürlich nicht reingeschaut...
    Werde ich mich mal dran halten. Muss erstmal den Platz freimachen und dafür mal eine 3 TB [lexicon]Festplatte[/lexicon] mal in Betrieb nehmen, die schon seit Wochen ungenutzt im System schlummert :D.

    @Deepstar Jo, ich hab den mittlerweile als Lesezeichen, weil mir das in letzter Zeit häufiger passiert ist, mit dem Unterschied, dass meine Sessions immer so 4 bis 6 Stunden gingen und dann bis zu 900 GB gerettet werden mussten. Mittlerweile ist mir das aber zu blöd geworden, und ich unterbreche nach so ca. 20 Minuten immer kurz, sodass ich bei kaputten Dateien immer nur einen Part retten muss und mir sogar noch die Schnittarbeit spare. ;)

    Zitat von Deepstar

    Ah danke schon. War mir mal so, dass es so ein Thread gibt. Habe den aber irgendwie nicht mehr so gefunden und im Tutorial Bereich natürlich nicht reingeschaut...
    Werde ich mich mal dran halten. Muss erstmal den Platz freimachen und dafür mal eine 3 TB [lexicon]Festplatte[/lexicon] mal in Betrieb nehmen, die schon seit Wochen ungenutzt im System schlummert :D.


    Noch ein Tipp, da ja 512 GB doch sehr riesig ist:


    Wenn du beim Hexeditor nicht eine neue Datei schreibst, sondern die geöffnete überschreibst, speicherts direkt und somit ohne Wartezeit - er wird dann eventuell selber ein backup machen wollen, aber das kannst ja dann canceln.

    Zitat von De-M-oN

    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.


    Adaptive Coding ist und war aktiviert, aber Thief weigert sich mit dedicated [lexicon]encoder[/lexicon] server aufgenommen zu werden. Einstellungen sind wie bei dir.
    Kanns am Spiel / dem Texture Pack bzw. den erweiterten Grafik Einstellungen liegen? Vorher ging es ohne Anstalten.

    @Vrall
    Dann die für mich interessante Frage:
    Wenn du nun den dedizierten [lexicon]Encoder[/lexicon]-Server wieder aktivierst und im RTSS auf 32-bit umstellst, geht es dann?
    Das sich der [lexicon]Encoder[/lexicon]-Server aufhängt deutet meist auf falsche Einstellungen im RTSS hin.


    @Spieluin
    Hast du versucht ein bestimmtes Spiel aufzunehmen?
    Auch wenn von meinem Verständnis her das Spiel keinen Einfluss auf die Desktopaufnahme haben sollte, so habe ich es ebenfalls bereits bei einem Spiel festgestellt, dass das Bild dem Ton hinterher hing.


    Wenn das bei allen Desktopaufnahmen so ist, weiß ich leider auch nicht wirklich weiter. Was ich testen würde:
    1. Von DirectSound auf WASAPI wechseln oder umgekehrt
    2. HPET zwangsaktivieren


    Wobei du ersteres wahrscheinlich schon probiert hast und letzteres eigentlich nur helfen sollte, wenn wirklich alle Aufnahmen davon betroffen wären.

    Zitat von Kayten

    2. HPET zwangsaktivieren


    Sollte eh grundsätzlich immer an sein. Ist halt dummerweise standardmäßig deaktiviert in Windows - aber windows standardeinstellungen und auch standardeinstellungen in manchen programmen sind halt öfter mal eh fragwürdig ;D


    Auf jeden Fall auch überprüfen ob die Sampleraten der Audiogeräte identisch sind.

    Zitat von Kayten

    @Spieluin
    Hast du versucht ein bestimmtes Spiel aufzunehmen?
    Auch wenn von meinem Verständnis her das Spiel keinen Einfluss auf die Desktopaufnahme haben sollte, so habe ich es ebenfalls bereits bei einem Spiel festgestellt, dass das Bild dem Ton hinterher hing.
    2. HPET zwangsaktivieren


    Also ich habe in Spielen keine Probleme mit Bild und Ton Asynchronität. Am Ende der Desktopaufnahme war die Bildaufnahme ganze 7 Sekunden länger als die Tonaufnahme.
    Und was ist HPET?

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden