使用 OpenGL 执行 YUV 颜色格式的视频合成 - 性能

Question

我编写了一个 C/C++ 实现，我称之为“合成器”（我来自视频背景），用于在视频源顶部合成/叠加视频/图形。我目前的合成器实现相当幼稚，并且还有改进 CPU 优化的空间（例如：SIMD、线程等）。

我已经为我目前正在做的事情创建了一个高级图表：

该图是不言自明的。尽管如此，我将详细说明一些限制：

• 主视频始终以 8 位 YUV 4:2:2 打包格式提供
• 辅助视频（可选）将以 8 位 YUV 4:2:2 或 YUVA 4:2:2:4 打包格式提供。
• 叠加层的输出必须以 8 位 YUV 4:2:2 打包格式输出

其他一些信息：

• 图形输入的数量会有所不同；它可能（也可能不是）是一个常数值。
• 图形的颜色格式可以固定为 ARGB 或 YUVA 格式（即，我可以根据您的需要提供）。目前，我将其固定到 YUVA 以保持一致的颜色格式。

使用 OpenGL 和随附的着色器的潜力相当吸引人：

1. 无需重新发明轮子（就实际执行构图而言）
2. 在可用的情况下使用 GPU 的可能性。

我对使用 OpenGL 的关注是性能。在网上环顾四周，我的理解是 YUV 表面会在内部转换为 RGB；我想尽量减少颜色格式转换的次数并确保最佳性能。如果没有之前的 OpenGL 经验，我希望有人能提供一些启示并建议我是否要冒险走错路。

在使用专用 GPU 时，也许我对性能的担忧不那么重要了？我是否需要考虑单独的代码路径：

• 带 GPU 的硬件
• 只有 CPU 的硬件？

另外，当我需要处理 10 位 YUV 时，我是否会遇到困难？

Answer 1

您应该能够始终将 YUV 视为独立通道。 OpenGL 着色器将调用它们 r、g 和 b，但它只是可以随意处理的数据。

大多数 GPU 将支持每通道 10 位（+ 2 alpha 位）。各种将支持所有 4 个通道的每个通道 16 位，但我在这里有点生疏，所以我不知道对此的支持有多普遍。不确定 4:2:2 数据，但您始终可以将其视为 3 个单独的表面。

• 图形输入的数量会有所不同；它可能（也可能不是）是一个常数值。

这是我不太确定的事情。像这样的着色器是可预测的。如果您的实现允许您迭代地添加每个输入，那么您应该没问题。

作为替代建议，您是否研究过 OpenCL？