据我了解， 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 元素)必须链接到新创建的源 pads 才能使流继续运行。这是通过添加 pad 的 信号和 pad 链接程序完成的。
如果没有这些焊盘特征中的任何一个，这种行为将是不可能的，并且一切都必须在获得流之前在金属中静态设置。这意味着您必须事先知道您将要阅读的流的内容是什么(这是一个非常非常重的限制!)
最后一句话:当您通过命令行指定管道时(就像我猜的 gst-launch)，您处于高级界面。在您指定的元素中，焊盘链接机制非常重要!事情是你不必打扰，因为事情会完成。但是“不必为某事烦恼”并不意味着这件事对您毫无用处。