Removing RTP Extensions in GStreamer - rtp

In a gstreamer (v1.17.0) application coded in C++, I have a stream of MPEG-TS/rtp with a specific-purpose rtp extension. I guess that rtpmp2tdepay has a problem with rtp extensions, as when I bypass the part of the chain adding rtp extensions, everything seems OK. So I decided to remove the rtp extension before rtpmp2tdepay element.
But as there is no remove_extension kind of thing in GstRtpBuffer, I have encountered problems with that.
This is my code, which results in segmentation faults:
GstRTPBuffer rtp = GST_RTP_BUFFER_INIT;
GstBuffer *buf = gst_buffer_make_writable(inputbuf);
gst_rtp_buffer_map(buf, GST_MAP_READWRITE, &rtp);
gst_rtp_buffer_set_extension(&rtp, 0);
if ((&rtp)->map[1].memory != NULL)
{
gst_buffer_unmap(buf, &((&rtp)->map[1]));
}
gst_rtp_buffer_unmap(&rtp);
return buf;
The error I encouter is this:
(receiver:1903): GStreamer-CRITICAL **: 13:19:43.409: gst_mini_object_unlock: assertion '(state & access_mode) == access_mode' failed
(receiver:1903): GStreamer-WARNING **: 13:19:43.409: free_priv_data: object finalizing but still has parent (object:0x7f4ea800d000, parent:0x7f4eb0107d80)
and later on:
(receiver:1903): GStreamer-CRITICAL **: 13:19:43.409: gst_mini_object_lock: assertion 'GST_MINI_OBJECT_IS_LOCKABLE (object)' failed
What is wrong with this code? Is there a better way to do this?

Related

GStreamer plugins 'interpipe' (Ridgerun) and intervideo do not handle RGB format

