直播錄影故障排除：9 大常見失敗及修復方案

你點下錄影鈕開始錄製直播，兩小時後打開檔案才發現錄影在 30 分鐘時就停止了。或者沒有音訊。或者檔案根本無法播放。又或者當你把播放器鎖定在 1080p 時，解析度卻莫名降到 480p。

直播錄影比 VOD 下載有更多的失敗模式，因為資料來源不斷變化——manifest 會輪轉、片段會逾時、主機的碼率波動、CDN 在會話中途切換邊界節點。本文是針對我們最常見的 9 大失敗的診斷流程圖，說明每種失敗的原因及其解決方案。

1. 錄影隨機在中途停止

症狀：你開始錄製一場 4 小時的直播，但檔案只有 45 分鐘長，而直播仍在進行。

最可能的原因：manifest URL 已輪轉，但錄影程式沒有跟進。

Twitch 約每 24 小時輪轉一次 HLS manifest 權杖。TikTok 約每 30 分鐘輪轉一次。Bilibili 在每次變更畫質時輪轉。一個簡單的錄影程式如果寫死了原始 URL，一旦該 URL 返回 403/404 就會放棄。

修復方案：使用一個能定期重新解析 manifest URL 的錄影程式。Video Downloader One-for-All 在每次擷取失敗時都會這樣做。如果你的錄影程式不這樣做，唯一的解決方案就是切換工具。

其他可能的原因：

• 瀏覽器分頁被暫停（Chrome 會積極暫停背景分頁以節省記憶體）——保持串流分頁可見或將其釘住
• 網路故障——足以中斷連線，但你沒注意到
• 磁碟空間已滿

2. 檔案中沒有音訊

症狀：影片播放正常，但完全沒有聲音。

最可能的原因：錄影程式沒有將音訊和影片混合到一起。

大多數直播分別提供音訊和影片作為獨立的 HLS 變體。要產生可播放的檔案，錄影程式必須同時擷取兩者、進行解多工，再重新多工到單一容器中。有些錄影程式（尤其是較舊或較簡單的）只擷取影片變體而完全跳過音訊。

修復方案：選擇一個明確宣傳直播音訊混合功能的錄影程式。在開始任何長時間錄製之前，先用 30 秒的測試錄影驗證一下。

其他可能的原因：

• 錄影時音訊變體無法使用（罕見，但在主播端出現技術問題時會發生）
• 播放器在系統層級被靜音了，而你的錄影程式竟然在做螢幕錄製而不是串流錄製（這不太常見；如果是這樣，你用錯工具了）

3. 檔案在 VLC 中可播放，但在 QuickTime／Windows Media Player 中不行

症狀：VLC 能正常開啟檔案，但原生 OS 播放器顯示錯誤。

最可能的原因：輸出是 .flv 或 .ts 檔案，原生播放器不支援這些格式。

VLC 和 MPV 支援任何容器；OS 內建播放器則很挑剔。FLV（Bilibili Lives）、TS（HLS 來源）和 MKV 在 VLC 中都能播放，但會在 QuickTime／Windows Media Player 中出問題。

修復選項：

• 使用預設輸出 MP4 的錄影程式（將 TS/FLV 重新多工轉換為 MP4 是無損且瞬間完成）
• 執行 ffmpeg -i input.flv -c copy output.mp4 以重新多工而不重新編碼
• 始終使用 VLC 播放錄製檔案

4. 檔案可播放但搜尋功能損壞

症狀：檔案從開頭播放正常，但拖動播放頭會跳過或凍結。

最可能的原因：moov atom 在 MP4 的末尾而不是開頭。

MP4 中繼資料（「moov atom」）告訴播放器每個關鍵幀的位置。如果它在末尾，播放器必須在能夠搜尋之前下載整個檔案。對於本機檔案，這通常沒問題，因為播放器只會載入所有內容，但某些播放器在搜尋期間無法正確處理 moov-at-end。

修復方案：執行 ffmpeg -i input.mp4 -c copy -movflags +faststart output.mp4。錄影程式應該自動執行此操作；如果沒有，那是錄影程式的 bug。

Video Downloader One-for-All 預設會寫入 faststart MP4。

5. 畫質低於你設定的畫質

症狀：將播放器鎖定在 1080p60，但檔案是 720p。

最可能的原因：播放器因為感知到頻寬壓力而在會話中途降級，你的錄影程式也跟著降級。

自動畫質邏輯內建在大多數播放器中。即使你「鎖定」到 1080p60，某些播放器（尤其是 Twitch 的）如果認為網路擁塞就會悄悄降低畫質。一個錄製播放器正在播放的內容的錄影程式會錄下降級的畫質。

修復方案：

• 使用獨立於播放器目前播放內容的畫質變體的錄影程式——這保證了無論播放器決策如何，都能獲得來源品質
• 或者只需確保有足夠的頻寬裕度

其他可能的原因：

• 直播從未在設定的畫質可用（有些主播只以 720p 廣播，無論你的下拉式選單說什麼）
• 畫質選單有多個「1080p」選項，你選了錯的（Twitch 有時會列出「1080p」和「1080p60」，它們的碼率不同）

