买家指南:实时转码器

本文刊登在…的二/三月号 流媒体 杂志，年度 流媒体行业资料手册. 在这些买方指南文章中, 我们并不声称涵盖某一特定类别的所有产品或供应商, 而是为我们的读者提供他们需要的信息来做出明智的购买决定, 有时使用特定的供应商或产品作为这些功能和服务的范例.

我们在另一篇文章中介绍了实时编码器买家指南但只是简单地谈到了实时转码. 在本买家指南中，我们将深入研究基于硬件和服务器的实时转码器的选项.

在广播界, 现场转码是近四十年来的主要内容, 从一种格式或信号类型转换到另一种格式或信号类型的过程通常称为格式转换. 在模拟传输时代, PAL信号可能被转换成NTSC或SECAM，以便跨国界或跨地域广播. 对于现场活动, 这种格式转换意味着转换信号的频率和分辨率.

数字空中传输(OTA)的世界并没有太大的变化. 在16:9宽高比高清电视被广泛采用之前, 格式转换包括频率转换和宽高比变化, 以4:3的宽高比容纳大量的传统电视. 这些数字格式转换器仍然是OTA交付的重要组成部分, 并在在线直播视频世界中发挥作用.

用于流媒体视频, 格式转换与打包和分割相结合, 将一种编解码器类型转换为另一种，甚至可能从一种帧率转换为另一种帧率.

需要寻找哪些关键特性?

1. 有多少编解码器、格式、分辨率和/或比特率可以实时转码? 虽然许多基于硬件的转码解决方案能够从一种格式或编解码器实时转换到另一种格式或编解码器, 可以同时进行多个转码的数量有限.

经验法则似乎是，大多数专用格式转换器都可以进行两种转换, 选择从组合帧率, 输出分辨率, 纵横比, 色彩空间变换. 这些专用转换器也可以处理梳状滤波器, 有些还会处理伴随的音频信号的预处理要求.

相反, 正如我们在NN页的买方指南中看到的那样, 有一些硬件软件解决方案的价格要低得多，但只要生产工作流程不需要实时转换，它们的工作效果就一样好.

2. 实时转换有多重要? 实时硬件转码器, 特别是那些工作在格式转换, 以毫秒为单位的延迟闻名吗. 为流, 还存在基于服务器的实时转码选项, 在转码步骤中可以投入大量额外的火力. 少数可用的基于服务器的解决方案能够处理一切——包括帧速率, 输出分辨率, 纵横比, 和分段——但需要额外的延迟，流媒体解决方案已经习惯了.

3. 可以实时转码多个输入吗? 格式转换器, 为了处理计算量大的预处理, 将一种信号类型转换为另一种信号类型. 另一方面, 那些有IP输入的实时转码解决方案通常有足够的能力处理多个信号的多个转码. 这方面的一个例子是接收MPEG-2传输流的实时转码盒, 对内容进行分类(例如.g.(MPEG-2编解码内容)，将内容转码为H.264，然后重新打包到另一个MPEG-2传输流重新传输.

4. 单一用途的设备有多重要? 就基于服务器或基于设备的转码解决方案而言, 单一用途装置的问题也是一个必要的考虑. 对于那些涉及广播或高调事件, 一个可以专门用于一项任务的单一用途设备可能是最吸引人的. 仅仅是一个开关和专用设备的即时响应就能温暖广播工程师的心，这是基于服务器的解决方案永远无法做到的.

另一方面, 单一用途的设备通常被锁定在一个时间点上, 有足够的马力来完成手头的任务，但升级处理其他格式的能力有限, 编解码器, 或者自适应比特率场景, 我们将在下一点看到. 广播设备的经销商可以向你展示满是过时设备的仓库, 一旦为他们的目的服务, 是为了给下一个能够提供增量升级功能的闪亮黑盒让路.

5. 自适应比特率是生产工作流程的必要部分吗? 最后一个例子引出了实时转码的另一个关键部分:对自适应比特率传输的潜在需求. 虽然这通常被认为是用于实时编码, 各种竞争格式的自适应比特率正迅速成为任何类型内容的必需品, 包括以夹层文件格式存储的按需内容. 基于服务器的实时转码解决方案将接收来自最终用户播放器的请求, 确定必要的分辨率和带宽需求, 然后将夹层文件转码/分段为客户端设备的适当输出.

你可能会问，为什么不事先这样做, 在内容请求时将媒体服务器从额外的处理中保存下来. 而当前内容通常是这样做的, 许多长尾视频还没有转换为自适应比特率传输. 而不是告诉终端用户某一段内容不可用, 实时转码允许长尾视频内容立即提供. 可以强制执行媒体服务器级别的其他业务规则, 将转码内容的副本保存一段时间, 避免需要为每个请求转码.

继续使用高质量的夹层文件，然后动态转码的另一个原因与Adobe的自适应比特率解决方案有关, 苹果, 微软和新批准的DASH标准. 直到自适应比特率稳定下来, 实时转码提供了一种维护单个资产的方法，然后在请求时将其转换为各种交付版本.

在总结这个买家指南之前，让我们考虑最后一个因素:成本. 一个专用的费用, 单一用途的格式转换器通常高于服务器和软件解决方案, 尽管近年来设备格式转换器的价格有所下降. 单是初始成本, 虽然, 不能成为唯一的决策点, 特别是当基于软件的解决方案在重大事件中出现问题时. 软件解决方案重新启动时的42秒延迟可能只是工作完成得很好和工作早就结束之间的区别.