Varidata 新聞資訊

知識庫 | 問答 | 最新技術 | IDC 行業新聞

為什麼直播串流媒體伺服器中的封包遺失與抖動比延遲更可怕

發布日期：2026-08-14

Packet loss and jitter degrading live streaming quality

你可能認為，延遲會徹底毀掉你的影片觀賞體驗。基礎延遲只是一種簡單、靜態的時間偏移。它會把你的觀賞時間軸整體往後推移幾秒鐘，但可以保留 100% 的影片畫面與資料完整性。相比之下，當網路中出現封包遺失與抖動時，直播串流媒體伺服器（例如你的日本伺服器）就會開始吃力。封包遺失會讓關鍵資料永久消失，你會看到畫面掉幀、嚴重馬賽克，以及刺耳混亂的音訊。與此同時，抖動會帶來不可預期的時間序波動，這些波動會干擾視訊解碼器並破壞播放同步。觀眾其實可以輕鬆容忍穩定的多秒級延遲，但不穩定的傳輸與遺失的封包卻會一再真實地破壞直播媒體的播放體驗。你也可能在觀賞直播媒體時頻繁遭遇這些問題。

關鍵重點

簡單的播放延遲只是把觀賞時間整體往後移，並不會損害畫面品質。
封包遺失會讓視訊資料永久消失，導致明顯的畫面瑕疵與馬賽克。
網路抖動會改變封包到達時間，從而破壞視訊與音訊的正確解碼。
現代串流協定（如 SRT）可以重傳遺失的封包，讓影片維持流暢。
合理設定抖動緩衝，可在惡劣網路環境下保護直播串流不至於頻繁卡頓。

作為可預測時間偏移的延遲

傳播與處理延遲

你感受到的基礎延遲，本質上是從實體攝影機拍攝到螢幕顯示之間的一個可預測時間偏移。這種初始延遲，會在直播視訊訊號穿越全球網際網路基礎設施時自然累積。距離會帶來不可避免的傳播延遲，因為光脈衝需要時間在光纖中傳遞。

在核心媒體處理流程中，直播串流媒體伺服器還會引入必要的處理延遲：

處理階段	典型延遲
擷取 / 編碼	2–120 ms
源站封裝	50–500 ms
未最佳化佇列	1–2 s

硬體編碼器在進行 H.264 或 HEVC 壓縮時通常需要 2–120 ms。源站封裝器在產生 HLS 或 DASH 切片時需要 50–500 ms。未最佳化的接入佇列還可能額外帶來 1–2 秒的延遲。這些相對固定的延遲，只是把你的觀賞時間整體往後平移，卻不會破壞影片的原始結構。

維持串流的完整性

可預測的延遲更像是一種有序緩衝，而不是毀壞媒體的故障點。傳輸協定會透過不同的架構方式來管理這種時間偏移：

協定	典型延遲	延遲等級
RTMP	5 秒（5,000 ms）	低
SRT	120 ms–4,000 ms	中

RTMP 一般可以把直播延遲控制在大約 5 秒（5,000 ms）左右，屬於低延遲。SRT 通常運作在 120 ms–4,000 ms 的中等延遲範圍內，你可以根據往返時間（RTT）與重傳需求來配置 SRT 的延遲參數。舉例來說，往返時間為 50 ms 的鏈路通常會設定約 200 ms 的延遲，而衛星鏈路則需要更高的延遲預算。

只要連線中的延遲維持穩定，你就能依序收到每一個媒體畫面。伺服器會有序地透過網路傳送關鍵畫面、差值畫面與音訊封包。固定的時間偏移在保留完整串流資料的同時，不會引入可見的偽影。由於封包以穩定節奏到達，視訊解碼器可以平順輸出高畫質影像。

封包遺失與抖動如何擾亂直播串流媒體伺服器

不穩定的網路連線會嚴重破壞直播媒體的傳輸品質。封包遺失與時間抖動會主動破壞直播串流媒體伺服器上的播放品質。任何時候只要網路遺失媒體封包，你就會立即看到畫面異常與惱人的影片卡頓。

資料完整性與遺失畫面

現代視訊壓縮高度依賴參考畫面來構建連貫的影像。如果一個 P 畫面或參考 B 畫面被丟棄或損壞，依賴它們的後續畫面就無法正確解碼。當發生這些封包遺失時，你會在直播畫面中看到嚴重的視覺瑕疵。通常在一個全新的 I 畫面到來之前，視訊解碼器很難從這種損壞中恢復。I 畫面可以獨立解碼，並讓整個視訊序列重新回到乾淨狀態。

在自適應位元率（ABR）直播中，每個切片段開頭都會帶有一個 IDR 畫面，每一段都可以獨立解碼。丟棄 P 畫面或 B 畫面雖然會在短時間內損害畫質，但播放會在下一個 IDR 段到來後恢復正常，該新切片會重設解碼器並徹底清除可見的畫面瑕疵。

