Hulu直播服务难点解析(三):关键收获

  • 时间:
  • 浏览:0

有时,亲们会看多所含时间戳的媒体播放列表引用过去或将来的媒体文件。为了确保亲们只出理 实时视频,在系统摄取日后亲们验证输入的播放列表和媒体是否是在一2个频道的合理的当前时间戳窗口内。

最短分片时长

人太好亲们在出理 多个输入源和连接时遇到了各种新挑战,但在后来状态下,亲们并能识别并减轻原始实现中的大疑问,以满足亲们的初始需求并改进亲们的视频摄取频道。总的来说,亲们的设计足以支持亲们最初的直播电视发布,有些 亲们正在不断地改进和加进新功能,为观众提供更好的播放体验。

当亲们的打包服务检测到一2个频道上有一定量缺失的分片时,在系统放弃该段转向摄取较新的视频日后,亲们会更改配置以增加等待分片从编码供应商到达系统的时间。此等待的增加将由于用户端的延迟更大,有些 丢失的分片越少用户将拥有越连续的播放体验,有些 亲们仅在最有大疑问的频道上启用你这名 偏移。减少你这名 发布延迟会由于更多段丢失,但客户能观看多更实时的内容。通过分析缺失的分片指标,亲们发现将等待持续时间设置为段长度的3000%会使缺失分片的频率减少63%。

Hulu的编码供应商居于美国各地。亲们注意到,将媒体文件从海岸另一端的供应商传输到亲们的摄取服务的性能并都在亲们我要我的,利用公共互联网连接,这会由于延迟和不可预测的性能。为了克服你这名 挑战,亲们与供应商密切合作,设置AWS Direct Connect,并在供应商的发布平台和Hulu的摄取服务之间建立私人连接。这绕过了公共互联网,从而实现了加快强度、更一致的文件强度。

原文:https://medium.com/hulu-tech-blog/the-challenges-of-live-linear-video-ingest-part-three-key-learnings-ac673e1d39c6

编码供应商首先尝试将媒体文件发布到Hulu的摄取服务,有些 是相应的媒体播放列表。在媒体无法在一定时间内发布的状态下,媒体播放列表将所含不连续性信息来表示该段丢失,有些 在视频播放期间它将不可用于终端用户。通过与供应商合作,将不同的最小分片发布超时设置在段持续时间的3000%(对于较长的段)和段持续时间的23000%(对于较短段)之间,亲们系统中缺失的分片便减少了52%。这与日后的配置相比,使用的最小超时大慨全版段持续时间的3000%。

SCTE-35标记用于指示ad-pods和程序的结束英文和结束英文时间。插入元数据的硬件和系统最初是为数字电视和有线电视设计的。SCTE-35规范全版说明了那此消息的发送法子,多年来有些 发展并扩展了其范围,但工作流程中的数字系统从不时不时并能与最新版本保持同步。不同的供应商通常以不兼容或不可互操作的法子解释规范。SCTE-35规范全版说明了用于OTT兼容性的内容元数据转换,它所含非常宽松的定义,每个频道或提供商通常以不同法子实现那此定义。那此标记由每个电视台生成,有些 在到达Hulu日后通过每个提供者和供应商时进行修改。有日后,广告结束英文标记有些 表示广告持续时间不准确,有些 有时Hulu根本不不收到广告结束英文标记。为了出理 用户在发送不准确的标记时总出 无休止的广告状态,Hulu摄取系统会自动结束英文广告,并在一段可配置的时间后将用户重新置于程序中。系统的广告时间轴逻辑简单地记录了任何延迟的提示(广告结束英文)事件,以便日后优化频道的超时限制。

与大多数面向消费者的系统不同,有些 视频播放列表和片段发布的一致性,亲们的实时视频摄取服务具有稳定且可预测的请求率。具体来说,亲们的目标是提供最高可用性的直播流服务,使观众并能在其强度可用时观看最高质量的视频。下面是亲们发现并缓解的有些具体挑战,以减少亲们客户端播放卡顿和播放错误。

