本文为媒矿工厂翻译的技术文章
原标题：Video Engineering for OTT – A 10K Foot View
原作者：Uday Shankar Ammanagi
原文链接：https://ottverse.com/video-engineering-for-ott-overview/
翻译整理：胡经川
如果你在谷歌上搜索"什么是视频编码"，排名第一的结果来自Mux，它将其解释为 "视频编码是通过压缩使视频文件变小的过程"。这可能是对 "编码 "一词最无可争议的定义。
然而，进入任何一家OTT公司的技术思维导图，你会看到一个至少有5-6个子节点的 "编码 "节点，上述定义根本无法清楚描述它。
例如，以下是一个典型的OTT公司的 "编码 "下所涵盖的技术清单。
源视频质量控制缩略图提取视频压缩包装成ABRS格式加密和DRM的打包字幕打包QoS和QoE内容管理系统 接下来会对上面列出的每个主题进行讨论并更好地理解它们——包括它们是如何实施的，以及在典型的 OTT 环境中的关键挑战和权衡。
一、源视频质量控制不同的商业模式对OTT服务的视频内容的方式和来源具有不同的作用。源视频质量控制（QC）所涉及的复杂性和挑战，取决于组织对摄入系统的夹层视频文件(mezzanine video files)的控制程度。视频工程团队和内容供应商之间就源视频的属性和质量限制签订合同是一种普遍的做法。
通常情况下，拒绝不符合约束条件的内容会使内容供应商有义务提供符合合同规定的源视频。然而，在某些情况下，OTT服务没有与内容所有者的谈判能力，这是一个需要解决的问题。
接下来我们讨论一下源视频中常见的几个不符合要求的操作
Letter Box 和Pillar Box：Letter Box是指视频顶部和底部的黑条。Pillar Box则是指视频左侧和右侧的黑条。通常情况下，被用来进行长宽比的调整并适应屏幕尺寸。低分辨率视频：这是指源视频的最小分辨率。它可以因内容而异。某些内容采取UHD，而其他内容也可以接受 720p。上采样视频：实际视频是720p。为了满足要求，它被上采样到了1080p的水平。这是内容提供商试图将不符合质量要求的内容出售给OTT服务提供商的结果。不完整的内容：比如源视频的大小为1.4GB，但OTT服务商只收到1.1GB。可能是由于不完整的复制操作，或由于网络中断，收到了不完整的源视频。不受支持的编解码器或容器：编解码器和容器的范围很广。理想情况下，我们应该支持所有符合标准的格式，但总会有一些限制。有许多这样的不合规范的视频源，检测源视频进行质量控制所涉及的复杂程度参差不齐，并十分耗费计算资源和计算时间。其中一些问题可以通过解析标题来检测，但一些复杂问题则需要包括视频解码在内的复杂分析。
对于一些诸如上采样视频的问题，主观上的质量控制会更有效。有些问题影响的是消费者的QoE，而有些问题（如流媒体无法解码）则直接不允许OTT对视频进行编码和发布。
低分辨率的问题是无法修复，因为没有简单可行的方法来提高视频的分辨率。在这种情况下，就不得不在进行质量上的妥协或拒绝业务之间做出选择。相比之下，像Letter Box 和Pillar Box的问题可以用FFmpeg等开源工具来解决。当然这种工具有很多--有些是开源的，如FFmpeg、ffprobe、MediaInfo、HandBrake等，还有一些是专有工具，如Baton、Rhozet、Telestream等。
二、视频压缩视频压缩是视频系统的核心。它是投资回报率最高的组件，也是构建 IP 范围最大的组件。对于任何 OTT 公司来说，做好它是关键。那么OTT公司视频工程团队在视频压缩方面的“目标”和“期望”有哪些呢？
使用所有平台都支持的编解码器--iOS、Android、Chromium、Firefox、Safari、Edge。在现有的编解码器中，H.264/AVC在通用性方面更胜一筹，而且预计至少在五年内都会如此。将视频流压缩到尽可能低的比特率，同时保持可接受的质量。比特率将取决于所使用的编解码器、内容复杂度、目标屏幕尺寸和分辨率。必须同时生成不同分辨率的视频以支持不同的网络条件。创建 144p 到 1080p（以及 4K）的分辨率是行业惯例。H.264/AVC 是必须的。此外VP9 和HEVC也是需要考虑的。由于要生成多种格式因此会涉及额外成本。包括编码所需的CPU成本、CDN节点缓存成本、HEVC专利池和相关使用费中涉及的不确定性。另外HEVC 和 VP9 编解码器的平台支持十分复杂。在采用这些编解码器之前，需要了解用户及其设备。除此之外，市场上还有很多关于下一代编解码器的议论，比如AV1、VVC以及LCEVC。编码社区中有很多讨论，但没有人清楚这些编解码器的未来。
对于针对东南亚和中东等发展中市场的OTT服务，由于这些市场主要是安卓市场，这些地区iOS用户不到10-15%（大部分在带宽较好、对成本敏感度较低的市场），只使用H.264/AVC和VP9编解码器会是一个好的选择。一旦有了VP9，HEVC就不值得投资了。当然开始探索AV1也会有帮助，但在这之前要注意行业趋势。
三、自适应比特流ABR （Adaptive Bitrate Streaming）是一种使视频播放器能够根据带宽波动来调整视频流质量的技术。正如上一节所讨论的，我们已经生成了不同比特率和分辨率的多种编码内容。为了使用 ABR，我们将视频分块(chunk)并开发索引，将这些分辨率映射到相应的比特率——这是打包过程中最关键的部分。有几种常见的 ABR 流媒体协议：HLS、DASH以及Smooth Streaming 。ABR 是通过 Internet 进行流式传输的支柱——这是简单技术产生巨大影响的一个很好的例子，感兴趣的话可以从这里获取更多这方面的内容：https://ottverse.com/what-is-abr-video-streaming/。
四、加密和 DRMOTT 内容是需要保护的。DRM 旨在保护内容免遭盗版。可以参考 OTTVerse 上的这篇文章来解释 DRM 的基础知识：https://ottverse.com/encoding-com-beamr-cabr/。DRM 的一些高级用例有：仅限高级消费者访问高清内容、限制通过 HDMI 端口和屏幕镜像访问内容、对内容的并发视图应用使用规则、下载到期的使用规则等
五、字幕与隐藏字幕字幕（文本）是单独创建的，通常由字幕供应商手动创建。有语音到文本转换的技术，但尚未在 OTT 领域广泛采用。有两种流行的标准来表示这些字幕——SRT 和 WebVTT。
字幕和隐藏式字幕(Closed Captions)之间有非常细微的区别。字幕的目的是帮助不懂内容语言的观众而隐藏式字幕用于帮助有听力障碍的观众或当内容需要静音时使用。在“打包”阶段，对 WebVTT 的引用被添加到 HLS 和 DASH 清单文件中。
每一项技术，无论它看起来多么简单--如果你以正确的方式采用它，就有机会实现差异化。考虑这个用例，即你在你的OTT平台上上线了一个没有字幕的内容，然后你想现在添加字幕。除非你的API是为这个用例设计的，否则不可能有效地做到这一点。理想情况下，应该有一个单独的微服务用于字幕打包。这是一个非常 "主流 "的用例。
六、内容管理（管理和存储）源视频、编码视频、字幕、元数据是OTT公司的资产。OTT的业务是关于这些资产的变现。那么，在哪里储存这些资产？有多种选择，成本各不相同。根据资产的 "老化 "情况，将内容归档到 "冷 "存储选项是一种流行的做法。
资产管理的另一个方面是这些资产的 "元数据"、"关系 "和 "层次结构"。这是CMS（内容管理系统）的主要关注点之一。其他问题是与这些资产相关的地域、屏幕类型、许可期限等有关的权限。然后是与资产管理相关的整个工作流程。
七、总结从内容提供商那里获取视频内容并对其进行处理以便在OTT平台上消费，这被称为视频工程。正如所讨论的，这是一个复杂的过程。它也可以说是OTT技术栈中最关键的部分--把它做好是至关重要的。
直到最近，OTT服务商中的大多数都在使用”交钥匙”的解决方案，只有一个目标——"使之工作"，但随着他们的业务日渐庞大，他们意识到这些技术是他们业务的核心。这些公司正在加强团队建设，并雇用了领域专家，这无疑是一件好事。
此外，像实时流媒体、低延迟、分析、客观/主观质量指标等话题，在今天的OTT领域同样重要。