如何解决在简单的TcpServerSrc到TcpServerSink管道中失败的gstreamer断言 [英] How to solve failing gstreamer assertions in a simple TcpServerSrc to TcpServerSink pipeline

查看:1970
本文介绍了如何解决在简单的TcpServerSrc到TcpServerSink管道中失败的gstreamer断言的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我目前有一个简单的管道,由一个tcpserversrc组成,中继它的输入一个tcpserversink。但是这个管道每次g_main_loop迭代都会重复以下4个错误消息。

I currently have a simple pipeline consisting of a tcpserversrc that relays its input a tcpserversink. But this pipeline repeats the following 4 error messages every g_main_loop iteration.

(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元素如下

in the constructor of my object I intialise the Gstreamer elements as follows

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()函数

In a separate function I call the g_main_loop_run() function

错误提示关于caps的一些信息,但是文档并不建议tcpserver sink和/或source需要它。 2个其他管道解码和编码mp3以及发送和接收从这个管道都没有上限附加到他们,没有断言失败在这些管道。

The errors suggest something about caps, but the documentation does not suggest it is required for the tcpserver sinks and or sources. 2 other pipelines that decode to and encode from mp3 as well as send to and receive from this pipeline both have no caps attached to them and no assertions fail in those pipelines.

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

I also should say that the pipeline operates normally, which does not mean my code isn't erroneous, but I find the CRITICAL assertions a bit awkward if the pipeline still works as intended. The main reason I want to get rid of the messages is a possible bug that might come back to bite me and the massive output that clogs up my application log.

推荐答案

在这种情况下,tcpServerSink不知道它在发送什么,这触发了断言。所以在我的case,因为我是通过这个管道流MP3音频,我不得不添加一个mpegaudioparse元素到我的管道。

In this case the tcpServerSink did not know what it was sending and this triggered the assertions. So in my case as I was streaming MP3 audio over this pipeline I had to add a mpegaudioparse element to my pipeline.

这确保tcpserversink知道它是什么

This ensured that the tcpserversink knew what it was about to send (it set the caps) so that it no longer spawns those assertions.

在面对同样的问题时,一些提示使用G_DEBUG = fatal_warnings环境变量和一个调试器获取一个stacktrace来识别失败(关键)断言的组件。

Some tips when facing the same issues, use the G_DEBUG=fatal_warnings environment variable in conjunction with a debugger to get a stacktrace to identify the component that has failing (critical) assertions.

这是一个汇总和稍微变化stackoverflow问题在这里找到:使用tcpserversink无法启动gst-launch

this is a summary and a slight variation to the stackoverflow question found here: gst-launch with tcpserversink not working

这篇关于如何解决在简单的TcpServerSrc到TcpServerSink管道中失败的gstreamer断言的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