C++ 如何在简单的TcpServerSrc到TcpServerSink管道中解决失败的gstreamer断言

我目前有一个简单的管道，由一个tcpserversrc组成，它将其输入中继到一个tcpserversink。但该管道在每次g_main_循环迭代中重复以下4条错误消息

(dmp-server:9726): GStreamer-CRITICAL **: gst_mini_object_ref: assertion 'mini_object != NULL' failed

(dmp-server:9726): GStreamer-CRITICAL **: gst_caps_get_structure: assertion 'GST_IS_CAPS (caps)' failed

(dmp-server:9726): GStreamer-CRITICAL **: gst_structure_has_field: assertion 'structure != NULL' failed

(dmp-server:9726): GStreamer-CRITICAL **: gst_mini_object_unref: assertion 'mini_object != NULL' failed

在我的对象的构造函数中，我初始化了Gstreamer元素，如下所示

GMainLoop* loop = g_main_loop_new(nullptr, false);
GstElement* pipeline = gst_pipeline_new("tcp_bridge");
GstElement* source = gst_element_factory_make("tcpserversrc", "recv");
GstElement* sink = gst_element_factory_make("tcpserversink", "send");
GstBus* bus = gst_pipeline_get_bus (GST_PIPELINE (pipeline))
uint16_t recv_port = 2000
uint16_t send_port = 2001

if (!pipeline || !source || !sink)
{
    throw std::runtime_error("Could not create the pipeline components for this radio.");
}

g_object_set(G_OBJECT(source), "port", gint(recv_port), nullptr);
g_object_set(G_OBJECT(sink), "port", gint(send_port), nullptr);

bus = gst_pipeline_get_bus (GST_PIPELINE (pipeline));
gst_bus_add_watch (bus, bus_call, this);

gst_bin_add_many (GST_BIN(pipeline), source, sink, nullptr);
gst_element_link_many(source, sink, nullptr);

在一个单独的函数中，我调用g_main_loop_run（）函数

这些错误表明了CAP的某些方面，但文档并未表明tcpserver接收器和/或源需要它。2其他从mp3解码和编码的管道以及从该管道发送和接收的管道都没有附加到它们的上限，并且在这些管道中没有断言失败

---

我还应该说，管道运行正常，这并不意味着我的代码没有错误，但如果管道仍然按预期工作，我发现关键断言有点尴尬。我想要清除这些消息的主要原因是可能会有一个bug再次攻击我，并且大量的输出阻塞了我的应用程序日志。

在这种情况下，tcpServerSink不知道它发送的是什么，这触发了断言。因此，在我的例子中，当我通过这个管道传输MP3音频时，我必须向管道中添加一个mpegaudioparse元素

这确保了tcpserversink知道它将要发送什么（它设置了上限），从而不再生成这些断言

一些提示当遇到相同的问题时，请将G_DEBUG=fatal_warnings环境变量与调试器结合使用，以获取stacktrace来标识具有失败（关键）断言的组件

这是对stackoverflow问题的一个总结和一个细微的变化：