實時流媒體系統設計

問題： 爲什麼視頻內容的實時流媒體具有挑戰性？

回答 → 這是因爲以下原因：

• 因爲視頻內容是以幾乎實時的方式通過互聯網發送的。

• 視頻處理的整個過程是計算密集型的。通過互聯網發送大量視頻需要時間。

問題： 任何視頻是如何從流媒體端傳輸的？

回答 → 以下是上傳視頻涉及的過程：

步驟 #1.) 播放者啓動視頻流。源可以是任何視頻和音頻，通過編碼器連接到編碼器，類似於流行的開源 OBS 軟件。

注意： 一些平臺，如 YouTube，提供了易於使用的軟件，可以從瀏覽器中使用攝像頭 OR 直接從手機攝像頭進行流媒體。

問題： 編碼器的目的是什麼？

回答 → 編碼器的工作是將視頻流打包並以傳輸協議發送，以供實時流媒體平臺接收進行進一步處理。最流行的協議稱爲 RTMP（即實時消息傳輸協議）。

問題： 解釋一下 RTMP？

•RTMP 是基於 TCP 的協議。很長時間以來，它一直是 Adobe Flash 的視頻流傳輸協議。• 編碼器可以輕鬆使用 RTMP 或其安全變體 RTMPS。

問題： 解釋一下 SRT？

• 還有另一種流行的選擇，稱爲 SRT，即安全可靠傳輸協議。•SRT 是基於 UDP 的協議。它承諾更低的延遲和更好的抗惡劣網絡條件的韌性。• 大多數流媒體平臺可能尚不支持 SRT。

問題： 展示各種協議的比較分析，以執行來自客戶端的視頻廣播？

問題： 如何爲播放者提供最佳的上傳條件？

回答 → 爲了爲播放者提供最佳的上傳條件：

• 大多數實時流媒體平臺在全球範圍內提供 出現點 服務器。

• 播放者連接到最近的 出現點 服務器。

問題： 播放者如何連接到最近的 POP 服務器？

回答 → 這是通過以下方式自動完成的：

• 基於 DNS 延遲的路由。

• 任播網絡。

問題： 視頻到達最近的 POP 服務器後會發生什麼？

回答 → 一旦流到達最近的 POP 服務器，它就會通過快速可靠的主幹網絡傳輸，進行進一步處理到達平臺 / 數據中心。

問題： 將視頻傳輸到平臺的主要目標是什麼？

回答 → 將視頻傳輸到平臺的主要目標是以不同的質量和比特率提供視頻流。

注： 實際的處理步驟可能因平臺而異以及輸出流式傳輸格式可能有所不同。

問題： 自適應比特率流是什麼？

回答 → 現代視頻播放器根據觀衆的互聯網連接質量自動選擇最佳的視頻分辨率和比特率，並且可以根據網絡條件的變化動態調整。

問題： 詳細解釋平臺執行的一般步驟？

回答 → 平臺遵循以下一般步驟：

步驟 #1.) 對傳入的視頻流進行轉碼爲不同的分辨率和比特率。基本上，這些是視頻的不同質量級別

步驟 #2.) 將轉碼流劃分爲較短的幾秒鐘的視頻段。

問題： 從 CPU 的角度看，轉碼過程是什麼樣的？

回答 → 轉碼 / 分段的這一步是計算密集型的，因此輸入流通常以並行方式轉碼爲不同的格式。

問題： 轉碼過程之後會發生什麼？

回答是打包 → 來自轉碼過程的視頻段集合被打包到不同的實時流式傳輸格式中，視頻播放器可以理解。

問題： 實時流式傳輸的最流行格式是什麼？

回答 → 進行實時流式傳輸的最常見格式是 “HTTP 實時流式傳輸（即 HLS）”。HLS 由 Apple 在 2009 年發明。直到今天，它仍然是最流行的流式傳輸格式。

問題： 解釋一下 HLS-Stream？

回答 → HLS-Stream 由清單文件和一系列視頻塊組成：

• 每個塊包含幾秒鐘的視頻段。• 清單文件是一個目錄，告訴視頻播放器輸出格式以及在 HTTP 上加載視頻塊的位置。

問題： 解釋一下 DASH？

回答 → DASH 代表 Dynamic Adaptive Streaming over HTTP，這是另一種流行的流媒體格式。Apple 設備不支持 DASH。

問題： 如何減少最後一英里的延遲？

回答 → CDN 層還會緩存生成的 HLS 文件和視頻塊，從而減少最後一英里的延遲。

問題： 視頻傳遞過程的下一步是什麼？

回答 → 現在，視頻開始到達觀衆的視頻播放器。以下是實時流媒體的端到端過程：

問題： 視頻交付過程的整體延遲是多少，我們如何優化？

回答 → 大約 20 秒的 “Glass To Glass Latency” 是正常的。

• 有幾個因素是 Streamer 或實時流媒體平臺可以調整的，以改善延遲，通過犧牲整體視頻質量的各個方面。• 改善延遲的最佳方法是通過優化本地設置，以實現從相機到流媒體平臺的最低延遲。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/nBWKEJtSEkDQreqo31kbaA