Hochauflösende Videos von 3DMark und anderen Demos oder Benchmarks.

• Im vorigen Artikel ging es darum wie man 16k und 64x DSR überhaupt erreichen kann. Hier ist es die nächste Stufe: Wie erstellt man Videos in solchen Auflösungen.
  Hier wird gleich ein ganzer Schwung weiterer Tools und Tricks nötig.



• Videos:
  Bandicam und Playclaw können beide Videos aufzeichnen. Bei 8k ist es aber ein Glücksspiel, ob es funktioniert, ob die Kodierung hinterherkommt oder ob man überhaupt mit 5 FPS aufzeichnen kann. Es lohnt sich aber zu probieren, je nach Rechner und Szenenkomplexität sind bei 8k bis 20 fps drin. Bei mehr als 8k klappt es als Video statt Screenshots bisher nur in einzelnen Fällen. Die beste Videoqualität bei niedriger CPU Last bietet Bandicam mit der Einstellung "MPEG1" und dem Qualitätsregler auf Maximum. Für Audio ist PCM passend. Die Datenmenge ist verschwindend klein und die CPU Ressourcen werden woanders gebraucht.
  
  Wer einen halbwegs aktuellen Rechner mit etwa 4 GHz hat, kann so flüssig 4k mit 30 FPS Aufzeichnen. Mit den neuesten CPUs funktioniert 4k mit 60 fps.
  Von NVEnc muss ich abraten. Es passieren selbst bei 4k zu häufig Kodierfehler. Die Aufnahme bricht mit einer seltsamen Meldung ab, welche auf NVEnc zurückgeführt werden kann. Das geht, je nach Treiber und Kartenkombination, so weit dass Windows 10 mit einem Blue-Screen abstürzt. Die Bildqualität von NVEnc ist bei RTX-Generation Karten gut, kann aber nicht mit der MPEG1 Variante von BandiCam mithalten.


• Screenshots:
  Sobald man über 8k geht, wird es mit Screenshots schwieriger. Drei Varianten sind zurzeit funktionsfähig: Bandicam, Playclaw und "Druck"-Taste + MSPAINT. Fraps wird seit einigen Jahren nicht mehr weiterentwickelt und funktioniert nicht mehr gut. Bandicam und Playclaw bieten beide reichlich Optionen. Mal ist das eine Programm besser als das andere ohne dass man eine klare Regel erkennt. Ich persönlich bevorzuge Bandicam.
  Meine Einstellungen für Screenshots sieht im Normalfall so aus. Der seltsam aussehende Hotkey ist ö da kein Spiel ö verwendet.
  
  Beide Programme teilen sich aber auch die Limitierungen:
  Bandicam und Playclaw können bei über 8k ihre Screenshots nicht immer im "Spiel-Modus" erstellen. Sie stürzen einfach ab, reisen das Spiel mit und blockieren mitunter Windows so, dass man keinen Desktop oder Mauszeiger sieht, obwohl der Rechner noch läuft. Ich vermute als Ursache eine zu hohe Auslastung des Videospeichers. Die Lösung ist die "Desktop-Screenshot" Methode zu verwenden, welche an sich gar nicht für Spiele vorgesehen ist: Man stellt, vor dem Start des Spieles, den Windows Desktop auf die gewünschte Auflösung. Dafür muss das Spiel nicht unbedingt auf "Windowed-Fullscreen" eingestellt sein. Der FPS Counter verschwindet, aber es funktioniert besser. Und im Fall eines Absturzes von Bandicam oder Playclaw stürzt das Spiel nicht mit ab.
  
  Screenshotformat:
  In der Theorie wäre .PNG das beste Format. Verlustfrei mit guter Komprimierung. Aber bei 8k .PNG benötigen Bandicam und Playclaw oft über zehn Sekunden einen Screenshot zu speichern. Manche Spiele frieren ein und warten bis der Screenhsot gespeichert ist oder stürzen ab. Die meisten ruckeln nur kurz während im Hintergrund gespeichert wird. Bei 16k kann es über eine Minute dauern bis ein .PNG Screenshot gespeichert ist.
  Daher ist im Normalfall .JPG besser, da es schneller kodiert wird. Die .JPG Datei ist bei 8k auf schnellen Rechnern in weniger als einer Sekunde gespeichert, bei 16k ab drei Sekunden bis über zehn Sekunden. Dabei macht auch die Komplexität der Szene einen großen Unterschied, wie lange das Speichern dauert. Ein episch leerer Weltraum mit Wolken wie bei Homeworld 2 macht weniger Probleme als komplexe Szenen mit vielen Details aus aktuelleren Spielen. Playclaw und Bandicam sind sehr absturzfreudig, wenn es darum geht .JPG Screenshots in diesen Auflösungen zu erstellen.
  Wenn schneller als nur alle 5 Sekunden und mehr Stabilität gewünscht ist, muss man diese als .BMP speichern. Die Entwickler von Bandicam und Playclaw haben seit 2015, auf meinen Wunsch hin, .BMP als Speicherformat. Bei 16k (15360x8640) bedeutet das 388 MB für jeden Screenshot. Man sollte also reichlich schnellen SSD Platz haben.
  Falls alles versagt gibt immer noch die einfachste Variante die "Druck" Taste zu betätigen, dann Microsoft Paint (oder jedes beliebige andere Malprogramm) zu starten und das Bild mit STRG+V einzufügen. Bei Unigine Heaven in 12k auf der Titan 1 funktionierte nur diese Methode für Screenshots während Bandicam, Playclaw und Fraps versagten.


