企业官网建设流程全解析

1. 认识Rockchip RGA：一块被低估的2D硬件加速引擎

先说结论：如果你在RK3588、RK3568、RV1126这类瑞芯微平台上做视频处理、AI图像预处理或者UI合成，却还在用CPU做缩放、格式转换、旋转，那真的亏大了。RGA（Raster Graphic Acceleration）是Rockchip芯片内部专门负责2D图像处理操作的硬件模块，它能以极低的CPU占用完成图像缩放、旋转、裁剪、格式转换、叠加和透明度混合等任务。

我第一次接触RGA是在一个RK3588的项目上，当时要做四路摄像头画面的实时拼接预览，每路1080p的NV12帧要缩放到720p再叠加OSD信息。一开始用CPU软缩放加memcpy，四路加起来直接吃掉了三个大核接近80%的算力，CPU温度蹭蹭往上走。后来把图像处理部分全部切到RGA，CPU占用率掉到不足10%，画面还更流畅了。从那以后，凡是芯片上带RGA的平台，我基本不会再写纯CPU的图像处理路径。

这篇文章适合哪类人看：正在做Rockchip平台图像处理方案选型的工程师、刚拿到RK3588开发板想跑通RGA流程的新手、以及被OpenCV软件处理性能问题折磨到怀疑人生的朋友。我会把RGA的核心功能、API设计思路、实测可用的代码、以及我在项目里踩过的坑全部整理出来，内容以RK3588平台为例，但原理和代码对其他带RGA的Rockchip芯片同样适用。

1.1 RGA在芯片里的位置和设计初衷

RGA全称Raster Graphic Acceleration，直译过来是"光栅图形加速器"。它在芯片中的位置通常在ISP和显示控制器之间，也可以被CPU通过Librga库直接调用。它和GPU不是一回事：GPU负责复杂的3D渲染和通用计算，而RGA是一颗专注2D图像操作的专用引擎，功耗低、延迟小、响应时间可预期。

设计初衷非常朴素：视频应用中大量图像处理操作是重复且规整的，比如把1080p缩放到720p，把NV12转成RGB888，把图像旋转90度。这些操作如果用CPU逐像素处理，效率低不说，还占用宝贵的算力。如果用GPU处理，则需要管理复杂的图形上下文，延迟不可控，功耗也高。RGA就是中间那条高速路：只要把源地址、目标地址、格式、分辨率这些参数配置好，硬件自动完成整块图像的处理。

从架构上看，RGA内部包含缩放模块、旋转模块、格式转换模块、颜色空间转换模块和alpha混合模块。这些模块以流水线方式工作，所以一次调用可以同时完成多种操作，比如"缩放+格式转换+旋转"一条命令搞定，不需要分多次执行，这也是RGA性能强劲的关键原因之一。

1.2 RGA能带来多少性能收益

用一个我自己实测的数据来说明。在RK3588上处理一张1920x1080的NV12图像，缩放到1280x720：

• CPU软实现（NEON优化版本）：平均耗时约6-9毫秒，大核占用率满负荷
• RGA硬件处理：平均耗时约0.8-1.5毫秒，CPU占用率基本为零

如果是格式转换，比如NV12转RGBA8888，CPU需要处理YUV到RGB的换算逻辑，耗时在10毫秒以上；RGA同样在1-2毫秒内完成。在连续的视频帧处理场景下，这个性能差距意味着你可以在同样的时间内多跑两三路视频流，或者在24fps的实时性要求下留出大量余量做AI推理和其他业务逻辑。

有一个容易被忽略的点：RGA不仅仅是省CPU，它还能降低系统功耗。硬件模块完成同样的工作消耗的能量远低于CPU，这在电池供电的边缘设备或者需要长时间无人值守的场景下非常关键。我在RK3588的智能摄像头项目上，把图像预处理全部切到RGA之后，整机功耗下降了约15%，发热量也明显改善。

1.3 RGA的硬件能力边界：先看清再动手

不同型号的Rockchip芯片，RGA的规格不一样。以RK3588为例：

