直播流中的视频延迟

直播流中的延迟是什么?

假设您正在通过 over-the-top (OTT) 流式处理服务观看一场足球比赛。与此同时,您隔壁的邻居正在传统电视上观看这场比赛,大声庆祝进球、咒骂处罚,而这些比赛场景您还要再等 30 秒才能看到。

或者,也许您正在看一场直播的才艺大赛,您满心期盼着揭晓最终获胜者,这时您的社交媒体源(通常由电视观众生成)在您看到结果前的 15 秒破坏了这一惊喜。

对于观众来说,视频延迟的最大问题是在事件发生之后才看到的沮丧感。随着时间的推移,观众对视频延迟的沮丧感逐渐变成了内容提供商的视频延迟问题。

对于时间敏感型的视频内容(比如电视体育、游戏、新闻或纯粹的 OTT 内容,像电子竞技和互动节目),观众期望实时观看事件的发生过程。在实时娱乐的世界中,视频延迟问题不仅仅毁掉了惊喜,如果任由其发展,它们还将会毁掉观众对其 OTT 内容提供商的信心。

是什么原因导致了视频延迟? 多种因素,从摄像头到显示器

从拍摄到播放这个过程中的很多步骤都会影响视频延迟:

  • 视频编码管道持续时间
  • 摄取和打包操作
  • 网络传播和传输协议
  • 内容分发网络 (CDN)
  • 切片长度
  • 播放器策略
               -缓冲
               -播放头定位
               -弹性
 
使用传统的自适应比特率流时,视频延迟主要取决于媒体切片长度。例如,如果您的媒体切片长度是 6 秒,那么您的播放器就已经比它请求第一个切片的实际绝对时间晚了 6 秒。
 
此外,播放器在实际开始播放之前会将其他媒体切片下载到缓冲区,这会增加第一个已解码视频帧的时间。
 
尽管有许多因素会导致延迟,比如视频编码管道持续时间、摄取和打包操作的持续时间、网络传播延迟和 CDN 缓冲(如果有),但播放器本身的延迟在总体视频延迟中占比很大。

如何测量视频延迟

方法有多种,但测量端到端视频延迟的最简单的方式如下:

  1. 使用一台运行 Clapperboard 应用程序的平板电脑
  2. 使用连接到视频编码器的摄像头拍摄
  3. 将视频流发布到您的源
  4. 通过 CDN 传送到播放器
  5. 将播放器放在 Clapperboard 平板电脑旁边
  6. 拍下两个屏幕的照片
  7. 减去时间码,就可以获得延迟的值

如何最大程度地减少直播流的视频延迟

OTT 视频延迟滞后于广播电视和社交媒体,这不是内容提供商唯一担心的事情。要实现低延迟,还要考虑以下几个其他问题:

Flash 和实时消息协议 (RTMP):使用 RTMP 流的基于 Flash 的应用程序,以前在实现低延迟方面表现得很好,但随着 Flash 被弃用,以及 Web 浏览器逐渐减少支持或阻止插件,内容分发网络 (CDN) 也已经开始弃用 RTMP,RTMP 限制了分发的规模,迫使内容提供商采取其他措施。

规模和可靠性与低延迟:解决规模问题的一种选择:切换到适合 HTML5 的流式处理技术,比如 HTTP Live Streaming (HLS)、Dynamic Adaptive Streaming over HTTP(DASH 或 MPEG-DASH)和 Common Media Application Format (CMAF)。

这些流式处理技术通过 HTTP 进行分发,这意味着交付是可缓存的,而且 CDN 可以更有效地交付更多内容。

但是,随着规模和可靠性的实现,端到端交付时间增加了数十秒,这与低延迟的目标相违背。

交互式功能:其他内容提供商可能会选择开发具有交互式功能的个人广播服务;但是,对于这些使用案例,视频信号延迟通常是不可接受的。

原因:如果从第一次用摄像头捕获的时间到观看的时间,视频延迟长达 30 秒,需要实时反馈的交互性就变得不可能了。

此外,想要开发同步的第二屏幕、社交观察、游戏或赌博应用程序的用户需要对视频流延迟进行精细的控制。

直播流的最佳视频延迟时间是多少?

视频延迟可以分为三个不同的类别,每一类都由高低边界定义。

视频延迟级别

  高(秒) 低(秒)
更低延迟 18 6
低延迟 6 2
超低延迟 2 0.2

但是,更低视频延迟、低视频延迟和超低视频延迟与广播视频延迟的不同之处是值得了解一下的(如果解释起来比较麻烦的话)。

平均 6 秒的广播视频延迟在该领域很常见,这意味着 OTT 视频延迟的最佳值应处于“更低视频延迟”类别的低范围或“低视频延迟”类别的高范围内。接近 5 秒的延迟可最大限度提高与广播和社交网络源竞争的机会。

此外,根据 OTT 视频编码器在内容准备工作流中的位置,如果编码器位于链的下游,就需要提高延迟降低目标。

在直播流应用中实现低延迟视频的最佳实践

从一个较高的层面上来说,为了使您的视频流解决方案能够归入低延迟类别,需要执行以下主要操作:

  • 在工作流中的每一步都测量视频延迟
  • 优化视频编码管道
  • 根据自己的要求选择合适的切片时长
  • 构建合适的架构
  • 优化(或替换)视频播放器

如何为视频打包选择合适的切片大小

您选择的切片时长对几乎所有播放器中的视频延迟都有机械影响。例如,您可以使用时长为 1 秒的切片,来实现 5 秒的延迟。选择时长为 2 秒的切片,视频延迟时间将介于 7 到 10 秒之间,除非您优化了播放器的设置。

基本规则是根据您自己的要求选择合适的大小。所以,如果 7 秒或以下的视频延迟并不重要,就选择 2 秒切片。

如果您的播放器使用 2 秒切片,可以将 GOP 的长度从 1 秒提高到 2 秒,这样就可以在恒定比特率下提高编码质量。

此外,如果您使用 HLS 作为摄取格式,您可以通过在摄取时使用 2 秒切片,来减少对源存储和打包计算的压力。

记住以下视频延迟事实和提示

  • 直播流的视频延迟并不是一个无法解决的问题。您可以通过努力最大程度地降低延迟
  • 标准 HLS 和 DASH 技术支持通过 HTTP 实现可扩展的低延迟
  • 现在的直播流的视频延迟标准是:少于 10 秒
  • 现在,如果您的业务有需要,将视频延迟稳定在 4 到 5 秒是可以做到的。
  • 分块的 CMAF 生态系统日渐成熟,很快就能实现稳定的 4 秒以下视频延迟

低延迟直播视频流演示

在此 AWS Elemental MediaStore 演示中,您将了解如何使用标准 HLS 或 DASH 协议实现可预测、稳定的低延迟视频流,并了解与 AWS 集成的高性能的云视频发放和存储功能。

低延迟直播视频流演示 [3:13]

开始使用

我们可以帮助您从咨询销售人员和架构设计组织入手,或者您也可以立即开始自己的试点部署。