目录一、先给结论Linux 硬加速现状速览二、VA-APILinux 硬解的“事实标准”1️⃣ 检查环境必做2️⃣ 最简单的硬解播放3️⃣ 转码硬解 硬编码三、NVDECNVIDIA 的“暴力美学”1️⃣ 确认驱动2️⃣ 硬解播放3️⃣ 硬解 CUDA 滤镜高级四、VDPAU老系统的“遗产”五、DRM Prime EGLWayland / 无 X11 的终极方案核心概念示例渲染不走 X11六、零拷贝Zero-Copy性能分水岭❌ 错误示范CPU 中转✅ 正确示范全程 GPU七、Docker / 服务器部署必踩的坑✅ 权限✅ 驱动必须进容器八、如何判断“到底有没有用到 GPU”Intel / AMDNVIDIA九、一个现实结论很重要十、总结一句话如果你在 Linux 上用过 FFmpeg 做视频处理大概率有过这种体验CPU 100%风扇起飞GPU 却在旁边“围观”。Linux 上的硬加速一直是碎片化重灾区Intel / AMD / NVIDIA 各玩各的API 一堆VA-API、VDPAU、NVDEC、AMF而且“支持”不等于“能用”更不等于“快”。这篇文章不堆参数只讲实战结论帮你把 FFmpeg 在 Linux 上的硬加速真正用起来。一、先给结论Linux 硬加速现状速览GPU推荐 APIFFmpeg 名称稳定性备注Intel✅ VA-APIh264_vaapi/hevc_vaapi⭐⭐⭐⭐⭐首选AMD✅ VA-APIh264_vaapi/hevc_vaapi⭐⭐⭐⭐新驱动AMD老⚠️ VDPAUh264_vdpau⭐⭐⭐仅 legacyNVIDIA✅ NVDECh264_nvdec/hevc_nvdec⭐⭐⭐⭐⭐闭源驱动NVIDIA开源 nouveau❌不可用—放弃嵌入式 / RK / Qcom✅ DRMh264_v4l2m2m⭐⭐⭐SoC 专用一句话选型Intel / 新 AMD →VA-APINVIDIA →NVDEC嵌入式 →v4l2m2m / DRM二、VA-APILinux 硬解的“事实标准”1️⃣ 检查环境必做vainfo看到类似输出才算“真可用”VA-API version: 1.20 Driver name: iHD / radeonsi Supported profile: VAProfileH264Main Supported profile: VAProfileHEVCMain❌ 如果只有VAProfileNone→ 驱动没装好2️⃣ 最简单的硬解播放ffplay -hwaccel vaapi \ -hwaccel_device /dev/dri/renderD128 \ input.mp4/dev/dri/renderD128是无特权渲染节点服务器 / Docker 必用。3️⃣ 转码硬解 硬编码ffmpeg -hwaccel vaapi \ -hwaccel_device /dev/dri/renderD128 \ -i input.mp4 \ -vf formatnv12,hwupload \ -c:v h264_vaapi \ output.mp4⚠️ 注意-vf formatnv12,hwupload不能少VA-API 默认工作在GPU 显存三、NVDECNVIDIA 的“暴力美学”1️⃣ 确认驱动nvidia-smiFFmpeg 编译时必须包含--enable-nonfree --enable-cuda-nvcc2️⃣ 硬解播放ffplay -hwaccel nvdec input.mp4 NVDEC自动选 GPU不需要手动指定 device。3️⃣ 硬解 CUDA 滤镜高级ffmpeg -hwaccel nvdec \ -hwaccel_output_format cuda \ -i input.mp4 \ -vf scale_npp1280:720 \ -c:v h264_nvenc \ output.mp4✅零拷贝✅ 滤镜直接在 GPU 跑四、VDPAU老系统的“遗产”AMD 老显卡 / 老驱动还能用ffmpeg -hwaccel vdpau -i input.mp4 ...❌ 不支持 HEVC❌ 新系统不建议再用除非你在维护 legacy 系统否则直接忽略。五、DRM Prime EGLWayland / 无 X11 的终极方案这是现代 Linux 桌面GNOME / KDE Wayland 的正确姿势。核心概念hwaccel vaapihwmapderive_devicedr直接把解码 surface 映射到 DRM 帧缓冲示例渲染不走 X11ffmpeg -hwaccel vaapi \ -vaapi_device /dev/dri/renderD128 \ -f rawvideo -pix_fmt drm_prime \ -i decoded_frames ... 常用于Wayland 播放器DRM/KMS 直出嵌入式 GUIQt / SDL EGL六、零拷贝Zero-Copy性能分水岭❌ 错误示范CPU 中转ffmpeg -hwaccel vaapi -i input.mp4 -pix_fmt yuv420p output.nv12 解码 → GPU → CPU → 再处理 →慢✅ 正确示范全程 GPUffmpeg -hwaccel vaapi \ -hwaccel_output_format vaapi \ -i input.mp4 \ -vf hwmap,scale_vaapiw1280:h720 \ -c:v hevc_vaapi \ output.mp4✅ 解码 → GPU → 滤镜 → 编码✅CPU 占用 5%七、Docker / 服务器部署必踩的坑✅ 权限docker run --rm \ --device/dev/dri/renderD128 \ -v /dev/dri:/dev/dri \ ffmpeg ...✅ 驱动必须进容器apt install i965-va-driver vainfo⚠️宿主机 容器驱动版本必须一致八、如何判断“到底有没有用到 GPU”Intel / AMDintel_gpu_topNVIDIAnvidia-smi dmon如果你看到GPU 使用率 ≈ 0%CPU 使用率 ≈ 400%你根本没在用硬解九、一个现实结论很重要FFmpeg 在 Linux 上“支持硬解” ≠ “默认启用硬解” ≠ “零拷贝”90% 的性能问题都是忘了-hwaccel忘了hwupload忘了hwaccel_output_format在 Wayland 下强行用 X11 路径十、总结一句话Linux 上 FFmpeg 硬加速的正确打开方式是Intel / AMD → VA-API DRM PrimeNVIDIA → NVDEC CUDA全程避免 CPU 中转用vainfo / nvidia-smi验证而不是看命令行参数
FFmpeg 硬解在 Linux 上：从“能跑”到“跑满 GPU”的实战笔记
目录一、先给结论Linux 硬加速现状速览二、VA-APILinux 硬解的“事实标准”1️⃣ 检查环境必做2️⃣ 最简单的硬解播放3️⃣ 转码硬解 硬编码三、NVDECNVIDIA 的“暴力美学”1️⃣ 确认驱动2️⃣ 硬解播放3️⃣ 硬解 CUDA 滤镜高级四、VDPAU老系统的“遗产”五、DRM Prime EGLWayland / 无 X11 的终极方案核心概念示例渲染不走 X11六、零拷贝Zero-Copy性能分水岭❌ 错误示范CPU 中转✅ 正确示范全程 GPU七、Docker / 服务器部署必踩的坑✅ 权限✅ 驱动必须进容器八、如何判断“到底有没有用到 GPU”Intel / AMDNVIDIA九、一个现实结论很重要十、总结一句话如果你在 Linux 上用过 FFmpeg 做视频处理大概率有过这种体验CPU 100%风扇起飞GPU 却在旁边“围观”。Linux 上的硬加速一直是碎片化重灾区Intel / AMD / NVIDIA 各玩各的API 一堆VA-API、VDPAU、NVDEC、AMF而且“支持”不等于“能用”更不等于“快”。这篇文章不堆参数只讲实战结论帮你把 FFmpeg 在 Linux 上的硬加速真正用起来。一、先给结论Linux 硬加速现状速览GPU推荐 APIFFmpeg 名称稳定性备注Intel✅ VA-APIh264_vaapi/hevc_vaapi⭐⭐⭐⭐⭐首选AMD✅ VA-APIh264_vaapi/hevc_vaapi⭐⭐⭐⭐新驱动AMD老⚠️ VDPAUh264_vdpau⭐⭐⭐仅 legacyNVIDIA✅ NVDECh264_nvdec/hevc_nvdec⭐⭐⭐⭐⭐闭源驱动NVIDIA开源 nouveau❌不可用—放弃嵌入式 / RK / Qcom✅ DRMh264_v4l2m2m⭐⭐⭐SoC 专用一句话选型Intel / 新 AMD →VA-APINVIDIA →NVDEC嵌入式 →v4l2m2m / DRM二、VA-APILinux 硬解的“事实标准”1️⃣ 检查环境必做vainfo看到类似输出才算“真可用”VA-API version: 1.20 Driver name: iHD / radeonsi Supported profile: VAProfileH264Main Supported profile: VAProfileHEVCMain❌ 如果只有VAProfileNone→ 驱动没装好2️⃣ 最简单的硬解播放ffplay -hwaccel vaapi \ -hwaccel_device /dev/dri/renderD128 \ input.mp4/dev/dri/renderD128是无特权渲染节点服务器 / Docker 必用。3️⃣ 转码硬解 硬编码ffmpeg -hwaccel vaapi \ -hwaccel_device /dev/dri/renderD128 \ -i input.mp4 \ -vf formatnv12,hwupload \ -c:v h264_vaapi \ output.mp4⚠️ 注意-vf formatnv12,hwupload不能少VA-API 默认工作在GPU 显存三、NVDECNVIDIA 的“暴力美学”1️⃣ 确认驱动nvidia-smiFFmpeg 编译时必须包含--enable-nonfree --enable-cuda-nvcc2️⃣ 硬解播放ffplay -hwaccel nvdec input.mp4 NVDEC自动选 GPU不需要手动指定 device。3️⃣ 硬解 CUDA 滤镜高级ffmpeg -hwaccel nvdec \ -hwaccel_output_format cuda \ -i input.mp4 \ -vf scale_npp1280:720 \ -c:v h264_nvenc \ output.mp4✅零拷贝✅ 滤镜直接在 GPU 跑四、VDPAU老系统的“遗产”AMD 老显卡 / 老驱动还能用ffmpeg -hwaccel vdpau -i input.mp4 ...❌ 不支持 HEVC❌ 新系统不建议再用除非你在维护 legacy 系统否则直接忽略。五、DRM Prime EGLWayland / 无 X11 的终极方案这是现代 Linux 桌面GNOME / KDE Wayland 的正确姿势。核心概念hwaccel vaapihwmapderive_devicedr直接把解码 surface 映射到 DRM 帧缓冲示例渲染不走 X11ffmpeg -hwaccel vaapi \ -vaapi_device /dev/dri/renderD128 \ -f rawvideo -pix_fmt drm_prime \ -i decoded_frames ... 常用于Wayland 播放器DRM/KMS 直出嵌入式 GUIQt / SDL EGL六、零拷贝Zero-Copy性能分水岭❌ 错误示范CPU 中转ffmpeg -hwaccel vaapi -i input.mp4 -pix_fmt yuv420p output.nv12 解码 → GPU → CPU → 再处理 →慢✅ 正确示范全程 GPUffmpeg -hwaccel vaapi \ -hwaccel_output_format vaapi \ -i input.mp4 \ -vf hwmap,scale_vaapiw1280:h720 \ -c:v hevc_vaapi \ output.mp4✅ 解码 → GPU → 滤镜 → 编码✅CPU 占用 5%七、Docker / 服务器部署必踩的坑✅ 权限docker run --rm \ --device/dev/dri/renderD128 \ -v /dev/dri:/dev/dri \ ffmpeg ...✅ 驱动必须进容器apt install i965-va-driver vainfo⚠️宿主机 容器驱动版本必须一致八、如何判断“到底有没有用到 GPU”Intel / AMDintel_gpu_topNVIDIAnvidia-smi dmon如果你看到GPU 使用率 ≈ 0%CPU 使用率 ≈ 400%你根本没在用硬解九、一个现实结论很重要FFmpeg 在 Linux 上“支持硬解” ≠ “默认启用硬解” ≠ “零拷贝”90% 的性能问题都是忘了-hwaccel忘了hwupload忘了hwaccel_output_format在 Wayland 下强行用 X11 路径十、总结一句话Linux 上 FFmpeg 硬加速的正确打开方式是Intel / AMD → VA-API DRM PrimeNVIDIA → NVDEC CUDA全程避免 CPU 中转用vainfo / nvidia-smi验证而不是看命令行参数