• 最大输入分辨率：8192x8192（需MMU支持）
• 最大输出分辨率：8192x8192
• 支持旋转角度：0度、90度、180度、270度
• 支持镜像：水平镜像、垂直镜像
• 缩放比例：1/16到16倍
• 支持的输入输出格式：RGB565、RGB888、RGBA8888、NV12、NV21、YUV420、YUV422等
• 支持的色彩空间：BT.601、BT.709、BT.2020

这里列的是RK3588的参数，RK3568和RK3399的RGA版本略低，格式支持和最大分辨率会打折扣。开始写代码之前，务必查阅对应芯片的TRM（Technical Reference Manual）或者RGA的版本说明，确认你需要的格式是否在支持列表里。我见过太多人栽在"我的板子不支持这个格式"这种问题上，白费几天功夫。

另外一个重要概念是MMU（Memory Management Unit）。带MMU的RGA可以使用普通用户空间的虚拟地址，不需要物理连续内存，这对开发体验来说是很大的解放。早期不带MMU的RGA（如RK3288上的老版本）要求输入输出buffer必须是物理连续且对齐的内存，否则驱动直接报错。现在RK3588、RK3568这些主流芯片都带MMU，用malloc分配的buffer也能正常工作，但性能上仍有差异，后面我会细讲。

2. 核心功能拆解：硬件能做的那些事

2.1 从老API到新API：Librga库的演进

RGA的用户态接口经历了两次比较大的变革。第一代API是基于rga_info_t结构体的ioctl方式，需要手动设置每个字段，容易出错，代码写起来也很繁琐。从Rockchip发布Librga 1.x后期开始，官方推出了面向对象的第二代API，使用rga_buffer_t描述图像buffer，用im_rect描述图像区域，配合imconfig和improcess两个核心函数完成操作。

第二代API的核心设计理念是"区域处理"。你可以把一张图像的不同区域分别配置成不同的操作对象，甚至把多个buffer组合到一次调用中。这在业务层面更贴近实际需求，比如视频墙的场景里，需要在同一帧画面上叠加多个不同位置的OSD图层，用老API你要调用多次ioctl，用新API一次improcess就能完成。

从工程角度，我强烈建议新项目直接使用Librga 2.x版本，也就是新API。不只是代码更清晰，而且新版本修复了大量老驱动中的格式兼容性问题，还优化了性能。获取方式有两种：从Rockchip的Github仓库（rockchip-linux/librga）拉源码编译，或者在SDK的external/librga目录下找到预编译版本。源码编译很简单，标准CMake流程。

2.2 我用得最多的6个功能场景

图像缩放：这是RGA最常用的功能。视频处理链路里，摄像头输出1080p，AI模型输入需要640x640，这个缩放必须高效完成。用RGA一行代码搞定，速度快到可以忽略不计。

格式转换：NV12转RGB888、RGB888转NV12、YUV420转RGBA8888，常见组合RGA全部原生支持。注意YUV到RGB转换涉及色彩空间标准的选择，RGA默认使用BT.601 Limited Range，如果遇到颜色偏淡或偏艳的问题，记得检查色彩空间配置。

旋转与镜像：在竖屏应用、前置摄像头预览、车载影像这类场景非常常用。RGA支持90/180/270度旋转以及水平/垂直镜像，一次调用完成，不像CPU实现需要大量内存搬运。

裁剪：从大分辨率图像中截取指定区域，然后可以选择性缩放输出。这个功能在做图像ROI检测时非常有用，比如只把画面中的车牌区域裁出来送OCR识别。

图像叠加与透明度混合：将前景图像叠加到背景图像上，支持alpha通道混合。UI层和视频层合成、OSD信息叠加、水印添加都是用这个功能。RGA的alpha混合效率非常高，实时视频上叠加复杂的半透明UI也不会卡顿。

纯色填充与颜色填充：把目标buffer填成指定颜色，常用于清屏操作。看起来简单，但用CPU填充一块4K的RGBA buffer也要消耗不少cycle，RGA瞬间完成。

2.3 必须吃透的数据结构：rga_buffer_t与im_rect

新API里最核心的数据结构是rga_buffer_t和im_rect。我用自己的理解把它们简化一下：

rga_buffer_t描述的是一个"完整图像buffer"，包含宽高、格式、内存地址、stride（步长）等信息。它描述的是"我有一块多大的图像，数据放在哪里"。与之配套的内存信息存放在rga_buffer_t内部关联的描述符中，通过wrapbuffer_*系列函数来创建和填充。

