应避免使用 av_hwframe_transfer_data，全程保持帧在 GPU 显存中仅传递句柄；需确保 AVFrame->data[0] 为设备指针、格式匹配渲染输入、显式同步解码与渲染流程，并按平台适配原生 API 实现零拷贝。
av_hwframe_transfer_data 是性能断点，别用它
很多开发者在 FFmpeg 硬解流程里卡在 av_hwframe_transfer_data 这一步：CPU 端申请内存 → GPU 解码输出 → 调用该函数把帧从显存拷回内存 → 再上传纹理。这等于把零拷贝管道硬生生掰成三段，PCIe 往返 + CPU 内存分配 + OpenGL 同步开销全回来了。
正确做法是全程让帧停留在 GPU 显存中，只传递句柄（如 VkImage、ID3D11Texture2D* 或 DRM PRIME fd），由渲染后端直接绑定。关键前提是解码器输出的 AVFrame->data[0] 必须是设备指针，而非主机可读地址。
- 检查
AVFrame->hw_frames_ctx是否非空，且AVFrame->buf[0]->data指向的是 GPU 地址（例如cudaMalloc分配的地址，或 VulkanVkDeviceMemory映射区） - 禁用所有含
transfer、map、download字样的 API 调用路径 - 在 RK3568 上，确保
avcodec_open2前已通过av_hwdevice_ctx_create创建AV_HWDEVICE_TYPE_RKMPP上下文，并设置AVCodecContext->hw_device_ctx
解码输出格式必须匹配渲染输入格式
GPU 解码器输出的像素格式（如 AV_PIX_FMT_DRM_PRIME、AV_PIX_FMT_CUDA、AV_PIX_FMT_VULKAN）不能直接喂给 OpenGL 的 glTexImage2D——后者只认 GL_RGBA、GL_BGRA 这类主机格式。你得让渲染后端知道“这张图在显存哪，怎么解释它的内存布局”。
典型方案：
立即学习“C++免费学习笔记（深入）”；
- Vulkan：用
vkGetImageMemoryRequirements获取解码输出VkImage的内存要求，创建兼容的VkImageView，跳过任何中间VkBuffer中转 - OpenGL（Linux DRM）：通过
drmPrimeFDToHandle把解码器返回的 PRIME fd 转为 local handle，再用glImportSemaphoreFdEXT+glImportSyncFd同步，最后绑定到GL_TEXTURE_EXTERNAL_OES - Windows D3D11：解码器输出
ID3D11Texture2D*可直接作为glTextureView的源，无需CopyResource
如果看到 Invalid enum 或 GL_INVALID_OPERATION，大概率是格式不匹配或同步缺失。
同步机制决定是否真零拷贝
零拷贝不是只要不调 memcpy 就算数——GPU 解码和 GPU 渲染若无显式同步，驱动会自动插入全屏障（full pipeline stall），帧率暴跌且不可预测。
必须显式控制执行顺序：
- Vulkan：在解码完成的
VkFence或VkSemaphore信号后，才提交渲染命令；避免用vkDeviceWaitIdle - OpenGL：用
glFenceSync在解码帧写入后插 fence，渲染前调glClientWaitSync（注意 timeout 设为GL_TIMEOUT_IGNORED会阻塞） - CUDA：用
cudaStreamSynchronize或cudaEventRecord/cudaEventSynchronize对齐解码流与渲染流
漏掉同步，表面看数据“没拷贝”，实则 GPU 在等 CPU 打信号，延迟比软解还高。
不同平台的零拷贝入口点差异极大
没有跨平台统一 API。FFmpeg 的 AVHWDeviceType 只是抽象层，真正打通解码-渲染链路，得靠平台原生扩展：
- RK3568（Linux DRM）：
AV_PIX_FMT_DRM_PRIME+libdrm+GBM+EGL，重点配置AVCodecContext->get_format = custom_get_format返回AV_PIX_FMT_DRM_PRIME - Windows（NVIDIA/AMD）：
AV_PIX_FMT_CUDA或AV_PIX_FMT_D3D11，需链接cuda.h或d3d11.h，并手动调cuGraphicsD3D11RegisterResource注册资源 - macOS Metal：
AV_PIX_FMT_METAL，依赖MTLTextureRef和MTLCommandBuffer，FFmpeg 6.0+ 才初步支持
别指望 avcodec_receive_frame 返回的 AVFrame 能直接塞进 glTexImage2D——那只是幻觉。每个平台都得写一段胶水代码，把硬件解码器的输出句柄，转换成当前图形 API 认得的资源对象。
最常被忽略的一点：解码器创建时传入的 AVBufferRef* 必须和渲染上下文共享同一套内存管理器（比如 Vulkan 的 VkPhysicalDeviceMemoryProperties 中的 memoryTypes 索引要一致），否则即使指针相同，也会因内存域不兼容触发隐式拷贝。
