直播視訊服務在網路演進過程中已經到了一個矛盾的關鍵時刻，當我們實施新的多流媒體平臺以適應消費者與實時視訊互動時不斷變化的動態時，首先要考慮到依靠內容交付網路 (CDN) 來支援其內容的點播可用性。

無法迴避的事實是，視訊流媒體市場不再完全依賴基於 HTTP 的 CDN 流媒體，這些具有多秒延遲和不同步接收指標的單向基礎設施，無法滿足與直播視訊交織在一起的實時視訊互動的要求。在全球範圍內，直播視訊流量遠遠大於點播流量，這與體育、電子競技、音樂會和其他現場活動觀看的視訊實時互動需求不謀而合。

依賴於 CDN 的直播服務策略，比如EasyDSS，與支援互動式視訊元件的視訊平臺的結合在前期看或許是個不錯的解決方式，但是在需求已經改變的現在，這種方式還具備一定的障礙。這兩者的結合不僅引入了操作複雜性，並且限制了互動平臺的質量和擴充套件性；它們還使源內容無法進行實時同步性流式傳輸，而未能達到令人滿意的使用者體驗。

我們目前使用的很多平臺也都提供了視訊聊天系統，比如Facebook、亞馬遜、Hulu 和 HBO Max等，但這些平臺僅限於共享觀看點播內容，這樣可以更輕鬆地確保同一組選擇的視訊檔案都通過單向 CDN 基礎設施，同時流式傳輸到所有參與者。但在大部分情況下，帶有實時或點播內容的視訊聊天都受到視訊和音訊質量不佳的限制，嘗試使用傳統的視訊會議平臺作為 CDN 的輔助手段來支援工作場所虛擬化和其他混合應用程式，也遠遠達不到所需要的程度。

對於 CDN，已在減少實時視訊流的延遲方面做出了重大努力，但實時連線仍然遙不可及，無法確保在所有端點上同時進行逐幀接收。例如，CDN 運營商聲稱通過與通用媒體應用格式 (CMAF) 一起使用的分塊傳輸編碼 (CTE) 實現的端到端延遲效能在兩秒左右觸底，但經常達到四秒甚至更高。蘋果公司對 HLS 協議的最新低延遲 HLS (LL HLS) 改進還提供了大約 2 到 5 秒的延遲效能。

相比之下，我們也更加需要一套穩定，且能夠有效承載任何方向、任何距離、任何數量使用者之間傳輸的基礎設施，每個人都可以同時檢視所有內容，並且內容交付的端到端延遲時間不超過 400 毫秒。因此基於這種理念，我們接下來將會對現有的傳輸架構進行更深一步的研究，同時，原有的幾個視訊平臺還是支援大家試用，我們在開發期間會不定期把開發歷程整理成部落格和大家分享，有興趣可以關注我們，也歡迎大家對EasyNVR、EasyGBS、EasyDSS等平臺的測試。