使用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？