6. 錄影立即失敗，顯示「未偵測到影片」

症狀：點擊擴充功能，彈窗顯示「未偵測到影片」，即使直播正在播放。

最可能的原因：頁面是在擴充功能安裝或重新整理之前載入的。

瀏覽器擴充功能會連接到內容指令碼的網路事件。在指令碼載入之前觸發的事件已經消失。如果 manifest 擷取發生在頁面載入期間且擴充功能還未執行，擴充功能永遠不會看到該串流。

修復方案：重新整理頁面。Manifest 擷取將重新觸發，擴充功能會看到它。

其他可能的原因：

• 該串流使用擴充功能不支援的協定（在 2026 年罕見；HLS、DASH、FLV 和 WebRTC 涵蓋約 99% 的直播）
• 該網站使用 DRM，擴充功能正確拒絕錄製——參考為什麼無法錄製受 DRM 保護的直播

7. 錄影大小遠小於預期

症狀：你錄製了 2 小時的串流，檔案只有 50MB。

最可能的原因：錄影程式只錄製了最低畫質變體，或只錄製了音訊，或只錄製了 manifest 而不是片段。

2 小時 1080p60 的錄製在典型 Twitch 碼率下應該約為 3-6 GB。50MB 表示有非常嚴重的問題。

修復方案：進行 30 秒的測試錄製，檢查結果檔案大小。30 秒 1080p60 的錄製應該是 25-50MB。如果你的 30 秒測試是 1-2MB，錄影程式從根本上就壞了——切換工具。

8. 長時間錄製期間瀏覽器崩潰

症狀：Chrome 在錄製幾小時後凍結或崩潰。

最可能的原因：錄影程式在記憶體中暫存所有內容，而不是串流到磁碟。

好的直播錄影程式會在片段到達時將其寫入磁碟並丟棄記憶體內緩衝。不好的會在記憶體中累積所有內容，直到 Chrome 用完分配給轄區處理程序的 RAM（通常每個轄區程序 2-4GB），然後崩潰。

修復方案：選擇持續將片段寫入磁碟的錄影程式。OFA 擴充功能就是這樣做的。長時間廣播（12+ 小時）無論錄製長度如何，應該只使用約 50MB 的 RAM。

9. 錄影已完成但檔案根本無法開啟

症狀：錄製已完成，但檔案在每個播放器中都給出「未知格式」錯誤。

最可能的原因：錄影程式無法寫入 moov atom 或未正確關閉檔案。

如果錄影程式崩潰或你在錄製中途強制結束 Chrome，MP4 可能遺失其結尾的 moov atom。影片資料存在，但沒有播放器能對其進行索引。

修復方案：

• 執行 ffmpeg -i broken.mp4 -c copy fixed.mp4 看 ffmpeg 是否能復原（通常可以）
• 執行 untrunc（專為復原截斷 MP4 而設計的開源工具）——它能從參考的健康檔案重建 moov atom
• 最壞的情況是錄製檔案遺失

預防：選擇一個寫入增量 moov 更新的錄影程式，這樣即使錄製中斷，部分檔案仍可播放。某些錄影程式也提供「fragment MP4」輸出，這是為了能夠在錄製進行中途也可播放而設計的。

任何長時間錄製前的診斷檢查清單

對於任何計劃超過一小時的錄製，首先執行此檢查清單：

1. 5 分鐘測試錄製，使用相同的畫質和來自相同的來源
2. 在 QuickTime／Windows Media Player 中開啟測試檔案（不是 VLC——VLC 什麼都能播放）
3. 驗證音訊存在
4. 驗證搜尋功能正常運作
5. 檢查檔案大小是否合理（以 1080p60 計約每分鐘 50-100MB）

如果檢查清單中有任何項目失敗，在開始真正的錄製之前先修復它。「我剛錄了 6 小時的串流，結果沒有音訊」這種情況無法復原。

何時停止除錯並切換工具

如果你已經嘗試了兩三個不同的錄影程式，並且持續遇到相同的失敗（尤其是 #1、#2、#7），問題不在你的設定——而是該情況下可用的錄影程式還不夠成熟。考慮：

• 對於 Twitch／Kick／YouTube Live：任何支援 HLS 的錄影程式都應該有效，包括 Video Downloader One-for-All
• 對於 Bilibili：特別需要 FLV 支援——不是所有 HLS 錄影程式都能處理它
• 對於 TikTok Live：需要積極處理會話中途的 manifest 輪轉
• 對於受 DRM 保護的串流：按設計，沒有擴充功能能運作

底線

大多數直播錄製失敗分為九個模式，大多數都有不需要切換工具的修復方案。最大的改進來自於：在開始前重新整理頁面（修復 #6）、在錄製前鎖定畫質（修復 #5），以及使用能處理 manifest 輪轉的錄影程式（修復 #1）。對於任何超過一小時的錄製，始終先進行 5 分鐘的測試錄製——發現 6 小時的錄製在第 6 小時時損壞是最壞的情況。