2017年10月11日
By Jan Ozer 特约编辑
专题文章

Demuxed:视频工程师的涅槃

Demuxed 被称为“视频工程师会议”,它是旧金山视频技术聚会小组的一个分支，主要由QoE供应商的员工制作 Mux 还有很多志愿者，由像 Bitmovin, Brightcove, Google, Netflix, DLVR, Beamr, Conviva, Wowza, and JWPlayer. 今年10月5日的大会座无虚席，有19位演讲者进行了10到45分钟不等的演讲. 各种各样的话题为每个人提供了一些东西, 大多数谈话都是高度技术性的, 权威的, 还有很有用的幻灯片和评论. 我很幸运, 在会议结束的时候，有许多与编码相关的演讲, 最后一次治疗结束后，我准备好接受更多治疗了. 后来, 有饮料和丰盛的开胃菜, 并有机会与演讲者和300名与会者交流.

你为什么要在意呢?? 因为所有这些演讲现在都可以在网上找到, 或者很快就会, 所以你可以在舒适的办公室或家里查看它们. 我在这里要做的是突出我觉得最有趣的演讲, 分享一些我在活动中收集到的信息. 为了简短起见，我不会提到所有的演讲，所以你应该看看主题 here 看看有没有你感兴趣的.

本文中的视频引用是捕获的实时流. 这一努力进行得并不顺利, 因此，从直播转换而来的视频点播片段中存在许多空白. 幸运的是, 所有会话都是离线记录的, 因此，在接下来的几周内，应该可以以标记良好的原始格式提供. 所有视频将在 demuxed.com. [Ed. 注:本文的早期版本包含原始视频的链接. 这些版本已被删除，并将很快被最终删减版所取代.]

HDR-Related会谈

Netflix的流媒体标准主管马克沃特森以45分钟的主题演讲拉开了序幕. 沃森首先讨论了电子节目指南(EPG)的演变。, 它从大量的文本菜单过渡到基于图像的指南，再到Netflix在这篇文章中记录的基于视频的发现体验 blog post. (Figure 1). The transition to video wasn't to produce eye candy; the videos shown are "specially designed video synopses that help members make faster and more confident decisions by quickly highlighting the story, 字符, 和标题的语气,沃森说.

Figure 1. Netflix的新视频发现体验使用视频来辅助选择, 但是这些视频的动态范围的变化使得这非常具有挑战性.

然后，沃森换了一个话题，讨论了Netflix是如何在其内容和EPG中添加HDR编码的, 全面回顾了各种HDR传输技术(HDR10), 杜比的愿景, HLG, HDR10+)及其组成部分(伽马曲线), 动态和. 静态元数据). 任何想要快速了解这些技术如何工作的人都会发现本节非常有用.

Finally, 沃森将这两个话题交织在一起, 描述呈现具有不同亮度级别的视频所涉及的技术问题, color, 和动态范围, 然而，做好这件事是多么重要, 以免观众选错视频, 或者更糟, 点击到另一个网站. Overall, 这是一场精彩的演讲，讨论了将HDR集成到OTT发现和交付服务中是多么具有挑战性.

在关于HDR的话题上，还有其他一些值得注意的会议. 十分钟后，毕姆家 Dr. 格雷格·米尔斯基涵盖了四种最突出的HDR技术, 杜比的愿景, HDR 10, HLG, HDR10+(带有动态元数据的HDR10), 用有用的图形和表格组合来突出它们的关键不同点和相似性. Beamr和Dr. 米尔斯基很友好地让我们在演示中使用两张总结幻灯片, 我把它们合并成一个(Figure 2). 如果你正在寻找关于HDR的快速入门，请查看Dr. 米尔斯基的演讲.

Figure 2. Summary of the pros and cons of four prominent HDR technologies; courtesy of Beamr和Dr. 格雷格·米尔斯基.

当天晚些时候，维托里奥Giovara, Vimeo的一位高级工程师就HDR技术做了一个30分钟的详细理论演讲，从人眼中的颜色和亮度感应锥和杆开始, 最后介绍了每种编解码器处理HDR的优缺点. 在此过程中，他还涵盖了所有相关的标准，比沃森和米尔斯基都要深入.

AV1更新

沃森之后，Mozilla视频编解码器工程师托马斯Daede 提供了来自开放媒体联盟的AV1编解码器的最新状态, 报道称，这些功能将在10月底冻结，并计划在2017年底实施硬冻结. 然后，他对新编解码器的许多独特功能进行了深入的技术讨论, 他说，所有这些都有助于AV1以75%的比特率达到HEVC的质量(Figure 3). 缺点是编码时间, Daede用200倍的VP9视频编码时间放的, 虽然这是针对未优化的代码. 解码图像要亮得多，AV1解码速度比VP9慢50%左右.

Daede还向观众指出了Bitmovin/Mozilla demo 可以播放AV1视频并自行测量解码复杂度, 不过你需要下载“夜间”版本的Firefox才能获得解码器.

