m3u8 の URL を貼れば再生。再生できないときは、その理由まで分かります。
アップロードはなし。ただし配信はブラウザが直接取得するので、配信元にはあなたの IP が見えます。
.m3u8 プレイリストへの https:// リンク。取得するのはあなたのブラウザで、こちらは何も見ません。
…または .m3u8 / .ts / .mp4 をドロップ
ローカルで読むだけ。アップロードはしません
このブラウザが何に対応しているか確認中…
.m3u8 プレイリストの HTTPS リンクを貼るか、ローカルの .m3u8 / .ts / .mp4 をドロップすると、そのブラウザが実際に持っている再生経路で始まります。Safari と iOS は canPlayType('application/vnd.apple.mpegurl') を返すので、URL をそのまま <video> に渡し、demux は OS が受け持ちます。それ以外のブラウザは Media Source Extensions 経由でしか HLS を再生できないため、hls.js を必要になった時点で読み込み、同じ要素を動かします。どちらの経路を選んだか、なぜそうしたかはページに表示され、いつでももう一方に切り替えて挙動の違いを確かめられます。
このツールの本体は、映像の隣にある情報パネルです。ビットレートラダーにはマスタープレイリストの全レンディションが並び、解像度、平均・ピーク帯域、コーデック文字列、宣言されたフレームレートが出て、いま再生中のものに印が付きます。音声と字幕の代替レンディションは、言語・名称・デフォルト指定つきで一覧されます。バッファ表示は再生位置より先に何秒たまっているかを示し、画質切り替えログは切り替えごとに時刻・切り替え元・切り替え先・その時点の帯域推定値を記録します。プレイリストのカードは VOD / EVENT / ライブの別、ターゲット長、セグメント数、VOD なら総再生時間、ライブなら計測された遅延を出します。
再生に失敗したときは、壊れた <video> を見せる代わりに、何が起きたのかを言葉で書きます。ブラウザのページで再生できない配信のほとんどは壊れてなどいません。Access-Control-Allow-Origin ヘッダーなしで配信されているせいで、ブラウザはプレイリストを取得したものの、このページの JavaScript に中身を渡してよいという許可がないため止めるのです。診断は URL を実際に叩き、その CORS のケースと、混在コンテンツ（https:// のページで http:// の配信）、単に到達できないホスト、プレイリストは読めてもブラウザがデコードできないメディア、をそれぞれ切り分け、サーバー側が返すべきヘッダーをそのまま示します。
正直に書いておく注意点がひとつだけあります。このサイトで唯一のものです。配信はブラウザが配信元から直接取得するので、配信元のサーバーにはあなたの IP アドレス、ユーザーエージェント、要求したセグメントがすべて見えます。ByteScope には何もアップロードされません。中間にサーバーがないからこそ、配信元からあなたが見えるわけです。DRM で保護された配信（Widevine、FairPlay、PlayReady）はここでは一切再生できません。権利者のキーサーバーとのライセンス交換が必要で、このページはそこに関与しないからです。平文の配信と、キー URI に到達できる AES-128 の配信は普通に再生できます。
配信サーバーが Access-Control-Allow-Origin ヘッダーを返していないからです。ページの JavaScript は、配信元が明示的に開放したクロスオリジンのレスポンスしか読めません。ブラウザでの HLS は、JavaScript がプレイリストとセグメントを読むこと、そのものです。配信自体は正常で、同一オリジンポリシーのない VLC や ffplay なら再生できます。直すのはサーバー側で、プレイリストとセグメントに Access-Control-Allow-Origin: *（または自分のオリジン）を、バイトレンジを使うなら Access-Control-Allow-Headers: Range も付けます。CDN ならたいていチェックボックス一つです。
こちらへは何もアップロードされません。このツールにサーバーはなく、ドロップしたローカルファイルはタブの外に出ません。ただしリモート配信はブラウザが配信元から直接取得するので、配信元にはあなたの IP アドレス、ユーザーエージェント、要求したセグメントが見えます。ほかのプレイヤーで開いた場合とまったく同じです。これがこのサイトで唯一のプライバシー上の注意点で、プロキシしないことの結果であって、見落としではありません。
できません。Widevine、FairPlay、PlayReady は権利者のキーサーバーへのライセンス要求が必要で、その署名に使う資格情報をこのページは持っておらず、正当に入手することもできません。失敗しますし、空のプレイヤーを見せる代わりにそう明記します。AES-128 暗号化の HLS は別で、#EXT-X-KEY の URI に到達でき CORS も開いていれば、hls.js が鍵を取得して普通に再生します。
開けます。ただし正直に言うと制限がひとつあります。ローカルのプレイリストはディスクから読むため、segment0.ts のような相対 URI には解決すべきディレクトリがなく、取得できません。その場合はそう表示したうえでベース URL の入力欄を出します。そのプレイリストがあった場所を貼れば、相対 URI をすべてそれを基準に書き換えます。セグメント URI が最初から絶対 URL のプレイリストはそのまま再生でき、単体の .ts や .mp4 は 1 エントリのプレイリストに包むので、セグメント 1 個だけの確認もできます。
ネイティブ HLS は、ブラウザと OS がプレイリストを自分で扱う経路です。macOS の Safari と iOS のすべてのブラウザがこれで、ハードウェアデコードと AirPlay が効くのもこちらです。hls.js は Media Source Extensions の上に HLS を JavaScript で実装したもので、Chrome・Firefox・Edge が HLS を再生できるのはこれのおかげです。情報パネルが充実するのは hls.js 側です。ラダー・バッファ・切り替えのすべてを hls.js が公開しているからで、ネイティブ経路ではそれらがメディアスタックの中に隠れるため、<video> 要素が申告する範囲しか出せません。
アダプティブビットレートが仕事をしている証拠です。hls.js はセグメントの到着速度から使える帯域を推定し、その推定で賄える一番上のバリアントを選びます。画質切り替えログはその判断を一件ずつ、その時点の帯域推定値つきで残すので、2 つのバリアント間で振動する配信も見えるようになります。たいていはラダーの段が近すぎるか、推定値が境界の真上に居座っているかです。レベル選択でバリアントを固定すれば、推定器を計算から外せます。
落としたセグメントや MP4 を調べる。コーデック、ビットレート、キーフレーム。
HLS 配信が運ぶ WebVTT トラックを SRT に変換。
失敗ではなく詰まるときは、回線そのものを確かめる。