下次当您收听YouTube直播，Facebook直播或Twitch广播时，请记住一件事-直播并不意味着直播。
这意味着什么？ 可以归结为以下事实：虽然您正在观看的事件实际上是当前直播，但将视频编码成块，将这些块传递到互联网并让互联网将它们传递给您所花费的时间就是我们所说的延迟。
如果您退后一步，品牌通常会牺牲等待时间，以便在其他领域获得收益。 在Flash时代，我们正在帮助客户使用Flash Media Server通过Internet将其广播的内容交付给用户。 这利用了RTMP / RTSP协议，如果部署正确，它可能会产生2秒以下的延迟。 部署问题，Apple最终取消了闪存以及CDN的高昂费用，使我们以及媒体行业的其他人都对HTTP流技术有了了解。
HTTP媒体流一直很棒，它降低了带宽成本，允许我们在流媒体中切换比特率以减少缓冲，允许更好的广告集成和更好的加密支持。 这些收益是以增加延迟为代价的。 如前所述，使用Flash Media Server，我们只需打开与用户设备的恒定连接并推送数据即可。 现在，我们需要将媒体拆分为“块”，将这些块编码为特定的格式和包装，将其推送到CDN，然后让CDN将它们交付给您。 如果我们增加了从摄像机到编码器的广播，这就是我们在行业中所说的“眼镜到眼镜”延迟。
随着应用程序需求变得更具交互性并吸引更多受众，整个行业一直在努力创建工作流，以减少我们在HTTP流处理中所花费的延迟。 例如，为了提供实时视频体验，其中等待时间足够低，以使观众可以感受到与主机的实时交互，我们考虑了以下几点：
- HLS和DASH将是最理想的，但对于玻璃到玻璃趋势而言，常见的延迟时间约为7-12秒。
- RTMP具有所需的延迟，我们已经解决了这一问题，但是由于大多数CDN开始弃用RTMP，因此损失了很多，并增加了成本。
在过去的一年中，在通过HTTP流支持超低延迟方面取得了长足的进步。 其中包括一些开源供应商展示的演示。 一些最大的媒体巨头和基础设施即服务提供商也意识到了这一需求。
- CMAF是一种社区驱动的通用包装格式的标准化，与协议无关。 这意味着我们可以使用HLS，DASH或同时使用两者，并与CDN合作伙伴一起提供CMAF支持。
- 在ParisTech上发表的一篇出色的白皮书概述了使用DASH传递和分块传输的概念验证，并且DASH清单规范的一些更新使视频播放器可以在分段完成之前就意识到这些分段，并在分段仍在请求时进行请求从编码器发布到来源。 在不同的网络条件下，此POC导致的延迟样本约为1.5s。
在进行了一些自己的研究之后，并且遍历了ParisTech白皮书，我们认为前进的最佳途径是利用CMAF封装，分块传输以及测试DASH和HLS协议。 这需要首先解决一些依赖性：
- CDN提供程序需要同时支持分块传输和CMAF打包。
- 我们需要一个支持CMAF封装的硬件编码器。
- 是否有本地支持分块传输的iOS和Android播放器？
我们与CDN的两个合作伙伴一起对他们的团队进行教育，并在其平台上测试其CMAF实施。 我们找到了硬件编码公司Keepixo并与之合作，后者是我们在市场上可以找到的少数支持CMAF封装的硬件编码器之一。 我们与他们合作，测试了他们的超低延迟规范，并帮助编写了代理代码以对我们的CDN来源进行身份验证。
对于视频播放器，我们测试了许多。 一些声称已经支持超低延迟（基本上启用了分块传输和某些缓冲区配置）的人，还有一些愿意与我们合作实施它的人。 迄今为止，我们最稳定的实现是AVPlayer和ExoPlayer的自定义构建。
对于我们的POC，我们正在以1 mbps的比特率进行测试，这在使用移动分辨率时可提供相当不错的质量。 我们了解白皮书中发布的结果受本地网络条件的影响。 在进行网络稳定性测试和一些缓冲区配置之前，我们的玻璃到玻璃结果平均延迟为3秒。 在完全实施CMAF打包支持之后，我们发现两个CDN合作伙伴之间都没有实质性的边缘延迟差异。
3秒太疯狂了！ 能够为客户提供此服务是一项了不起的成就，我们将继续努力。 我们首先解决了移动设备问题，而其他公司最近仅在桌面浏览器上推出了这种延迟支持。 我们知道，直接访问我们在浏览器中获取块的方式将比移动方式容易得多，并且通过最新一轮的网络稳定性测试，我们在不牺牲延迟的情况下大大提高了稳定性。
REDspace帮助全球品牌向每台设备交付内容。 现在，我们可以将超低延迟视频带入您的工作流程。 让我们帮助您 -redspace.com 。
