云端虚拟视频转码

服务提供商 将匹配的资源分配到应用程序。

对于视频转码，通过面板可提供大量视频经过优化的资源。为每个 用户/应用程序建立策略以管理对转码功能的使用，这由面板强制 执行。策略派生自服务级别，它极其灵活，能力具有弹性，例如：

• 　　临时允许超额容量 以溢价成本提供超额容量
• 　　对于想要实施网络功能虚拟化(NFV，此术语表示将网络应用与它们的基础硬件分离)的运营商/服务提供商，OpenStack 受到他们 的极大关注。换句话说，OpenStack 就是“适用于电信应用的云基 础架构”。

SDN/NFV 标准化

ETSI 建立了行业标准化工作组 (ISG) 来研究是否需要 NFV 标准。 虽然 OpenStack 来自企业界，但集中协调虚拟化的资源这种概念 将是形成 NFV 标准的关键组成部分。OpenStack 或其运营商级 版本可能会作为关键技术出现。

从基础架构上至管理和协调，ETSI NFV ISG 已经在 NFV 的结构 上建立了信息化工作。就其本身而论，这是对推荐做法的描述， 而不是如何实施 NFV 的任何标准，或来自多个供应商的、很多用 户使用的和许多服务提供商运行的设备和软件实际上将如何交互 操作的任何标准。但几乎可以肯定的是，NFV ISG 将继续工作两 年，目标是建立 NFV 的规范标准。

ISG 本身是由全球著名的服务提供商、设备制造商和独立软件供 应商组成。可以公平地说，NFV 拥有广泛且坚定的行业支持，将 会成功推荐出标准方案来实施包括视频在内的众多应用。

　　多视频处理资源的 SDN/NFV 控制

协调很多用户可用的多个异构视频资源不是一项简单的任务。事 实证明，OpenStack 在企业云环境下可扩展性极大，期望形成的任何 NFV 标准都将拥有相同的可扩展性。

但是，作为应用程序的视频与企业云应用程序差异很大，应该认 真考虑。视频传输是资源消耗的“完美风暴”：

需要使用大容量存储才能维持视频内容的数据库视频流从源格式到最终传输格式的转码(比特率、视频格式、

屏幕尺寸等)需要消耗大量计算资源到最终用户的流量传递几乎是实时的;可用带宽必须匹配转码器生成的流量

因此，协调器必须知道可用于视频转码的资源，以及通过网络获得视频数据包所需的带宽。这是一个网络边缘问题(最终传递到 消费者设备)。这对于中间处理也是一个问题，中间处理是将原 始的、集中化的内容(通常来自制作者或播送者)转码，并推送到位于网络边缘(尽可能靠近最终消费者)的多个实例。

另外一个考虑是假设 OpenStack 控制(“协调”)虚拟资源——本 质上，虚拟机 (VM) ——通过其管理程序层加以实现，该层从底层硬件抽象出应用程序执行环境。服务器可支持多个 VM，资源被 认为在规模上有弹性。

视频再次遇到了问题。如果转码从主机 CPU 转到一个加速器上，那 么 OpenStack 协调器需要知道加速器可用(且支持视频功能)。更糟 糕的是，加速器架构通常不使用 VM 技术，而是在 CPU 主操作系统上直接运行(常用术语“裸机”描述非 VM 模式)。

OpenStack 如何协调直接映射到硬件的“执行”资源?幸运地是，这个 问题有解决方案：OpenStack 有一个插件(称为 “Ironic”)用于协调 裸机资源。其 Northbound API 与管理 VM 的接口完全相同，但 Southbound 接口知道它管理单一的硬件资源。

将来，ETSI NFV 工作组将标准化这样做所需的接口和基础架构。同 时，OpenStack 和 SDN 的互补技术将弥补此间隙。OpenStack 允许 协调资源时，SDN 利用 OpenFlow 协议配置网络交换机，以提供与 要传输的视频流量一致的互连能力。OpenDaylight 等 SDN 控制器可协助协调流量。

另一种方法是，简单地提供将视频处理为“永远在线”所需的“最坏情 况”计算和网络资源。因为所提供的资源大部分时间不使用，这将导 致网络的能力过剩(以及由此产生的成本)。

在 Hulu 模式中，视频每天以批量“离线”的方式被处理和传输。“大众 消费事件”的情况甚至更加极端，例如大型体育赛事，其现场直播必 须缓存和实时处理。

通过组合使用 NFV (OpenStack) 和 SDN，资源仅在使用时被消费和 付费。资源可用性的弹性意味着，可以满足意想不到级别的需求，而且无需事先过度配置。

这里所使用的 OpenStack、OpenFlow、OpenDaylight 等现有技术， 均为开源项目，开发人员可免费使用以实施这些服务。

　　应用示例：OTT 视频流 电视回看 OTT 内容传递

云端视频转码越来越多地被使用，其中一种情况是电视回看或追赶，内容提供商接收来自多个制作者的