Hulu在其博客发布了建立直播服务遇到的挑战及出理 方案,这对于日后只提供点播服务的系统而言是一次彻底的升级。LiveVideoStack对原文进行了摘译。本文是系列文章的第三篇,访问第二篇和第一篇。

为了优化每个输入集的服务,亲们开发了独特的配置。亲们并能在每个频道,每个提供者或每个供应商的基础上自动或手动应用那此配置。那此配置允许亲们根据任何给定流或流集的行态校准出理 并指定错误阈值。

视频片段由编码器以4秒的常规节奏进行分割。然而,当节目和广告之间的内容转换时,无论持续时间怎么才能 才能 ,那此片段都在被缩短,以便媒体片段仅所含广告或节目内容。这是必要的,以便亲们并能动态地使用相关的新的广告替换那我的广告播放给每个观众。连续广告标记总出 在非常接近的地方,这由于了在一行中总出 多个秒级的片段。通常,传输和出理 每个段所花费的时间比段的持续时间长,从而由于用户的重新缓冲和较差的播放质量。为了缓解你这名 大疑问,亲们与视频编码供应商合作,将连续的广告标记组合在同時 ,以确保最短的片段持续时间为0.5秒。

有些 您日后加入亲们,在看亲们的最后一篇文章日后请看看亲们的直播视频摄取文章系列的第一主次和第二主次。在第一主次中,亲们讨论了实时视频摄取系统的挑战和设计需求,并在第二主次中概述了亲们怎么才能 才能 构建该系统。在本系列的最后一篇文章中,亲们将全版介绍在构建实时视频摄取服务时遇到的最具挑战性的大疑问。

时间戳的全版性

自动结束英文广告中断

有些 您时不时关注亲们日后的文章,您就知道亲们与多家供应商合作,那此供应商为亲们提供了来自多个网络的编码流。有些 你这名 过程涉及有些来源和参与者,有些 亲们收到的视频文件和元数据在流到达Hulu日后通常会以各种法子进行更改。亲们遵循多个行业标准来确保系统是以规范、一致的法子接受输入。有些 ,那此规范通常由各方以不同的法子实现。

摄取系统的一2个重要功能是识别所含相同视频的不同节目。该系统最初错误地假设所有挂钟时间戳将在比特率阶梯上为相同的内容对齐,这对于客户端在质量之间平滑切换是必要的。为了缓解你这名 大疑问,亲们加进了一2个配置来控制时间戳精度。在有些状态下,这并能设置为十分之一秒,以便正确对齐视频片段的质量。在有些状态下,应用单独的配置,使得那此节目组由公共视频PTS(描述时间戳)值标识。

分片发布超时

文 / Allison Deal

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/83510357

时间戳对齐和精度

最慢的1%发布操作时间(毫秒)。重试功能在15:00日后启用。

供应商网络连接

S3文件操作

更好的媒体文件传输技巧:私有供应商连接和优化Amazon S3

卡顿事件随着时间的推移进行计数。最小段持续时间更改在21:00日后启用。

亲们的服务使用S3来临时和永久地存储播放列表和视频片段。亲们发现零星的S3文件操作时间是实现一致的用户播放质量的挑战。S3上传和克隆技术操作出理 起来至关重要,有些 有些 一2个视频无法及时保存或转移到正确的位置,没人 终端用户将无法播放该视频并由于播放中断。为了消除偶发的操作时间,亲们不断分析指标,以根据每个文件的大小选则每个文件的当前预期的中值时间。一旦日后的文件发布时间超过此预期时间,发布操作将立即取回并重试发布服务。你这名 实现法子将S3的低性能操作时间提高了35%,几乎消除了所有播放质量下降的状态。

必须一2个强大、灵活的系统

译 / 许海燕

构建最好的系统:微调,微调,微调

那我主要挑战是在摄取过程中加快媒体文件的传输时间。

发布偏移

亲们系统的每个组件都必须经过细微地调整和优化来减少延迟和错误。视频出理 很繁复,一2个看似很小的错误或延迟有些 由于流被错误地摄取或不及时出理 ,由于无法实时播放。

结论