• Und wie erreicht man 60 fps oder 120 fps?
  Anstatt zu versuchen, den Benchmark 120 fps in dieser Auflösung laufen zu lassen und aufzunehmen, was in keiner Hardwarekonstellation möglich ist, ist es der Trick das Programm auszubremsen.
  Am besten fuktioniert hierfür CheatEngine. Jedes andere Programm, welches ich vor Cheatengine ausprobiert hatte, brachte schlechtere Ergebnisse.
  Cheatengine ist auch ein Beispiel für guten Support. Bis Cheatengine 6.2 gab es das Limit dass der Speedhack Wert nur zwei Nachommastellen hat und keine Brüche akzeptiert. Im Fall eines Faktors von 1/30, um in Bandicam mit 2 fps Aufzunehmen und 60 fps als Resultat zu bekommen, war der Speedhack Wert vor dem Fix 0,03 statt 0,033333... gestellt. Das machte es schwieriger bestimmte Verlangsamungen zu erreichen und Audio zu synchronisieren.
  Dafür sind keine komplizierten Scans oder ähnliches nötig, es reicht das intere LUA Scripting zusammen mit Funktion speedhack_setSpeed(). Nach dem Start wird "Show Cheat Table Lua Script" im Menü "Table" geöffnet.
  
  Die bequemste Variante ist es einen Hotkey zu definieren um ein beliebiges Programm mit den gewünschten Faktor ausbremsen. Mit einem Timer sorgt man dafür, dass Cheatengine keine unnötige Systemlast erzeugt. Mit "Execute script" wird es aktiviert. Hier ist das Beispiel für 3DMark Night Raid.
  
  "N" ist für normale Geschwindigkeit, "M" bremst um den Faktor 60 aus, und "K" um den Faktor 360. Faktor 360 bedeutet, dass Night Raid statt knapp 4 Minuten über 24 Stunden läuft, während Bandicam alle 3 Sekunden eine 388 MB große .BMP Datei schreibt. Eine schnellere Screenshotfolge, wie Verlangsamung um Faktor 300 und alle 2,5 Sekunden ein Screenshot, sorgt für inkonsistentes Timing und sichtbare Mikroruckler im Video. Für das die etwa 13 Minuten vom 3DMark06 Demo waren, pro Aufnahmeversuch, mehr als drei Tage zu veranschlagen.
  Für die 16k Aufnahme war noch ein weiterer Task nötig, denn über 90'000 Screenshots von 3DMark 06 mit je 388 MB sind über 30 Terabyte an Daten, und so viel Platz habe ich nicht. Ein paralleler, auf einem anderen Computer laufenden, Task sorgte während der Aufnahme dafür, dass die .BMP Dateien mit Convert aus dem ImageMagick Paket zu .JPG konvertiert und auf einem anderen Computer gespeichert wurden. Je nachdem wie viel Rechenzeit am aufnehmenden Rechner noch übrig ist, kann es auch dort laufen und muss nicht ausgelagert werden.
  Der Task ist ein im Loop laufendes .cmd script, hier im Beispiel zum download ist es auf meine Konstellation angepasst, aber mit etwas Programmiererfahrung kann dies leicht angepasst werden:
  

  :: This batch runs in a loop to convert incoming .BMP files to .jpgs.
  
  :: Its purpose is to save space, and save the .jpg files somewhere else than the busy source.
  :: The test1.txt / test2.txt / test3.txt trick allows a sort of multithreading from a batch file.
  :: It allows to start the first in foreground, the second in background and the third in background.
  :: Needed since Imagemagik-Convert is single-threaded and therefore too slow to convert fast enough to avoid the source running out of space.
  ::
  :: (c) 2019 Joachim Otahal, jou@gmx.net and youtube@joumxyzptlk.de
  
  @echo off
  
  :start
  :: Destination directory
  mkdir E:\tmp\Bandicam 2>NUL
  :: Source directory, in my case a mapped network drive from the recording computer.
  :: This moves all movable source files out of the way. The purpose is to avoid access conflicts while the main computer is still capturing.
  mkdir b:\temp 2>NUL
  move B:\*.bmp b:\temp 2>NUL
  
  :: Process the .BMPs
  for %%f in (b:\temp\*.bmp) do (
         echo %%f
  :: Part of "Multithread" control.
         if not exist %temp%\test1.txt if not exist %temp%\test2.txt if not exist %temp%\test3.txt copy NUL %temp%\test1.txt > NUL
  
  :: the actual conversion in up to three threads
         if exist %temp%\test1.txt "C:\Program Files\ImageMagick-7.0.8-Q16\convert.exe" "b:\temp\%%~nf.bmp" -quality 92 "e:\tmp\Bandicam\%%~nf.jpg"       
         if exist %temp%\test2.txt start "" /MIN "C:\Program Files\ImageMagick-7.0.8-Q16\convert.exe" "b:\temp\%%~nf.bmp" -quality 92 "e:\tmp\Bandicam\%%~nf.jpg"
         if exist %temp%\test3.txt start "" /MIN "C:\Program Files\ImageMagick-7.0.8-Q16\convert.exe" "b:\temp\%%~nf.bmp" -quality 92 "e:\tmp\Bandicam\%%~nf.jpg"
  
  :: Part of "Multithread" control.
         if exist %temp%\test3.txt del %temp%\test3.txt
         if exist %temp%\test2.txt ren %temp%\test2.txt test3.txt
         if exist %temp%\test1.txt ren %temp%\test1.txt test2.txt
  )
  :: Clean up temp on source after conversion.
  rd /s /q b:\temp 2>NUL
  :: This avoids racing the batch at full speed if there is nothing to do.
  ping -n 2 127.0.0.1 >NUL
  goto :start

  
  
  Beim Final Fantasy XV Benchmark in 8k war es einfacher da bei 8k die Screenshots als .JPG problemlos funktionieren. Es brauchte aber fünf Anläufe bis eine passende Kombination von Verlangsamung, in diesem Fall 1/180, und Screenshothäufigkeit, in diesem Fall alle 1,5 Sekunden, gefunden war um ein flüssiges Ergebnis ohne Mikroruckler erhalten. Eine Verlangsamung auf 1/240 mit einer Screenshotfrequenz 2 Sekunden brachte nicht das gewünschte Ergebnis.
  Ein Nachteil ist, dass zwei Aufnahmen gemacht werden müssen. Audio läuft nicht synchron zur Verlangsamung. Dies muss in einem getrennten Druchlauf mit niedriger Auflösung in normaler Geschwindigkeit aufgenommen werden um es nacher mit dem Hochauflösenden Video zu mischen. Somit kann auf kein normales Gameplay aufgenommen werden, sondern immer nue selbstlaufende Demos oder ein aufgenommenes Gameplay, welches von Spielengine abgespielt wird.


