Kurz gefasst
Das Wichtigste
- Eine Datei mit 60 Bildern pro Sekunde beweist nicht, dass 60 unterschiedliche Bilder aufgenommen wurden. Bewegung, Ton und Zeitablauf müssen die gesamte Aufnahmekette überstehen.
- Lassen Sie die Seite sagen, wann Aufnahme und Stopp erfolgen. Eine feste Anzahl Sekunden zu warten geht irgendwann schief.
- Ein Rendering, das eine Datei zurückgibt, kann trotzdem falsch sein. Zählen Sie verlorene Bilder und liefern Sie sie mit dem Video aus.
Was das Aufnehmen einer Webseite wirklich bedeutet
Ein Browser ist bereits ein gutes Zeichenwerkzeug. CSS animiert, Canvas malt Bild für Bild, WebGL beherrscht 3D-Szenen und die Web-Audio-API erzeugt Klang. Wer eine Webseite bauen kann, kann den Inhalt eines Videos bauen: eine Erklärung, eine Datenvisualisierung, eine Produktdemo, einen Kanal, der von selbst veröffentlicht.
Die Seite zu laden ist die leichte Hälfte. Die schwere Hälfte besteht darin, das Gesehene aufzuzeichnen, ohne zu verändern, wie der Browser es zeichnet. Die GPU muss beteiligt bleiben, die Bildrate stabil, der Ton synchron, und irgendetwas muss wissen, wann die Seite wirklich fertig ist.
Hilfreich ist außerdem die Erkenntnis, dass sich hinter derselben Suchanfrage zwei verschiedene Aufgaben verbergen. Jemanden beim Klicken durch eine Website aufzunehmen ist Bildschirmaufnahme. Eine Seite zu rendern, die als Video gedacht war, ähnelt eher einer Renderfarm. Pagecorder macht das Zweite.
Warum ein Screencast nicht genügte
Der ältere Screencast-Weg von Puppeteer zeigt den Unterschied zwischen einem aufgezeichneten Browsertest und einer produzierten Videodatei. Er empfängt PNG-Bilder über das Chrome DevTools Protocol, dekodiert deren Base64-Transport in Node.js und leitet sie an einen separaten FFmpeg-Prozess weiter. Dieser Rekorder schaltet Ton ausdrücklich ab und verwendet VP9-Software-Encoding. Eine per GPU gerenderte Seite macht aus dieser Bildübertragung noch keine hardwarebeschleunigte Aufnahme ohne Kopiervorgänge.
Die FPS-Einstellung bestimmt den Zeitablauf der Ausgabedatei. Der Rekorder wiederholt aufgenommene Bilder, um die Abstände zwischen eintreffenden Frames zu füllen. Eine als 60 FPS ausgewiesene Datei kann deshalb weniger als 60 unterschiedliche Aufnahmen pro Sekunde enthalten: Bildwiederholungen holen keine verpasste Bewegung zurück. MediaRecorder oder canvas.captureStream ermöglichen Aufnahmen innerhalb der Seite, doch auch dort brauchen gewöhnliches HTML, mehrere Canvas-Elemente und Ton eine durchdachte gemeinsame Erfassung.
Pagecorder wurde für die vollständige Aufnahme entwickelt: GPU-Rendering, native Bildschirm- und Tonaufnahme mit 60 Bildern pro Sekunde und ein MP4 über eine API. Die Seite steuert Start und Ende. Aufträge können eine gebündelte Seite samt Ressourcen verwenden; das Ergebnis enthält Angaben zu verlorenen Frames, HTTP-Fehler und Konsolenmeldungen. Das sind Aufnahmeanforderungen, keine Extras, die ein anderes Dateiformat bereitstellt.
- Die Bewegung erfassen, nicht nur die gewünschte Bildrate in die Metadaten schreiben.
- Browser-Rendering, Video-Encoding und Tonsynchronisation zusammenbringen.
- Fehlende Frames und Seitenfehler zusammen mit dem fertigen Video melden.
Puppeteer hat inzwischen eine separate Page.record-API mit Audio-Optionen ergänzt. Die genannten Grenzen betreffen den älteren PNG-zu-FFmpeg-Screencast, nicht jede heutige Aufnahmemethode. Eine API-Option allein belegt keine gleichwertige Aufnahmequalität oder Leistung.
Lassen Sie die Seite den Start bestimmen
Ein Rekorder kann nicht erraten, wann Ihre Animation bereit ist. Ein ruhiges Netzwerk heißt nicht, dass die Schriften sitzen, die Daten im Worker fertig geladen sind oder die Animation begonnen hat. Fünf Sekunden nach dem Laden zu starten behebt das nicht, es verschiebt das Problem nur dorthin, wo es weniger auffällt.
Pagecorder bietet der Seite einen Aufruf zum Starten und Stoppen der Aufnahme, sobald sie bereit ist. Die optionalen Aufrufe unten werden übersprungen, wenn diese Funktion in einem normalen Browser fehlt. runAnimation steht hier für Ihre eigene Animationsfunktion, deren Promise am Ende erfüllt wird.
<script>
window.pagecorder?.('start');
runAnimation().then(() => {
window.pagecorder?.('stop');
});
</script>Warten Sie auf das, was ein Zuschauer tatsächlich bemerken würde, nicht nur darauf, dass die Seite fertig geladen ist.
Bei 60 Bildern pro Sekunde bleiben 16 Millisekunden
Sechzig Bilder pro Sekunde bedeuten rund 16,7 Millisekunden pro Bild. Layout, Ihr JavaScript, das Zeichnen, die GPU-Arbeit, das Zurücklesen des Bildes und dessen Kodierung müssen alle in dieses Fenster passen. Eine Seite, die auf Ihrem Laptop butterweich läuft, kann trotzdem Bilder verlieren, sobald sie in 4K gerendert wird und daneben ein Encoder arbeitet.
Die üblichen Ratschläge gelten. Animieren Sie Transformationen und Deckkraft statt Dinge, die ein Neuberechnen des Layouts erzwingen, halten Sie Arbeit aus der Bildschleife heraus, und profilieren Sie schwere Canvas- oder WebGL-Szenen in der Größe, die Sie tatsächlich exportieren. Der Rekorder hat aber eine zweite Aufgabe: zu bemerken, was schiefging. Eine Anfrage, die eine Datei zurückgibt, ist kein Erfolg, wenn unterwegs fünfzig Bilder verloren gingen.
Pagecorder liefert deshalb zusammen mit dem MP4 die Zeitpunkte verlorener Bilder, die fehlgeschlagenen Anfragen und die Browserkonsole. Aus „das Video ruckelt“ wird „bei Sekunde 14 ist etwas schiefgegangen, und hier steht, worüber sich die Seite beschwert hat“.
Halten Sie Browser und Encoder nah beieinander
Alles begann mit einer Lücke. Screenshots per Browser-Automatisierung waren einfach; Tausende hochauflösende Bilder schnell genug zwischen Prozessen zu bewegen, um sie zu kodieren, war es nicht. Die heutige Fassung nutzt Chromium mit eingeschalteter GPU und spricht aus C++ direkt mit den Bibliotheken von FFmpeg, statt das Kommandozeilenwerkzeug aufzurufen.
Der Gedanke dahinter ist schlicht, das Kopieren zu beenden. Jedes Mal, wenn ein Bild von der Grafikkarte in den Hauptspeicher wandert, eine Prozessgrenze überquert und in einen Encoder geht, verbringt es Zeit mit Transport statt mit Komprimierung. Aufnahme und Kodierung nah beieinander zu halten lässt mehr von diesen 16 Millisekunden für die Seite selbst übrig.
Ton bringt eine zweite Uhr ins Spiel. Bilder und Audiodaten müssen sich auf eine gemeinsame Zeitachse einigen, die Pufferung des Encoders überstehen und gemeinsam enden. Eine Pipeline, die nur Video behandelt, sieht im Fünf-Sekunden-Test perfekt aus und driftet bei einem zehnminütigen Rendering deutlich ab.
Schicken Sie die ganze Seite, nicht nur einen Link
Den Renderer auf eine öffentliche URL zu richten ist bequem, macht das Ergebnis aber abhängig von DNS, CDN-Geschwindigkeit, Ratenbegrenzungen und davon, welche Version der Website gerade ausgeliefert wird. Eine Schrift, die nicht lädt, oder ein Bild, das zu spät kommt, verändert sowohl das Aussehen als auch die Dauer.
Pagecorder nimmt deshalb auch eine ZIP-Datei mit der Seite und allem, was sie braucht, und liefert sie für die Dauer des Auftrags lokal aus. Der größte Teil der Netzwerkschwankungen verschwindet, ein altes Rendering lässt sich Jahre später wiederholen, und Sie halten eine Datei in der Hand, die genau festhält, was gerendert wurde, statt nur, wo der Renderer nachsehen sollte.
Für einen einmaligen Auftrag bleibt eine schlichte URL richtig. Für alles, was Sie wiederholt produzieren, verhält sich das Paket eher wie eine Quelldatei.
Selbst bauen oder bezahlen
Wer das selbst baut, übernimmt die Aufnahmekette und ruft nicht bloß eine Browser-API auf. Zu prüfen sind tatsächlich unterschiedliche Frames, Tonsynchronisation, GPU-Verhalten und Ausgabequalität bei der vorgesehenen Auflösung und Dauer. Dazu kommen Browser-Updates, Encoder-Änderungen und Fehler, die erst unter Last auftreten.
Pagecorder stellt diese Arbeit über eine Rendering-API bereit. Sie senden eine URL oder ein ZIP-Archiv, lassen die Seite Start und Ende signalisieren und erhalten das MP4 samt Aufnahmediagnose. Der Dienst ist für Produkte gedacht, die Videos erzeugen müssen, ohne eine eigene Infrastruktur aus Browsern und Encodern aufzubauen und zu betreiben.
Die Kunden von Pagecorder kann ich nicht nennen, aber die Muster wiederholen sich: automatisierte YouTube-Kanäle, Clips für soziale Netzwerke, Produktdemos, Dashboards, die zu Videos werden, Motion Design von Leuten, die ohnehin CSS beherrschen. Alle komponieren im Browser und überlassen das Rendern der Infrastruktur eines anderen.
