FFmpeg avcodec_send_packet高内存占用及高分辨率帧损坏问题

原因分析 #

• FFmpeg软解码器初始化阶段会为对应分辨率的帧分配缓冲区，4K YUV420p单帧内存约12MB，但内存峰值高主要源于：
  • 解码器未开启引用计数帧，首帧处理时缓存大量未释放的AVFrame/AVPacket；
  • Java与Native层内存交互未优化，比如DirectByteBuffer未及时回收、重复分配内存；
  • 解码器线程数设置过高，每个线程都会分配独立缓冲区；
  • 首帧处理时解码器需初始化内部状态，会临时分配额外内存，后续复用缓冲区后内存趋于稳定。

解决步骤 #

• 开启引用计数帧：解码器上下文初始化时设置codec_ctx->refcounted_frames = 1，解码后的帧处理完成后必须调用av_frame_unref(frame)，AVPacket使用后调用av_packet_unref(pkt)，确保内存及时释放；
• 优化解码器线程数：设置codec_ctx->thread_count = av_cpu_count() / 2（避免线程过多占用内存），同时设置codec_ctx->thread_type = FF_THREAD_FRAME；
• 排查Java层内存：用DirectByteBuffer存储YUV数据时，使用完后通过sun.misc.Cleaner主动回收，避免重复分配新的ByteBuffer；
• 监控Native内存：用JDK的jcmd <pid> VM.native_memory detail或VisualVM排查是否存在内存泄漏，首帧后内存稳定无持续增长即可排除泄漏问题。

原因分析 #

• 使用av_find_best_stream或指定"vp9"解码器时，可能自动选择了软解码器或不支持高分辨率的硬件解码器；
• 硬解码未正确绑定硬件设备上下文，导致解码器无法正常处理高分辨率帧；
• 帧数据处理时忽略AVFrame->linesize（步长），直接用分辨率计算内存偏移，导致YUV分量错位；
• FFmpeg默认的max_pixels限制了高分辨率帧的解码，超过阈值会导致帧截断或损坏。

解决步骤 #

硬解码场景优化 #

• 优先绑定硬件解码器：调用av_find_best_stream获取流信息后，手动筛选硬件解码器（比如前缀带_cuvid的VP9解码器），或初始化时强制创建CUDA设备上下文并绑定到解码器：

  // Native层示例代码
  AVBufferRef* hw_ctx = NULL;
  int ret = av_hwdevice_ctx_create(&hw_ctx, AV_HWDEVICE_TYPE_CUDA, NULL, NULL, 0);
  if (ret >= 0) {
      codec_ctx->hw_device_ctx = av_buffer_ref(hw_ctx);
      av_buffer_unref(&hw_ctx);
  }
  

• 显式指定硬件解码器：若av_find_best_stream未选中合适硬解码器，可手动调用avcodec_find_decoder_by_name("vp9_cuvid")，并确保解码器参数正确初始化；

帧处理与参数配置 #

• 正确处理YUV帧的步长：渲染时必须使用frame->linesize计算各分量的内存偏移，比如Y分量的每行字节数是frame->linesize[0]，而非直接用width；
• 解除像素数限制：初始化解码器时设置codec_ctx->max_pixels = 8192 * 4320（支持8K级别，可按需调整），避免解码器因像素数上限丢弃帧数据；
• 软解码验证：若使用软解码器，开启codec_ctx->flags2 |= AV_CODEC_FLAG2_FAST优化，同时升级FFmpeg到最新稳定版，确保VP9解码器支持对应高分辨率；

渲染排查 #

• 确认渲染组件尺寸与解码帧实际分辨率完全匹配，避免拉伸或裁剪导致视觉损坏；
• 硬解码输出的帧可能是硬件格式（如CUDA），需先调用av_hwframe_transfer_data将硬件帧拷贝到内存帧，转换为YUV420p后再渲染。

内容的提问来源于stack exchange，提问作者iexav