Rustで書き直された asciinema CLI 3.0、ライブストリーミングとファイル形式のアップグレードを提供

 (blog.asciinema.org)
11 ポイント 投稿者 GN⁺ 2025-09-17 | 2件のコメント | WhatsAppで共有
  • ターミナル録画ツール asciinema CLI 3.0 が Rust で 全面的に書き直され、ファイル形式のアップグレード と ターミナルのライブストリーミング 機能が追加
  • Rust 採用により 静的バイナリ の提供、高速な起動時間、AVT 統合による 並行処理・システムコール処理 の容易化、新機能実装の基盤を確保
  • 新しい asciicast v3 フォーマットは、イベントの インターバル（デルタ）ベースのタイミング、term 配下へのメタデータ構造化、"x" 終了イベント、# 行コメントを導入し、編集性と表現力を向上
  • ライブターミナルストリーミング はローカル内蔵サーバーとリモートリレー（セルフホスト/公式サーバー）の2モードで提供され、ネットワーク状況に応じた 適応型バッファリング により滑らかな視聴体験を提供
  • 基本哲学を Local-first として再整備し、rec はファイル名を必須とし、アップロードを分離（upload <ファイル>）することで、セルフホスティングとの親和性 と 意図しないデータ流出の防止 を強化

3.0 リリース: Rust で書き直された asciinema CLI と主な改善点

  • asciinema CLI 3.0 が正式にリリース
  • 今回のバージョンでは コード全体が Rust に書き直され、同時に 録画ファイル形式もアップグレード
  • ターミナルセッションのライブストリーミング など、さまざまな機能が追加・改善

Rust への書き直しと全体的な改善

  • CLI を Rust で全面的に書き直し、開発者体験と保守性を高めるとともに、静的バイナリ 配布によってインストール経路を簡素化し、起動速度を向上、機能拡張性も確保
    • システムコールと 並行処理 が Python と比べて容易だという作者の経験に基づいて選択され、asciinema virtual terminal (AVT) を CLI に統合したことで新機能の実装が可能になった
  • その結果、性能・配布・アーキテクチャの面で 今後の機能追加の土台 を整備

asciicast v3 ファイル形式

  • asciicast v3 ファイル形式へと進化し、従来の v2 で明らかになっていた複数の欠点を補完
  • v2 の絶対タイムスタンプを 間隔（インターバル/デルタ）ベースのタイミング に置き換え、イベントの挿入・削除時に生じる 後続タイムスタンプの一括調整問題 を解消
  • ヘッダーを再構成してターミナル関連メタデータを term キー 配下にグループ化し、セッション終了状態の保存用に "x"（exit）イベント をサポート
  • ファイル内の 行コメント（#） を許可し、可読性と管理のしやすさを向上
  • 例示スニペットにより、構造とイベントストリーム構成を直感的に提示
  • 新フォーマットは asciinema server、asciinema player ですでにサポート済み

ライブターミナルストリーミング

  • ローカルモード: 内蔵 HTTP サーバーにより同一ネットワーク内で視聴可能なストリームを提供し、データが視聴者のブラウザにのみ送られる プライバシー優先 モード
    • CLI に最新の asciinema player がバンドルされており、すぐに再生可能。ファイアウォールでのポート開放が必要になる場合がある
  • リモートモード: asciinema server（公式またはセルフホスト）をリレーとして使い、共有可能な URL でストリームを配信
    • 2つのモードは 同時に 使用でき、状況に応じた配信構成が可能
  • プレイヤーは リアルタイムのネットワーク遅延測定 に基づく 適応型バッファリング により、低遅延とバッファアンダーラン防止のバランスを取る
  • サーバーは ストリームの自動録画 をサポートし、現在の asciinema.org 運用サーバーでは録画無効・同時 1 ストリーム制限 のポリシーを採用
    • セルフホスト時はデフォルトで録画有効・同時ストリーム数の制限なし

Local-first への回帰

  • 過去の asciinema rec ではアップロード動作がデフォルト経路に含まれており、無意識の公開・情報流出 のリスクがあった
    • 2.4 で アップロード前の確認プロンプト を導入して移行を準備し、3.0 では ファイル名必須、rec から アップロード機能を削除、upload <ファイル> という 明示的なコマンド に分離
  • 基本哲学を ローカル優先 として明確化し、ユーザーが意図を持って公開/共有を決められるようフローを再設計
    • ローカル専用の利用が 完全にサポート され、必要なときだけ明示的に公開する