im_rect描述的是一个"区域"。它有x、y、width、height四个字段，本质上是相对于buffer原点的一个矩形范围。RGA操作的粒度是可以精确到像素区域的，这个设计非常实用。比如你要处理一张大图上的一小块区域，直接用im_rect圈定就行，RGA只会处理这块区域，速度更快。

代码里典型的创建方式：

rga_buffer_t src = wrapbuffer_virtualaddr(src_ptr, src_width, src_height, src_format); rga_buffer_t dst = wrapbuffer_virtualaddr(dst_ptr, dst_width, dst_height, dst_format); im_rect src_rect = {0, 0, src_width, src_height}; im_rect dst_rect = {0, 0, dst_width, dst_height};

注意wrapbuffer_virtualaddr用于虚拟地址，wrapbuffer_physicaladdr用于物理地址。如果你的buffer来自dma-buf、ION或DMA heap，用wrapbuffer_fd函数传入文件描述符，这能实现真正的零拷贝流程。这块我在后面性能优化部分会详细展开。

2.4 格式选择与内存对齐：新手最容易翻车的区域

RGA对内存对齐有严格的要求。老版本要求宽高和stride必须是16或64的整数倍，新版本通过参数配置可以放宽，但强烈建议遵守对齐规范，违背对齐要求轻则性能下降，重则出现花屏甚至驱动报错。

实际项目中最稳妥的做法是：宽、高、stride都向16对齐。比如你的图像宽度是100像素，RGB888每个像素3字节，那stride就建议设置为128（100*3=300，向16字节对齐是304？不对，300向上取16的倍数等于304，但还要考虑宽度对齐，RGB888的每行字节数需要对齐到16字节，所以300 -> 304，但304不是64的倍数，如果你想要64对齐，可以取320）。在RK3588上32字节对齐基本就能正常工作，16字节对齐在某些场景会警告，64字节对齐是性能最佳的选择。

一个简单规则：分配buffer时，每个维度都搞成16的倍数，stride显式设置，不要依赖驱动自动推导。我踩过最疼的坑就是NV12图像宽度是奇数，导致Y平面正常但UV平面错位，花屏难排查到怀疑人生。后来统一在源头上把宽度对齐到16，这种问题再也没有出现过。

3. 工程实战：从零跑通一个RGA任务

3.1 环境准备与Librga编译

开发环境我以RK3588平台配Ubuntu系统、官方SDK为例。首先确认你的内核RGA驱动是否存在：

ls /dev/rga

如果能看到设备节点，说明驱动OK。然后处理用户态库，从Github仓库拉取源码：

git clone https://github.com/rockchip-linux/librga.git cd librga mkdir build && cd build cmake .. make -j8 sudo make install

安装完成后头文件在/usr/include/rga目录下，主要包含RgaApi.h、rga.h、drm.h这些文件。链接时用-lrga即可。

编译完毕先用官方自带的demo验证一下环境是否正常。在源码的samples目录下有rgaImDemo的示例程序，直接可以调用。如果demo能正常运行并输出正确的图像文件，说明RGA通路已经打通。

一个细节：确认Librga库的版本号。在代码里可以打印版本信息：

int version = rga_get_version(); printf("RGA version: 0x%x\n", version);

不同版本对格式的支持和性能表现差异不小，我建议使用至少2.2.0以上的版本。

3.2 完整的缩放与格式转换示例

下面给出一段完整的、可以直接跑通的C代码。功能是读取一张NV12格式的1080p图像，通过RGA缩放到720p并转换成RGB888格式输出，然后保存为文件。为了简化说明，代码省略了文件读取细节，直接假设有NV12的buffer：

