ByteScope

HLS / M3U8 Player

貼上 m3u8 網址就開播；播不動的時候，這裡會告訴你到底卡在哪。

沒有上傳，但串流是你的瀏覽器直接抓的，來源伺服器看得到你的 IP。

串流來源

指向 .m3u8 播放清單的 https:// 連結。抓取的是你的瀏覽器，我們看不到。

…或拖進 .m3u8 / .ts / .mp4 檔

只在本機讀取，不會上傳

播放路徑

正在確認這台瀏覽器支援哪些路徑…

這個工具做不到的事

  • 有 DRM 保護的串流（Widevine、FairPlay、PlayReady）播不了。它們需要跟版權方的金鑰伺服器換授權，而這一頁不參與那件事。
  • 沒有送 Access-Control-Allow-Origin 的串流，任何網頁都播不了，包括這一頁。那是瀏覽器的規則，不是我們寫程式能繞過去的限制。
  • 沒有任何東西上傳到我們這裡——這個工具根本沒有伺服器。但串流是你的瀏覽器直接向來源抓的，所以來源看得到你的 IP 位址、user agent，以及你要過哪些分段。這是全站唯一的隱私但書，也是不做中繼要付的代價。

關於這個工具

貼一條 .m3u8 播放清單的 HTTPS 連結，或是把本機的 .m3u8、.ts、.mp4 拖進來，它就會用你這台瀏覽器真正有的路徑開始播。Safari 和 iOS 會回報 canPlayType('application/vnd.apple.mpegurl')，所以網址直接餵給 <video>，由作業系統自己解多工。其他瀏覽器只能靠 Media Source Extensions 播 HLS，因此 hls.js 會在需要的當下才載入，去驅動同一個元素。頁面會寫明它挑了哪條路徑、為什麼這樣挑，你也可以隨時切到另一條，看同一支串流在兩邊表現差在哪。

這個工具真正的重點是影片旁邊那塊資訊面板。畫質階梯會列出主播放清單裡的每一個畫質版本：解析度、平均與尖峰頻寬、codec 字串、宣告的影格率，並標出現在正在播的那一段。音訊與字幕的替代軌會連語言、名稱、預設旗標一起列出來。緩衝顯示會告訴你播放點前面還存了幾秒，切換紀錄則把每一次畫質變動都記下來：時間、從哪一階、切到哪一階，以及當下的頻寬估計值。播放清單卡片會報出 VOD / EVENT / 直播、目標片長、分段數量，VOD 有總長度，直播則在 hls.js 有回報時顯示延遲。

播不出來的時候，它不會丟一個壞掉的播放器給你，而是把實際發生的事寫清楚。在網頁裡播不動的串流，多半根本沒壞：只是伺服器沒送 Access-Control-Allow-Origin 標頭，瀏覽器抓到了播放清單，卻找不到把內容交給這頁 JavaScript 的許可，於是擋下來。診斷會實際去試那個網址，把這種情況跟混合內容（https:// 頁面載 http:// 串流）、根本連不到的主機、以及清單讀得到但瀏覽器解不了的媒體分開，並且直接把伺服器該送的標頭寫給你看。

有一個必須講明白的但書，而且這是全站唯一的一個：串流是你的瀏覽器直接向來源伺服器抓的，所以那台伺服器看得到你的 IP 位址、你的 user agent，以及你要過哪些分段。沒有任何東西上傳到 ByteScope——中間根本沒有伺服器，這正是來源看得到你的原因。有 DRM 保護的串流（Widevine、FairPlay、PlayReady）在這裡完全播不了：它們需要跟版權方的金鑰伺服器換授權，而這一頁不參與那件事。沒加密的串流，以及金鑰 URI 連得到的 AES-128 串流，都能正常播。

常見問題

為什麼我的串流會出現 CORS 錯誤？

因為串流伺服器沒有送 Access-Control-Allow-Origin 標頭。網頁的 JavaScript 只能讀取來源明確開放的跨來源回應，而瀏覽器裡的 HLS，本質就是 JavaScript 在讀播放清單和分段。串流本身沒問題，用沒有同源政策的 VLC 或 ffplay 照樣播得動。要修是修伺服器那一端：在播放清單和分段上送 Access-Control-Allow-Origin: *（或你自己的來源），有用到 byte range 的話再加 Access-Control-Allow-Headers: Range。用 CDN 的話通常就是一個勾選項。

會上傳東西嗎？這樣算隱私嗎？

不會上傳到我們這裡——這個工具沒有伺服器，你拖進來的本機檔案也不會離開這個分頁。但遠端串流是瀏覽器直接向來源抓的，所以那台伺服器看得到你的 IP 位址、user agent 和你要了哪些分段，跟你用任何播放器打開它完全一樣。這是全站唯一的隱私但書，而且是「不做中繼」的必然結果，不是疏忽。

可以播有 DRM 的串流嗎？

不行。Widevine、FairPlay、PlayReady 都要向版權方的金鑰伺服器要授權，而簽署這個請求要用的憑證，這一頁沒有，也沒有正當管道拿到。它們會失敗，而工具會直接寫明，不會丟一個空播放器給你。AES-128 加密的 HLS 是另一回事：只要 #EXT-X-KEY 的 URI 連得到、CORS 也開著，hls.js 會去拿金鑰並正常播放。

可以開本機的 .m3u8 嗎？

可以，但有一個必須講清楚的限制。本機播放清單是從磁碟讀進來的，所以像 segment0.ts 這種相對 URI 沒有目錄可以對照，抓不到。遇到這種情況它會直接說，並開一個 base URL 欄位給你：把這份清單原本所在的目錄貼進去，所有相對 URI 就會照著它改寫。分段 URI 本來就是絕對網址的清單可以直接播；單獨一個 .ts 或 .mp4 會被包成只有一筆的播放清單，讓你檢查單一分段。

原生 HLS 和 hls.js 差在哪？

原生 HLS 是瀏覽器和作業系統自己處理播放清單——macOS 的 Safari 和 iOS 上所有瀏覽器都走這條，硬體解碼和 AirPlay 也是這條才有。hls.js 則是用 JavaScript 在 Media Source Extensions 上面實作 HLS，Chrome、Firefox、Edge 能播 HLS 全靠它。資訊面板在 hls.js 這條路上會豐富很多，因為階梯、緩衝、每一次切換都是 hls.js 主動揭露的；原生那條把這些都藏在媒體堆疊裡，所以工具只能顯示 <video> 元素願意講的那些。

畫質為什麼一直跳？

那是自適應位元率在做它該做的事：hls.js 量分段到達的速度，估出你目前可用的頻寬，再挑這個估計撐得住的最高一階。切換紀錄會把每一次判斷連同當下的頻寬估計值記下來，所以在兩階之間來回震盪的串流會變成看得見的東西，而不只是讓人煩躁——通常是階梯的兩階靠太近，或是估計值剛好卡在分界線上。用畫質選單釘住某一階，就能把估計器整個排除在外。

相關工具