Asciinema CLI 3.0がRustで書き直され、ライブストリーミング機能を追加し、ファイルフォーマットがアップグレードされました

252日前原文(blog.asciinema.org)

概要

asciinema CLI 3.0が Rustで完全リライト され、パフォーマンスや拡張性が大幅向上。録画ファイルフォーマットが v3に進化 し、編集や管理が容易に。 ターミナルライブストリーミング 機能が追加され、ローカル・リモート両対応。 ローカル保存が必須 となり、意図しないデータ公開リスクを低減。 セルフホスティング やサーバー連携がより柔軟・安全に。

asciinema CLI 3.0 リリース概要

asciinema CLI 3.0 のリリース発表
Rustによる完全リライト で、起動速度向上・静的バイナリ化・新機能実現
asciinema virtual terminal （Rust製）をCLIに統合
インストール容易化 と新機能の基盤強化

asciicast v3 ファイルフォーマット

asciicast v3 はv2の課題を解決した新フォーマット
イベント間隔（デルタ）方式 でタイミング管理が容易
ヘッダー構造の整理、関連情報をグループ化（例：term下に端末情報集約）
"x"（exit）イベントタイプ 追加、セッション終了ステータス記録に対応
#で行コメント が可能となり、可読性向上
asciinema server・player は既にv3対応済み

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

ローカルモード ：組み込みHTTPサーバーでLAN内ストリーミング、外部送信なし
- asciinema player 同梱、ブラウザから直接視聴可能
リモートモード ：asciinema server経由でURL共有型ストリーミング
両モード同時利用 も可能
adaptive buffering機構 でネットワーク遅延に自動対応、滑らかな再生体験
サーバー側でライブ配信録画 も可能（asciinema.orgでは現在制限あり）

ローカルファースト設計への転換

録画ファイル名指定が必須 となり、録画→即アップロードの旧仕様を廃止
アップロードは明示的なコマンド （asciinema upload <filename>）で実行
意図しない録画公開・情報漏洩リスクの低減
セルフホスティング推奨、asciinema.orgはあくまでサンプル兼共有用
クラウドサービス回避志向、ローカル運用重視

サーバー連携・セルフホスティング強化

初回利用時にサーバーURL選択プロンプト を表示、意図的な選択を促進
選択内容は今後も保持、設定ファイルや環境変数での切り替えも従来通り可能
非意図的なデータ送信防止、特に開発・検証環境での利便性向上

まとめ・入手方法

3.0は順次各ディストリビューションで利用可能 になる予定
GitHubリリースページ からGNU/Linux・macOS用バイナリ配布中
ソースビルドもサポート
フィードバック歓迎 （メール・Mastodonで受付）

今後の展望と利用者へのメッセージ

新しいワークフローやユースケース の発見をユーザーに期待
asciinema.orgのリソース利用制限 は今後調整予定
Brightbox によるクラウドサービス提供への謝辞
オープンソースコミュニティとの連携 推進

Hackerたちの意見

今までで一番好きなElixirプロジェクトがRustで書かれたんだね。めっちゃ嬉しい！みんなは、秘密やキーみたいな敏感なアイテムのためにコマンド文字列をクレンジング/監視する機能を追加したの？軽量LLMの進化で、今まで以上に簡単になった気がする。

└

みんなは、秘密やキーみたいな敏感なアイテムのためにコマンド文字列をクレンジング/監視する機能を追加したの？軽量LLMの進化で、今まで以上に簡単になった気がする。これ、冗談だよね？

└

今までで一番好きなElixirプロジェクトがRustで書かれたんだね。前はPythonで書かれてたよね？

└

CLIはRustで書き直されたよ。サーバーはまだElixir/Phoenixで、この機能にはぴったりだね。

Asciinemaは、今まで使った中で最高の製品/ツールの一つだよ。認証やアップロードのCLIフローがすごくシンプルで使いやすいし、いくつかのレイヤーを越える必要があるけど、Asciinemaは使ってる時に全然「邪魔にならない」んだよね。

Twitchのストリーマーがストリーミングのために二台のコンピュータを使ってるって聞いたことがある。1台はストリームに映ってるコンピュータで、もう1台はOBSを動かしてHDMIキャプチャーデバイスを使ってるんだ。この新しいAsciinemaのライブストリーミング機能があれば、プログラミングストリーマーの一部はHDMIキャプチャーデバイスを買わずに済むかもしれない。特にターミナルだけで作業する開発者にとってはね。この少数の人たちは、HDMI出力をキャプチャする代わりに、Asciinema 3を使って開発マシンからOBSマシンにターミナルをストリーミングできるようになるんだ。

└

あなたが説明しているセットアップは、主にビデオエンコーディングを別のPCにオフロードするために使われていると思う。プログラミングストリーマー（グラフィック集中的なゲームをやってない人たち）にはあまり関係ないかもしれないね。

└

Asciinemaのストリーミングには、パフォーマンスに影響を与えないから、あまり関係ないと思うよ。ゲームストリーミングのための2台のデバイスのセットアップは、x264エンコーディングの重いCPU使用量から生まれたものだから。ゲーム専用のPCを持って、ストリーミングPCがエンコーディングの負荷を引き受けるってわけ。でも、最近は多くの人がGPUを使ってエンコーディングできるようになったから（Nvidia NVENC）、ほとんどオーバーヘッドがなくて、同じか少し劣る品質を提供してるんだ。OBSのx264は、YouTube動画のためのオフライン録画にだけ使うべきだね。

└

Twitchのストリーマーがそうするのは、GPU集中的な作業（ビデオゲーム）をストリーミングソフトとGPUリソースを競わせないためだよ。それに、ゲームによるドライバーのクラッシュがストリームをクラッシュさせるのを防ぐためでもあるんだ。