• Video encoden:
  Wenn man das Glück hat und direkt ein 8k Video aufnehmen konnte, kann dieses mit Virtualdub, ffmpeg, x264, x265, Avidemux oder Handbrake umkodiert werden. Zu der Zeit als ich 4k, 6k und 8k Videos erstellt habe konnte keines der bekannten Programme damit umgehen. Somit bin ich es gewohnt die genannten zu nutzen und kann nicht vorhersagen wie Sony Vegas, Adobe, Magix und wie sie alle heißen mit 8k umgehen.
  Im Falle von Screenshots müssen diese passend umbenannt werden. Häufig wird das Schema PROGRAMMNAME-DATUM-UHRZEIT genutzt.
  
  Die meisten Videoeditoren und Encoder wollen aber eine fortlaufende Nummer im Dateinamen, idealerweise mit führenden Nullen. Bulk Rename Utility bringt die Dateinamen am einfachsten auf Vordermann so dass sie dem Schema DATEINAME.LAUFENDENUMMER.jpg entsprechen.
  
  Bei Virtualdub kann man den ersten Screenshot via "Drag und Drop" öffnen, Virtualdub erkennt automatisch die fortlaufende Nummer. Man muss noch die Framerate einstellen, eventuelle Filter und Encodingeinstellungen machen und schon kann man encoden.
  Ffmpeg kann auch Bildfolgen verarbeiten. Eine Beispielkommandozeile für eine fünfstellige Bildsequenz:
  

  ffmpeg.exe -framerate 120 -i "E:\tmp\Aufnahme\screenshot.%05d.jpg" -vcodec libx264 -preset:v veryslow -crf 20 E:\tmp\Video.mkv

  
  Das encodieren von hochauflösenden Videos braucht Unmengen von Hauptspeicher. Für 8k sollte der Rechner 32 GB RAM haben. Für 12k sollte der Rechner 64 GB haben. Fü 16k sind mehr als 128 GB nötig wie ich bei Homeworld 2 feststellen musste. Bei 16k wird der Hauptspeicher in großen zusammenhängenden Stücken alloziert. Aufgrund der Fragmentierung des Hauptspeichers läft es daher erst mit 160 GB. Gebrauchte Server mit 160 GB oder 192 GB RAM gibt es recht günstig.
  


• Fazit:
  Es steckt viel Aufwand dahinter solche Videos zu erstellen. Wer sich darauf einlässt begibt sich auf ein Terrain wo nicht viele sind. Bei Problemen kann oft keine Suchmaschine helfen. Man muss bereit sein für Werkzeuge neue Funktionen zu erfragen oder auch extra zu sponsorn damit es funktioniert.

Legal Stuff: This is a private homepage. All "TM" mentioned here belong to their owners and not me. Anyone offended contact me.