gst_element_send_event(element, gst_event_new_eos()) takes a long time to return
Hello,
I have a gstreamer pipeline: appsrc -> identity -> customsink. The identity element is essentially being used as a heartbeat to track if data is flowing from appsrc to customsink. If there is no data flow for 45 seconds (i.e no heartbeats), I send an EOS event using gst_element_send_event(sink, gst_event_new_eos()). However, this takes 15 minutes to return or maybe more in some cases. I am trying to understand what this event usually waits on and what are the possible scenarios it can hang. I also have a buffer callback on collect pads in customsink that sends an EOS message on the bus when the received buffer is NULL.
How can I gracefully terminate the pipeline in this design where the application is sending the EOS because it detected no data flow for 45 seconds.
More about the application: The application has a Java, JNI and a C++ component. A start() method is invoked in the Java layer that translates to start() in C++ via JNI. This method set GST pipeline to PLAYING state. At any point, if the identity element is not hit in the pipeline (indicating no heartbeats), a stop() call is made to stop the pipeline. This translates the same way as the start() call. In the stop() call this is the order of things:
gst_element_send_event(sink, gst_event_new_eos());
gst_element_set_state(pipeline, GST_STATE_NULL);
g_main_loop_quit(main_loop);
gst_bus_remove_signal_watch(bus);
gst_object_unref(bus);
gst_object_unref(pipeline);
In the custom sink, I have a callback registered that listens in on the incoming buffer on the collect pad:
gst_collect_pads_set_buffer_function (collect,GST_DEBUG_FUNCPTR (gst_handle_buffer), sink);
In this callback, I am checking if the incoming buffer is NULL to detect EOS and take the necessary action like this:
if (buffer == NULL && data == NULL) {
LOG_INFO("Received event);
// Take necessary library action
LOG_INFO("Sending eos");
// send out eos message to gstreamer bus
message = gst_message_new_eos (GST_OBJECT_CAST (sink));
gst_element_post_message (GST_ELEMENT_CAST (sink), message);
ret = GST_FLOW_EOS;
}
My hunch is this pad is still receiving data because of which the gst_element_send_event is taking a long time to get processed. But if there was data, identity element should have been hit in the buffer flow, unless it is getting optimized out since the element does nothing with the buffer.
I have collected some verbose Gstreamer logs. Hope it helps in providing some pointers on what could be going on. In the attached log file, the EOS event seems to be resolving after 2 minutes.