Aufnahmezerstörung?

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

  • Aufnahmezerstörung?

    Anzeige
    Zuerst Vorwort ;) Ich verfolge aktuell das The Forest LPT von Gronkh und Sarazar und dort sind gleich mehrere Folgen defekt (The Forest schmiert im Multiplayer wohl recht oft ab und dann geht die Folge defekt), also dann kann man die Folge nur auf einem Kanal schauen (beide hatten diese Probleme) bzw. nur unvollständig.
    Gronkh erzählte auch bisschen von seinen Rettungsversuchen (Header, Hexeditor usw.) und zeigte wie das Video nach den Rettungsversuchen wild rumspringt, das Bild gestört ist und halt viele Frames verloren sind. Sarazar meinte die Tage, dass sie Bandicam benutzen. Allerdings habe ich auch schon bei DXTory von sowas gehört und sicherlich auch bei anderen Aufnahmeprogrammen. Ich persönlich finde es ja ein absolutes No-Go, dass eine teilweise vorhandene Aufnahme einfach komplett zerstört wird.

    Vorwort Ende :D Nun zum Knackpunkt: Wie kann es überhaupt sein, dass ein Problem beim Spiel zu einem Problem der Aufnahme führt? Würde mich einfach mal vom technischen Standpunkt interessieren.
    Klar gibt's da das Hooking, so dass ich mir vorstellen kann, dass ein Programmcrash erstmal ein Problem darstellen kann und was auch unterschiedlich (technisch und qualitativ) gelöst ist. ABER:
    - Warum gibt's da keine Lösungen z.B. wie bei Chrome wo ein crashendes Plugin/ein crashener Tab nicht gleich ganz Chrome zum Absturz bringt?
    - Warum sind die Videodateien denn unrettbar zerstört? Hab mal gehört die werden gelöscht (dann können logischerweise Teile überschrieben werden) - dann wäre aber die Frage warum? Die sind doch schon auf der Festplatte und bis zum Zeitpunkt des Problems korrekt abgespeichert, also warum werden sie gelöscht?
    Oder wenn nicht gelöscht aber defekt dann warum ist auch schon der abgespeicherte Teil defekt? Zumal bei Stream-geeigneten Formaten ein Dateiabbruch ja ohnehin ziemlich egal ist.
    - Gibt's Aufnahmeprogramme die das ganze vernünftig lösen und bei denen ein Verlust auch bei Spielabsturz sehr unwahrscheinlich ist?
    YouTube-Channel Twitch siehe Profil
  • MarelpeLP schrieb:

    Vorwort Ende Nun zum Knackpunkt: Wie kann es überhaupt sein, dass ein Problem beim Spiel zu einem Problem der Aufnahme führt? Würde mich einfach mal vom technischen Standpunkt interessieren.


    Spiele werden aus Performancetechnischen Gründen gehookt. Sprich das Aufnahmeprogramm hakt sich in die Engine des Spieles ein um im Speicher des Spieles die berechneten (gerenderten) Frames rauszuholen. Dies kann auf jeder Darstellungsfläche angewendet werden, wenn nötig. z.B. Direct3D, OpenGL, DirectDraw, Surface, Overlay, Glide, etc.
    Es werden also aus dem sogenanten Buffern (Front-, Backbackbuffern) der jeweiligen Darstellungsengine die berechneten Bilder des Spieles direkt ohne Umwege im Rohzustand an einen Encoder geschickt.
    Den Encoder betreibt das Aufnahmeprogramm dann. Das Aufnahmeprogramm wirkt auf die Rohdaten mit Filter etc. ein bzw. schickt sie an den Encoder direkt ohne Filter. Der Encoder encodiert diese Bilder in den Format den man angegeben hat im Aufnahmeprogramm. z.B. x264, NVEnc, QVS, UT Video, etc pp.

    Bricht das Spiel ab, gibt es Fehler beim Hooking. Mit anderen Worten: Das Aufnahmeprogramm versucht den Speicher des Spieles auszulesen und zu encodieren, obwohl das Spiel gar nicht mehr als Prozess arbeitet.
    Es kann aber auch sein das Aufnahmeprogramm und Enginetyp des Spieles nicht passen oder gar der Encoder mit dem Aufnahmeprogramm nicht funktioniert. Entsprechend kann der gesamte Verlauf gestört werden und es gibt defekte Videodatein.
    Mal gibt es dann Headerfehler, da viele Aufnahmeprogramme den Header erst zum Schluss schreiben, und mal gibt es diverse Hooking bzw. Codecfehler.

    Wie das Aufnahmeprogramm sich in die Engine des Spieles hooken tut ist dabei auch entscheidend. Nicht jeder Spielcode kann gehookt werden. Daher nutzen richtige Let's Player auch mehrere Aufnahmeprogramme, statt nur sich auf ein einziges zu verlassen.

    Eine Aufnahme die wärend der Aufnahme aus welchen Gründen auch immer abgebrochen wird durch ein Fehler, kann zu defekten Videos führen. Dieses Risiko besteht bei jedem Aufnahmeprogramm das es gibt. Egal welches.


    Fehlinformationen die in einer kaputten Videodatei geschrieben werden können sind z.B:
    • Defekter Header -> Lässt sich unter Umständen mit einem Hexeditor retten, da Header sich bei gleicher Aufnahme in der Regel immer gleichen hat man hier eine Referenzdatei.
    • Defekte Streams -> Lassen sich nicht mehr retten, da die Kodierung der Streams wärend der Aufnahme falsche Werte geschrieben hat und dazu vllt auch noch komprimiert hat. Dies kann man nicht retten, da es bei einem Kompressionscodec wie die Nadel im Heuhaufen ist die Bytes im Speicher mit einen Hexeditor zu reparieren. Meist nimmt man neu auf.
      Wenn defekte Streams enthalten sind und man kann sie noch abspielen, dann gibt es gerne mal sehr kuriose Darstellungen des Bildes. Bildverzerrungen, [lexicon]GOP[/lexicon] / [lexicon]Frame[/lexicon] Zerstörung (Lücken = Sprunghaftes Verhalten), Farbfehler, Flackerndes Bild, usw.

      Dies kann auch Audio betreffen. Da Audio auch nur angezapft wird von Gerät x über Verfahren xy.
      z.B. kann es hier sein das manche Onboard Soundkarten WASAPI nicht richtig vertragen. So kann es zum Fehler führen das die ersten 5 Minuten aufgenommen werden und dann auf einmal wärend der Aufnahme das Gerät gestört wird und es nur noch Stummaudio gibt.
      15 Minuten Audio und davon 5 Minuten Ton und dann alles Stumm.

    Ablauf einer gehookten Aufnahme:

    Spiel --> Hat eine Engine (z.B. Direct3D über DirectX9.0c) --> Spiel lässt über die Grafikkarte + Engine die Bilder berechnen. --> Die Berechneten Bilder liegen nun im Speicher der Engine rum. (Bei Direct3D oftmals im Backbuffer) --> Das Aufnahmeprogramm hookt sich in Spielcode und Engine ein um die berechneten Bilder abzufangen. --> Die Rohbilder (RGB32 meist) werden zum Encoder xy geschickt, der diese dann Encodieren tut. --> Es folgt die Speicherung und Kompression dieser Rohbilder.

    Die Rohbilder die im Backbuffer sich befinden werden im Takt der Bildwiederholfrequenz der Spielengine vorgegben. Dies nennt man dann Ingame FPS.

    Damit ein Encoder im Aufnahmeprogramm nicht massiv viele Rohbilder verarbeiten muss, stellt man sich selbst die Aufnahme FPS ein. Sprich die AufnahmeFPS greift im Takt xy aus dem Backbuffer die Bilder des Spieles ab.

    So ist es unsennig mit mehr FPS aufzunehmen als das Spiel hergibt. ^^

    Und dazu muss ich auch sagen... jeder Header ist anders aufgebaut, je nach dem welcher Codec benutzt wurde um die Streams zu encodieren.


    Stell dir vor du hast ne Nachricht:
    "Hallo Welt"

    Die enkodierst du in:
    "jgiip_deiw"

    Was wäre aber wenn du wärend dieser Enkodierung eine neue Nachricht hast, weil dir jemand den Zettel weggenommen hat (Spielabsturznachstellung)
    Dann bekommst du auf einmal sowas:
    "jgiip,er"

    Du kannst es nicht mehr korrekt Dekodieren, weil dir der entsprechende Schlüssel der dir zur Verfügung steht (Headerinformationen) dich nicht die Nachricht komplett entschlüsseln kann.

    Bei Videos ist das so... das immer ein Block zusammengefasst wird. min. Bestehend aus 16x16 Pixelfelder. Daher ist die kleinste Auflösung egal welches Video immer 16x16, das man hinterher auch Dekodieren und abspielen lassen kann.

    Also nochmal: Streamdefekte lassen sich 0 reparieren, da ein Codec im Kompressionszustand einfach ein Ding der Unmöglichkeit ist. Man kämpft nicht nur mit der Kompression, sondern auch mit Fehlenden Streaminformationen.

    Headers lassen sich unter Umständen reparieren, sofern man richtige Referenzmaterialien hat.


    unkomprimierte Rohvideos die keinen Header haben kann man z.B. mit VirtualDub auch decodieren, sofern man die dazugehörigen Informationen besitzt und angeben kann.
    Angaben sind z.B. dann Farbraum, Anordungen der Reihenfolge der Farbraumparameter wie Y, U und V, bzw. R, G und B. Denn es gibt ja auch noch YUYV oder auch VYUY. Auch gibt es BGR oder halt das bekannte RGB.

    SuperNintendo Emulatoren haben im Speicher wo die Frames im Originalzustand liegen BGR kodierte Pixel.

    Dann muss man Auflösung wissen und FPS des Spieles.

    Auch sollte man wissen wieviele Blöcke / Chunks wahtever zusammengehören, damit aus dem ganzen Informationswirrwarr und den gesamten Angabe die man getätigt hat ein Bild bzw. Video wird.

    Diese Angabe wird auch als Header bezeichnet. Es enthält im Kopf des Videos alle Informationen / Schlüsselwerte die für den Decoder zum dekodieren erforderlich sind.

    MarelpeLP schrieb:

    Ich persönlich finde es ja ein absolutes No-Go, dass eine teilweise vorhandene Aufnahme einfach komplett zerstört wird.


    Hatte ich ja schon gesagt... Berufsrisiko.
    Ich empfehle nicht mehr als 1h aufzunehmen. Niemals mehr. Noch besser wäre wenn man noch weniger macht. z.B. in 15min Takt.
    Dabei halten sich die Komplettverluste in relativ sehr guten Grenzen.

    MarelpeLP schrieb:

    - Gibt's Aufnahmeprogramme die das ganze vernünftig lösen und bei denen ein Verlust auch bei Spielabsturz sehr unwahrscheinlich ist?


    Auch schon genannt... gibt es nicht. Software und gerade Software die mit Software arbeitet haben immer Fehler irgendwo. Kein Programm ist 100% Perfekt von der Programmierung. Das trifft auf Spiele, als auch auf normale Anwendungen zu.

    MarelpeLP schrieb:

    Klar gibt's da das Hooking, so dass ich mir vorstellen kann, dass ein Programmcrash erstmal ein Problem darstellen kann und was auch unterschiedlich (technisch und qualitativ) gelöst ist. ABER:
    - Warum gibt's da keine Lösungen z.B. wie bei Chrome wo ein crashendes Plugin/ein crashener Tab nicht gleich ganz Chrome zum Absturz bringt?


    Ohne das Hooking (Desktopaufnahme), könnte man nicht alle Spielengines aufnehmen. In diesem Falle kann nicht auf spezielle Buffer zugegriffen werden die das Spiel eventuell benötigt und man bekommt als Aufnahme ein schwarzes Bild.

    Und wenn das Spiel aufgenommen werden kann durch eine Desktopaufnahme, dann ist die gesamte Performance weg. Denn Windows arbeitet mit FPS xy, die Spielengine übersteigt die Windows FPS z.B. um 100 FPS und das Aufnahmeprogramm greift auf den Speicher zu wo Windows die Bilder ablegt.

    Bedeutet wenn du aufzeichnest: Du nimmst mit 30FPS auf, das Spiel läuft auf 400FPS und Windows läuft auf 60FPS. Was passiert? Richtig, Die aufgenommene Datei gibt dir das wieder was logisch erscheint und gibt dir das Video total mit FPS Drops wieder.

    Die Performance ist einfach nicht vorhanden. Dies merkt man bei Spielen wo das Spiel sehr schnelle Bild-Bewegungen hat.


    Hooking ist also wichtig, um auf den Bildspeicher der Engine performant die berechneten Bilder die von der Grafikkarte kommen abzugreifen und einen Encoder zu geben.

    Bricht diese Kette auf einmal sind Fehler vorprogrammiert. Die Masse der Aufnahmeprogramme kennen nur Terminierungseffekte der Spielprozesse und können dann die Aufnahme korrekt schließen und fertig schreiben.

    Tritt ein Fehler seitens des Spieles auf was die Grafik betrifft, so betrifft dies auch dem Hookprozess.
  • Die Aufnahme sind nicht wirklich defekt, sondern der Header, also der Kopf der Datei fehlt.
    Und dieser wird erst geschrieben wenn die Aufnahme beendet wird.
    Ist ja auch logisch weil da die länge der Datei und und und drin steht.

    Wenn man mit dem MSI Afterburner aufnimmt und den dedezierten Encoder-Server nutzt, kann man nach einem Absturz des Spiels, das Spiel wieder öffnen und die Aufnahme normal schließen.
    Wenn man Programme wie MSI, DXTory, Bandicam nutzt, kann man die Aufnahmen sehr leicht retten, wenn man einen Codec nutzt der in FFMPEG drin ist, also UT Video, DXTory Codec, Lagarith...
    Wenn man nur mit Avisynth (SSM) und MeGui arbeitet, muss man dank FFMS2 nicht mal die Datei retten, da durch FFMS2 die Aufnahme Indexiert wird und damit die fehlenden Information aus dem Header vorhanden sind.
    Wenn man einen NLE nutzten möchte, erstellt man einfach ein Avisynth Skript mit FFMS2, lädt es dann in VitualDub und speichert die Aufnahme einfach neu ab.
  • MarelpeLP schrieb:

    - Warum sind die Videodateien denn unrettbar zerstört


    Sind sie normalerweise nicht, wenn man verlustfreien Codec und AVI benutzt hat.

    DXTory und Fraps tun normalerweise die Aufnahme noch schließen bei einem Spielcrash. Afterburner nicht immer, kann man aber wie von GelberDrache erwähnt nachholen sofern dedicated encoder server benutzt.

    Ansonsten: Ungeschlossene AVI (fehlender Header, index, keyframes) reparieren
    Aktuelle Projekte/Videos




    Seit etlichen Monaten komplett veraltete Signatur, wie ihr sicherlich schon bemerkt habt. Habe mittlerweile mehr als 4 Projekte, weshalb die Signatur leider momentan gesprengt ist xD
    Notdürftig die Liste was aktuell läuft: Unreal | Complex DooM (LPT) | DooM 2016 | Need For Speed III: Hot Pursuit | Dirt Rally | Dirt 4 | WRC 7
  • Anzeige
    Vielen Dank, insbesondere Sagaras für die ausführliche und gut verständliche Erklärung :)

    Beruhigt mich ja, dass eine unrettbare Situation sehr selten vorkommt.

    Ist das mit der Löschung von Aufnahmen ein Sonderfall, oder mittlerweile durch Updates obsolet? Weil das erschließt sich mir noch nicht... wenn ein Programm beim Speichern abstürzt (und die Aufnahmeprogramme werden ja nicht alles im Arbeitsspeicher halten :D), bleibt ja eigentlich der schon geschriebene Teil auf der Festplatte (mitsamt dem schon vorhandenen Dateisystemeintrag).
    YouTube-Channel Twitch siehe Profil