セルフホスティングとの親和性強化

  • upload / stream / auth を初めて使う際に サーバー URL 選択プロンプト を表示し、デフォルト値として asciinema.org を提示しつつ、ユーザーの意図に沿ったインスタンス選択 を保存
    • 従来も設定ファイル/環境変数で指定できたが、対話的な環境（新規 VM・Dev コンテナなど） でより簡単に指定できるようになった
  • これはセルフホスティングの使い勝手を高めると同時に、望まない外部アップロードの防止 という追加の安全装置としても機能

配布と利用案内

  • 各ディストリビューションのパッケージリポジトリに反映されるまでには時間がかかる場合がある
  • それまでの間は GNU/Linux・macOS 向けの事前ビルド済みバイナリ を GitHub Releases からダウンロードして使うか、ソースからビルド できる
  • リリースノートと詳細な変更履歴は GitHub の release notes および CHANGELOG 文書で確認できる

関連記事

2件のコメント

 
xguru 2025-09-17

3.0は以前に出ていなかったっけ？ と思って検索してみたら、2021年にPlayerをRustで書き直し、4倍小さく、50倍速くなると予告していた記事でしたね。

Asciinema - ターミナル画面を録画して共有
Asciinema 3.0 - 4倍小さく、50倍速く
 
GN⁺ 2025-09-17
Hacker News のコメント

  • Asciinema は本当に素晴らしいツールだ。TerminalTextEffects のデモをすべてキャプチャするのに使っていて、Asciinema GIF Generator（AGG）が asciicast ファイルを高品質なターミナル GIF に変換してくれるので、TerminalTextEffects のリポジトリやドキュメントにデモを簡単に載せられる。
    raw ファイル出力や termsvg 系の方法は stdout に膨大なデータが出力されるため、TTE には向いていない。
    AGG ドキュメント と TerminalTextEffects リポジトリ のリンクも参考になる。

    • サーバーの motd やスタートアップメッセージを毎回ランダムな TTE で飾って流すのが楽しい。
      自分で作った例は ここ で見られる。

    • このプロンプト効果は本当に美しい。使い道があるかどうかに関係なく、ただ作り続けてほしい。見とれてしまう。
      TTE は、昔 Compiz ウィンドウマネージャーで初めて Linux を使うきっかけになったあの幻想的な効果が、ターミナルで再現されたような感じだ。
      TTE を tmux や vim にスクリーンセーバーのように断続的に適用する方法が気になる。パイプでつなぐべきか、alias にするのがよいのかなど悩んでいる。
      普段どう使っていて、制作時にはどんな用途を想定していたのか、今はどう活用しているのか知りたい。
      これからも発展し続けてほしい。

    • t-rec も非常に便利なツールだ。好きなウィンドウを録画して動画や gif にできる。
      完全に同じではないが、単にターミナル gif を素早く共有したいだけなら t-rec のほうが簡単な場合もある。

    • 15MB の GIF ファイルはとても耐えられない。
      シークもできず、テキスト選択もできず、帯域も 15 倍無駄になる。
      滑らかに圧縮できて、シークしやすく、アクセシブルなテキストを、最悪の形式の動画に変えてしまうのは本当にもったいない。
      せめて raw の asciinema ファイルか Web ビューアへのリンクも一緒に付けてくれるといい。そうすれば短時間で読み込めて、一時停止・シーク・コピー＆ペーストまで全部できる。
      高速でループするだけの GIF では、作った本人以外には意図がほとんど伝わらない。

  • asciinema.org サイトは人気が出すぎて現在トラフィックが集中しており、btop ストリームにつながっているサーバーの CPU 使用率が 95% に達している。
    そのストリームの例は ここ で見られる。
    それでも BEAM 上で動く Elixir/Phoenix サーバーは、多くのリクエストと高い CPU 使用率の中でも問題なくサービスを続けている。これぞ BEAM の力だ。
    現時点では 2GB RAM の VM 2 台だけで耐えているが、近いうちにスケールする必要を感じている。

    • すべてのインフラがクラウドに集まる時代に、これほど有名なサービスがたった 2 台の 2GB VM で安定稼働しているのは驚きだ。
      最近のミドルクラスのノート PC のメモリより少ない資源なのに、快適に動いている。

    • インフラをすぐにスケールした結果、再び安定してレスポンスも良くなった。

    • 今は btop ストリームがひどく途切れていて、CPU 使用率も 0%〜100% の間で激しく変動し続けている。
      もしかしてサービスがクラッシュと再起動を繰り返しているのではと気になる。

    • BEAM よ永遠なれ！

    • アドバイスすると、btop の更新間隔を下げたほうがよさそうだ。100ms にすると btop 自体が CPU をかなり使ってしまう。

  • Asciinema クライアントは Python → Golang → Python → Rust と移り変わってきた。
    変遷のドキュメント と 関連ブログ も参考になる。

    • こういうプロジェクトはどの言語で実装してもあまり関係ない気がする。どの言語でも似たような性能が出るからだ。
      コードベースが小さいので、どの言語に移しても機能面への影響は小さく、開発者のモチベーションが上がる言語で書き直し続けても構わないと思う。

    • 興味深い話だ。
      Go の問題点の多くは、コードを書く前にある程度把握できているべきだと思う。少し調べるだけでも packaging の問題のような点は 2016 年当時ならもっともな不満だったが、Go modules 以後は解決されている。
      その後も ClojureScript、Elixir、Rust へと書き直し続けるのは、技術トレンドを追いかけている印象を拭えない。
      こうした頻繁な言語変更はエンジニアリングへの信頼を損なう。

  • Asciinema に愛着があり、小さな貢献や寄付でプロジェクトを支援している。
    寄付案内 と、Linux システムの問題解決で Asciinema がどう見えるかについては SadServers のリプレイ も一度見てほしい。

  • Asciinema は、自分が使ったツールや製品の中でも群を抜いて最高だ。
    CLI での認証やアップロードの流れが洗練されていて直感的なので、いくつか手順があってもまったく煩わしく感じない。
    他の CLI にも似た設計はあるが、Asciinema では邪魔されている感じがまったくなかった。

  • 本当に素晴らしい成果で、おめでとう。
    ただ、asciinema に SVG や GIF へ直接保存する機能が内蔵されるとうれしい。
    別の変換アプリなしで Markdown ファイルに埋め込めるようになるので、使い勝手がさらに良くなるはずだ。

  • Asciinema の熱心なファンとして、今回の作業は本当に素晴らしいと思う。
    ライブストリーミング機能については、自分が共同創業者をしている s2.dev の stream の上に似たものをハックして載せたことがあるが、この構成なら中継リレーなしでも可能そうだ。
    個人的には btop をリアルタイムで見せていたのがよかった。
    ライブストリーミングの構成については このドキュメント が参考になる。

  • ターミナルのリアルタイムストリーミング機能が入ったのなら、誰かが ASCII アートの vtuber アバターをターミナル上にオーバーレイしてくれると面白そうだ。

    • Max Headroom v0.2 を思わせるアイデアだ。

  • 自分が最も好きな elixir プロジェクトである asciinema が、ついに Rust でも書き直された。
    この進化は本当に気に入っている。
    コマンド中のシークレットやキーのような機密情報を自動でマスク・監視する機能も追加されたのか気になる。今は軽量な LLM も多いので、以前より簡単になっていそうだ。

    • CLI は Rust で書き直されたが、サーバーは依然として Elixir/Phoenix のままだ。この部分は機密情報フィルタリングのような機能にまさに向いている。

    • 以前は最初に Python で作られていなかっただろうか。

    • コマンド内のシークレットやキーの自動フィルタリング機能についての質問は、冗談ではないのかと少し思った。

  • Twitch ストリーマーがよく 2 台の PC で配信するのは、1 台が配信画面を表示するため、もう 1 台が OBS と HDMI キャプチャを動かすためだ。
    Asciinema の新しいライブストリーミング機能を使えば、コンソール（terminal）だけで作業する開発者なら、HDMI キャプチャ機なしでも dev マシンのターミナル画面を OBS マシンへそのまま配信できそうだ。
    ごく少数のプログラミング配信者にとっては、Asciinema 3 が本当の代替手段になり得る。

    • Asciinema のストリーミングなら性能への影響はほとんどないので、こうしたデュアル機材構成は不要だ。
      2PC 構成が生まれたのは x264 エンコードの CPU 負荷が理由だったが、今では GPU でエンコード（Nvidia NVENC）すれば負担はほとんどない。
      OBS の x264 は、オフライン録画用（YouTube 動画など）でない限り、ほぼ必要なくなっている。

    • Twitch ストリーマーが 2PC を使うのは、GPU を大量に使うゲーム配信でリソース競合を防ぐためでもある。
      また、ゲーム中のドライバクラッシュが配信に影響するのを防ぐ意味もある。

    • こうした配信機材の構成はたいてい動画エンコード負荷の分散が目的なので、コンソールだけで作業するプログラミング配信者ならそこまで必要ないと思う。