评估云转码选项的4个关键

许多高质量的现场制作都涉及云转码, 因为将单个流发送到云端进行转码通常是最节省带宽和成本的方法. I've been benchmarking hardware and software transcoders for the last 12 months or so; this column shares the key differentiating points among transcoders as I see them.

密度/成本

用于大容量操作, 第一个需要确定的比较因素是每小时每个编码阶梯的成本. 来计算这个, 您可以为所有转码器创建一个具有代表性的编码阶梯, 确保对齐参数，如比特率控制方法(始终保持恒定比特率), 关键帧间隔, 封闭的共和党, 预设, 以及尽可能接近的侧写. 由于来自不同供应商的相互冲突的建议(比如一个建议两个b帧，另一个建议三个b帧)，您必须在开始测试之前进行协调，这通常会使问题变得复杂.

一旦设置了命令, 我通常在AWS或其他运行Ubuntu的云实例上进行编码，并使用针对我正在测试的转码器修改的FFmpeg版本，或者使用适用于x264和x265的FFmpeg常规版本. 计算每小时每个编码阶梯的成本, 你开始用编码器对一个梯子进行编码, 如果你达到了全帧速率, 您打开另一个终端窗口并启动另一个流. 最近，在c5d上运行x264.大号的大约1美元.我花了75个小时，使用60帧/秒的源文件以55帧/秒或更高的速度制作了6个完整的编码阶梯. 这样每架梯子每小时的成本约为0美元.30. 只要你是在一个每小时收费的平台上进行测试，这个方法就很简单.

质量

质量就没那么简单了，它有三个方面:客观的、主观的和短暂的. 用视频多方法评估融合(VMAF)很容易创建生成率失真曲线和BD-Rate比较所需的四种编码。, SSIMWAVE, 峰值信噪比(PSNR), or other metrics; just remember to follow the tuning recommendations for each codec. 例如，x264具有PSNR(我也将其用于VMAF)和SSIM的调优设置. 在比较不同的转码引擎时，客观指标的问题在于它们通常不能准确反映人眼对视频的实际评价. 所以我几乎总是通过像Subjectify这样的服务进行主观比较.我们还是GBTech.

评估瞬时质量很容易:我将不同的文件加载到莫斯科国立大学的视频质量测量工具(VQMT)中，并运行每个度量. VQMT生成一个结果图，显示文件持续时间内的度量分数. 明显的质量下降, 你可以点击一个按钮来查看那个位置的帧并确认降级的质量. 如果质量下降持续超过几帧, 它可能会被一个实际的观众注意到.

瞬态质量通常是软件转码器容易降低的地方, 特别是当运行低质量的预设时，比如非常快或超快(对于x264和x265). So you can't just look at overall score; you have to look for transient quality issues.

延迟

在编码器之间你不会看到巨大的延迟增量, 但是，由于一两秒钟的延迟可以提高整体质量，并减少出现暂时问题的可能性, 你也要追踪这个. 虽然我使用的是云中的Ubuntu实例, 实际上，我是在办公室的一台windows电脑上运行这些测试的. 测量延迟, 我用Camtasia之类的屏幕捕捉程序捕捉测试, 它既能提供准确的测量，又能提供我可以与客户分享的记录.

数据速率的一致性

数据速率一致性是指转码器产生的数据速率与平均数据速率的跟踪程度, 通过标准偏差或流的惊人数据速率图来测量. 有视频点播, 数据速率一致性不是问题，因为所有观众在不同的时间观看. 有直播, 如果你在为成千上万的观众举行的goooaaall庆祝活动中将数据速率提高50%, 您可能会超出交付生态系统的百家乐软件，导致事件崩溃. 如果你分发了几千个流, this isn't important; if you're in the hundreds of thousands, 这是一个你需要考虑的比较.

结束语:首先，H.基于264的转码在云中运行良好, HEVC requires many more resources and may not; hardware is often a better option. 第二个, 虽然这个测试听起来很简单, 即使在对编解码器进行了超过25年的基准测试之后, 我发现第一次做对是非常困难的. 因此，在你的计划中要为反复测试留出时间.