RK3588 MPP硬解码实战：从FFmpeg拉流到QT显示的踩坑与优化记录

RK3588 MPP硬解码实战：从FFmpeg拉流到QT显示的踩坑与优化记录

第一次在ArmSoM-W3开发板上尝试四路RTSP流硬解码时，屏幕上的画面让我愣住了——四路视频中有两路出现绿色条纹，另外两路则直接黑屏。这场景让我想起刚入行时前辈的忠告："嵌入式多媒体开发，90%的时间都在和内存与线程打交道。"果然，从FFmpeg拉流到QT最终显示的完整链路中，每个环节都藏着意想不到的陷阱。

1. FFmpeg与MPP的接口对接：数据喂食的艺术

在demo项目里跑通单路解码并不难，但当四路1080P流同时涌入时，系统很快就因为内存泄漏崩溃。经过反复测试，发现关键在于AVPacket到MppPacket的转换策略：

// 典型错误示例：直接复用AVPacket内存 ret = mpp_packet_init(&packet, av_packet->data, av_packet->size);

这种写法会导致MPP释放内存时与FFmpeg的内存管理冲突。正确的做法应该是：

// 创建独立内存空间 uint8_t *buffer = (uint8_t *)malloc(av_packet->size); memcpy(buffer, av_packet->data, av_packet->size); mpp_packet_init(&packet, buffer, av_packet->size); mpp_packet_set_pts(packet, av_packet->pts);

关键发现：

• 每路流需要维护独立的MppContext实例
• PTS时间戳必须正确传递，否则会导致音画不同步
• 建议设置10帧的缓冲队列避免卡顿

2. 多路解码的线程架构设计

最初采用简单的"一码流一线程"方案，结果RK3588的六个核心很快就被调度开销拖垮。通过perf工具分析发现，线程切换开销占用了30%的CPU资源。

优化后的线程模型：

核心代码结构：

class DecoderPool { public: void addTask(AVPacket* pkt) { std::lock_guard<std::mutex> lock(queue_mutex_); packet_queue_.push(pkt); cond_.notify_one(); } private: void workerThread() { while(running_) { AVPacket* pkt = getNextPacket(); // 解码处理逻辑 mpi_->decode_put_packet(ctx_, packet); } } };

3. YUV到RGB的色彩空间转换陷阱

当第一路视频出现色偏时，我以为是RGA配置错误。但检查所有参数后发现问题更隐蔽——RK3588的RGA对某些YUV420sp格式的支持存在硬件限制。

解决方案矩阵：

关键配置参数：

# RGA转换核心参数 rga_info.src_format = RK_FORMAT_YCbCr_420_SP; rga_info.dst_format = RK_FORMAT_RGB_888; rga_info.rotation = 0; rga_info.virWidth = ALIGN(width, 16);

4. QT显示性能优化实战

在四路1080P@30fps的场景下，直接用QLabel显示会导致CPU占用飙升到70%。通过QOpenGLWidget重构渲染逻辑后，性能提升显著：

优化前后对比：

1. 原始方案：

   • QLabel + QPixmap
   • 每帧都需要内存拷贝
   • 主线程阻塞严重

2. 优化方案：

   • 自定义QOpenGLWidget
   • 零拷贝纹理上传
   • 异步渲染队列

核心渲染逻辑：

void VideoWidget::paintGL() { glClear(GL_COLOR_BUFFER_BIT); glActiveTexture(GL_TEXTURE0); glBindTexture(GL_TEXTURE_2D, texture_id_); // 使用VBO渲染四边形 glDrawArrays(GL_TRIANGLE_STRIP, 0, 4); }

重要提示：在RK3588上必须启用EGLFS平台插件，X11的环境下无法发挥GPU加速性能

5. 内存泄漏排查实战记录

项目最棘手的bug是运行8小时后出现OOM崩溃。通过valgrind结合自定义内存追踪，最终定位到三个关键泄漏点：

1. FFmpeg未释放的解复用器上下文：

   // 必须显式释放 avformat_close_input(&format_ctx);

2. MPP帧引用计数问题：

   // 每获取一帧必须释放 mpp_frame_decref(frame);

3. QT图像缓存未清理：

   // 纹理资源需要手动删除 glDeleteTextures(1, &texture_id_);

开发过程中总结的检查清单：

• 所有av_开头的分配必须有对应的free
• MppFrame必须检查eos标志
• OpenGL资源需在析构函数中释放

6. 性能调优的终极方案

当所有基础功能稳定后，我们通过以下手段将四路解码的延迟从120ms降低到42ms：

硬件加速全开：

# 启用NEON指令集 -march=armv8-a+simd # 内核参数调整 echo performance > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor

关键参数优化表：

最终在ArmSoM-W3上实现的性能指标：

• 四路1080P@30fps稳定解码
• 端到端延迟<50ms
• CPU总占用率<60%
• 连续运行72小时无内存泄漏