#include <stdio.h> #include <stdlib.h> #include <string.h> #include <rga/RgaApi.h> #define SRC_W 1920 #define SRC_H 1080 #define DST_W 1280 #define DST_H 720 int main(int argc, char **argv) { // 1. 检查RGA版本 int version = rga_get_version(); printf("RGA version: 0x%x\n", version); // 2. 分配源buffer和目标buffer（示例用虚拟地址） size_t src_size = SRC_W * SRC_H * 3 / 2; // NV12大小 size_t dst_size = DST_W * DST_H * 3; // RGB888大小 unsigned char *src_buf = (unsigned char *)malloc(src_size); unsigned char *dst_buf = (unsigned char *)malloc(dst_size); if (!src_buf || !dst_buf) { printf("malloc failed\n"); return -1; } // 3. 填充源数据（这里应该读取你的NV12图像文件） // ... 读取NV12文件到src_buf // 4. 用新API包装源和目标buffer rga_buffer_t src_handle = wrapbuffer_virtualaddr(src_buf, SRC_W, SRC_H, RK_FORMAT_YCbCr_420_SP); rga_buffer_t dst_handle = wrapbuffer_virtualaddr(dst_buf, DST_W, DST_H, RK_FORMAT_RGB_888); if (src_handle.handle <= 0 || dst_handle.handle <= 0) { printf("wrapbuffer failed\n"); return -1; } // 5. 设置处理区域：整图处理，不需要裁剪 im_rect src_rect = {0, 0, SRC_W, SRC_H}; im_rect dst_rect = {0, 0, DST_W, DST_H}; // 6. 配置并执行操作 imconfig config; config.color = {0, 0, 0, 0}; // 背景色，不影响本场景 int ret = improcess(src_handle, dst_handle, src_rect, dst_rect, NULL, NULL, &config, 0); if (ret != IM_STATUS_SUCCESS) { printf("RGA improcess failed: %d\n", ret); free(src_buf); free(dst_buf); return -1; } // 7. 保存目标文件（以RGB888方式写入文件即可） FILE *fp = fopen("output.rgb", "wb"); if (fp) { fwrite(dst_buf, 1, dst_size, fp); fclose(fp); } printf("RGA process done.\n"); free(src_buf); free(dst_buf); return 0; }

这段代码逻辑不复杂，核心就三步：wrapbuffer创建buffer描述，im_rect设置区域，improcess执行。很多人在第二步容易犯迷糊：src_rect和dst_rect的宽度比不一致时，RGA会自动做缩放吗？答案是会的。src_rect是1920x1080，dst_rect是1280x720，RGA自动完成缩放，不需要额外设置缩放比例参数。

需要注意improcess的第八个参数是usage，通常传0即可。但如果你要做旋转、镜像、透明度混合等更复杂的操作，就需要通过imconfig结构体配置，或者使用imrotate、imflip这些封装好的快捷函数。以90度旋转为例：

rga_buffer_t rotated = imrotate(src_handle, IM_HAL_TRANSFORM_ROT_90); ret = improcess(rotated, dst_handle, src_rect, dst_rect, NULL, NULL, NULL, 0);

imrotate不产生实际数据拷贝，只是生成一个"旋转后的描述符"，真正旋转发生在improcess执行时，这个设计很巧妙，性能上几乎没有额外开销。

3.3 与OpenCV和MPP的配合使用

工程实战里很少单独使用RGA，更多是跟其他模块配合。我项目里最常用的两个组合：RGA + OpenCV和RGA + MPP。

RGA + OpenCV：OpenCV在ARM平台上的性能问题一直被诟病，尤其是resize和cvtColor这两个函数，耗时高得离谱。在RK3588上，完全可以只把RGA当作一个高性能的预处理引擎，OpenCV负责后续的算法逻辑。关键是消除内存拷贝，让RGA直接处理OpenCV Mat的数据：

cv::Mat src_mat = cv::imread("test.jpg"); // BGR888格式 // 注意OpenCV的Mat数据不能直接传给RGA，因为可能有行对齐问题， // 正确的做法是先获取Mat的ptr和数据长度，用wrapbuffer_virtualaddr包装， // 并把format指定为对应的格式。 rga_buffer_t src_rga = wrapbuffer_virtualaddr(src_mat.data, src_mat.cols, src_mat.rows, RK_FORMAT_BGR_888); cv::Mat dst_mat(cv::Size(1280, 720), CV_8UC3); rga_buffer_t dst_rga = wrapbuffer_virtualaddr(dst_mat.data, dst_mat.cols, dst_mat.rows, RK_FORMAT_BGR_888);