網路抖動會造成到達時間序的波動，從而意外耗盡用戶端緩衝區。比方說，TCP 對亂序封包的數量有嚴格限制，超過門檻就會丟棄該批封包並重新請求。抖動會讓封包亂序到達，從而觸發丟棄與重傳。當用戶端重新請求資料期間，沒有新的媒體資料進入緩衝區，短時間內就會導致緩衝被耗盡，畫面立刻凍結。

如果你的網路實際吞吐率剛好等於影片位元率，那麼任何一點小小的網路抖動都可能迅速吃光你的緩衝媒體。像 Emby、Jellyfin 這類媒體平台很好地展示了緩衝區大小是如何抵銷網路不穩定的：某些遠端使用者在 Emby 上會不時出現緩衝被耗盡的問題，即便速度測試結果看起來很好；但切換到具備較大緩衝區的 Jellyfin 之後，透過吸收短時頻寬波動就能避免播放中斷。

重傳開銷與壅塞

發生封包遺失時，直播串流媒體伺服器和用戶端裝置都不得不重新傳送遺失資料。現代傳輸協定透過不同的重傳策略來處理遺失恢復：

協定	遺失恢復能力	重傳／開銷行為
RIST	在 100% 額外開銷下可恢復最高 25% 封包遺失，在 200% 開銷下可恢復最高 50% 封包遺失，可持續承受最高約 55% 遺失，以及最高約 86% 的短期突發遺失	ARQ 僅使用 NACK，可減少重傳所消耗的頻寬
SRT	在約 10–12% 封包遺失率下依然表現良好，在 15% 以上時效率會顯著下降甚至完全失效	基於 NAK 的選擇性重傳；同時使用 NACK 與 ACK；會儘快重送遺失封包，但在高錯誤率下，重傳可能會擠壓窄頻鏈路頻寬並造成額外壅塞

SRT 在 UDP 之上實作選擇性重傳。接收端為每一個遺失封包送出單一 NAK，傳送端只重傳該遺失封包。一般來說，如果延遲預算約為四倍往返時間，就可以容納大約三次重傳嘗試，之後才會丟棄來得太晚的封包。每一次重傳失敗，都會再增加一個完整往返時間到串流的總延遲上。

在某個實際生產環境中，晚高峰時段 SRT 的 NAK 數量一度達到總封包數的 1.8%。在 400 ms 的延遲預算內，這些重傳仍能準時到達，從而維持了乾淨的直播畫面。但當錯誤率非常高時，直播串流媒體伺服器不得不不斷重送遺失封包，這種持續重傳會引發二次網路壅塞，很快吃光窄頻鏈路的可用頻寬，並在整個網路中引入嚴重抖動。

抖動對解碼器時鐘與音訊的影響

解碼器時鐘失步

網路抖動會改變封包到達時間，打亂媒體解碼器內部的時鐘同步。硬體視訊解碼器依賴節目時鐘參考（PCR）時間戳來平順對齊音訊與視訊輸出。標準 MPEG-2 系統通常要求 PCR 精度在 ±500 ns 以內，而 DVB TR 101 290 要求 PCR 漂移率低於 75 mHz/s（約 2.77 ppb/s）。高抖動會使封包間隔超出這些嚴格限制。

MPEG-2 串流要求 PCR 間隔 ≤100 ms，而 DVB 網路則要求 ≤40 ms。延遲的封包會讓解碼器中的鎖相迴路（PLL）開始「搖晃」。當 PCR 頻率偏移達到 ±810 Hz（±30 ppm）時，時鐘頻率會在一段時間內持續偏移，這會讓播放緩衝區的填充或消耗變得不精確。螢幕會出現週期性掉幀與微卡頓。如果在 2 小時後音訊累積延遲達到 40 ms，即便解碼器仍在容差範圍之內鎖定，你依然會明顯察覺到嘴型不同步。

音訊失真與畫面卡頓

不穩定的封包到達間隔會顯著降低即時音訊與視訊渲染的表現。抖動會在封包遲到時耗盡播放緩衝。WebRTC 中的 NetEQ 系統會對 RTP 封包進行緩衝，以因應亂序或延遲。然而，如果到達時間的波動幅度超過緩衝深度，就會出現明顯的音訊破壞：你會聽到清楚的爆音、劈啪聲以及短暫靜音。

當抖動超過 30 ms 時，音訊會變得像機器人說話一樣斷斷續續，畫面也會變得支離破碎。

原因（網路抖動）	播放影響	緩解策略
封包延遲導致緩衝耗盡	音訊爆音、劈啪聲、機器人音與影片卡頓	NetEQ 緩衝、前向錯誤修正（FEC）以及用戶端影格率調整
多播 IPTV 中不穩定的封包到達	影片卡頓、音訊完全中斷	使用抖動極低的直播串流媒體伺服器（如 Flussonic Media Server）

