網路攝影機實際串流測試 — 對方真正看到的畫面品質
你在網路攝影機預覽中看到的影像是本地擷取視圖——透過 getUserMedia() 傳遞的攝影機畫面——而非原始感測器輸出。視訊通話對方收到的是經 WebRTC 協商、壓縮並可能降級的瀏覽器編碼串流。本指南說明 WebRTC 編解碼器協商如何運作、如何在 RTCPeerConnection 上使用 getStats() 測量實際串流參數，以及如何修正常見的品質損失原因。本站的攝影機工具僅檢查本地擷取軌道和瀏覽器幀率，不測量 outbound WebRTC 編碼串流。
你坐在視訊通話中，自己的視窗顯示清晰、光線充足的 1080p 影像。你看起來銳利、背景乾淨、構圖正確。然後同事說你的視訊一直凍結和模糊，他們分享螢幕時你看到自己是一個十年前廉價網路攝影機才會產生的方塊方塊狀、邊緣模糊的畫面。同一台攝影機。同一個照明。同一台機器。不同的影像。
大多數視訊通話指南跳過的是：那個差距通常不是硬體故障或感測器缺陷——雖然偶爾驅動程式異常也會造成。它通常是攝影機產生的畫面與瀏覽器實際送出的畫面之間的差異。你的預覽從本地擷取路徑供應——WebRTC 編碼之前的畫面。對方收到的是在離開你機器的毫秒之間被 WebRTC 協商、重新編碼、速率限制並可能降級的壓縮串流。
那個編碼層從使用者介面看不到，在正常運作時也無聲無息。通話視窗中沒有任何東西告訴你它存在，沒有東西報告它的決定，你的預覽也不反映它們。一個熟悉的場景：使用者花幾小時重新安裝攝影機驅動程式，因為通話中顯示模糊影像——結果透過 chrome://webrtc-internals 發現瀏覽器是根據頻寬估算協商降到 480p15，而不是攝影機或驅動程式的問題。本頁說明攝影機感測器與通話對方螢幕之間發生了什麼、瀏覽器為什麼默默降低你的品質，以及最重要的是——如何測量離開你機器的實際串流，而非信任預覽。
預覽沒有告訴你的事
視訊通話建立在一個完全在你意識之外運作的管線上。你送出的每個畫面經過以下階段：
- 攝影機感測器擷取一一幀；瀏覽器透過 getUserMedia() 以請求的解析度和幀率傳遞。
- 瀏覽器透過
getUserMedia()API 接收該幀並交給 WebRTC 引擎。你的本地預覽從這個階段供應——所以它總是看起來完美。 - WebRTC 編碼器以協商的編解碼器、解析度、幀率和位元率將畫面壓縮成位元流。
- 編碼後的畫面被分割成 RTP 封包透過網路傳送。
- 每個接收端將封包解碼回畫面並渲染到螢幕上。
你的預覽在第二階段接入管線。它顯示的是 WebRTC 編碼之前的畫面。通話對方看到的串流是第三階段的產出。在這兩點之間，編碼器決定了世界收到什麼，而它根據你看不見的條件做決定。
編碼器默默協商三個參數，每個都可能在通話中途無預警變更：
- 解析度 — 編碼幀的寬度和高度，可能從 1920x1080 自動降到 1280x720 或 640x480。
- 幀率 — 編碼後存活的每秒幀數，通常最先下降（從 30 降到 15 或更低）。
- 位元率 — 編碼器每秒可使用的位元數，設定整體壓縮程度。
這三個值決定了對方看到的一切。以低位元率壓縮的 1080p 影像看起來柔軟模糊。30fps 串流突然以 10fps 運行看起來抖動不自然。當你理解預覽不報告這些值中的任何一個，好攝影機卻通話品質差的謎團就解開了。
SDP 在你送出第一幀之前協商
協商在第一幀送出之前就開始了。加入通話時，平台和你的瀏覽器交換 Session Description Protocol（SDP） 提供和回答。SDP 廣告雙方支援的編解碼器和媒體能力；實際解析度和幀率隨後透過傳送和接收參數進一步協商，並受頻寬估算限制。
編解碼器選擇只是開始。通話建立後，第二個機制接管：頻寬估算。WebRTC 持續監控雙向網路路徑並執行擁塞控制演算法：
- 封包遺失，接收端透過 RTCP 回饋訊息報告。
- 往返時間，送出封包到收到確認之間的延遲。
- 吞吐量，資料實際跨越連接的有效速率。
演算法將這些測量值輸入估算網路當前能承載多少頻寬的模型。該估算成為交給編碼器的目標位元率，編碼器調整輸出以配合。迴圈持續且快速：估算下降時，編碼器在不到一秒內以較低位元率重新編碼。
持續封包遺失超過約 5% 可能觸發目標位元率降低。1080p 30fps 串流通常需要約 4~6 Mbps 上傳頻寬才能看起來乾淨。如果估算器結論只有 1 Mbps 可用，它不會強推串流——而是降低目標，編碼器回應以降低解析度到 480p 和幀率到 15fps（Google: WebRTC Congestion Control Whitepaper, 2019; RFC 8888: Congestion Control Feedback for RTP）。
串流隱藏的三種失敗模式
預覽將串流的真實狀態隱藏三種反覆出現的失敗模式背後。學會從症狀辨識每一種，因為正確的修復因情況而異。三種共用一個特徵：預覽全程保持完美，因為它在編碼器之前取樣。只有編碼串流——以及對方的螢幕——顯示損壞。
位元率陷阱
症狀： 預覽完美、CPU 閒置。對方看到永不銳化的模糊低解析度影像。本地錄影出色；通話卻差。 診斷： 瀏覽器估算網路無法承載完整串流並限制了位元率，迫使編碼器縮小解析度。限制是上傳頻寬或媒體伺服器中繼容量，不是攝影機。跑速度測試比較量到的上傳與 1080p30 需要的 4~6 Mbps。
遺失閾值
症狀： 通話的靜止影像看起來好，但任何動作都抖動且像機器人。音訊保持流暢而視訊卡頓，每隔幾秒短暫凍結後以較低幀率恢復。 診斷： 封包遺失間歇性跨越 5% 閾值，擁塞控制器反覆削減目標位元率，編率，編碼器丟幀以配合。幀率先降——從 30 降到 15 fps 可減半資料率而不改解析度。檢查 Wi-Fi 干擾、不良乙太網路線或增加遺失和延遲的 VPN。
關鍵幀凍結
症狀： 加入後或分享螢幕後的前 2~5 秒，對方看到凍結或嚴重模糊的影像。然後畫面突然對焦並正常運作直到下次大場景變化。
診斷： 視訊編解碼器送出兩種幀類型。關鍵幀編碼整個畫面，在固定間隔出現。增量幀只編碼自上一幀以來的變化。增量幀封包遺失時接收端無法重建——可要求重傳、要求新關鍵幀或在等待時隱藏錯誤。請求成功時恢復快；失敗時畫面凍結直到下個排程關鍵幀到達。
用 getStats() 測量實際串流
停止猜測。數字不好看，但真實。WebRTC API 暴露了統計介面，報告編碼器確切在做什麼。在 RTCPeerConnection 物件上呼叫 getStats()，然後過濔回傳報告中 kind 為 video 的 outbound-rtp 條目。關鍵值：
- framesPerSecond（media-source 條目）— 攝影機交付給編碼器的幀率。30fps 攝影機上低於 30 表示擷取路徑本身有問題——這往往是 USB 頻寬競爭問題，我們的 USB 頻寬競爭指南講解了如何診斷。
- framesPerSecond（outbound-rtp 條目）— 編碼器實際產生的幀率。低於輸入表示編碼器在丟幀。
- frameWidth 和 frameHeight（outbound-rtp 條目）— 編碼解析度。與通話設定比較；任何差異都是默默降級。
- bytesSent（outbound-rtp 條目）— 總編碼資料。間隔一秒取樣兩次，差值乘 8 得到實際位元率。
- packetsSent 和 packetsLost — 注意 outbound-rtp 條目的 packetsLost 不一定有值；遺失率從 remote-inbound-rtp 條目讀取更可靠，該條目報告接收端視角。
- currentRoundTripTime（candidate-pair 條目）— 網路延遲。高 RTT 加遺失表示擁塞。
你不需要寫程式來讀取這些值。Chrome 和 Edge 內建統計檢視器在 chrome://webrtc-internals，擷取瀏覽器中每個 WebRTC 連線。在加入會議前開啟它，讓它錄製，然後檢查視訊發送者的 outbound-rtp 條目。這是在真實平台通話中當場抓住降級的最快方式。
Zoom、Meet、Teams：三種不同的攝影機
同一台攝影機、同一台筆電、同一個網路在不同應用中可能產生明顯不同的結果，因為每個平台在瀏覽器的 WebRTC 實作之上套用自己的編碼政策。
- Zoom 通常優先穩定性。可能限制送出解析度並犧牲視訊品質以保持音訊和螢幕分享穩定。
- Google Meet 傾向適應測量到的頻寬，早期降低解析度並在條件改善時快速恢復。
- Microsoft Teams 套用自己的編碼和後處理管線。影像可能被進一步壓縮。
- 瀏覽器原生 WebRTC 送出協商串流，沒有平台政策疊加。是硬體和網路在普通 WebRTC 下能提供什麼的最接近真相。
實用結論：比較 Zoom 通話和 Meet 通話不是攝影機測試。是各平台編碼決策的測試。先用普通 WebRTC 頁面或網路攝影機測試工具測量原始串流。如果原始串流乾淨而某平台仍差，平台的政策是限制因素，硬體升級無法改變。
乾淨串流的七個步驟
這些步驟隔離不同的原因。串流看起來正確時可以停止——但每次變更前後都要測量以確認修復確實移動了數字。
- 先測量。 開啟 chrome://webrtc-internals 或用 getStats() 記錄解析度、幀率和位元率。如果原始串流已降級，攝影機和連接是問題。如果乾淨，平台是問題。
- 檢查頻寬。 視訊通話 720p 至少需要 1 Mbps 上傳，1080p 約 4 Mbps。從通話的機器測試。可能就改用有線連接；Wi-Fi 遺失是看不見降級的最常見原因。
- 修照明。 光線充足的拍攝對象比暗的壓縮效果好得多。面向窗戶或使用柔和光源。不花錢且經常產生比任何設定更大的改善。
- 停用視訊降噪。 環境已安靜且照明良好時。某些平台在低光場景中套用激進降噪，可能明顯柔化編碼串流中的精細細節。
- 停用虛擬背景。 背景分割增加有效位元率的開銷並消耗編碼器的 GPU 週期。照明一致的乾淨真實背景勝過任何虛擬背景。
- 檢查編解碼器。 CPU 可負荷時 VP9 提供每位元最佳品質；看到幀丟或 CPU 突升時 H.264 編碼更快。
- 測試不同平台。 一個服務品質好而另一個差，平台的編碼政策是限制因素。你的硬體沒有問題。
結論
預覽是攝影機的本地自畫像：攝影機能交付給瀏覽器的有利視圖。串流是世界實際看到的——經協商、壓縮，由網路狀況和平台政策塑造。它們是同一拍攝對象的兩段不同影片，只有一段對你的呈現方式重要。
開啟 chrome://webrtc-internals。加入你的下次通話。觀察 outbound-rtp 條目。如果 frameWidth 或 framesPerSecond 低於攝影機設定中的值，降級正在發生。原因通常與頻寬相關——瀏覽器被允許花費多少，以及你的連接是否真的能承載你以為在送的串流——但 CPU 負載、編碼器選擇、平台政策和約束配置也可能貢獻或主導降級。