这样RGA处理完成后，数据已经直接落在OpenCV的Mat里，零额外拷贝，后续接cv::Mat的图像处理算法完全无缝。这种方式下视频倍速播放、摄像头预览等场景性能提升立竿见影。

RGA + MPP：MPP是Rockchip的视频编解码库，解码出来的帧通常是NV12格式的YUV数据，存储在专用内存（dma-buf）中。传统做法是先memcpy到用户空间，再做像素格式转换。更好的做法是用wrapbuffer_fd直接拿MPP解码帧的fd，在RGA内部完成格式转换和缩放。

// mpp_frame_get_fd获取解码帧的fd int fd = mpp_frame_get_fd(frame); rga_buffer_t src_rga = wrapbuffer_fd(fd, width, height, RK_FORMAT_YCbCr_420_SP, width, height, 0);

使用wrapbuffer_fd时，RGA驱动会直接操作那个已分配的物理连续内存（或dma-buf），省去了CPU参与的memcpy环节。这就是真正意义上的零拷贝流水线：MPP解码输出直接进RGA，RGA输出直接给显示或AI模块，全程CPU只管配置参数，像素数据不经过CPU。

这里有一个前提条件：确保MPP解码帧的内存是dma-buf且RGA支持输入该内存类型。在RK3588平台实测是没有问题的，其他平台需要检查SDK的配置。

3.4 多路视频场景下的RGA使用策略

多路视频处理是RGA最典型的应用场景之一。我做过一个八路D1分辨率（704x576）视频墙项目，每路视频解出来之后要缩放到不同位置，同时叠加中文标题。如果一路一路单独调用RGA，虽然每路都很快，但多次调用之间有驱动切换开销。

更优的做法是：充分利用RGA的region叠加功能。在一次improcess调用中传入多个src buffer和多个dst rect，让RGA把多路视频画面分别缩放到一个大背景帧的不同区域。这种批量处理模式能显著降低系统调用次数和驱动开销。

具体实现上，新API支持improcess批处理模式，需要构造rga_buffer_t数组和对应的im_rect数组。驱动内部会自动按顺序执行每个region的处理，看起来就像GPU提交了一个大的draw call一样。实测在RK3588上，8路D1缩放叠加到1080p大帧，总耗时从逐路调用的12毫秒降到5毫秒，效果显著。

4. 性能优化指南：把RGA榨干

4.1 零拷贝：从虚拟地址到dma-buf

RGA性能优化第一原则：尽量让像素数据不经过CPU。原始方式是用wrapbuffer_virtualaddr传用户空间虚拟地址，驱动内部会通过MMU把虚拟地址映射到物理地址，然后DMA读取。这个过程本身没有问题，但有个性能隐患：RGA访问内存时会发生cache一致性问题，驱动可能需要做cache flush操作，这在频繁处理大图像时开销很明显。

解决方式是使用dma-buf。如果你的输入输出buffer来自DMA-BUF Heap、ION、或某个具有dma-buf导出能力模块（比如MPP解码帧），直接用wrapbuffer_fd传给RGA。RGA驱动会走专门的硬件路径，DMA直接访问buffer，绕过不必要的cache操作，性能提升稳定在15%-30%之间。

分配一个dma-buf的标准做法：

#include <linux/dma-heap.h> #include <sys/ioctl.h> int heap_fd = open("/dev/dma_heap/system", O_RDWR); struct dma_heap_allocation_data data; memset(&data, 0, sizeof(data)); data.len = buffer_size; data.fd_flags = O_RDWR | O_CLOEXEC; ioctl(heap_fd, DMA_HEAP_IOCTL_ALLOC, &data); int dma_fd = data.fd;

拿到dma_fd之后，RGA就可以用wrapbuffer_fd(dma_fd, ...)来使用它。如果你需要CPU也能访问这块buffer做数据填充或结果读取，可以用mmap将其映射到用户空间。这套组合拳打下来，性能基本到达板卡上限。

4.2 多线程并发与RGA实例管理

Librga默认是线程安全的，内部有互斥锁保护驱动调用。但要注意：默认情况下所有线程共享同一个RGA设备，驱动内部的调度可能会让并发请求排队处理，如果你的多线程业务依赖并行处理来提效，需要仔细测试实际并发效果。