在多播 IPTV 情境中，接收端在伺服器封包到達不穩定時很難重新組合完整的視訊串流，這會導致明顯的畫面卡頓。網路不穩定往往是封包遺失與抖動疊加出現，即使封包遺失率只有 1%，也足以造成可見的大塊馬賽克、嚴重像素化以及完全的音訊中斷。

固定延遲與串流損壞的對比

被動時滯 vs 主動劣化

在觀看直播時，你通常可以輕鬆接受穩定的 3 秒延遲。可預測的延遲只是讓你比現場觀眾晚幾秒看到事件本身，但你仍然享受清晰的畫面和完全同步的音訊輸出。

相反，主動的串流劣化會立刻讓觀眾流失。封包遺失會導致畫面凍結、馬賽克和含糊不清的語音。尤其是在關鍵時刻音訊突然消失時，你的挫折感會瞬間拉滿。

網路封包遺失直接威脅即時媒體的傳輸。例如，5% 的封包遺失率會對不同協定產生截然不同的影響：

SRT 可以快速偵測到遺失的封包序號，並向傳送端請求重傳。它可以讓播放依然保持流暢，將整體畫質維持在約 90% 左右，並確保連線穩定存在。
WebRTC 仰賴節奏化的播放時鐘，在標準配置下並沒有內建 ARQ 重傳機制。對於超過播放時限才到達的封包，它會直接丟棄，進而帶來明顯的畫面破損。

直播串流媒體伺服器嚴重依賴可預測的封包到達時間來維持解碼器穩定。固定延遲可以在網路傳輸過程中保持資料完整，而無法恢復的封包遺失則會瞬間摧毀媒體品質。

傳輸協定與緩衝韌性

現代傳輸協定往往用少量延遲換取在不穩定網路上的整體串流可靠性。SRT 和 RIST 使用智慧的 UDP 傳輸來取代傳統的 TCP 連線。

協定	遺失保護機制	遺失處理與開銷權衡
SRT	在 UDP 之上使用 ARQ 式選擇性重傳，適用於單播鏈路	面向低至中度遺失（約 10–12%），在恢復遺失封包的同時，將端到端延遲控制在 1 秒以內
RIST	結合 ARQ 與 FEC，自適應於廣播級網路	在大量遺失（25–50%）下依然保持穩定，但需要 100–200% 的重傳開銷

SRT 避免了冗長的 TCP 交握，可以把端到端延遲目標設定到 120 ms 這一量級。SRT 透過 ARQ 機制重傳遺失資料，而不會完全阻塞直播串流，它只請求真正遺失的那部分封包。這種選擇性策略既保留了整體吞吐量，又能在壅塞的行動網路上維持亞秒級延遲。

在直播串流媒體伺服器上正確配置抖動緩衝，可以主動防止不同網路路徑上因抖動造成的緩衝耗盡。

情境	建議抖動緩衝	操作建議
私有區域網路（LAN）	60 ms	在穩定鏈路上可設定為極低延遲。
本地鏈路	100–200 ms	有線連線通常使用較低範圍。
國內鏈路	100–300 ms	在整體畫質與延遲之間取得平衡。
國際鏈路	100–400 ms	因應跨國廣域網路更高的延遲與抖動。
無線網路	250–750 ms	吸收多使用者無線網路中的突發抖動。
衛星 IP	500–999 ms	補償極高延遲與抖動環境。

在媒體設備上，你應將自動抖動深度設定在 60–1000 ms 之間，並且至少要在正式開播前 5 分鐘接入網路。這段預先連線時間可以讓編解碼器量測即時網路狀況，並自動調整緩衝大小。

經過合理調校的抖動緩衝，可以在封包進入視訊解碼器之前，就吸收絕大部分到達時間的波動。直播串流媒體伺服器透過為 ARQ 重傳預留足夠到達時間，使遺失封包能在不打斷播放的前提下順利補齊。

基礎延遲只是單純地把你的觀賞時間軸往後移動。相比之下，封包遺失與網路抖動才是真正的媒體故障模式：它們會摧毀影片畫面、破壞音訊並讓解碼器時鐘失步。因此，在設計直播傳輸架構時，你應該優先確保網路穩定性、可靠封包傳遞與合理的抖動緩衝設定，而不是一味追逐極限低延遲。

透過採用具備彈性特性的傳輸協定以及嚴謹的 QoS 設定，你可以切實保護直播串流媒體伺服器。例如，SRT 協定可以在高達 10% 的封包遺失率下，仍然控制畫質不出現明顯劣化，同時平滑處理網路抖動。像 EBU Eurovision 光纖網路這樣的企業級基礎設施，每年要傳輸超過 80,000 小時的直播節目，它們倚賴高可靠性的傳輸平台來完成這項任務。為你的直播環境選擇並正確設定這些高可靠協定，才能真正維持畫面始終乾淨順暢。