一、前言
本文是基于RK3588的YOLO多线程推理多级硬件加速引擎框架设计项目的延申与拓展，单独分析所提出的方案4的性能和加速原理，即同时开启 RKmpp 硬件视频解码和 RGA 硬件图像缩放、旋转。
二、实验结果回顾
在项目的总览篇中，给出了该方案的推理效果，这里重新贴上：
这个组合方式本应该是最快的方案，但是同时开启硬件解码和 RGA 加速，帧率就下降：
使用 15 个推理线程（继续增加没有明显变化），帧数稳定在 139 帧左右，反倒是等于没有使用硬件加速，与纯 OpenCV 实现的方案结果相近。
不过好消息是，相比于第一个方案，CPU 和 NPU 的占用率都有下降，CPU 占用率下降了约 21 个百分点，NPU 下降约 8 个百分点，这说明方案4的上限还没到，还有优化的空间。下面是 RGA 的使用情况，使用率与之前保持相同：
三、代码逻辑分析
1、加载器
方案4的视频加载器是 FFmpeg，并且已经提前编译好源码，支持 RKmpp 解码器，只需要在初始化时选择 h264_rkmpp 即可，其他流程就是普通的 FFmpeg C++接口配置方法，具体详见下面的文章：
2、取出图像
主函数的 for 循环每次取出一帧，然后传递给线程池，由于实操过程发现前几帧总是非正常图像，于是做了一个跳过处理：
/* 跳过不需要的帧 */
if (!video_reader_ptr->readFrame(img)) {// 如果已经成功开始处理图像，则代表已处理完所有图像或读取错误if (fps != 0)break;elsecontinue;}// 放入 rknn 线程池
if (!img.empty())if (yolo_pool.put(img) != 0)break;video_reader_ptr 是 FFmpeg 和 OpenCV 的多态指针，在执行程序时根据命令行参数选择具体的实例化类，在方案 4 中，使用的是 FFmpeg，调用 RKmpp。下面是 FFmpeg 类的 readFrame 函数：
/*** @Description: 读取一帧* @param {Mat&} frame: 取出的帧* @return {*}*/
bool FFmpegReader::readFrame(cv::Mat& frame) {// 读取帧/*if (av_read_frame(formatContext, packet) < 0) {return false; // 没有更多帧}*/while (av_read_frame(formatContext, packet) >= 0) {if (packet->stream_index != videoStreamIndex) {av_packet_unref(packet);continue;}break;}// 如果是视频流if (packet->stream_index != videoStreamIndex) {cerr << "Not a video stream: " << packet->stream_index << " != " << videoStreamIndex << endl;av_packet_unref(packet);return false; // 不是视频流}// 发送数据包到解码器if (avcodec_send_packet(codecContext, packet) < 0) {std::cerr << "Failed to send packet to decoder" << std::endl;av_packet_unref(packet);return false; // 发送数据包失败}// 接收解码后的帧if (avcodec_receive_frame(codecContext, tempFrame) < 0) {std::cerr << "Failed to receive frame from decoder" << std::endl;av_packet_unref(packet);return false;}// 成功读取一帧，保存在 tempFrame 中// 将帧数据转换为 cv::Mat BGR 格式if (this->NV12_to_BGR(frame) != 0) {std::cerr << "Failed to convert YUV420SP to BGR" << std::endl;av_packet_unref(packet);return false;}// 释放数据包av_packet_unref(packet);return true; // 处理完成
}这里的 av_read_frame 和上面逻辑一样，目的是跳过部分帧，我实测发现会在视频开始的第一次需要跳过，正常播放后就不会再进入循环。需要关注的是 NV12_to_BGR 函数，它是我用于转换图像格式的接口：
/*** @Description: 转换格式，NV12 转 BGR* 该函数内有三种转换方式：* 1. FFmpeg SwsContext 软件转换 * 2. OpenCV 软件转换，可启用 opencl（目前区别不大）* 3. RGA 硬件加速转换* @param {Mat&} frame: * @return {*}*/
int FFmpegReader::NV12_to_BGR(cv::Mat& bgr_frame) {if (tempFrame->format != AV_PIX_FMT_NV12) {return -EXIT_FAILURE; // 格式错误}// 设置输出帧的尺寸和格式，防止地址无法访问bgr_frame.create(tempFrame->height, tempFrame->width, CV_8UC3);#if 0 // 方式1：使用 FFmpeg SwsContext 软件转换return this->FFmpeg_yuv420sp_to_bgr(bgr_frame);
#endif// 创建一个完整的 NV12 数据块（Y + UV 交错）cv::Mat nv12_mat(tempFrame->height + tempFrame->height / 2, tempFrame->width, CV_8UC1);// 将 AVFrame 内的数据，转换为 OpenCV Mat 格式保存this->AV_Frame_To_CVMat(nv12_mat);// 硬件加速if (this->accels_2d == ACCELS_2D::ACC_OPENCV) {// 方式2：使用 OpenCV 软件转换cv::cvtColor(nv12_mat, bgr_frame, cv::COLOR_YUV2BGR_NV12);return EXIT_SUCCESS;} else if (this->accels_2d == ACCELS_2D::ACC_RGA) {// 方式3：使用 RGA 硬件加速转换return RGA_yuv420sp_to_bgr((uint8_t *)nv12_mat.data, tempFrame->width, tempFrame->height, bgr_frame);}elsereturn -EXIT_FAILURE;
}具体的细节在注释中都有说明，有三种转换方式，分别是
1. FFmpeg SwsContext 软件转换
2. OpenCV 软件转换
3. RGA 硬件加速转换
方案 4 使用 RGA 进行转换。
3、色彩空间转换
取出的原始帧格式为 RK_FORMAT_YCbCr_420_SP（NV12），由于 YOLO 的输入格式需要 RGB888，因此需要使用 RGA 的 imcvtcolor 接口进行一次图像色彩空间的转换，所以针对 NV12 转 RGB888 编写了一个模块，数据的传输依赖 cv::Mat 对象：
/*** @Description: 将 YUV420SP(NV12) 格式的图像转换为 BGR 格式* @param {uint8_t} *frame_yuv_data: 原始 YUV 图像数据（这里为了减少对 AVFrame 的依赖，只传入 data 数据）* @param {Mat} &bgr_image: 转换后的 BGR 图像* @return {*}*/
int RGA_yuv420sp_to_bgr(const uint8_t *frame_yuv_data, const int& width, const int& height, cv::Mat &bgr_image) {rga_buffer_t src_img, dst_img;rga_buffer_handle_t src_handle, dst_handle;int src_width, src_height, src_format;int dst_width, dst_height, dst_format;int src_buf_size, dst_buf_size;memset(&src_img, 0, sizeof(src_img));memset(&dst_img, 0, sizeof(dst_img));/* 输入输出大小 */ src_width = width;src_height = height;dst_width = bgr_image.cols;dst_height = bgr_image.rows;/* 将转换前后的格式 */// 选自 rk 官方 demo 中的格式src_format = RK_FORMAT_YCbCr_420_SP;dst_format = RK_FORMAT_BGR_888;/* 使用图像数据构建 rga_buffer_t 结构体，两个指针指向同一个数据 */src_img = wrapbuffer_virtualaddr((void *)frame_yuv_data, src_width, src_height, src_format);dst_img = wrapbuffer_virtualaddr((void *)bgr_image.data, dst_width, dst_height, dst_format);/* 图像检查 */IM_STATUS STATUS;/*STATUS = imcheck(src_img, dst_img, {}, {});if (IM_STATUS_NOERROR != STATUS) {printf("%d, check error! %s", __LINE__, imStrError(STATUS));return -1;}*//* 将需要转换的格式与rga_buffer_t格式的结构体src、dst⼀同传⼊imcvtcolor() */STATUS = imcvtcolor(src_img, dst_img, src_format, dst_format);/* 释放内存（正确和错误均执行） */if (src_handle)releasebuffer_handle(src_handle);if (dst_handle)releasebuffer_handle(dst_handle);if (IM_STATUS_SUCCESS != STATUS) {fprintf(stderr, "rga resize error! %s", imStrError(STATUS));return -1;}return 0;
}/*** @Description: 将 YUV420SP(NV12) 格式的图像转换为 BGR 格式* @param {uint8_t} *frame_yuv_data: 原始 YUV 图像数据（这里为了减少对 AVFrame 的依赖，只传入 data 数据）* @param {Mat} &bgr_image: 转换后的 BGR 图像* @return {*}*/
int RGA_handle_yuv420sp_to_bgr(const uint8_t *frame_yuv_data, const int& width, const int& height, cv::Mat &bgr_image) {rga_buffer_t src_img, dst_img;rga_buffer_handle_t src_handle, dst_handle;int src_width, src_height, src_format;int dst_width, dst_height, dst_format;int src_buf_size, dst_buf_size;memset(&src_img, 0, sizeof(src_img));memset(&dst_img, 0, sizeof(dst_img));/* 输入输出大小 */ src_width = width;src_height = height;dst_width = bgr_image.cols;dst_height = bgr_image.rows;/* 将转换前后的格式 */// 选自 rk 官方 demo 中的格式src_format = RK_FORMAT_YCbCr_420_SP;dst_format = RK_FORMAT_BGR_888;/* 计算图像所需要的 buffer 大小 */src_buf_size = src_width * src_height * get_bpp_from_format(src_format);dst_buf_size = dst_width * dst_height * get_bpp_from_format(dst_format);/* 将缓冲区对应的物理地址信息映射到RGA驱动内部，并获取缓冲区相应的地址信息 */src_handle = importbuffer_virtualaddr((void *)frame_yuv_data, src_buf_size);dst_handle = importbuffer_virtualaddr(bgr_image.data, dst_buf_size);/* 封装为RGA图像结构 */src_img = wrapbuffer_handle(src_handle, src_width, src_height, src_format);dst_img = wrapbuffer_handle(dst_handle, dst_width, dst_height, dst_format);/* 图像检查 */IM_STATUS STATUS;/*STATUS = imcheck(src_img, dst_img, {}, {});if (IM_STATUS_NOERROR != STATUS) {printf("%d, check error! %s", __LINE__, imStrError(STATUS));return -1;}*//* 将需要转换的格式与rga_buffer_t格式的结构体src、dst⼀同传⼊imcvtcolor() */STATUS = imcvtcolor(src_img, dst_img, src_format, dst_format);/* 释放内存（正确和错误均执行） */if (src_handle)releasebuffer_handle(src_handle);if (dst_handle)releasebuffer_handle(dst_handle);if (IM_STATUS_SUCCESS != STATUS) {fprintf(stderr, "rga resize error! %s", imStrError(STATUS));return -1;}return 0;
}这里我放了两个函数，它们实现的是同一个功能，区别在于是否将数据导入 RGA 驱动内部。函数名带有 handle 代表使用 RGA 驱动内部进行数据处理，另一个函数则是直接操作用户提供的图像数据，详细的分析可以看这篇文章：
瑞芯微RKRGA（librga）Buffer API 分析-CSDN博客
https://blog.csdn.net/plmm__/article/details/146571080?spm=1001.2014.3001.5501 在 YOLO 这样需要高频率取出图像并进行格式转换的场景，我自然选择直接操作原始的图像数据，我在实践后也确实如此，相比之下每帧的处理速度可以提高 2ms 左右（尺寸1024*720）。
4、适配模型输入
另一个使用到 RGA 库的就是模型的推理部分，由于输入 YOLO 模型的图像色彩空间需要 RGB888，而调用 OpenCV 的 imshow() 函数则需要 cv::Mat 的默认格式 BGR888，除非不显示图像检测结果（那就失去了目标检测的灵魂）。
原作者将图像的前处理和后处理都放在了推理函数中，目的就是可以将他们独立到各个线程中，提高多线程执行效率。由于后处理部分主要使用 BGR888 格式，因此推理函数中就需要同时存在这两种格式。本来想在解码时就直接转为 RGB888，但是后处理调试比较费时间，并且考虑到可以随时切换为 OpenCV 进行软件转换，提高代码的复用性，于是在推理线程中保留了格式转换的 RGA 接口：
// YOLO 推理需要 RGB 格式，后处理需要 BGR 格式// 即使前处理时提前转换为 RGB，后处理部分任然需要转换为 BGR，需要在本函数中保留两种格式if (this->config.accels_2d == ACCELS_2D::ACC_OPENCV) {cv::cvtColor(orig_img, rgb_img, cv::COLOR_BGR2RGB);}else if (this->config.accels_2d == ACCELS_2D::ACC_RGA) {if (RGA_bgr_to_rgb(orig_img, rgb_img) != 0) {cout << "RGA_bgr_to_rgb error" << endl;return cv::Mat();}}else {cout << "Unsupported 2D acceleration" << endl;return cv::Mat();}如果输入尺寸不匹配，还会进行 resize 操作：
// 图像缩放if (orig_img.cols != width || orig_img.rows != height){// 如果需要缩放，再对 resized_img 申请大小，节约内存开销resized_img.create(height, width, CV_8UC3);if (this->config.accels_2d == ACCELS_2D::ACC_OPENCV){// 打包模型输入尺寸cv::Size target_size(width, height);float min_scale = std::min(scale_w, scale_h);scale_w = min_scale;scale_h = min_scale;letterbox(rgb_img, resized_img, pads, min_scale, target_size, this->config.opencl);}else if (this->config.accels_2d == ACCELS_2D::ACC_RGA){ret = RGA_resize(rgb_img, resized_img);if (ret != 0) {cout << "resize_rga error" << endl;}}else {cout << "Unsupported 2D acceleration" << endl;return cv::Mat();}inputs[0].buf = resized_img.data;}else{inputs[0].buf = rgb_img.data;}这部分与原作者保持一致，都是来自瑞芯微官方的代码。
四、对比分析
以上大致梳理了方案 4 的整个调用过程，涉及一个硬件视频解码和三个 RGA 加速库的调用。因为单独使用硬件视频解码和 RGA 加速库都可以提高帧率，但是两个一起使用则反而降低了速度，所以问题应该是出在同时开启硬件视频解码和 RGA 加速库才会执行的代码，也就是 RGA_yuv420sp_to_bgr 这个函数，用于将 NV12 的格式转为 BGR888。
我在 NV12_to_BGR 函数中，将 RGA_yuv420sp_to_bgr 替换为 OpenCV 软件转换，其余正常保持硬件加速，发现帧率变得不稳定，从 100 到 160 之间来回跳变，上限确实是突破了目前最高的 150 帧：
不知道是不是 OpenCV 转换后的图像与 RGA 库转换的结果有数据对齐方面的问题，会导致图像数据错误，进而导致丢帧，因为我的 main 函数的逻辑有下面这条：
// 如果取出的图像为空，则跳过
if (img.empty())continue;我不确定是否有直接关系，但是如果执行过这条语句，从我计算 FPS 的原理来讲，确实会导致帧率下降，目前也在一直查找问题。
目前可以确定的是，两种硬件加速的瓶颈就是 RGA 库的 RGA_yuv420sp_to_bgr 转换函数导致的，我准备继续研究 RGA 接口，优化代码。
代码会公布至 Github，如果有小伙伴感兴趣，欢迎一起讨论。