asciinema CLI 3.0 in Rust neu geschrieben und mit Live-Streaming sowie Dateiformat-Upgrade

 (blog.asciinema.org)
11 Punkte von GN⁺ 2025-09-17 | 2 Kommentare | Auf WhatsApp teilen
  • Das Terminal-Aufnahmewerkzeug asciinema CLI 3.0 wurde vollständig in Rust neu geschrieben; hinzu kommen ein Upgrade des Dateiformats und Live-Streaming für Terminal-Sitzungen
  • Durch die Umstellung auf Rust gibt es statische Binärdateien, schnelle Startzeiten und mit der AVT-Integration eine einfachere Umsetzung von Nebenläufigkeit und Systemaufrufen sowie eine Grundlage für neue Funktionen
  • Das neue Format asciicast v3 führt intervall-/delta-basierte Zeitangaben für Ereignisse, eine strukturierte Metadatenhierarchie unter term, ein "x"-Beendigungsereignis und #-Zeilenkommentare ein, was Bearbeitbarkeit und Ausdruckskraft verbessert
  • Live-Terminal-Streaming wird in zwei Modi angeboten: mit lokal integriertem Server und mit entferntem Relay (selbst gehostet/offizieller Server); je nach Netzwerksituation sorgt adaptives Buffering für ein flüssiges Seherlebnis
  • Die Grundphilosophie wurde wieder auf Local-first ausgerichtet: rec verlangt nun zwingend einen Dateinamen, Uploads sind getrennt (upload <Datei>), und eine Eingabeaufforderung zur Serverauswahl verbessert Self-Hosting-Freundlichkeit und den Schutz vor unbeabsichtigtem Datenabfluss

Release 3.0: in Rust neu geschriebene asciinema CLI und die wichtigsten Verbesserungen

  • asciinema CLI 3.0 wurde offiziell veröffentlicht
  • In dieser Version wurde die gesamte Codebasis in Rust neu geschrieben und zugleich das Format der Aufzeichnungsdateien aktualisiert
  • Außerdem wurden verschiedene Funktionen ergänzt oder verbessert, darunter Live-Streaming von Terminal-Sitzungen

Rust-Neuschreibung und allgemeine Verbesserungen

  • Die CLI wurde komplett in Rust neu geschrieben, um Developer Experience und Wartbarkeit zu verbessern; durch die Auslieferung als statische Binärdatei wird der Installationsweg vereinfacht, die Startgeschwindigkeit erhöht und die Erweiterbarkeit verbessert
    • Laut den Erfahrungen des Autors fiel die Wahl auf Rust, weil Systemaufrufe und Nebenläufigkeit damit einfacher zu handhaben sind als in Python; außerdem wurde das asciinema virtual terminal (AVT) in die CLI integriert, wodurch neue Funktionen implementierbar wurden
  • Insgesamt schafft das in den Bereichen Performance, Distribution und Architektur eine Grundlage für künftige Funktionserweiterungen

