直播視頻服務在網絡演進過程中已經到了一個矛盾的關鍵時刻，當我們實施新的多流媒體平台以適應消費者與實時視頻互動時不斷變化的動態時，首先要考慮到依靠內容交付網絡 (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等平台的測試。
