h264_nvenc/hevc_nvenc无“显卡极限压制”，其并发数、延迟、码率等受GPU架构硬限约束；初始化需AV_HWDEVICE_TYPE_CUDA上下文且pix_fmt设为AV_PIX_FMT_CUDA，否则静默回退软编；真实负载看nvidia-smi pmon的ENC列而非GPU-Util。
直接说结论：h264_nvenc 或 hevc_nvenc 本身不支持“显卡极限压制”——它有硬性物理上限，不是调个参数就能榨干GPU。所谓“极限”，其实是把 NVENC 的并发路数、码率档位、延迟模式和像素格式全部对齐到硬件能力边界，同时避开驱动/SDK/FFmpeg三者版本错配导致的隐性降频。
为什么avcodec_open2()返回NULL却没报错？
这是最常被忽略的第一道坎：NVENC编码器初始化失败时，FFmpeg默认不抛异常，只让avcodec_open2()返回NULL，而av_err2str()可能输出空字符串或“Invalid argument”。根本原因不是代码写错了，而是运行时找不到正确的CUDA上下文或NVENC句柄。
- 必须在
avcodec_open2()前调用av_hwdevice_ctx_create()创建AV_HWDEVICE_TYPE_CUDA上下文，且传入有效的device_idx（比如0） -
codec_ctx->pix_fmt必须设为AV_PIX_FMT_CUDA，不能是AV_PIX_FMT_NV12或AV_PIX_FMT_YUV420P——后者会导致内部自动回退到软编码 - Linux下需确保
libnvcuvid.so在LD_LIBRARY_PATH中，Windows下nvcuda.dll要和ffmpeg.exe同目录或在PATH里
h264_nvenc的真正并发瓶颈在哪？
NVENC不是CPU，不能靠开线程堆性能。它的并发能力由GPU型号决定：Turing架构（RTX 20系）起支持最多8路1080p@30fps并发编码，Ampere（RTX 30系）提升至16路，但前提是每路都满足“低延迟+CBR/VBR+8-bit 4:2:0”条件。一旦启用lossless或10bit，并发数立刻腰斩。
- 查真实并发上限：运行
nvidia-smi -q -d ENCODER，看Active Sessions当前值和Max Sessions理论值 - 避免跨GPU调度：多卡系统中，
av_hwdevice_ctx_create()的device_idx必须和-gpu命令行参数一致，否则会静默绑定到默认卡 - 不要手动
cudaSetDevice()：FFmpeg的CUDA设备管理是独立的，混用会导致cuCtxDestroy冲突
如何压出NVENC的最低延迟和最高帧率？
关键不在码率参数，而在priv_data里的底层控制项。预设preset只是快捷方式，真要压极限，得直操作NVENC物理寄存器级参数：
通过 NVIDIA NIM API 调用 Kimi K2.5 视觉模型分析图像，非常适合为 MiniMax M2.5、GLM-5 等非视觉模型赋予视觉能力。
- 设
av_opt_set(codec_ctx->priv_data, "delay", "0", 0)强制零延迟队列（非所有GPU支持） - 用
av_opt_set(codec_ctx->priv_data, "rc", "cbr_ld", 0)启用CBR Low Delay模式，比vbr更稳 -
av_opt_set(codec_ctx->priv_data, "forced_idr", "1", 0)确保每帧都是IDR，避免B帧堆积延迟 - 分辨率必须是偶数，且宽高需满足
width % 2 == 0 && height % 2 == 0，否则NVENC内部会自动pad，吞吐骤降
为什么nvidia-smi显示GPU利用率只有5%？
这不是bug，是NVENC设计使然。它的编码单元是固定功能电路（Fixed-Function Unit），不走CUDA核心，所以nvidia-smi里GPU-Util列反映的是通用计算单元占用率，和NVENC无关。要看真实编码负载，得盯nvidia-smi pmon -i 0里的ENC列（单位%）——这才是NVENC引擎的实际使用率。
最容易被忽略的一点：NVENC的“满载”表现为ENC持续95%+，同时MEM带宽接近显存总带宽上限。如果ENC上不去，八成是输入帧没正确上传到GPU内存（av_hwframe_transfer_data()失败或未调用），或者AVFrame->data[0]指向的是CPU内存地址。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
