題幹與適用場景
如果要在瀏覽器中實作即時影片預覽、濾鏡與上傳，你會如何用 WebCodecs 組織擷取、解碼、處理、編碼與封裝，並處理背壓、時間戳與瀏覽器能力差異？
這道題適合前端、瀏覽器、即時音訊影片與多媒體職位。重點是資料流與資源邊界，而不是背 API 名稱。WebCodecs 提供原始影格、編碼區塊以及編碼器和解碼器介面，但不負責把編碼資料自動封裝成可播放檔案，也不保證每種 codec 在每個瀏覽器都可用。
面試官考察點
- 能否區分原始
VideoFrame、EncodedVideoChunk與容器封裝。 - 是否把擷取、處理、編碼和傳送拆成有界佇列。
- 是否理解
configure、encode、flush、reset、close的生命週期。 - 是否用 Worker、
VideoFrame.close()和佇列深度控制主執行緒與記憶體。 - 是否處理時間戳、關鍵影格、丟影格和音畫同步。
- 是否透過
isConfigSupported()、能力矩陣和降級路徑應對瀏覽器差異。
30 秒回答框架
「我會把鏈路拆成擷取、解碼、影格處理、編碼、封裝和上傳六段。原始影格和編碼區塊都帶時間戳，佇列設上限；生產速度超過編碼或網路消費速度時丟棄可重建的中間影格，並保留關鍵影格與指標。重運算放在 Dedicated Worker，及時關閉已消費的 VideoFrame。啟動前用能力探測選擇完整設定，失敗時退回 MediaRecorder 或伺服器處理。上傳前再做容器封裝，監控延遲、佇列深度、丟影格和編碼錯誤。」
分步驟深入解答
第一步：定義資料型別和邊界
擷取層可以從 MediaStreamTrack 取得影格，解碼層把編碼區塊轉成 VideoFrame，濾鏡或縮放消費並產生新影格，編碼層把影格轉成 EncodedVideoChunk。這些物件不是同一種資料，不能把編碼區塊直接當成可播放檔案。
容器封裝負責把編碼區塊、時間戳和軌道資訊寫入 MP4、WebM 等格式。若目標只是即時傳送，可以直接傳送編碼區塊和設定中繼資料；若目標是下載或回放，則必須增加 muxer，並驗證產生檔案的時間軸。
第二步：把處理放入可觀測流水線
每段佇列都記錄目前長度、等待時間和丟棄數。瀏覽器主執行緒只負責控制、預覽和使用者互動，逐影格處理放在 Dedicated Worker；Worker 與主執行緒之間傳遞可轉移或可關閉的影格物件，避免長期持有底層圖形記憶體。
濾鏡不應無限制複製影格。處理完成後明確所有權：編碼器或繪製器接管的影格由對應消費者關閉，例外路徑也要釋放。佇列滿時優先丟棄尚未編碼的非關鍵影格，不能讓記憶體增長掩蓋即時性下降。
第三步：設定編碼器並處理生命週期
先呼叫能力探測確認 codec、寬高、影格率、bitrate 和硬體加速選項，再建立 VideoEncoder。configure() 後依序呼叫 encode()；結束輸入時呼叫 flush() 等待已提交工作完成，重新設定或故障恢復時使用 reset()，徹底退出時呼叫 close()。
編碼輸出回呼只負責把 chunk 交給下游，不能在回呼中做無界同步工作。遇到設定錯誤、編碼錯誤或輸出佇列過深，要停止繼續餵影格並進入降級或重啟流程，避免錯誤持續放大。
第四步：設計背壓、丟影格與延遲策略
即時預覽通常更在意新鮮度，上傳歸檔更在意完整性。為兩者設定不同策略：預覽佇列只保留最近窗口，歸檔佇列可以暫停擷取或降低影格率。用高水位暫停生產、低水位恢復生產，避免只靠計時器猜測負載。
丟影格時保留時間戳連續性和關鍵影格邊界。若編碼器需要從關鍵影格重新解碼，恢復點應強制請求關鍵影格；網路傳送端記錄編碼佇列、傳送佇列和確認延遲，區分編碼慢、網路慢與渲染慢。
第五步：處理時間戳和音畫同步
所有影格與編碼區塊都使用統一時間基準，不能用抵達時間取代媒體時間戳。濾鏡改變處理耗時，不應改變原始呈現時間；重取樣、丟影格和變速都要明確更新時間軸。
音訊鏈路採用相同原則，並以主時鐘校正漂移。播放器或上傳器發現時間戳倒退、間隔異常或軌道結束不一致時，應標記損壞片段並停止靜默拼接，否則會產生音畫跳變。
第六步：做能力探測、降級和觀測
能力探測只說明目前設定是否被實作支援，不代表長時間編碼一定符合目標影格率。執行中繼續記錄編碼耗時、輸出間隔、錯誤類型、佇列深度和裝置資訊，並以小樣本測試確認硬體加速是否真的生效。
瀏覽器不支援目標 codec 或 Worker 鏈路時，可降級為 MediaRecorder、降低解析度和影格率，或上傳原始片段交由伺服器處理。降級必須保持使用者可理解的狀態，並保留原始媒體，避免半成品無法恢復。
資訊增益與邊界
這道題的關鍵增益是把「瀏覽器能編碼影片」落實為有界、可恢復的資料流：WebCodecs 提供影格和編碼區塊介面，Worker 減少主執行緒阻塞，背壓和時間戳保證即時性，封裝與能力探測保證結果可播放、可降級。
它不等於瀏覽器會自動完成 muxing、跨瀏覽器 codec 統一或無限吞吐。生產設計仍要評估隱私、攝影機權限、裝置溫度、記憶體上限、上傳中斷和伺服器相容性。
高品質示範回答
「我會先定義目標是即時預覽、即時傳輸還是可下載歸檔，因為三者對丟影格和完整性的取捨不同。擷取後的媒體進入解碼、影格處理、編碼、封裝和上傳流水線，VideoFrame、EncodedVideoChunk 和容器檔案分別建模，不能混用。
逐影格工作放在 Dedicated Worker，每段佇列設定高低水位並記錄深度、等待時間和丟影格數。預覽佇列保留最新影格，歸檔佇列在高水位時暫停擷取或降低影格率；重啟時從關鍵影格恢復。統一使用媒體時間戳，音訊用同一時鐘校正漂移。
啟動前探測 codec、尺寸、影格率、bitrate 和硬體選項；執行中觀察編碼耗時、輸出間隔、錯誤和裝置資源。flush 用於等待已提交資料，reset 用於重新設定，close 用於釋放資源。輸出區塊要交給 muxer 產生目標容器，不能直接假設能播放。
如果能力或效能不符合目標，我會降低解析度、降低影格率、切換 MediaRecorder 或轉伺服器處理，並向使用者保留可恢復的原始片段。這樣方案同時覆蓋正確性、即時性、資源安全和跨瀏覽器降級。」
常見錯誤
- 把
EncodedVideoChunk當檔案 → 它缺少容器軌道和封裝資訊 → 歸檔路徑增加 muxer 並驗證時間軸。 - 只呼叫
isConfigSupported()就宣稱可用 → 長時間負載仍可能掉影格或報錯 → 用短時壓測和執行指標覆核。 - 佇列無上限 → 編碼變慢時記憶體持續增長 → 高低水位背壓並明確丟影格策略。
- 不關閉
VideoFrame→ 圖形記憶體無法及時釋放 → 按所有權在成功和例外路徑關閉。 - 用抵達時間重寫時間戳 → 延遲抖動會變成音畫漂移 → 沿用媒體時鐘並記錄修正。
- 只測一個瀏覽器 → codec、硬體和 Worker 能力可能不同 → 建立能力矩陣與降級鏈路。
追問及應對
為什麼不能直接把編碼區塊寫成 MP4？
編碼區塊只表示 codec 資料和時間資訊，MP4 還需要軌道、樣本表和容器中繼資料。應使用相容的 muxer，將區塊依時間順序寫入並驗證播放器行為。
佇列滿時為什麼優先丟非關鍵影格？
關鍵影格是後續解碼的恢復點；丟掉普通影格可以降低延遲，保留關鍵影格能讓解碼器在下一恢復點重新建立上下文。歸檔場景則應暫停生產或降低品質，而不是靜默丟資料。
如何判斷硬體加速真的有效？
比較相同設定下的編碼耗時、CPU 使用率、輸出影格間隔和溫度趨勢，並持續觀察錯誤和掉影格。設定欄位只是請求或偏好，不能取代執行時測量。
什麼時候把處理切到伺服器端？
當裝置能力不足、瀏覽器不支援目標 codec、需要統一轉碼或原始媒體不能留在端上時切換。客戶端應上傳可恢復片段，並顯示處理狀態和重試邊界。