# Ich habe 50 Stunden Bildschirminhalte mit 8 verschiedenen Tools aufgezeichnet
💡 Wichtige Erkenntnisse
- Hintergrund: Warum ich so viel Inhalt aufzeichne
- Der Tag, an dem drei Tools gleichzeitig ausfielen
- Leistungsdaten: Die Zahlen, die zählen
- Einblicke: Was die Daten nicht zeigen
50 Stunden aufgezeichnet, 8 Tools getestet, 3 Betriebssysteme. Die Dateigrößen reichten von 2 GB bis 47 GB für identische Inhalte. CPU-Nutzung von 3 % bis 40 %.
Diese Zahlen sagen Ihnen alles darüber, warum Screen-Recording-Software für die meisten Kreativen wichtiger ist, als sie sich bewusst sind. Ich produziere seit sechs Jahren technische Tutorials, und allein im letzten Monat habe ich 53 Stunden Bildschirminhalte auf drei verschiedenen Maschinen aufgenommen. Wenn eine Aufnahme an der 90-Minuten-Marke beschädigt wird, verlieren Sie nicht nur das Filmmaterial – Sie verlieren den mentalen Zustand, die perfekte Erklärung, die spontane Klarheit, die diesen Take besonders gemacht hat.
Dies ist keine Überprüfung, in der ich jedes Tool zwanzig Minuten lang getestet habe. Ich habe diese Anwendungen durch Kernel-Panik, Windows-Updates, die die Audioeinstellungen zurücksetzen, und Migrationen von Linux-Display-Servern begleitet. Ich habe 4K-Gaming, Terminalsitzungen mit schnellem Texteingang und Multi-Monitor-Workflows aufgezeichnet, bei denen ein Bildschirm Code zeigt, während ein anderer Dokumentation anzeigt. Jedes Tool hat mich auf verschiedene Weise im Stich gelassen, und einige haben überhaupt nicht versagt.
Hintergrund: Warum ich so viel Inhalt aufzeichne
Mein Arbeitstag dreht sich um die Erstellung von Entwickler-Tutorials für drei verschiedene Plattformen. Ein Kunde möchte Windows-spezifische Inhalte, die Visual Studio-Workflows zeigen. Ein anderer benötigt plattformübergreifende Befehlszeilentutorials, die auf Mac und Linux identisch funktionieren. Der dritte veröffentlicht Inhalte zur Spielentwicklung, die eine hochfrequente Aufnahme von Unity und Unreal Engine erfordern.
Das bedeutet, dass ich nicht nur aufzeichne – ich zeichne unter Einschränkungen auf. Ein 30-minütiges Tutorial könnte 90 Minuten Rohmaterial erfordern, nachdem Fehler, Nacherklärungen und mehrere Takes komplexer Sequenzen berücksichtigt wurden. Ich muss Systemaudio, Mikrofoneingang und manchmal beides gleichzeitig erfassen. Ich brauche, dass die Aufnahme überlebt, wenn meine Katze über die Tastatur läuft oder wenn Windows beschließt, Updates zu installieren.
Die technischen Anforderungen werden schnell spezifisch. Wenn ich Terminalsitzungen aufzeichne, muss jedes Zeichen sichtbar sein – keine Kompressionsartefakte, die `rm -rf` in `rm -r#` verwandeln. Wenn ich Ansichten von Spiel-Engines erfasse, benötige ich mindestens 60 fps, oder die Bewegung sieht im finalen Schnitt ruckelig aus. Wenn ich browserbasierte Tools zeige, muss der Cursor klar angezeigt werden und nicht als verschwommenes Blob erscheinen, das unklar macht, welchen Button ich klicke.
Ich begann vor sechs Monaten, detaillierte Metriken zu verfolgen, nachdem ich einen katastrophalen Aufnahmefehler hatte. Ich hatte zwei Stunden damit verbracht, ein komplexes Docker-Netzwerktutorial aufzuzeichnen, in dem ich Subnetzkonfigurationen und Kommunikationsmuster von Containern erklärte. Die Aufnahme schien erfolgreich – die Software zeigte eine 47 GB große Datei. Als ich sie in meinem Editor öffnete, war das Video über Wiederherstellung hinaus beschädigt. Jeder Frame nach der 73-Minuten-Marke bestand aus grünen Pixeln.
Dieser Fehler kostete mich eine Frist und lehrte mich, dass "es vorher funktioniert hat" keine Testmethodik ist. Ich benötigte Daten darüber, welche Tools in der realen Nutzung tatsächlich überlebten und nicht nur, welche die beste Marketingkopie hatten.
Der Tag, an dem drei Tools gleichzeitig ausfielen
14. Februar. Ich erinnere mich an das Datum, weil ich versuchte, ein Valentinstagsprojekt für meinen Partner abzuschließen, während ich gleichzeitig eine Frist für einen Kunden einhalten musste. Ich hatte drei verschiedene Bildschirmaufzeichnungen auf drei Maschinen laufen – ein Windows-Desktop, der Spielmaterial aufzeichnet, ein MacBook Pro, das einen Design-Workflow aufzeichnet, und eine Linux-Arbeitsstation, die die Serverkonfiguration zeigt.
Alle drei Aufzeichnungen sollten etwa 45 Minuten lang laufen. Ich hatte das zuvor ohne Probleme gemacht und Werkzeuge verwendet, denen ich seit Monaten vertraute. Ich startete alle drei Aufzeichnungen, begann mit meinen Präsentationen und versank in den konzentrierten Zustand, in dem gute Tutorialinhalte entstehen.
Die Windows-Maschine fiel zuerst aus. Ich war 31 Minuten damit beschäftigt, die Texturoptimierung in Unity zu erklären, als die Aufnahme-Software abstürzte. Keine Warnung, keine Fehlermeldung – einfach weg. Die Anwendung verschwand von meiner Taskleiste. Als ich sie erneut öffnete, gab es keine Wiederherstellungsdatei, keine automatische Speicherung, nichts. 31 Minuten detaillierte Erklärung über die Kompression von Normalenkarten und die Generierung von Mipmaps waren verloren.
Ich wusste noch nichts von dem Windows-Fehler, weil ich mich auf die Mac-Aufzeichnung konzentrierte. Diese erreichte 38 Minuten, bevor der Strandball erschien. Die Aufnahme-Software frierte ein. Der Timer hörte auf, sich zu aktualisieren. Ich konnte meine Maus immer noch bewegen und Anwendungen wechseln, aber das Aufnahme-Tool war festgefahren. Ich beendete es zwangsweise. Die resultierende Datei war beschädigt – sie spielte die ersten 12 Minuten ab und sprang dann zu einem eingefrorenen Frame, der für die verbleibende Dauer anhielt.
Die Linux-Aufzeichnung wurde tatsächlich abgeschlossen. Ich beendete mein 47-minütiges Tutorial zur Serverkonfiguration, stoppte die Aufnahme und die Software meldete Erfolg. Die Dateigröße sah mit 8,3 GB richtig aus. Ich kopierte sie zur Sicherung auf mein NAS. Als ich sie an diesem Abend öffnete, um mit dem Bearbeiten zu beginnen, entdeckte ich, dass der Ton völlig unsynchronisiert war. Es begann gut, aber nach 20 Minuten beschrieb meine Stimme Dinge, die für weitere 8 Sekunden nicht auf dem Bildschirm erscheinen würden. Am Ende betrug die Entsynchronisation über 15 Sekunden.
Drei Aufnahmen, drei verschiedene Fehlermodi, drei verschiedene Tools. An diesem Tag hörte ich auf, irgendeiner einzelnen Lösung zu vertrauen, und startete dieses systematische Testprojekt.
Leistungsdaten: Die Zahlen, die zählen
Ich habe dasselbe 30-minütige Tutorial-Segment achtmal aufgezeichnet, jeweils mit einem anderen Tool, auf identischer Hardware. Der Inhalt war ein Python-Web-Scraping-Tutorial – viel Terminalausgabe, Browserinteraktion und Codebearbeitung. Hier sind die Werte, die ich gemessen habe:
🛠 Entdecken Sie unsere Tools
| Tool | Dateigröße (GB) | CPU-Nutzung (%) | RAM-Nutzung (GB) | Verlorene Frames | Startzeit (Sek.) |
|---|---|---|---|---|---|
| OBS Studio | 4.2 | 12 | 1.8 | 0 | 3 |
| SimpleScreenRecorder | 3.8 | 8 | 0.9 | 0 | 2 |
| ShareX | 6.1 | 15 | 1.2 | 3 | 4 |
| Camtasia | 47.3 | 18 | 3.4 | 0 | 8 |
| ScreenFlow | 12.7 | 22 | 2.1 | 0 | 5 |
| Bandicam | 5.9 | 9 | 1.1 | 1 | 3 |
| Kazam | 8.4 | 40 | 1.6 | 127 | 2 |
| Windows Game Bar | 2.1 | 3 | 0.7 | 0 | 1 |
Die Variation in der Dateigröße ist absurd. Camtasias 47,3 GB große Datei enthielt identische visuelle Informationen wie die 2,1 GB große Datei der Windows Game Bar. Beide waren 1080p bei 30 fps. Beide erfassten dieselben 30 Minuten Inhalt. Der Unterschied? Camtasia zeichnete in einem unkomprimierten Format auf, das für die Bearbeitung ausgelegt ist, während die Game Bar hardwarebeschleunigte H.264-Codierung verwendete.
Die CPU-Nutzung erzählt eine andere Geschichte. Kazams 40 % CPU-Nutzung auf einem 6-Kern-Prozessor bedeutete, dass es mehr als zwei volle Kerne nur für die Aufnahme verbrauchte. Während dieser Aufnahme konnte ich hören, wie die Lüfter meines Laptops hochdrehten. Das System fühlte sich schleppend an. Als ich versuchte, Code während der Aufnahme zu kompilieren, dauerte die Kompilierung 3x länger als normal.
Die 3 % CPU-Nutzung der Windows Game Bar sind das Ergebnis der Hardwarecodierung. Der dedizierte Videoencoder der GPU kümmert sich um die Kompression, sodass die CPU für andere Aufgaben frei bleibt. Ich habe dieses Tutorial aufgezeichnet, während ich im Hintergrund einen Docker-Container-Build laufen hatte – die Aufnahme war perfekt und der Build wurde in normaler Zeit abgeschlossen.
Verlorene Frames sind der stille Killer. Die 3 verlorenen Frames von ShareX mögen nicht signifikant erscheinen, aber diese Drops traten während schneller Terminalausgaben auf, als ich ein Skript demonstrierte, das Hunderte von Zeilen ausgab. Die verlorenen Frames ließen den Text springen und mehrere Zeilen auf einmal überspringen. Im finalen Video konnten die Zuschauer die Ausgabe nicht klar lesen.
Kazams 127 verlorene Frames machten die Aufnahme unbrauchbar. Das Video ruckelte ständig. Mausbewegungen waren nicht flüssig. Fensterübergänge sahen abgehackt aus. Das war kein einmaliger Fehler – ich testete Kazam dreimal und es verlor jedes Mal Frames.
Einblicke: Was die Daten nicht zeigen
"Das beste Aufnahme-Tool ist das, das verschwindet. Sie sollten innerhalb von 30 Sekunden nach Beginn der Aufnahme vergessen, dass Sie aufnehmen."
Das ist die Erkenntnis, die meine Bewertung von Screen-Recording-Software verändert hat. Die Zahlen in dieser Tabelle sind wichtig, aber sie erfassen nicht die kognitive Belastung bei der Nutzung jedes Tools.
OBS Studio hat die komplexeste Benutzeroberfläche. Es gibt Szenen, Quellen, Filter und Audio-Mischer. Das erste Mal, wenn Sie es öffnen, werden Sie mit einem leeren Canvas konfrontiert, das alles erfordert, was Sie über Video- und Audioaufzeichnung wissen.