Hulu如何大规模提供可靠的流媒体服务

了解更多关于大规模流媒体的信息流媒体东部2022.

阅读这段录音的完整文本:

尼克·布鲁金斯学会: “大规模提供可靠的直播流”到底是什么意思?这个交付词会让你立刻想到CDN. 当然, 这将是这里的重点, 但还有更多, 尤其是为了让这一切顺利进行. 首先，对于水平集，你需要能够测量我们在这里讨论的东西. 可用性或可靠性的指标，比如VPF, 播放失败, 启动失败, 启动时间重缓冲延迟过长. 还有平均比特率, 因为如果你传输的是可靠的数据流, 但是在一个低于用户期望的质量或功能水平的水平上, 他们还是不会开心的. 所以所有这些都需要结合在一起, 规模是另一个非常棘手的部分因为为一个用户或一百个用户做事情总是比为十万，一百万或上亿的用户做事情容易得多. 随着规模的扩大, 可靠性和性能下降, 你必须不断地调整你的系统，确保你看到的是正确的事情.

这些数字也很容易让人迷失方向. 期望总是在上升, 缓冲的程度可能是可以接受的, 说, 五年前的事情现在往往是不能接受的. 所以你必须非常小心不要管理过多的指标平均值.

但是往上游走一点, 视频管道是紧密相连的, 尤其是视频直播, 链条中的任何一个环节都可能导致任何可以想象到的下游问题. 所以你真的需要对你的媒体系统进行广泛的考虑，从端到端，以便在最后阶段有可靠的交付.

所以，至少在我的世界里，这一切都回到了摄取:你从哪里得到你的实时信号? 你有你需要的那种弹性吗? 理想情况下，你有热切换路径吗?? 您是否使用协议加速? 你在尽你所能吗? 因为如果你没有得到其中一个片段, 你无法合成它, 或者让小溪在另一边流下去, 除了增加延迟和更大的缓冲区, 什么会对你的用户产生某种影响. 因为如果他们在看直播, 他们可能在看体育比赛或新闻，这对他们来说是及时的.

然后是编码, 这可能发生在摄入之前，也可能发生在摄入之后，或者两者都发生，这取决于设置. 但我要关注的是编码的最后阶段那通常发生在你创建自适应比特率集的时候.

这是需要仔细考虑的:你想要对基础设施拥有什么样的所有权? 将ABR的编码和管理引入内部会增加很多复杂性, 但给你一个更严格的控制你的ABR堆栈和视频功能. 它还允许你更严格地控制编解码器, 包装, 你正在使用的加密, 这些都是真的, 在交付阶段非常重要. 你想要有足够的比特率平衡. 每个用户都有一个理想的比特率. 如果他们有1兆比特的吞吐量，你是否有800K的吞吐量可以可靠地传输? 但是要保持平衡，不要有太多的比特率或变化，避免碎片化.

So, 这让我们进入了一个交付阶段，在这个阶段，你拥有的碎片越多, 就越难可靠地完成最后的交付阶段. 假设你添加了一个新的编解码器, 这很有意义，因为每个人都在使用这种新的花哨的编解码器——也许是AV1——可能会减少30%的带宽或吞吐量, 他们得到了更好的体验. 问题是你现在已经支离破碎，你正在处理所有的事情和额外的时间. 你已经把你的储存需求翻了两倍，三倍，甚至四倍, 但您也将缓存转发到CDN中，这样他们就不太可能找到缓存命中. 会有更多的点击回到原点. 所以这是一个相互关联的生态系统. 一次又一次, 我鼓励人们往上游想, 即使你真正想做的是优化传递部分.

Live对于缓存性来说非常好，因为在Live边缘有更集中的用户数量，并且更有可能获得缓存命中. 他们都或多或少在同一时间点观看. 但它也不那么容易原谅，因为如果你错过了一个环节，就无法弥补.

当然，与您的cdn一起调整您的缓存. 查理可能是最合适的人来谈谈这个问题. 但交付并不是游戏的终点，因为玩家或客户可能会向你发出不同的信号, 无论是播放列表，清单，还是DRM密钥和元数据, 必须仔细考虑这个问题. 特别是，你真正需要的动态程度? 动态性对于添加特性和功能非常有用，但很难扩展. 数据变化的频率有多高? 您是否有机会预先计算和提供静态的东西，而不是总是进行数据库查找或让某些东西命中复杂的服务?

最后一点我要提一下, 我认为在整个制作过程中，最后一个终端环节就是玩家. 这名球员, 希望每个人都知道自适应比特率流, 非常重要, 因为ABR的整个概念是我们已经改变了哪个部分的智能, 在任何给定的时间，玩家应该使用哪个比特率, 因为玩家可以根据特定用户的设备和网络特征等做出最佳决定. 确保你有可靠的回放, 你有很好的ABR决策, 你从玩家那里得到了正确的遥测数据, 然后也许——如果你是一个多cdn商店, 我相信玩家是完成多重cdn战略的关键部分.