为何GStreamer解复用器初始不创建源Pad？

核心原因：解复用器的内容驱动特性 #

• 解复用器的作用是解析MP4、MKV这类封装格式，拆分出内部的音视频流，但它启动初期完全不知道输入媒体包含多少轨、是什么编码格式——这些信息都存在媒体容器的头部，必须等它读取解析完头部数据后才能确定。
• 如果提前创建源Pad，根本无法匹配实际的流数量和类型：比如有的媒体只有单轨音频，有的是音视频双轨，甚至有多轨字幕或多语言音频，初始创建的Pad要么冗余，要么完全不符合后续处理要求，直接导致管道运行失败。

和普通元素的本质区别 #

普通元素（如autoaudiosink、videoconvert）的输入输出格式固定或可预定义，功能逻辑单一，因此初始化阶段就能创建好对应Pad；但解复用器是内容驱动的组件，行为完全依赖输入的媒体内容，必须动态生成源Pad来匹配解析出的流。

为什么无法直接用gst_element_link_many或gst_element_link链接 #

初始化阶段解复用器的源Pad还未创建，gst_element_link系列函数找不到可链接的Pad端点，自然会链接失败。正确做法是监听解复用器（或uridecodebin）的pad-added信号，当新的源Pad创建时，再动态将其与后续元素的Sink Pad链接。

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