直播视频服务在网络演进过程中已经到了一个矛盾的关键时刻，当我们实施新的多流媒体平台以适应消费者与实时视频互动时不断变化的动态时，首先要考虑到依靠内容交付网络 (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等平台的测试。
