非实时硬件转码器买方指南

我们开始讨论实时或实时转码器时，讨论了是否需要实时转码, 因此，这是非实时转码器买家指南中的一个很好的话题.

实时硬件转码器, 例如格式转换器, 是基于服务器的解决方案还是基于独立硬件的解决方案. 基于服务器的解决方案能够处理一切——包括帧率, 输出分辨率, 纵横比, 和细分——但需要额外的延迟，流媒体解决方案已经习惯了.

相比之下, 独立的基于硬件的转码解决方案可以用于实时（实时）转换——价格相当高，只是作为一个专用的, 单一用途的格式转换器-或非实时转码. 后一组, 哪个转换文件而不是实时流, 是我们将在这本《百家乐app下载》中重点介绍的吗.

比实时更快?

当我们谈到非实时转码时, 它并不一定意味着比实际时间慢：就像在零的两边都有整数一样, 称为正整数和负整数, 转码系统可以存在于实时等式的任何一边.

有些系统可以比实时更快地转换文件, 在不到一个小时的时间内转码一个小时长的文件——包括插入广告内容.

评估编解码器和格式需求

即使您的实时编码器-甚至您的实时格式转换转码器-也可以作为基于文件的转码解决方案, 格式或编解码器的数量可能受到编码器的限制. 例如，H.264编码器可能不支持基于WebM文件的转码, 因为WebM不是H的主要用途的组成部分.264编码器.

检查这些配置文件

另一个重要的问题是一次需要转换多少编解码器和格式. 毕竟, 市场上的编解码器数量可能正在减少, 但是离散的和不同的设备的数量正在迅速增长. 典型的代码转换会话可能需要多达30个不同的配置文件, 包括不同的纵横比, 帧速率, 和决议.

有多少转码的问题也与下一个主题有关, 自适应比特率, 哪个正在接管流媒体世界的几乎所有方面.

自适应比特率要求

要问的一个必然问题是，您的工作流是否需要自适应比特率传递（ABR）. 如今，答案几乎毫无疑问是“是的”."

而传统上被认为是实时编码, ABR的各种与Adobe竞争的格式, 苹果, 微软正迅速成为任何类型内容的必需品. 当我们说任何内容, 我们还指存储在夹层文件格式中的按需内容. 基于服务器的转码解决方案——以及转码和翻译, 我们在另一份买家指南中详细讨论了这一点——从最终用户的玩家那里收到请求, 确定必要的分辨率和带宽需求, 然后将夹层文件转码/分段为客户端设备的适当输出.

好消息是，由于之前提到的所有ABR竞争公司的辛勤工作，ABR已经以HTTP动态自适应流（DASH）的形式标准化了. 这个新的MPEG标准进一步被提炼成碎片化的mpeg4文件（fMP4）格式, 以H为中心.264，称为DASH 264. 这一部分应该会在今年年初获得批准.

一个平台还是多个平台?

我们之前提到WebM是为了提出关于基于硬件的转码器的另一个决策点. 许多基于硬件的解决方案将支持许多遗留的编解码器和格式，但实现新的编解码器和格式的速度会较慢. 这个过程通常涉及到达到能够以特定格式查看内容的最终用户的临界质量, 在一个特定的平台上, 然后确认编解码器和平台(e.g., 一个web浏览器)在提交到硅之前已经稳定了，一个最近的编解码器还没有标准化.

单个，成对或一组转码器?

单一用途的转码设备有多重要? 在决定是基于服务器还是

基于设备的代码转换解决方案, 在通用硬件上使用设备和软件的问题经常出现.

对于那些涉及广播或高调事件, 一个可以专门用于一项任务的单一用途设备可能是最吸引人的. 仅仅是一个开关和专用设备的即时响应就能温暖广播工程师的心，这是基于服务器的解决方案永远无法做到的.

另一方面, 如果时间是多种编解码器的本质, 那么你可能需要考虑几个转码器, 每个人访问一个单独的夹层文件，以便所有的转码可以并行执行.

一些基于硬件的转码器提供了一次解码夹层文件的省时功能, 记住它, 然后将其用于多个相似类型的转码. 这通常与ABR一起出现, 在哪里组的图片（GOP）对齐是各种比特率之间的关键, 但有些系统也会通过评估配置文件之间的冗余，并与每个匹配或几乎相似的配置文件共享解码文件，从而加快整个工作流程. 这种聪明的转码方法大大减轻了操作人员的负担.