我理解你的需求：现有一个GStreamer应用可以正常流式显示视频并写入文件，但你希望仅在运行时动态变化的外部条件为真时才写入文件，同时保持视频显示不受影响。你之前尝试的几种方法没达到预期，我来给你梳理可行的解决方案，顺便分析下之前的问题出在哪：

方案1：使用valve元素（最推荐，实现最简单） #

valve是GStreamer官方提供的专门用于动态控制数据流通的元素，完美匹配你的场景——不需要修改管道结构、不需要频繁切换元素状态，只需要改一个属性就能开关文件写入。

1. 调整管道结构 #

假设你原来的管道是类似这样的：

src -> [视频处理元素] -> tee
                          |-> queue -> videosink（显示用）
                          |-> queue -> filesink（写入文件用）

现在只需要在filesink前面插入一个valve：

src -> [视频处理元素] -> tee
                          |-> queue -> videosink（显示用）
                          |-> queue -> valve -> filesink（写入文件用）

2. 动态控制逻辑 #

在你的代码里，监听外部条件的变化，然后通过设置valve的drop属性来控制是否写入：

• 当条件为真（需要写入文件）：

  g_object_set(valve_element, "drop", FALSE, NULL);
  

• 当条件为假（停止写入文件）：

  g_object_set(valve_element, "drop", TRUE, NULL);
  

drop设为TRUE时，valve会直接丢弃所有流向filesink的数据，不会写入文件；设为FALSE时正常传递数据。整个过程管道状态完全不变，视频显示不受任何影响。

方案2：动态连接/断开Filesink的Pad（更灵活） #

如果需要更精细的控制（比如停止写入时彻底释放文件资源），可以通过动态管理pad的连接来实现：

实现步骤 #

1. 初始化时，创建tee、queue_for_file、filesink元素，但不要一开始就把queue_for_file和filesink链接起来，或者链接后立即断开。
2. 当外部条件为真时：
   • 获取queue_for_file的src pad和filesink的sink pad
   • 调用gst_pad_link()完成链接
   • 将filesink设置为GST_STATE_PLAYING
3. 当外部条件为假时：
   • 先给filesink发送EOS信号，确保写入的文件完整：

     gst_element_send_event(filesink, gst_event_new_eos());
     

   • 调用gst_pad_unlink()断开两个pad的连接
   • 将filesink设置为GST_STATE_NULL（释放文件句柄等资源）

关键注意事项 #

所有pad的链接/断开操作**必须在GStreamer的主线程（即GMainLoop所在线程）**中执行，否则会触发线程安全问题，导致管道崩溃。

分析你之前尝试的问题 #

1. gst_element_set_locked_state()的误用：这个函数的作用是锁住元素的状态，不让它响应管道的全局状态变化，完全不是用来控制数据流的。你强制锁住videosink的状态后，管道状态同步逻辑被破坏，自然会出现黑屏。
2. 直接切换filesink状态为NULL：当你把filesink切回PLAYING时，tee之前缓存的视频数据会继续流向filesink，所以看起来文件还在写入。而且频繁切换元素状态容易导致管道内部数据流异常，不是最优解。
3. Pad Probe的正确用法：你提到的gst_pad_add_probe()其实是可行的——在filesink的sink pad上添加probe，当条件为假时返回GST_PAD_PROBE_DROP丢弃数据，为真时返回GST_PAD_PROBE_OK放行。但这个方法需要处理probe的回调逻辑，比valve的实现复杂一些，适合需要自定义数据处理的场景。

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