据我了解，gst_parse_launch()基于描述管道的命令行语法创建了一个新管道。它会自动处理请求填充（有时是填充等）的所有复杂细节并构建管道。
所以我的问题是，为什么不一直使用它？为什么要添加垫添加处理程序，请求和链接垫等？
是否有使用gst_parse_launch()不会做的情况？
许多 GStreamer 元素将使用这些功能来探测它们应该加载哪个插件。想到的最好的例子是decodebin或playbin插件。对于第一个，您只需选择源（例如filesrc）。
现在，播放我们的媒体流时会发生什么？
一开始，decodebin的“内部”只有：
--- 下沉 -->|[ TypeFind] |
此时没有源 pad 出来，因为元素仍然不知道流内容。
如果您有avi视频文件，则decodebin将首先使用特定的 GStreamer 元素来探测流中使用的容器/编解码器是什么。此元素 ( GstTypeFind ) 将根据流和编解码器/容器之间的相似性计算分数。
在这个例子中，TypeFind 将命中avi容器，因此它将分配一个avi解析器。decodebin的“内部”现在正在扩展...... avi解析器分析流以了解是否有音频/视频子流要解析。如果是这样， typefind 会再次进入以查找使用的编解码器。
然后分配适当的解码器。在这里，decodebin现在已经完全准备好了，下游元素（例如 sink 元素）必须链接到新创建的 source pads 才能使流继续运行。这是通过添加焊盘的信号和焊盘链接程序完成的。
如果没有这些焊盘特征中的任何一个，这种行为将是不可能的，一切都必须在获得流之前在金属中静态设置。这意味着您必须事先知道您将要阅读的流的内容是什么（这是一个非常非常重的限制！）
最后一句话：当您通过命令行指定管道时（就像gst-launch我猜的那样），您处于高级界面。在您指定的元素中，焊盘链接机制非常重要！事情是你不必打扰，因为事情会完成。但是“不必为某事烦恼”并不意味着这件事对您毫无用处。