关键瓶颈在于硬件解码器输出与图形API纹理对象之间缺乏统一的external memory handle共享机制，必须通过VK_KHR_external_memory等扩展显式打通DMA-BUF或句柄传递路径，否则仍会退化为内存拷贝。
零拷贝解码到 GPU 纹理的关键瓶颈在哪
直接答案：C++ 本身不提供零拷贝视频解码管线，真正起作用的是底层 API 协同——libavcodec + Vulkan/OpenGL + 硬件解码器驱动（如 NVDEC、AMF、VideoToolbox）三者对“DMA-BUF”或“external memory handle”的共享支持。你写 C++ 代码只是把它们串起来，不是靠语言特性实现零拷贝。
常见误解是以为调用 avcodec_send_packet 后拿 AVFrame->data[0] 贴到纹理就能零拷贝——实际这是 CPU 可见的 YUV 指针，99% 情况下仍是显存→系统内存的拷贝。真零拷贝必须绕过 AVFrame->data，走硬件解码器输出的 native surface handle。
Vulkan 下用 NVDEC 实现 AVFrame → VkImage 零拷贝
以 NVIDIA GPU 为例，核心路径是：NVDEC 解码输出 VkImage（通过 VK_KHR_external_memory_win32 或 VK_KHR_external_memory_fd），再用 VK_EXT_video_decode_queue + VK_KHR_video_queue 扩展直接绑定解码输出到 Vulkan 图像对象。
- 必须启用
VK_KHR_get_physical_device_properties2和VK_KHR_external_semaphore_capabilities查询硬件是否支持 external memory -
vkGetPhysicalDeviceImageFormatProperties2中传入VkPhysicalDeviceImageFormatInfo2+VkImageFormatListCreateInfo，并设置handleTypes = VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT（Linux）或_WIN32_BIT（Windows） - 创建
VkImage时，VkImageCreateInfo::flags要含VK_IMAGE_CREATE_ALIAS_BIT；VkExportMemoryAllocateInfo必须在分配内存时显式声明可导出 - NVDEC 解码器需用
cuvidCreateVideoSource+cuvidCreateVideoParser初始化，并在CUVIDDECODECREATEINFO中设ulCreationFlags = cudaVideoCreate_PreferGPU，且vidLock回调中调用cuvidMapVideoFrame获取 CUDA device pointer，再用cudaExternalMemory_t导出为 Vulkan 可识别句柄
示例关键片段（省略错误检查）：
立即学习“C++免费学习笔记（深入）”；
VkImportMemoryFdInfoKHR import_info = {};
import_info.handleType = VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT;
import_info.fd = fd_from_cuvid_map; // 从 cuvidMapVideoFrame + cudaImportExternalMemory 得到
vkBindImageMemory(device, vk_image, mem, 0);
OpenGL 路径为什么更难做真正零拷贝
OpenGL 的 GL_TEXTURE_EXTERNAL_OES 看似方便，但它本质是 EGL 层面的 shortcut，依赖厂商对 EGL_EXT_image_dma_buf_import 或 EGL_NV_stream_consumer_gltexture 的实现。桌面端（非 Android）几乎不可靠。
- Intel iHD 驱动仅支持 VAAPI 输出到
DRM PRIME fd，再用glEGLImageTargetTexture2DOES绑定——但要求EGLImage创建时用EGL_LINUX_DMA_BUF_EXT，且 kernel DRM/KMS 必须启用CONFIG_DRM_I915_CAPTURE_ERROR（否则纹理黑屏） - NVIDIA OpenGL 驱动不支持 DMA-BUF 导入，只能走
cuGraphicsEGLRegisterImage+ CUDA interop，此时仍需一次cuMemcpyDtoH拷贝到 PBO，不算严格零拷贝 - macOS 上必须用
VTDecompressionSessionRef+CVMetalTextureCache→Metal→MTLTexture→CVOpenGLESTextureCache，中间至少两次跨 API 同步，且CVOpenGLESTextureCacheCreateTextureFromImage会触发隐式 copy unlesskCVOpenGLESTextureCacheMaximumTextureAgeKey设为 0 并禁用 FBO blit
libavcodec 自带的 hwaccel 接口为何不能直接用于零拷贝渲染
avcodec_open2 设置 AVCodecContext::hw_device_ctx 后，解码输出的 AVFrame->buf[0] 是 AVBufferRef，指向 GPU 内存，但它的 layout 和 lifetime 完全由 FFmpeg 内部管理——你无法保证它和你的 VkImage 或 GLTexture 共享同一块物理页。
-
av_hwframe_transfer_data一定会触发拷贝（CPU 或 GPU memcpy），这不是零拷贝 - 即使
AVFrame->data[0]是CUdeviceptr或VkDeviceMemory，FFmpeg 不暴露其 handle，也没办法直接 bind 到图形 API - 唯一可行的是绕过
avcodec_receive_frame，改用硬件 SDK 原生解码接口（如cuvid、vaBeginPicture、vtDecodeFrame），让解码输出直接落入你控制的图形资源
真正落地时，最易踩的坑是假设 “用了 hardware decode 就等于零拷贝”——其实硬件解码只解决 CPU 解码瓶颈，数据落点仍在驱动私有内存池里；要跨到图形管线，必须显式打通 external memory handoff 流程，且每一步都要查扩展支持、配对 handle type、同步 fence。漏掉任意一环，就会退化成 memcpy + glTexSubImage2D 这类高延迟路径。