Dateiformat asciicast v3

  • Das Dateiformat entwickelt sich zu asciicast v3 weiter und behebt mehrere Schwächen, die in v2 sichtbar wurden
  • Die absoluten Zeitstempel aus v2 wurden durch intervall-/delta-basierte Zeitangaben ersetzt, wodurch beim Einfügen oder Löschen von Ereignissen das Problem der globalen Nachjustierung nachfolgender Zeitstempel entfällt
  • Der Header wurde umstrukturiert, sodass terminalbezogene Metadaten unter dem Schlüssel term gruppiert werden; außerdem wird ein "x"-Ereignis zum Speichern des Beendigungsstatus einer Sitzung unterstützt
  • Zeilenkommentare (#) innerhalb der Datei sind nun erlaubt, was Lesbarkeit und Wartbarkeit verbessert
  • Ein Beispiel-Snippet zeigt die Struktur und den Aufbau des Ereignisstroms anschaulich
  • Das neue Format wird bereits von asciinema server und asciinema player unterstützt

Live-Terminal-Streaming

  • Lokaler Modus: Ein integrierter HTTP-Server stellt einen Stream bereit, der im selben Netzwerk angesehen werden kann; dabei werden Daten ausschließlich an die Browser der Zuschauer übertragen – ein Privacy-first-Modus
    • Die CLI enthält den aktuellen asciinema player als Bundle, sodass die Wiedergabe sofort möglich ist; unter Umständen müssen Firewall-Ports geöffnet werden
  • Remote-Modus: Ein asciinema server (offiziell oder selbst gehostet) dient als Relay, um den Stream über eine teilbare URL bereitzustellen
    • Beide Modi können gleichzeitig verwendet werden, sodass sich die Verteilung je nach Situation flexibel gestalten lässt
  • Der Player nutzt adaptives Buffering auf Basis einer Echtzeitmessung der Netzwerklatenz, um geringe Verzögerung und Schutz vor Buffer-Underruns auszubalancieren
  • Der Server unterstützt automatische Aufzeichnung von Streams; auf dem derzeitigen Betriebsserver von asciinema.org ist die Aufzeichnung deaktiviert und es gilt die Richtlinie maximal ein gleichzeitiger Stream
    • Beim Self-Hosting ist die Aufzeichnung standardmäßig aktiviert, und es gibt keine Begrenzung für gleichzeitige Streams

Rückkehr zu Local-first

  • Früher war bei asciinema rec ein Upload-Verhalten in den Standardablauf eingebaut, was das Risiko einer unbewussten Veröffentlichung oder eines Informationsabflusses mit sich brachte
    • Mit 2.4 wurde zur Vorbereitung bereits eine Auswahlabfrage vor dem Upload eingeführt; in 3.0 wurden nun Dateiname als Pflichtangabe, die Entfernung der Upload-Funktion aus rec und die Trennung in den expliziten Befehl upload <Datei> umgesetzt
  • Die Grundphilosophie wurde klar als Local-first definiert, sodass Nutzer Veröffentlichung und Weitergabe bewusst entscheiden; der Ablauf wurde entsprechend neu gestaltet
    • Eine rein lokale Nutzung wird vollständig unterstützt, und veröffentlicht wird nur noch bei ausdrücklichem Bedarf

Verbesserte Self-Hosting-Freundlichkeit

  • Bei der ersten Nutzung von upload, stream oder auth erscheint eine Eingabeaufforderung zur Auswahl der Server-URL; standardmäßig wird asciinema.org vorgeschlagen, die Wahl einer Instanz nach Nutzerabsicht aber gespeichert
    • Bereits zuvor war dies über Konfigurationsdateien oder Umgebungsvariablen möglich, doch in interaktiven Umgebungen (neue VM, Dev-Container usw.) wird die Einrichtung dadurch einfacher
  • Das verbessert nicht nur die Nutzbarkeit beim Self-Hosting, sondern dient auch als zusätzliche Sicherheitsmaßnahme gegen unerwünschte Uploads an externe Ziele

Verfügbarkeit und Nutzung

  • Bis die Paket-Repositories der einzelnen Distributionen aktualisiert sind, kann es einige Zeit dauern
  • In der Zwischenzeit können vorkompilierte Binärdateien für GNU/Linux und macOS aus den GitHub-Releases heruntergeladen oder das Projekt aus dem Quellcode gebaut werden
  • Release Notes und die detaillierte Änderungshistorie sind in den Release Notes und im Dokument CHANGELOG auf GitHub einsehbar

Verwandte Beiträge

2 Kommentare

 
xguru 2025-09-17

Gab es 3.0 nicht schon früher? Also habe ich danach gesucht und festgestellt, dass es sich um einen Beitrag aus dem Jahr 2021 handelte, in dem angekündigt wurde, dass der Player durch eine Neuschreibung in Rust 4-mal kleiner und 50-mal schneller werden soll.

Asciinema - Terminalbildschirm aufzeichnen und teilen
Asciinema 3.0 - 4-mal kleiner und 50-mal schneller
 
GN⁺ 2025-09-17
Hacker-News-Kommentare

  • Asciinema ist wirklich ein großartiges Tool; ich nutze es, um alle TerminalTextEffects-Demos aufzuzeichnen. Der Asciinema GIF Generator (AGG) wandelt asciicast-Dateien in hochwertige Terminal-GIFs um, sodass sich Demos leicht im TerminalTextEffects-Repository oder in der Dokumentation veröffentlichen lassen.
    Raw-Dateiausgabe oder Methoden wie termsvg eignen sich nicht gut für TTE, weil dabei riesige Datenmengen auf stdout ausgegeben werden.
    Siehe auch die AGG-Dokumentation und das TerminalTextEffects-Repository

    • Es macht einfach Spaß, die motd des Servers oder Startmeldungen jedes Mal mit zufälligen TTEs auszuschmücken, wenn ich sie weiterreiche.
      Ein Beispiel von mir gibt es hier

    • Dieser Prompt-Effekt ist wirklich wunderschön; ich hoffe, es werden einfach weiter neue gebaut, egal ob es dafür einen praktischen Nutzen gibt oder nicht. Ich kann kaum wegsehen.
      TTE fühlt sich an wie die fantastischen Effekte des Compiz-Fenstermanagers, die mich vor langer Zeit überhaupt erst zu Linux gebracht haben — nur eben im Terminal umgesetzt.
      Ich frage mich, wie man TTE gelegentlich wie einen Bildschirmschoner auf tmux oder vim anwenden könnte — ob man das per Pipe verbinden sollte, besser über einen Alias arbeitet usw.
      Mich würde interessieren, wie ihr es üblicherweise verwendet, wofür es beim Erstellen gedacht war und wie ihr es heute einsetzt.
      Ich hoffe, das Projekt entwickelt sich weiter.

    • t-rec ist ebenfalls ein sehr nützliches Tool; damit kann man das gewünschte Fenster aufnehmen und daraus ein Video oder GIF machen.
      Nicht exakt dasselbe, aber wenn man einfach schnell ein Terminal-GIF teilen will, ist t-rec manchmal einfacher.

    • Eine 15-MB-GIF-Datei ist wirklich nicht tragbar.
      Man kann darin nicht navigieren, keinen Text auswählen und verschwendet auch noch ein Vielfaches an Bandbreite.
      Es ist wirklich schade, glatt komprimierten, gut navigierbaren und barrierearmen Text in das schlimmstmögliche Videoformat zu überführen.
      Wenigstens ein Link zur rohen asciinema-Datei oder zum Web-Viewer wäre gut; dann ließe sich alles schnell laden und man könnte pausieren, navigieren sowie kopieren und einfügen.
      Schnell loopende GIFs vermitteln fast niemandem außer der Person, die sie erstellt hat, die eigentliche Absicht.

  • Die Website asciinema.org ist im Moment so beliebt, dass sie gerade unter extremem Traffic leidet; die CPU-Auslastung des Servers mit dem angebundenen btop-Stream liegt bei satten 95 %.
    Ein Beispiel für diesen Stream gibt es hier.
    Trotzdem läuft der Elixir/Phoenix-Server auf BEAM auch bei vielen Anfragen und hoher CPU-Last stabil weiter — das ist die Stärke von BEAM.
    Derzeit hält das Ganze noch mit nur zwei VMs mit jeweils 2 GB RAM durch, aber bald wird wohl skaliert werden müssen.

    • Es ist erstaunlich, dass ein so bekannter Dienst in einer Zeit, in der alle Infrastruktur in die Cloud wandert, stabil auf nur zwei 2-GB-VMs läuft.
      Das ist weniger Speicher, als viele Mittelklasse-Laptops heute haben, und trotzdem funktioniert es reibungslos.

    • Nachdem die Infrastruktur sofort skaliert wurde, ist jetzt wieder alles stabil und reaktionsschnell.

    • Der btop-Stream ruckelt derzeit stark, und die CPU-Auslastung springt ständig zwischen 0 % und 100 %.
      Ich frage mich, ob der Dienst womöglich immer wieder abstürzt und neu startet.

    • Lang lebe BEAM!

    • Als Tipp: Es wäre vermutlich gut, das Aktualisierungsintervall von btop zu erhöhen. Bei 100 ms verbraucht btop selbst ziemlich viel CPU.

  • Der Asciinema-Client wurde fortlaufend von Python → Golang → Python → Rust umgestellt.
    Siehe auch die Historien-Dokumentation und den zugehörigen Blogpost

    • Ich glaube, bei so einem Projekt ist es ziemlich egal, in welcher Sprache es implementiert ist, weil praktisch alle Sprachen eine ähnliche Leistung liefern.
      Da die Codebasis klein ist, sind die funktionalen Auswirkungen eines Wechsels minimal, deshalb finde ich es in Ordnung, wenn es immer wieder in die Sprache portiert wird, die den Entwicklern gerade Motivation gibt.

    • Interessant.
      Ich finde, die meisten Probleme mit Go sollte man erkennen können, bevor man überhaupt Code schreibt. Selbst bei oberflächlicher Recherche wären Packaging-Probleme solche Punkte gewesen; 2016 war das berechtigte Kritik, wurde aber später mit Go Modules gelöst.
      Danach wirkte das fortlaufende Umschreiben in ClojureScript, Elixir und Rust für mich eher wie das Hinterherlaufen hinter Techniktrends.
      Solch häufige Sprachwechsel untergraben das Vertrauen in die technische Entscheidungsfindung.

  • Ich habe viel Sympathie für Asciinema und unterstütze das Projekt mit kleinen Beiträgen und Spenden.
    Ich empfehle, sich auch die Hinweise zum Spenden anzusehen und einen Blick darauf zu werfen, wie Asciinema bei der Fehlersuche in Linux-Systemen aussehen kann (SadServers Replay).

  • Asciinema ist mit Abstand das beste Tool bzw. Produkt, das ich je benutzt habe.
    Der Ablauf für Authentifizierung und Upload per CLI ist so sauber und intuitiv, dass es sich selbst bei mehreren Schritten nie umständlich anfühlt.
    Es gibt ähnliche Designs auch bei anderen CLIs, aber bei Asciinema hatte ich nie das Gefühl, dass es im Weg steht.

  • Glückwunsch zu dieser wirklich großartigen Leistung.
    Ich würde mir allerdings wünschen, dass asciinema direkt eine eingebaute Funktion zum Speichern als SVG oder GIF hätte.
    Damit ließe es sich ohne separate Konvertierungs-App direkt in Markdown-Dateien einbetten, was die Nutzbarkeit weiter verbessern würde.

  • Als großer Fan von Asciinema finde ich diese Arbeit wirklich großartig.
    Was die Live-Streaming-Funktion betrifft: Ich habe einmal etwas Ähnliches auf dem Stream von s2.dev, dessen Mitgründer ich bin, zusammengehackt, und bei so einer Struktur scheint es auch ohne zwischengeschalteten Relay zu gehen.
    Persönlich fand ich es ziemlich cool, btop in Echtzeit zu sehen.
    Für die Architektur des Live-Streamings ist dieses Dokument hilfreich.

  • Jetzt, wo es Live-Streaming fürs Terminal gibt, wäre es lustig, wenn jemand einen ASCII-Art-Vtuber-Avatar als Overlay über das Terminal legen würde.

    • Das erinnert mich an Max Headroom v0.2.

  • Mein Lieblingsprojekt im Elixir-Ökosystem, asciinema, wurde jetzt auch noch in Rust neu geschrieben.
    Mir gefällt diese Entwicklung sehr.
    Ich frage mich, ob auch eine Funktion hinzugekommen ist, die sensible Informationen wie Secrets oder Schlüssel in Befehlen automatisch bereinigt bzw. überwacht; mit den vielen leichten LLMs dürfte das heute einfacher sein als früher.

    • Die CLI wurde zwar in Rust neu geschrieben, aber der Server ist weiterhin Elixir/Phoenix. Das ist genau die Art von Architektur, die gut zu Funktionen wie dem Filtern sensibler Informationen passen würde.

    • War es früher nicht zuerst in Python geschrieben?

    • Ich bin mir nicht sicher, ob die Frage nach automatischer Filterung von Secrets/Schlüsseln in Befehlen ernst gemeint ist.

  • Twitch-Streamer nutzen oft zwei Computer zum Streamen: einen für die eigentliche Anzeige des Streams und einen zweiten für OBS und HDMI-Capture.
    Mit der neuen Live-Streaming-Funktion von Asciinema könnte ein Entwickler, der ausschließlich in der Konsole arbeitet, den Terminalbildschirm seiner Dev-Maschine vermutlich direkt auf die OBS-Maschine streamen, ganz ohne HDMI-Capture-Gerät.
    Für die kleine Zahl an Programmier-Streamern könnte Asciinema 3 damit eine echte Alternative sein.

    • Beim Streaming mit Asciinema gibt es praktisch keinen Performance-Einfluss, daher ist so ein Dual-PC-Setup dafür nicht nötig.
      Solche 2-PC-Setups entstanden ursprünglich wegen der CPU-Last von x264-Encoding, aber heute ist die Belastung beim Encoding über die GPU (Nvidia NVENC) fast verschwunden.
      OBS mit x264 braucht man eigentlich nur noch für Offline-Aufnahmen wie YouTube-Videos.

    • Twitch-Streamer nutzen 2-PC-Setups vor allem bei grafikintensiven Spielen, um Ressourcenkonflikte zu vermeiden.
      Außerdem verhindert es, dass ein Treiberabsturz während des Spiels den Stream beeinträchtigt.

    • Solche Streaming-Setups dienen meistens dazu, die Last des Video-Encodings zu verteilen; für Programmier-Streamer, die nur in der Konsole arbeiten, ist das wahrscheinlich nicht nötig.