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

How to solve failing gstreamer assertions in a simple TcpServerSrc to TcpServerSink pipeline

本文关键字：解决 失败 断言 gstreamer 管道 简单 TcpServerSrc TcpServerSink      更新时间：2023-10-16

我目前有一个简单的管道，由一个tcpserversrc组成，该管道将其输入中继到tcpserversink。但此管道每g_main_loop迭代重复以下 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（） 函数

这些错误建议了一些关于上限的信息，但文档没有建议 tcpserver 接收器和/或源需要它。 2 其他管道解码到 mp3 并从中编码，以及发送到此管道和从此管道接收，它们都没有附加上限，并且这些管道中没有断言失败。

我还应该说管道运行正常，这并不意味着我的代码没有错误，但如果管道仍然按预期工作，我发现 CRITICAL 断言有点尴尬。我想摆脱这些消息的主要原因是一个可能的错误，它可能会回来咬我，以及阻塞我的应用程序日志的大量输出。

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

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

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

这是此处找到的堆栈溢出问题的摘要和略有变化：带有TCPservers的GST启动无法正常工作

相关文章：