即時串流的影片延遲

什麼是即時影片串流中的延遲?

假設您正透過 over-the-top (OTT) 串流服務觀看足球比賽。在此同時,您的隔壁鄰居在傳統電視上觀賞相同的比賽,而且比您早 30 秒大聲慶祝得分並為罰球發出哀號。

或者,也許您正在觀賞才藝比賽直播,正滿心期待優勝者揭曉的時刻,您的社群媒體饋送 – 通常由電視觀眾產生 – 早 15 秒破壞了這個驚喜。

對於觀眾而言,影片延遲最大的問題是無法在事件發生當下看到它發生,這會讓人感到非常失望。一段時間之後,觀眾對影片延遲的失望會轉變為內容供應商的影片延遲問題。

對於時間敏感的影片內容 – 如電視體育、遊戲和新聞,或者甚至是電競和互動節目等單純的 OTT 內容 – 觀眾希望可以即時看到各種活動。在即時娛樂的世界中,影片延遲問題不只會破壞驚喜;如果不盡快解決,會損及觀眾對 OTT 內容供應商的信任。

影片延遲的原因為何? 從攝影機到顯示器等各種因素

G2G 路徑的步驟數會影響影片延遲:

  • 影片編碼管道持續時間
  • 擷取和封裝操作
  • 網路傳播和傳輸協定
  • 內容交付網路 (CDN)
  • 片段長度
  • 播放器政策
               –緩衝
               –播放頭位置
               –恢復能力
 
對於傳統的調整式位元速率串流,影片延遲主要取決於媒體片段長度。例如,如果您的媒體片段長度為六秒,與實際絕對時間相比,當播放器請求第一個片段時就已延遲六秒。
 
此外,播放器在實際開始播放之前緩衝的每個額外媒體片段,都會延長第一個解碼影片畫面的時間。
 
雖然有很多因素會產生影片延遲 – 影片編碼管道持續時間、擷取和封裝操作持續時間、網路傳播延遲和 CDN 緩衝 (如果有) – 但播放器本身也是整體影片延遲的重要原因。

如何測量影片延遲

雖然有其他方法,但測量端對端影片延遲最簡單的方法如下:

  1. 使用執行場記板應用程式的平板電腦
  2. 使用與影片編碼器連接的攝影機拍攝
  3. 將您的影片串流發布到來源
  4. 透過 CDN 交付到播放器
  5. 將播放器和場記板平板電腦放一起
  6. 拍攝兩個畫面的照片
  7. 執行時間碼減法以得出您的數字

如何大幅降低即時串流的影片延遲

OTT 影片延遲落後於廣播電視和社群媒體不是內容供應商擔心的唯一問題。若要達到低延遲還必須考量以下幾個問題:

快閃記憶體和即時簡訊協定 (RTMP):使用 RTMP 串流的快閃記憶體應用程式過去可以獲得不錯的低延遲效能,但隨著快閃記憶體的淘汰和 Web 瀏覽器持續降低或封鎖對外掛程式的支援,內容交付網路 (CDN) 也開始淘汰 RTMP – 原來在交付端就已無太大的空間 – 迫使內容供應商採取替代動作。

擴展和可靠性與低延遲:解決擴展問題的其中一個選項:切換到易於使用 HTML5 的串流技術,如 HTTP 即時串流 (HLS)、經由 HTTP 的動態調整式串流 (DASH 或 MPEG-DASH),以及一般媒體應用程式格式 (CMAF)。

這些串流技術經由 HTTP 分發,這表示可快取交付,而且 CDN 可透過更快的效率交付更高的數量。

然而,雖然解決了擴展和可靠性的問題,但端對端交付的時間增加了數十秒,破壞了低延遲的比例。

互動式功能:其他內容供應商可能會選擇開發含互動式功能的個人廣播服務;然而,這些使用案例通常不能接受影片訊號延遲。

原因:如果從第一次在攝影機擷取影片到觀賞這段時間的影片延遲高達 30 秒,則無法呈現需要即時回饋的互動性。

此外,想要開發同步第二螢幕、社會觀察、遊戲或賭博應用程式的人員,需要能夠非常精細地控制影片串流延遲。

即時串流的最佳影片延遲位置為何?

影片延遲可分成三大類,每個都由其上限和下限定義。

影片延遲層級

  高 (秒) 低 (秒)
降低延遲 18 6
低延遲 6 2
超低延遲 2 0.2

然而,您必須了解降低影片延遲、低影片延遲和超低影片延遲與廣播影片延遲的差異,要解釋這些差異並不容易。

六秒的廣播影片延遲通常是業界的平均值,這表示 OTT 影片延遲的最佳位置介於降低影片延遲類別的低標,或低延遲類別的高標。接近五秒可以最大限度地提高與廣播和社群網路饋送競爭的機會。

此外,根據 OTT 影片編碼器所在的內容準備工作流程位置,隨著編碼器的位置越接近供應鏈下游,達成降低延遲目標的機會越大。

在即時串流應用程式完成低延遲影片的最佳做法

若要將您的影片串流解決方案納入低延遲類別,通常可採取這裡提供的幾個主要動作:

  • 測量工作流程中每個步驟的影片延遲
  • 優化影片編碼管道
  • 針對您的需求選擇適當的片段持續時間
  • 建立適當的架構
  • 優化 (或替換) 影片播放器

如何為影片封裝選擇正確的片段大小

您選擇的片段持續時間幾乎對每個播放器的影片延遲都會產生機械效應。例如,片段持續時間為一秒,您可以達到五秒延遲。選擇持續時間為兩秒的片段,將會產生七到十秒的影片延遲 – 除非您優化播放器的設定。

基本規則是根據您的需求「調整大小」。因此,如果可接受七秒或以下的影片延遲,則選擇持續時間為兩秒的片段。

如果您的播放器使用兩秒片段,將 GOP 長度從一秒提高到兩秒,以穩定的位元速率提升編碼品質。

此外,如果您使用 HLS 做為擷取格式,可在擷取時使用兩秒片段降低原始儲存和封裝運算的壓力。

記住這些影片延遲事實和秘訣

  • 即時串流的影片延遲不是無解的問題。您可以透過一些努力將其降到最低
  • 標準 HLS 和 DASH 技術可透過 HTTP 支援可擴展的低延遲
  • 現在的即時串流影片延遲標準:少於 10 秒
  • 如果您的業務需要,現在要達到穩定的四到五秒影片延遲是可行的
  • 分區 CMAF 生態系統漸趨成熟,即將支援低於四秒的穩定影片延遲

低延遲即時影片串流示範

透過這個 AWS Elemental MediaStore 示範,了解如何使用標準 HLS 或 DASH 協定達到可預測且穩定的低延遲影片串流,以及有關與 AWS 整合的雲端影片創作和儲存的高效能功能。

Low-Latency Live Video Streaming Demo [3:13]

開始使用

我們能協助您先向我們的業務與架構機構諮詢,或者您今天就可以開始進行前導測試。