網路恢復後 HLS 畫質仍模糊：ABR 診斷指南
網路頻寬恢復後，HLS 畫質仍停留在低檔？本文帶你區分 ABR 估算、手動鎖定、播放器上限、播放清單中繼資料、傳輸問題與顯示效果。
HLS 播放器在網路壅塞時降低了畫質。連線恢復、速度測試也顯示很快，畫面卻依然模糊。這不代表自適應位元率（ABR）演算法卡住了。播放器可能仍在累積新證據、正在播放先前選定的媒體、遵守手動畫質或視窗大小上限、避開最近失敗的檔位，或播放本身就不清晰的高解析度編碼。
請把目前顯示的檔位、下一個請求的檔位、頻寬證據，以及實際解碼畫面分開診斷。只測試自己擁有或獲准檢查的串流；分享記錄前移除簽章 URL、Cookie、權杖、觀眾識別碼、IP 位址和私人主機名稱。
*驗證方法 — 2026 年 9 月 25 日：*我們使用 Node.js 24.12.0 執行確定性測試，建立宣告位元率為 0.5、1.4、3.0、6.0 Mbps 的四個合成檔位。簡化估算器使用 estimate = 0.3 × sample + 0.7 × previous，並選擇不高於估算值 80% 的檔位。樣本為 0.6 和 0.8 Mbps 時選到 0.5 Mbps；網路恢復後連續收到 8 Mbps 樣本，第一次新樣本後選到 1.4 Mbps、第二次後選到 3.0 Mbps、第八次後才選到 6.0 Mbps。設定上限會把結果限制在 3.0 Mbps，手動鎖定會維持 0.5 Mbps；一個 2.4 MB、四秒的合成片段換算為 4.8 Mbps，與宣告的 3.0 Mbps 不符。這只驗證測試中的算術，不代表 hls.js 的 ABR 演算法，也沒有測試瀏覽器、HLS 播放、CDN、網路限速、解碼器、螢幕或實體裝置。測試腳本：scripts/test-hls-abr-recovery-fixture.cjs。
先確認實際播放的是哪種畫質
「模糊」是視覺症狀，不是檔位編號。至少記錄以下不同數值：
| 證據 | 能回答的問題 | 常見誤判 |
|---|---|---|
| 目前顯示的檔位 | 現在播放的影格來自哪個變體？ | 把下一個請求當成已顯示的畫面 |
| 下一個／載入中的檔位 | 播放器正要求哪個變體？ | 把排定升級說成已完成切換 |
| 影片原生尺寸 | 解碼後的影片回報什麼尺寸？ | 把 CSS 播放器大小當成來源解析度 |
| 顯示尺寸與像素比例 | 螢幕要填滿多少像素？ | 在高密度 4K 螢幕上把正常的 720p 稱為低畫質 |
| 播放器頻寬估算 | 播放器目前認為可用容量是多少？ | 用不相關的速度測試取代它 |
| 已緩衝媒體 | 已選取的內容還剩多少？ | 期待緩衝尚未播放完就立刻變清晰 |
瀏覽器影片的 video.videoWidth 和 video.videoHeight 會在媒體可用後回報資源的原生尺寸。使用 JavaScript/MSE 的播放器也要記錄目前、載入中和下一個檔位。原生 HLS 不會提供完全相同的 hls.js 屬性；應使用播放器文件說明的指標、媒體屬性和經許可的網路擷取，不要假裝它們完全一致。
記錄網路恢復後的片段證據
速度測試會對另一個服務建立連線，使用不同的快取、路由、伺服器和請求大小，無法量出此播放器取得下一個授權媒體物件的速度。請觀察實際播放工作階段送出的要求。
使用 hls.js 時，可在同一條單調時鐘上排列 FRAG_LOADING、FRAG_LOADED、FRAG_BUFFERED、LEVEL_SWITCHING、LEVEL_SWITCHED 和 ERROR 事件。記下檔位、媒體長度、位元組數、要求開始時間、首位元組時間、完成時間，以及是否來自快取。欄位必須以你實際使用的播放器版本為準，不要直接複製另一版本的記錄器。
| 頻寬恢復後的觀察 | 可能所在層級 | 下一步檢查 |
|---|---|---|
| 一段時間沒有新片段要求 | 仍在播放既有前向緩衝 | 記錄緩衝量，等待下一次選擇機會 |
| 新樣本仍然很慢 | CDN 路徑、伺服器回應、封包遺失或要求開銷 | 分開計算首位元組等待時間與傳輸時間 |
| 估算值上升，但最高檔位仍低 | 視窗、FPS、應用程式、裝置或商業規則上限 | 記錄每項上限及其設定事件 |
| 停用了自動選擇 | 手動畫質或過期的應用程式狀態 | 使用產品支援的控制項恢復 Auto |
| 已要求高檔位但出錯 | 檔位播放清單、片段、編碼、金鑰或授權 | 檢查第一個失敗的高畫質要求 |
| 高檔位已載入，畫面仍模糊 | 編碼、縮放、解碼器或檔位對應錯誤 | 確認原生尺寸並檢查獲准使用的來源媒體 |
若媒體要求停滯或到達過慢，請參考判斷 HLS 緩衝問題；若問題只在離開隱藏分頁或鎖定裝置後發生，請看背景與螢幕鎖定復原指南。
了解估算器的記憶效應
自適應播放器不應只因一次樂觀樣本就升檔，否則可能很快再次卡頓。估算器會保留近期慢速下載的證據、套用安全係數，並考慮緩衝耗盡風險。確切公式和預設值依播放器與版本而異。
我們的合成估算器需要多次 8 Mbps 樣本才選到宣告為 6 Mbps 的檔位。這只是估算器記憶和安全餘裕的示例，不是對 hls.js 或任何正式播放器的預測。hls.js 文件提供頻寬估算和設定，API 指南也說明 ABR 選擇以避免重新緩衝為目標。修改參數前，先確認實際安裝版本。
也要留意樣本不足的情況。前向緩衝很大時，播放可能不需要下載新片段；在新要求發生前，播放器也許沒有新傳輸證據。此時強制最高檔位測試的是手動覆寫，不是自動復原能力。
找出手動鎖定和硬性上限
檢查播放器介面、網址參數、儲存的偏好、帳戶權限、裝置規則、視窗邏輯、掉格保護、省流模式和應用程式狀態。搜尋所有變更檔位或最高檔位的程式碼，並為每次變更記錄原因。
常見阻礙包括：使用者選了固定畫質且偏好被保留；介面顯示 Auto 但舊的手動檔位仍生效；播放器依顯示尺寸設定上限；行動網路、省電、電池或帳戶等級觸發上限；解碼器壓力導致掉格保護降檔；高畫質變體曾失敗而暫時被避開；伺服器內容導向提供不同檔位集合；或頁面復原時元件以舊設定重建播放器。
不要一次移除所有上限。每次只改一個可控因素，記錄新的最大檔位和下一個檔位，再還原設定。即使網路容量很高，上限仍可能是為了解碼、流量、溫度或訂閱規則而設。
驗證多變體播放清單
播放器只能在成功解析且可播放的變體中選擇。保存多變體播放清單，列出每個 EXT-X-STREAM-INF URI、BANDWIDTH、AVERAGE-BANDWIDTH、RESOLUTION、FRAME-RATE、CODECS、音訊群組和視訊範圍。
RFC 8216 將 BANDWIDTH 定義為峰值片段位元率，AVERAGE-BANDWIDTH 則是平均值，並警告不準確的平均值可能造成停頓或讓用戶端無法播放變體。Apple 的 HLS 製作規範也列出宣告值與實測值的限制。不要把平均編碼輸出直接標成峰值；若有關聯音訊，測量完整可播放組合。
請確認：檔位梯度有實用差異；宣告值隨實際傳輸成本合理上升；CODECS 涵蓋變體及其群組使用的格式；高檔播放清單和首個片段在相同授權條件下可成功取得；切換所需的變體時間軸相互對齊；介面解析度標籤對應正確的檔位 ID。
我們的四秒合成片段實測為 4.8 Mbps，但虛構檔位宣告 3.0 Mbps。這只證明 位元組 × 8 ÷ 媒體秒數 的計算方式，不代表真實播放清單標示錯誤。請測量多個獲准檢查的片段，並依適用規範處理。
區分首位元組等待與傳輸容量
以位元組數和相關傳輸時段計算媒體吞吐量，同時保留連線和回應各階段。一個很小的片段可能大部分時間都在等第一個位元組。快取中的速度測試物件無法揭露來源站過載、授權緩慢、CDN 冷路徑或單一檔位主機故障。
每個片段記錄檔位 ID、宣告位元率、解析度、媒體長度；去識別化的主機／路徑分類與快取結果；要求開始、首位元組、完成、位元組數、重試及狀態；回應是否真的是媒體而非 HTML 錯誤頁；選擇與下載完成時的緩衝量；以及播放器公開的前後估算值。比較同一工作階段的高低檔位；若只有高檔物件慢或失敗，調整全域估算器通常不是正確修復。
不要把檔位和主觀銳利度混為一談
播放器即使回報 1080p，畫面仍可能模糊：來源可能本來就失焦，編碼器可能配置太低的位元率，播放器可能把影像放大到超過解碼尺寸，瀏覽器縮放會影響比較，或螢幕像素密度很高。反過來說，小播放器中的 720p 也可能恰到好處。
記錄 videoWidth、videoHeight、元素顯示矩形、像素比例，以及選中檔位宣告尺寸。透過編碼品質管制流程，比較獲准使用的來源與變體影格。不要單憑肉眼判定檔位過低，也不要沒看實際媒體就宣稱編碼有缺陷。
安全復原，不要強制最高畫質
通常先解除非預期的手動鎖定或錯誤上限，再讓自動選擇觀察新下載。強制最高檔位可能造成停頓並掩蓋原始原因。hls.js 將 nextAutoLevel 定義為下一個自動選取檔位，並指出在特定啟動情況下設定它可能只影響一個片段；這不能證明自動升檔已持續成功。
可將成功定義為一連串可觀察結果：自動選擇已啟用且上限已確認；實際 HLS 路徑收到新片段樣本；頻寬估算合理變化；選取更高檔位且要求成功；LEVEL_SWITCHED 確認切換；原生尺寸和持續播放證實結果顯示在畫面上；播放穩定一段時間，排除立刻降回低檔。
若還需要返回直播位置，請把它當成獨立決策。直播延遲與 Go Live 指南會說明畫質選擇和直播位置是不同控制項。
執行可控的復原矩陣
使用真正支援的播放器和獲准檢查的檔位，重複執行網路限速測試，並記錄限速工具、目標速率、延遲、封包遺失、持續時間，以及限制作用於瀏覽器、裝置還是獨立代理。
| 維度 | 最低測試案例 |
|---|---|
| 復原模式 | 突然恢復、逐步恢復、短暫尖峰、穩定高容量 |
| 緩衝狀態 | 幾乎耗盡、一般、大量前向緩衝 |
| 選擇狀態 | Auto、各手動檔位、視窗上限、應用程式上限 |
| 傳輸路徑 | CDN 暖快取、冷路徑、來源站、高檔位失敗案例 |
| 內容類型 | VOD 與直播、低／高動態、代表性的片段大小差異 |
| 播放路徑 | hls.js/MSE、支援時的原生 HLS、官方手機或電視路徑 |
| 顯示方式 | 小播放器、全螢幕、不同像素比例 |
桌面瀏覽器分頁限速不能證明手機無線網路切換、解碼限制、省流政策或電視表現。未測試的平台應明確標示未測試。不要為了重現問題而削弱授權，或公開帶簽章的媒體網址。
報告圍繞一次檔位選擇機會
有用的報告可以這樣寫：「自動選擇已啟用。網路受限期間後，正在播放檔位 0，前方緩衝 14 秒。第一個新片段以 7.6 Mbps 完成，估算升到 2.9 Mbps，播放器要求檔位 1。再累積樣本後估算上升，檔位 2 成功切換。檔位 3 仍被排除，因為視窗控制器把 autoLevelCapping 設為 2。」這描述了證據與責任層級，而不是籠統地說演算法卡住。
附上播放器和瀏覽器版本、檔位表、自動／手動狀態、每個上限及設定來源、前向緩衝、片段時間、估算值、檔位事件、錯誤、原生與顯示尺寸，以及去識別化要求 ID。並說明哪些平台是實體測試、哪些僅核對文件。
主要參考資料
- RFC 8216：HTTP Live Streaming
- Apple：Apple 裝置的 HLS 製作規範
- Apple：HLS 製作規範附錄
- hls.js API：播放器狀態與頻寬估算
- hls.js API：事件
- hls.js API 指南
- MDN：HTMLVideoElement videoWidth
- W3C：Media Source Extensions
先確認正在播放的檔位、下一個選取檔位，以及限制最高檔位的規則，再追蹤網路恢復後的第一批實際片段樣本。這些證據能區分正常的估算器記憶、手動鎖定、硬性上限、播放清單宣告錯誤、高檔位傳輸故障，或 ABR 無法解決的影像品質問題。