Asciinemaは最高だね。TerminalTextEffectsのデモを全部キャプチャするのに使ってるよ。彼らのAsciinema GIF Generatorツール（AGG）は、asciicastファイルを処理して高品質なターミナル録画GIFを作ってくれるんだ。これがREADMEやドキュメントで共有できる短いターミナル録画を作るためのベストな方法だと思う。生のファイル出力やtermsvgタイプのソリューションは、TTEには合わないんだ。stdoutに書き込まれるデータ量が膨大だからね。

└

これ、めっちゃ美しいね！使い道があるかはわからないけど、すごく気に入ったし、これからも続けてほしいな。見てると魅了されるし、美しい。TTEは昔のCompizウィンドウマネージャーを思い出させる。あれのおかげでWindowsを捨ててLinuxにしたんだ、ターミナル以外はね。tmuxやvimにTTEみたいなものをスクリーンセーバーとして追加することはできる？たまにトリガーされるような感じで。パイプするの？エイリアス作るの？普段はどう使ってるの？最初に書いたときの意図は何だったの？今は何に使ってるの？頑張ってね！

└

t-recは素晴らしいツールで、どんなウィンドウでも録画して動画やGIFを作れるんだよね。ちょっと違うけど、ターミナルのGIFをシェアしたいときはこれが簡単だと思う。

└

サーバーのmotd / スタートアップをランダムなtteを通して流してるんだけど、毎回嬉しくなるよ。ありがとう！ 1: https://keeb.dev/static/login.mp4

└

15MBのGIFファイル。無理だわ、ほんと無理。マジで無理。シークもできないし、テキストも選べない。しかも、読み込むのに必要な帯域幅の15倍も使わなきゃいけない。お願い、やめて。お願い。美しく圧縮できて、シーク可能で、アクセスしやすいテキストを、動画にとって最悪なフォーマットに押し込んで、それを良いって呼ぶのはやめてほしい。どうしてもそうしたいなら、せめて生のasciinemaか、彼らのウェブビューアへのリンクを貼ってほしい。そうすれば、時間を大幅に短縮できて、一時停止したり、前後にシークしたり、テキストをコピー＆ペーストできるから。わかってる、わかってるよ、そんなの誰が欲しがるんだって。クリエイター以外には意味がないくらい速くループするGIFの方がずっといいんだろうね。

ターミナルライブストリーミングの紹介これで、ターミナルの上に重ねるASCIIアートのVTuberアバターを開発してくれる人が必要だね。

└

Max Headroom v0.2

これ素晴らしいね！大きな成果おめでとう！唯一の願いは、asciinemaがsvgやgifにネイティブで保存できるようになってほしいこと。そうすれば、出力をそのフォーマットに変換するためにサイドアプリをインストールしなくても、簡単にマークダウンファイルに追加できるから。

asciinema.orgは現在、すごい負荷がかかってる！btopのストリームはサーバーの一つからで、現在95%のCPU使用率を報告してるよ。でも、ちゃんと動いてる！asciinemaサーバーはElixir/Phoenixで、BEAM上で動いてるから、たくさんの接続や高いCPU使用率でもリクエストをうまく処理できるんだ。BEAMの力だね。ふぅ。今は2つのVM、各2GBのRAMで動いてるから、すぐにスケールアップが必要になると思うよ :)

└

BEAM万歳！

└

すべてがクラウドの時代に、こんな高プロファイルなサービスが2GBのVMだけでスムーズに動いてるのはすごいよね。中級のノートパソコンよりも少ないRAMなのに、あのマシンは現代のブラウザを動かすのも大変なんだから。

└

すごいサービスをありがとう！ストリームをミラーリングする方法ってあるの？ウィキペディアのダンプみたいに。

└

ヒント：btopのリフレッシュレートを下げた方がいいかも。100msだと、btop自体がかなりのCPU時間を使ってる可能性があるよ。

└

今、btopのストリームがめっちゃ遅れてるし、CPUがフルとアイドル0%を行ったり来たりしてる。サービスがクラッシュして再起動してるのかな？

└

スケールアップしたら、またかなり安定して反応も良くなったみたい。

Asciinemaの大ファンで、これは素晴らしい仕事だね。ライブストリーミング機能については、s2.devのストリームの上に似たようなものをハックしたんだ（注：私は共同創設者です）。これがこのアーキテクチャでの中継の必要性を軽減できるかもしれないね。もちろん、btopを見せるのが一番のハイライトだったよ :-D。 [1]: https://s2.dev/blog/s2-term [2]: https://docs.asciinema.org/manual/server/streaming/#architec...

Asciinemaのクライアントは、PythonからGolang、またPythonに戻って、今はRustになったんだって。 https://docs.asciinema.org/history/ https://blog.asciinema.org/post/and-now-for-something-comple...

└

それは…面白いね。Goに関する不満の多くは、実際にコードを書く前に予測できたはずだし、ちょっとした下調べで分かることだと思う。パッケージの問題は2016年のもので、今はGoモジュールで解決されてるけどね。それからClojureScript、Elixir、そして今はRustへの書き換え…うーん。これが示してるのは、著者たちがしっかりしたエンジニアというよりはトレンドを追いかけてるだけってこと。だから、このプロジェクトに対する信頼が薄れちゃうな。

Asciinemaが大好きで、ちょっと貢献もしたよ。プロジェクトを支援したいなら寄付してね: https://docs.asciinema.org/donations/#individuals もし、AsciinemaがLinuxのトラブルシューティング中にどう見えるか知りたいなら: https://replay.sadservers.com/

ハクソク