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

  • 时间:
  • 浏览:9
  • 来源:uu快3棋牌_uu快3讨论群_规律

视频片段由编码器以4秒的常规节奏进行分割。然而,当节目和广告之间的内容转换时,无论持续时间怎样,什儿 片段还会 被缩短,以便媒体片段仅蕴含 广告或节目内容。这是必要的,以便大家 都时要动态地使用相关的新的广告替换原来 的广告播放给每个观众。连续广告标记突然突然出现在非常接近的地方,这意味着了在一行中突然突然出现多个秒级的片段。通常,传输和处里每个段所花费的时间比段的持续时间长,从而意味着用户的重新缓冲和较差的播放质量。为了缓解什儿 问题,大家 与视频编码供应商合作协议,将连续的广告标记组合在同去,以确保最短的片段持续时间为0.5秒。

S3文件操作

文 / Allison Deal

分片发布超时

Hulu的编码供应商地处美国各地。大家 注意到,将媒体文件从海岸另一端的供应商传输到大家 的摄取服务的性能并还会 大家 想要的,利用公共互联网连接,这会意味着延迟和不可预测的性能。为了克服什儿 挑战,大家 与供应商密切合作协议,设置AWS Direct Connect,并在供应商的发布平台和Hulu的摄取服务之间建立私人连接。这绕过了公共互联网,从而实现了更慢、更一致的文件传输下行下行速率 。

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

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

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

供应商网络连接

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

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

时间戳的完整

自动后后刚结速广告中断

最短分片时长

大家 的服务使用S3来临时和永久地存储播放列表和视频片段。大家 发现零星的S3文件操作时间是实现一致的用户播放质量的挑战。S3上传和基因重组操作处里起来至关重要,可能可能一一两个 视频无法及时保存或转移到正确的位置,没人终端用户将无法播放该视频并意味着播放中断。为了消除偶发的操作时间,大家 不断分析指标,以根据每个文件的大小挑选每个文件的当前预期的中值时间。一旦后后的文件发布时间超过此预期时间,发布操作将立即撤除并重试发布服务。什儿 实现依据将S3的低性能操作时间提高了35%,几乎消除了所有播放质量下降的情形。

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

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

译 / 许海燕

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

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

结论

可能您突然关注大家 后后的文章,您就知道大家 与多家供应商合作协议,什儿 供应商为大家 提供了来自多个网络的编码流。可能什儿 过程涉及许多来源和参与者,全都大家 收到的视频文件和元数据在流到达Hulu后后通常会以各种依据进行更改。大家 遵循多个行业标准来确保系统是以规范、一致的依据接受输入。全都,什儿 规范通常由各方以不同的依据实现。

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

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

发布偏移

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

为了优化每个输入集的服务,大家 开发了独特的配置。大家 都时要在每个频道,每个提供者或每个供应商的基础上自动或手动应用什儿 配置。什儿 配置允许大家 根据任何给定流或流集的型态校准处里并指定错误阈值。

当大家 的打包服务检测到一一两个 频道上有少许缺失的分片时,在系统放弃该段转向摄取较新的视频后后,大家 会更改配置以增加等待的图片 分片从编码供应商到达系统的时间。此等待的图片 时间的增加将意味着用户端的延迟更大,全都丢失的分片越少用户将拥有越连续的播放体验,全都大家 仅在最有问题的频道上启用什儿 偏移。减少什儿 发布延迟会意味着更多段丢失,但客户能观看了更实时的内容。通过分析缺失的分片指标,大家 发现将等待的图片 持续时间设置为段长度的1150%会使缺失分片的频率减少63%。

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

可能您后后加入大家 ,在看大家 的最后一篇文章后后请看看大家 的直播视频摄取文章系列的第一主次和第二主次。在第一主次中,大家 讨论了实时视频摄取系统的挑战和设计需求,并在第二主次中概述了大家 怎样构建该系统。在本系列的最后一篇文章中,大家 将完整介绍在构建实时视频摄取服务时遇到的最具挑战性的问题。

时要一一两个 强大、灵活的系统

时间戳对齐和精度

大家 系统的每个组件都时要经过细微地调整和优化来减少延迟和错误。视频处里很僵化 ,一一两个 看似很小的错误或延迟可能意味着流被错误地摄取或不及时处里,意味着无法实时播放。

虽然大家 在处里多个输入源和连接时遇到了各种新挑战,但在全都情形下,大家 也能识别并减轻原始实现中的问题,以满足大家 的初始需求并改进大家 的视频摄取频道。总的来说,大家 的设计足以支持大家 最初的直播电视发布,全都大家 正在不断地改进和加进去去新功能,为观众提供更好的播放体验。