Figure 3. 根据Mozilla的托马斯Daede的说法，AV1以大约75%的带宽提供了与HEVC相同的质量.

所有这些都是初步的, of course, 因为部署AV1的不同公司将以不同的方式配置和优化编解码器. Still, 很高兴听到AV1仍在继续发展，并将在2017年底左右上市.

接下来是Twitch的10分钟演讲 Tarek Amara 在AV1的s帧上. Briefly, s帧是一种新的帧类型，可以在不需要IDR帧的情况下在段之间进行流交换, 这样可以提高系统对变化条件的响应能力并减少延迟. 我们一直在研究I, B-, and P-frames since MPEG-2; you'll be hearing a lot more about S-frames going forward.

在这两次与av1相关的讨论之后，我们与律师一起转向了HEVC的阴暗面赫克托耳Ribera 识别持牌人, licensors, 三个专利池的定价政策(MPEG LA), HEVC提前, 和Velos), 还有其他公司, 喜欢鲜艳的色彩, 声称拥有hevc相关知识产权的公司. 据Ribera报道，Velos仍未公布其计划中的版税模式, 其中可能包含或不包含内容版税. 他还表示，Velos集团中至少有一家授权方声称拥有部署在VP9甚至AV1上的IP.

虽然里贝拉没有说明, 这可能意味着Velos将尝试为AV1建立一个专利池, 就像不受欢迎的MPEG LA DASH池一样, 或者可能会起诉联盟侵犯专利. 所有这些以及更多的事情都将在2018年发生, 或者更晚, 考虑到Velos IP所有者迄今为止的发展速度.

Netflix和动态优化

从纯粹的编码角度来看，最有趣的演讲之一是Netflix的此举使Manohara他将Netflix对标题编码的改进称为动态优化. 在她题为“250Kbps的流媒体”的演讲中, 提高期望值,Manohara首先详细介绍了向全球许多市场提供高质量低比特率视频的重要性.

你可能还记得，Netflix在2015年底推出了按标题编码. 在高水平上, Netflix的按标题编码模式通过在不同质量水平和不同分辨率下对源视频产生多个测试编码来为该视频找到理想的比特率阶梯. 基于这些发现, Netflix自定义整个视频文件的编码，以优化每个标题的质量和带宽.

寻求更大的收获, Netflix是在逐帧的基础上测试编码的, 尽管这种分析所涉及的排列被证明对Netflix的编码能力来说太大了. So, 他们聪明地将分析范围缩小到最有可能产生可用输出的质量水平和分辨率的组合, 并开始将多个镜头组合成更长的片段. Still, 编码一部Netflix电影可能需要12小时到9天不等, 视长度而定, 输出格式.264或VP9)，以及编码积压.

的好处? 取决于编解码器和电影, 动态优化提供了高达55%的节省比每个标题编码, 将“高质量视频”的数据速率从600Kbps降低到270Kbps. Manohara在演讲结束时展示了几个前后的视频, 结果看起来很惊人. Netflix将在未来的博客中详细介绍这种技术，我个人已经迫不及待地想看到了.

Wowza的低延迟视频

在过去的12到18个月里，延迟一直是一个热门话题, 也是Wowza的首席架构师兼副总裁斯科特Kellicker 高级产品经理杰米雪利酒我们在现场做报告吗, “3秒规模的端到端延迟,，详细介绍了Wowza为提供低于3秒延迟的服务所做的努力. 高管们首先介绍了各种交付机制中延迟状态的当前状态, 如图所示 Figure 4在Wowza的演讲中.

Figure 4. 延迟状态的当前状态.

他们还指出，苹果HLS通常提供30秒以上的延迟(使用10秒的块)。, 而DASH提供10-30秒的延迟. 虽然这种性能对于许多现场活动是可以接受的, 这显然不适合其他人, 特别是当涉及到赌博或拍卖时.

该演示介绍了Wowza团队关于减少延迟的最佳方法的分析, 谁首先得出结论，基于块的流对于某些用例来说太慢了. 相反，他们的解决方案将使用“老派”的基于服务器的流媒体. 接下来，他们考虑是使用webbrtc还是websocket传输, 最终决定使用后者，因为它在不同的浏览器实现中更加稳定, 并且在编解码器方面更加灵活. 元数据不能与音频和视频同步的事实是WebRTC的另一个限制.

Kellicker和Sherry说过, 在构建系统时, 他们已经有了坚实的基础, 包括一个强大的流媒体服务器, 为云产品提供成熟的基础设施, 以及基于媒体源扩展的播放器. 接下来，他们必须选择一个流媒体协议, 结果是他们可以使用内部的, 低延迟, 用于服务器到服务器通信的双向协议WOWZ. 因此，他们将该协议添加到Wowza的媒体服务器和播放器中，并通过websockets进行传输. 他们还设计了一种结构，可以在原点上使用, midgress, 和边缘服务器，因为这是他们的大型客户使用技术的方式.