GStreamer中h264depay后接d3d11h264dec报未协商(-4)错误

not negotiated (-4)是GStreamer典型的元件Pad能力协商失败错误，这个场景的核心矛盾是d3d11h264dec作为D3D11硬件解码器的输入要求，和rtph264depay的默认输出不匹配：

• d3d11h264dec要求输入的H.264码流必须按完整访问单元（即单帧）对齐，且码流格式、SPS/PPS参数集等元数据必须在解码前通过Caps明确传递，不支持实时解析零散NAL单元获取流信息。
• rtph264depay默认输出的是按RTP包切片的零散NAL单元，既没有做帧级对齐，经过RTP封包解包流程后也丢失了原编码器输出的码流格式元数据，无法直接满足硬件解码器的输入要求。
• 之前单独加h264parse不生效，是因为h264parse默认依赖上游传递的元数据判断输出格式，上游元数据丢失后它输出的Caps无法匹配d3d11h264dec的能力集，协商直接失败。

不需要额外引入其他元件，只需要调整两个位置的配置即可，修复后可正常运行的流水线命令如下：

gst-launch-1.0 dx9screencapsrc width=1920 height=1080 monitor=1 ! "video/x-raw, framerate=30/1" ! videoconvert ! x264enc speed-preset=medium threads=12 aud=true ! rtph264pay config-interval=1 pt=96 ! "application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96" ! rtph264depay ! h264parse ! "video/x-h264, stream-format=byte-stream, alignment=au" ! d3d11h264dec ! d3d11videosink

• 给x264enc添加aud=true参数：强制编码器在每帧数据前插入访问单元分隔符，方便h264parse准确识别帧边界，完成帧级对齐。
• 在h264parse后强制声明Caps video/x-h264, stream-format=byte-stream, alignment=au：跳过自动协商环节，明确告知下游d3d11h264dec当前输入是AnnexB格式、按完整帧对齐的H.264码流，完全匹配硬件解码器的输入要求。
• 整条流水线全程在D3D11内存域完成解码和渲染，不需要额外添加videoconvert做格式转换，不会产生CPU-GPU间的额外内存拷贝，性能最优。

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