实测RK3588上，两个线程同时提交不同尺寸的RGA任务，总耗时并不总是等于单线程的一半。这是因为RGA硬件引擎本身是共享的，大任务会占用较长时间，小任务会被排到后面。优化的做法是用批处理模式将多个小任务合成一个请求提交，而不是让线程各自抢占RGA。

如果多线程场景下遇到明显的性能回退，尝试调整线程优先级，把RGA调用线程设置为高优先级SCHED_FIFO，减少调度延迟。受限于驱动实现，这个方式不要指望带来质变，但小幅度提升是能感知到的。

4.3 避开性能陷阱：常见低效写法

很多性能问题不是RGA本身慢，而是调用方的用法不对。几个典型场景：

• 频繁分配和释放buffer：每帧都malloc/free，还要经过mmap，内存分配本身就有开销。正确做法是buffer池化，预分配一个或多个buffer循环使用，必要时做双缓冲保证RGA写当前帧的同时CPU准备下一帧。
• 不必要的格式中间转换：比如你把NV12转成RGB888存到OpenCV Mat，然后OpenCV又转回YUV送编码器，这中间白白多了一次RGA调用和一次内存写入。直接查一下编码器支持什么输入格式，如果支持NV12，就让RGA直接从NV12到NV12只做缩放，省掉格式转换的步骤。
• 在低分辨率buffer上过度对齐：分配一个128x128的RGBA buffer，不需要stride对齐到4096。stride过大意味着DMA读的字节多，带宽浪费在空洞上。
• 在性能关键路径上使用虚拟地址：凡是帧率高、数据量大的场景，优先用dma-fd。虚拟地址RGA也可以工作，但始终有额外的映射和同步开销。

4.4 缓存一致性机制与注意事项

RGA缓存一致性是一个老话题。在带MMU的新芯片上，驱动一般会自动处理cache同步，但如果你同时让CPU写数据、RGA读数据、又让CPU读结果，就必须注意同步时序。

一个典型场景：你从摄像头拿到一帧NV12数据放在dma-buf里，CPU写入了这一帧，然后要交给RGA缩放。这时候如果不做cache清理，RGA读到的可能是CPU cache里还没写回内存的旧数据。反之，RGA写完结果后CPU也要读，如果cache里有旧的脏数据，CPU可能读到错误内容。

Librga在新版本中通常会在执行前自动处理这个同步操作，但为了保险起见，尤其在高帧率场景下，建议显式调用：

// 在CPU写入数据后、调用RGA前，同步内存 msync(dma_buf_mmap_ptr, buffer_size, MS_SYNC); // 或者对于虚拟地址buffer，使用标准cache操作接口

如果发现图像偶尔出现"掉数据"或者"有一两帧花屏但下一帧又好了"的诡异现象，第一反应就检查cache同步。这种问题在低版本Librga里尤为常见，升级到2.2.0以上会有明显改善。

5. 高频问题排查与调试技巧

5.1 一张问题速查表

我在多个项目里积累的RGA常见问题排查表，先上表格再逐个细说：

5.2 花屏问题的深度复盘

花屏是我见过最多的RGA问题，尤其是NV12格式下。NV12的内存布局是：先是一个完整的Y平面，大小是widthheight，然后是UV交错平面，大小是widthheight/2，U和V各占一半且交错排列。很多人在手动构造NV12 buffer或从MPP解码帧复制数据时，UV平面的偏移算错了。

正确计算方式是：UV偏移 = stride_y * height，这里的stride_y是Y平面的行字节数，不一定是width。如果width是1920，stride对齐到64，那stride_y = 1920，UV偏移就是19201080。但如果width是1000，stride对齐到1024，UV偏移就变成1024height，不是1000*height。只要偏移算错，UV平面错位，画面就会出现典型的绿色或紫红色花屏。

排查方法很简单：打印NV12数据Y平面的最后几行和UV平面的开头几行，如果UV平面的起始数据看起来和Y平面结尾数据内容反差不大，说明偏移算错了。另外推荐使用RGA自带的imcheck函数做参数复查：

IM_STATUS status = imcheck(src_handle, dst_handle, src_rect, dst_rect); if (status != IM_STATUS_SUCCESS) { printf("imcheck failed: %s\n", im_status_string(status)); }

