问3度转码帧I420 RGBA BGRA

EN

当接收原始视频帧时，帧包含在I420格式中。

如果你相信VideoLAN wiki，解码所有视频时的标准格式（没有libi420_rgb_plugin模块和/或libi420_rgb_plugin），每帧都以I420格式给出

从VideoLAN YUV页面引用：

I420

It has the luma "luminance" plane Y first, then the U chroma plane and last the V chroma plane.

The two chroma planes (blue and red projections) are sub-sampled in both the horizontal and vertical dimensions by a factor of 2. That is to say, for a 2x2 square of pixels, there are 4 Y samples but only 1 U sample and 1 V sample.

This format requires 4*8+8+8=48 bits for 4 pixels, so its depth is 12 bits per pixel.

I420 is by far the most common format in VLC. Most video decoders output raw pictures in I420 format.

A graphical illustration: Each letter represents one bit.

For a single I420 pixel: YYYYYYYY UU VV
For a 50-pixel I420 frame: YYYYYYYY*50 UU*50 VV*50 (or Y*8*50 U*2*50 V*2*50 for short)
For an n-pixel I420 frame: Y*8*n U*2*n V*2*n
 

从书面来看，只有一个是可以理解的，这种格式包含的框架重量较轻，但更难以阅读和转换为这种或那种格式。从不清楚的是，需要将多少内存分配给例如大小的帧1920x1080，并且有可能对于软件转码2个缓冲区，原始帧和重新编码的帧是必需的。关于CPU时间，所需格式的编码成本以及图片输出的许多问题都来自这里。

可以使用现成的解决方案，如RV32，但SFML以BGRA格式创建纹理，但渲染帧格式为色度RV32 RGBA即。这里有一个用于重新排列颜色通道的顶部费用R <-> B。在我的弱PC上，“转码”/重新排列频道的成本大约需要22-150ms，在视频帧速率不高于每秒60帧的情况下，大小不会超过1080p。

在论坛的某个地方我看到，随着opengl改变颜色通道，有一个“硬件/软件”我并不完全理解排列，但是，立即写出成本很高。因此问题是，获取RAW图像并在需要的图像中编码一次并不容易吗？是否有任何解决方案可以在硬件级别执行此类操作而无需触及软件部分？