I am trying to use RidgeRun's Interpipe plugin. When the input video is I420, it works fine, but negotiation fails with RGB video.
Below the gst-launch commands I use in my app.
"videotestsrc ! video/x-raw,format=xRGB ! interpipesink name=camera sync=false"
"interpipesrc name=display listen-to=camera accept-events=false accept-eos-event=false enable-sync=false allow-renegotiation=false ! autovideosink sync=false async=false"
And the error I get:
ERROR: from element /GstPipeline:pipeline1/GstInterPipeSrc:display: Internal data stream error.
Additional debug info:
gstbasesrc.c(3055): gst_base_src_loop (): /GstPipeline:pipeline1/GstInterPipeSrc:display:
streaming stopped, reason not-negotiated (-4)
WARN basesrc gstbasesrc.c:3055:gst_base_src_loop:<display1> error: Internal data stream error.
WARN basesrc gstbasesrc.c:3055:gst_base_src_loop:<display1> error: streaming stopped, reason not-negotiated (-4)
Is RGB not supported? How do I find out what formats are supported?
I get the same error from the intervideosrc/sink plugin, and was hoping the interpipe plugin would not have this limitation.
If this is so, what other solution do I have?
Can someone provide pointers as to how to add support for additional formats (I've started looking at the source code for interpipe, but any pointer would be appreciated).

Error while trying to send opus encoded audio to a server using gstreamer

I am using a Kaldi-Gstreamer-Server library, which uses python gstreamer bindings, for live speech recognition application. The library uses onlinegmmdecodefaster gstreamer element (which is included with the Kaldi library) along with other elements (decodbin, audioconvert...) to accept audio and transcribe it to text . The library requires when sending a request to the server, the content-type query parameter be specified using GStreamer 1.0 caps format and encoded to the request Url.
When sending raw audio to the server by setting the content-type to audio/x-raw,format=S16LE,channels=2,layout=interleaved everything works fine and I get transcription text from the server. However, for low latency, I am trying to encode the audio using opus encoder and send to the server. I set the content-type request parameter to the caps format of the opusdec element pad as this:
audio/x-opus, channel-mapping-family=(int)[ 1, 255 ], channels=(int)[1, 255 ], stream-count=(int)[ 1, 255 ], coupled-count=(int)[ 0, 255 ]
However I get the following error while gstreamer tries to use the above capabilities:
2017-03-15 13:53:26 - INFO: decoder2:
0578f66f-8474-48db-996b-ce401ed5c034: Setting caps to audio/x-opus,
channel-mapping-family=(int)[ 1, 255 ], channels=(int)[ 1, 255 ],
stream-count=(int)[ 1, 255 ], coupled-count=(int)[ 0, 255 ]
(python:1145): GStreamer-CRITICAL **: gst_event_new_caps: assertion
'gst_caps_is_fixed (caps)' failed
(python:1145): GStreamer-CRITICAL **: gst_pad_push_event: assertion
'GST_IS_EVENT (event)' failed 2017-03-15 13:53:27 - ERROR: decoder2:
(GLib.Error('Internal data flow error.', 'gst-stream-error-quark', 1),
'gstbasesrc.c(2933): gst_base_src_loop ():
/GstPipeline:pipeline0/GstAppSrc:appsrc:\nstreaming task paused,
reason not-negotiated (-4)') 2017-03-15 13:53:27 - INFO: decoder2:
0578f66f-8474-48db-996b-ce401ed5c034: Resetting decoder state
(python:1145): GStreamer-CRITICAL **: gst_event_new_caps: assertion
'gst_caps_is_fixed (caps)' failed
(python:1145): GStreamer-CRITICAL **: gst_pad_push_event: assertion
'GST_IS_EVENT (event)' failed
(python:1145): GStreamer-CRITICAL **: gst_event_new_caps: assertion
'gst_caps_is_fixed (caps)' failed
(python:1145): GStreamer-CRITICAL **: gst_pad_push_event: assertion
'GST_IS_EVENT (event)' failed 2017-03-15 13:53:27 - ERROR: decoder2:
(GLib.Error('Internal data flow error.', 'gst-stream-error-quark', 1),
'gstbasesrc.c(2933): gst_base_src_loop ():
/GstPipeline:pipeline0/GstAppSrc:appsrc:\nstreaming task paused,
reason not-negotiated (-4)')
What could be the cause of this error? How can I resolve this so that I can send opus encoded audio data to the server?

Gstreamer 1.0 error: Missing element: HTTP protocol source

I have installed gstreamer 1.0 with base, good, ugly and bad plugin. When I run following command using:
gst-launch-1.0 playbin uri=http://-somr url to video src-
It gives me following error:
Setting pipeline to PAUSED ...
ERROR: Pipeline doesn't want to pause.
Missing element: HTTP protocol source
ERROR: from element /GstURIDecodeBin:uridecodebin0: No URI handler implemented for "http".
Additional debug info:
gsturidecodebin.c(1416): gen_source_element (): /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0
Setting pipeline to NULL ...
Freeing pipeline ...
I am new to this and found most solution for gstreamer-0.10 which doesnot work for me. btw I am using ubuntu 14.04.
Badly looking for help.
Thanks in advance.
Missing element: HTTP protocol source
And
no_source:
{
/* whoops, could not create the source element, dig a little deeper to
* figure out what might be wrong. */
if (err != NULL && err->code == GST_URI_ERROR_UNSUPPORTED_PROTOCOL) {
gchar *prot;
prot = gst_uri_get_protocol (decoder->uri);
if (prot == NULL)
goto invalid_uri;
gst_element_post_message (GST_ELEMENT_CAST (decoder),
gst_missing_uri_source_message_new (GST_ELEMENT (decoder), prot));
GST_ELEMENT_ERROR (decoder, CORE, MISSING_PLUGIN,
(_("No URI handler implemented for \"%s\"."), prot), (NULL));
g_free (prot);
} else {
GST_ELEMENT_ERROR (decoder, RESOURCE, NOT_FOUND,
("%s", (err) ? err->message : "URI was not accepted by any element"),
("No element accepted URI '%s'", decoder->uri));
}
g_clear_error (&err);
return NULL;
}
Mean your gstreamer install has problem, you miss http client source plugin. Try gst-inspect-1.0 souphttpsrc? If no result, try to re-install plugin-good.

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

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
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);
In a separate function I call the g_main_loop_run() function
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.
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.
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.
This ensured that the tcpserversink knew what it was about to send (it set the caps) so that it no longer spawns those assertions.
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.
this is a summary and a slight variation to the stackoverflow question found here: gst-launch with tcpserversink not working

Gtk::Label update label speed

I have a program that tries to update a Gtk::Label at a very high frequency, and is exhibing very unstable behaviour. I get several of these errors:
(gtkWindow:26559): Pango-CRITICAL **: pango_layout_copy: assertion 'PANGO_IS_LAYOUT (src)' failed
(gtkWindow:26559): Pango-CRITICAL **: pango_layout_set_width: assertion 'layout != NULL' failed
(gtkWindow:26559): Pango-CRITICAL **: pango_layout_get_pixel_extents: assertion 'PANGO_IS_LAYOUT (layout)' failed
(gtkWindow:26559): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
until the program eventually crashes with:
Pango:ERROR:pango-layout.c:3916:pango_layout_check_lines: assertion failed: (!layout->log_attrs)
2921
Aborted (core dumped)
The relevant code lines:
while(1){
std::string sensorLine="";
_serial.readLine(&sensorLine); // read serial data with boost::asio
_output->set_label(sensorLine.data()); // _output -> Gtk::Label*
std::cout<<sensorLine<<std::endl;
//sleep(1);
}
I only get the error if I try to use _output->setlabel, if I comment this line everything runs smoothly, with the output printed in the console. The same thing happens if I call sleep()inside the loop, the Gtk::Label is updated as the commandline and no errors are thrown.
This loop is running on a separate thread that receives _output as argument.
Use g_idle_add (which actually is threadsafe) with a callback which in turn actually modifies (read: calls set_label on) your GtkLabel.
Do not call UI functions from a different thread! Never ever! You open the box of pandora if you do.