ブラウザの対応を確認中…
端末の画面をタブでライブに見る、あるいは動画ファイルに録る — どちらも USB ケーブル越しに。
フレームはこのタブ内でデコードし、録画はそのままお使いのディスクへ流し込みます。どこにもアップロードせず、デバイス上の一時ファイルはコピーが終わり次第削除します。
ブラウザの対応を確認中…
Android 端末を Chromium ブラウザに USB でつなぐと、このページはその画面に対して 2 つの別なことをします。ミラーリングは画面を H.264 として受け取りタブ内でデコードするので、数十ミリ秒の遅れで端末をウィンドウの中に見られます。録画は端末自身のエンコーダーに MP4 を作らせ、そのファイルをそのままお使いのディスクへ流し込みます。端末には何もインストールせず、どこにもアップロードしません。先に正直な注意を 1 つ。ミラーリングには scrcpy のサーバーバイナリ（Apache-2.0）が必要ですが、この静的ビルドには**同梱していません**。無い場合はごまかさずそう表示します。録画はどちらでも動きます。必要なのは Android に元から入っている screenrecord だけだからです。
scrcpy は画面共有アプリではなく、プロトコルと、クライアントが端末へ送り込んで shell ユーザーとして動かす小さなサーバーです。そのサーバーが SurfaceFlinger から画面を取り、端末のハードウェア H.264 エンコーダーで符号化し、ADB ソケット越しに送り返します。クライアントの仕事はデコードして描くことだけで、だからこそブラウザがクライアントになれます。ここでのデコードは WebCodecs の VideoDecoder で、デスクトップのクライアントが受けるのと同じストリームを食べ、canvas に描きます。逆方向の操作（タッチとキー）も同じプロトコルの一部で配線済みなので、始まったミラーはクリックできるミラーです。
60 fps の端末画面は JavaScript のデコーダーが追いつける量をはるかに超えるので、ハードウェアデコードがないミラーリングは「遅い」のではなく成立しません。だからこのページはマウント後に VideoDecoder の対応を調べ、無ければ黒い矩形を出すボタンを置く代わりにそう言います。Firefox と Safari は普通「無い」側、デスクトップの Chromium 系は普通「ある」側です。録画はこれとは無関係で、符号化は端末側、ブラウザはバイト列をファイルに書くだけです。
隣に並んでいても振る舞いは全く違います。ミラーは即時で何も残しません。ファイルはなく、タブを閉じればどちらのマシンにも痕跡は残りません。デモ、棚に置いた端末の監視、キーボードで操作したいときに向いています。録画は始まりと終わりのあるファイルで、作るのは私たちではなく端末です。バグ報告やストア掲載用に向いています。ここの録画は開始**前**にディスク上の保存先を選びます。File System Access のピッカーはクリックを要求し、バイト列が来るのは数分後だからです。その後、動画は端末から小さな塊でそのファイルへ流れるので、2 GB のキャプチャがタブのメモリーに座ることはありません。端末上の一時ファイルはコピーが終わり次第削除し、ケーブルが抜けて残ったものは次の録画の前に片付けます。
録画の制約はプラットフォームのもので、ファイルを見てから気付くよりここで読むほうがましです。音声はありません。screenrecord は映像だけを取り、音のためのフラグもありません。Android 11 以降に内蔵の録画機能は取れますが、それは別のプログラムです。1 回の録画について明記された既定値かつ上限は 180 秒で、ビルドによってはもっと長くでき、拒否された場合に表示するのは端末自身の言葉です。DRM で保護された映像は黒い矩形になります。コンポジターがそのフレームをエンコーダーに渡さないためで、スクリーンショットが黒くなるのと同じ理由です。フレームサイズは開始時に固定されるので、途中で回すと以降はレターボックスになります。そして任意の --size は要求であって保証ではありません。AVC エンコーダーは対応しない解像度を拒否できるので、ここで出す選択肢はエンコーダーが概ね受け入れるものにしてあります。
このページのどちらの半分も、手に持った実機の代わりにはなりません。ミラーリングは音ゲーで体感できる遅延を足しますし、4 Mbps で録った映像は画面に無かった圧縮ノイズを速い動きに出します。両方が得意なのは、何が起きたかを他人にそのまま見せることです。ここからは、logcat ビューアーでキャプチャ中に端末が言っていたことが見られ、システムモニターで CPU と温度の様子が見られ、Web ADB ハブには残りのツールがあります。
良好な USB 接続なら数十ミリ秒です（端末で符号化、転送、ここでデコードして描画）。デモや操作説明、アプリを触って回るには十分で、タイミングそのものが目的の用途には向きません。値は端末のエンコーダー、ケーブル、こちらのマシンの忙しさで変わり、ブラウザ側からこのページが直せるものではありません。フレーム単位の正確さが要るなら録画してください。録画は端末側で端末のペースで作られるので、遅延は関係なくなります。
操作は scrcpy プロトコルの一部で、ここでも配線済みです。ミラーが動いている間、canvas 上のクリックとキー入力はデバイスへ送り返されます。何でないかも大事です。インターネット越しのリモートアクセスではなく、root でもありません。入力は画面を取っているのと同じ `shell` ユーザーのサーバーが注入するので、shell にできないことはここでもできません。録画は本質的に一方通行で、ファイルを書いている間に操作するものはありません。
`screenrecord` は 1 回の録画について 180 秒を既定値かつ上限として明記しているので、このページが出す上限もそれです。ビルドによっては引き上げられており、値が拒否された場合に見えるのは私たちの推測ではなく端末自身のメッセージです。もう 1 つの制約はサイズで、既定の 20 Mbps なら 3 分で約 450 MB。設定に対する上限を開始前にパネルへ出します。ディスクへコピーし終わるまでファイルを抱えるのは端末側のストレージだからです。
独立した理由が 2 つあり、どちらなのかはページが示します。ミラーリングには WebCodecs のハードウェア H.264 デコードが必要で、デスクトップの Chromium 系にはあり Firefox と Safari にはありません。無ければソフトウェアデコードでは端末の画面に追いつけないので、カクついた黒い窓を見せる代わりにできないと言います。ミラーリングにはもう 1 つ scrcpy のサーバーバイナリが必要で、このビルドには同梱していません。無いときはそのとおり表示します。録画はどちらにも依存せず、ファイルをディスクへ流し込む File System Access API だけが必要です。
デバイスのダッシュボード、shell ドロワー、その他すべての Web ADB ツール。
録画したい現象を再現しながら、同時にログを見る。
撮っている間、デバイスの CPU と温度がどうなっていたか。