确认对GStreamer动态管道构建及pad_added回调函数的理解是否正确

• 初始管道构建逻辑：
  代码中确实将所有元素添加到了pipeline的bin中，但仅完成了audioconvert -> audioresample -> autoaudiosink的静态链接，没有直接链接uridecodebin（即data.source）。这是因为uridecodebin属于动态元素，它的source pad无法在初始化阶段就确定，必须等它完成媒体流的解析、内部解复用器/解码器创建后才会生成。

• pad-added信号与回调的触发逻辑：
  不是我们主动为decoder添加source pad，而是uridecodebin在内部完成媒体处理流程（比如识别媒体格式、实例化解复用器和解码器）后，会自动为内部的解码器元素创建source pad，随后触发pad-added信号，进而调用你注册的pad_added_handler回调函数。
  回调的实际参数为：

  1. 发出信号的元素（data.source，即uridecodebin）
  2. 新生成的source pad
  3. 你传入的自定义数据&data

• gst_pad_link的作用：
  在回调函数中执行gst_pad_link(new_pad, sink_pad)，本质是把uridecodebin动态生成的音频source pad，与audioconvert的sink pad完成链接，补全了整个管道的数据流路径。

• 最终管道结构：
  你描述的uridecodebin[source-demux-decoder-[src]] -->[sink]audioconvert --> audioresample --> autoaudiosink完全准确。uridecodebin内部会封装从媒体源读取、解复用、解码的完整流程，最终输出的音频流通过动态链接的pad流入后续的音频转换、重采样和输出元素。

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