GStreamer中rtmpsrc拉RTMP流为何无需rtph264depay与h264parse

出现这个差异的本质是对各GStreamer组件的输入格式要求、RTMP协议的封装格式、decodebin的自动处理逻辑存在认知偏差，具体可以拆成三点说明：

• rtph264depay完全不适用于RTMP流场景
  rtph264depay的唯一作用是处理RTP协议打包的H264流：它会剥离RTP包头、重组被RTP分片拆分的H264 NALU，输出原始H264码流，它的输入必须满足application/x-rtp, media=video, encoding-name=H264的caps要求。
  而RTMP协议传输音视频时，是把音视频数据封装成FLV Tag格式、再切分成RTMP Chunk传输的，rtmpsrc输出的数据是FLV封装格式，和RTP格式没有任何关系，caps根本不匹配，只要在rtmpsrc后面接rtph264depay，第一级pad协商就会直接失败，流水线根本无法启动。
• 手动在decodebin前加h264parse属于逻辑错误
  h264parse的作用是对裸H264码流做规整：比如补全SPS/PPS参数、对齐帧边界、给解码器输出符合规范的输入格式，它的输入必须是video/x-h264格式的裸码流。
  而rtmpsrc直接输出的是FLV封装的复合音视频数据，不是裸H264码流，h264parse根本无法识别这种输入，哪怕你去掉rtph264depay直接在rtmpsrc后面接h264parse，同样会因为caps协商失败报错。
• decodebin已经内置了所有必要的处理流程，不需要手动提前加解析/解负载组件
  decodebin是GStreamer的自动解封装解码组件，它会自动识别输入数据的封装格式，按需加载对应的解复用、码流解析、解码组件，不需要用户手动干预。
  你给出的可正常运行的流水线，内部实际的处理链路是自动完成的：

1. rtmpsrc拉取RTMP流，输出FLV封装的音视频混合数据
2. decodebin自动识别FLV格式，加载flvdemux完成解封装，分离出H264视频流和对应音频流
3. decodebin自动给分离出的H264裸流匹配h264parse做码流预处理
4. decodebin自动匹配对应的H264解码器，输出原始YUV/RGB格式的视频帧
5. 视频帧经videoconvert做格式适配后，送到autovideosink完成渲染

补充说明：只有拉取直接传输RTP载荷的流（比如RTSP传输的RTP媒体数据）时，才需要在源组件后手动添加rtph264depay做RTP负载解析。如果源输出的是完整封装格式的流，直接交给decodebin自动处理即可，手动提前插入解析、解负载组件只会因为输入格式不匹配导致caps协商失败，流水线无法运行。

内容的提问来源于stack exchange，提问作者John M.