imcheck会在真正执行前检查所有参数是否合法，对于定位问题非常有帮助，新手完全应该把这一步作为标准流程的一部分。

5.3 旋转场景的宽高陷阱

RGA旋转90度或270度后，图像的宽高会互换。比如你有一张1920x1080的图像，旋转90度后变成1080x1920。大部分人在配置dst_rect的时候忘了这个，导致输出的目标区域尺寸不对，RGA可能裁剪或报错。

正确的做法是：在旋转场景中，根据旋转角度动态计算目标宽高：

int dst_w = (rotate == 90 || rotate == 270) ? src_h : src_w; int dst_h = (rotate == 90 || rotate == 270) ? src_w : src_h;

另外还要注意，在im_rect里设置的dst_rect宽度和高度都必须是正数，宽高为负表示镜像翻转，这是新API的一个冷门用法，但也是镜像操作的底层实现方式。如果你要用im_rect做镜像而不是用imflip，就要把宽度设为负值，此时图像会沿Y轴翻转。这个用法容易踩坑，不太推荐新手直接操作，用封装的imflip更安全。

5.4 格式支持矩阵：提前确认比事后调试更高效

RGA对不同格式的支持程度并不均等，有的格式是"完美支持"，有的格式是"支持但有性能惩罚"，还有的格式在特定芯片上根本不支持。最权威的信息来源是RGA文档里的RGA_SPEC_FORMAT枚举，实际上就是代码里的rga.h头文件。建议在做方案设计时就把格式支持矩阵查好，而不是等代码写完再碰运气。

以RK3588为例，我最常用的几个格式支持情况大致如下：

• NV12/NV21：完美支持，RK平台视频领域的"普通话"
• RGB888/BGR888：完美支持，和OpenCV配合时常用
• RGBA8888/BGRA8888：完美支持，UI叠加场景必备
• RGB565：支持，但某些缩放场景下质量一般
• YUV422（YUYV/UYVY等）：支持度视版本而定，建议实测确认
• 10bit YUV（P010等）：新版本才支持，老版本会报错

上面这些信息供参考，实际以你的Librga版本和芯片型号为准。我习惯的做法是写一个小工具，把所有常见格式组合跑一遍，验证可用性后固化到项目的静态配置表中。这样后期集成新的功能时，不需要反复踩"这个格式能不能用"的坑。

6. 工程实践中的几个重要认知

做RGA开发几年下来，我最大的体会是：RGA真正难的地方不在API，而在于对整个数据流的理解。你需要清楚每一帧数据从哪里来（摄像头、解码器、网络）、到哪里去（显示、编码器、AI推理），在哪个环节需要什么格式、什么分辨率、什么颜色空间，然后在最合适的位置插入RGA操作。

新人在RGA上浪费的时间，绝大部分不是在写RGA代码本身，而是花在内存分配方式、格式对齐、数据同步这些"外围细节"上。这些坑踩过一次之后，要养成三个习惯：

第一，所有buffer的宽高stride强制对齐到16或64。即使RGA驱动允许非对齐，对齐后的稳定性和性能会好很多。在业务逻辑层就把这个规则固化下来，让上下游的buffer分配都遵守同一套对齐标准。

第二，在集成RGA到复杂流水线之前，先做最小验证。为每个RGA操作设计一个独立的小测试，确认这个操作单独执行没问题，再把它接入整体流程。我在项目里会用独立的命令行小工具，专门接收一张本地图片，测试各种RGA转换参数。这样调试问题时，可以快速用工具复现，不用每次重新编译整个应用程序。

第三，尽量把多个RGA操作合并成一次调用。improcess的批处理能力很多开发者没用起来，导致每帧都要做多次系统调用。我实测一次批处理调用比多次单次调用总耗时减少一半以上，尤其在多路视频的场景下效果明显。

最后再分享一个小技巧：如果你在开发过程中遇到RGA的行为和文档描述不一致的情况，优先查阅当前SDK版本的librga源码中的注释和驱动代码，因为这些代码往往比外网文档更新更及时。Rockchip平台的东西，源代码永远是最权威的说明书。我在好几个疑难问题的排查中，都是通过阅读rga_drv.c驱动代码里的注释找到答案的。