<div dir="ltr">From the information provided here <a href="http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/GstPad.html#gst-pad-send-event" target="_blank">http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/GstPad.html#gst-pad-send-event</a> I can only conclude that something else is holding the lock off that pad. Maybe someone more experienced can provide hints on the usual things that normally acquire locks on pads.<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:13px">On exit, call gtk_main_quit() then add a callback on the filesink sink pad:</span></blockquote><div>Once again, I don't think you should be invoking <span style="font-size:13px">gtk_main_quit() </span> while you're still doing things in your pipeline.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:13px">gst_pad_add_probe (pad, </span><span style="font-size:13px">GST_PAD_PROBE_TYPE_BLOCK|GST_</span><span style="font-size:13px">PAD_PROBE_TYPE_EVENT_</span><span style="font-size:13px">DOWNSTREAM, </span><span style="font-size:13px">(GstPadProbeCallback) cb_pad_event, data, NULL);</span></blockquote><div>EOS is a serialized event that travels with data. If you're blocking the filesink sink pad, I find it very strange you're receiving even receiving the EOS.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <span style="font-size:13px"> return GST_PAD_PROBE_DROP;</span></blockquote><div>You're dropping the pad regardless of whether or not the event is an EOS. You're basically dropping the pad as soon as you receive a buffer or any event.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:13px">data->mux_pad = pad;</span></blockquote><div><div>Should you not be incrementing the reference counter for this?</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-01-05 16:06 GMT+01:00 Paul Barber <span dir="ltr"><<a href="mailto:paul.barber@oncology.ox.ac.uk" target="_blank">paul.barber@oncology.ox.ac.uk</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Happy New Year to all (this thread is continued since before Christmas)<br>
<br>
Sérgio Agostinho wrote:<br>
>From what you describe the EOS callback is returning. It is locking somewhere else.<br>
<br>
After another look and tidy up I see the call that locks is gst_pad_send_event()<br>
It also locks if I try to send the event from another pad elsewhere in the pipeline.<br>
The debug output looks like a loop of repeated EOS events:<br>
0:00:06.529580866 22492       0x6f78f0 DEBUG              GST_EVENT gstevent.c:300:gst_event_new_custom: creating new event 0xc75a40 eos 28174<br>
0:00:06.529586525 22492       0x6f78f0 DEBUG               GST_PADS gstpad.c:4550:store_sticky_event:<mpegpsmux0:src> pad is EOS<br>
0:00:06.529591227 22492       0x6f78f0 DEBUG               GST_PADS gstpad.c:4845:gst_pad_push_event:<mpegpsmux0:src> We're EOS<br>
0:00:06.529595976 22492       0x6f78f0 DEBUG              mpegpsmux mpegpsmux.c:512:mpegpsmux_collected:<mpegpsmux0> Pads collected<br>
0:00:06.529600104 22492       0x6f78f0 DEBUG             GST_MEMORY gstmemory.c:138:gst_memory_init: new memory 0xa2d430, maxsize:4 offset:0 size:4<br>
0:00:06.529605836 22492       0x6f78f0 DEBUG             GST_MEMORY gstmemory.c:88:_gst_memory_free: free memory 0xa2d430<br>
These 6 lines are repeated again and again ...<br>
<br>
I tried gst_element_send_event() instead, this does not lock, and the EOS is received, but this does not solve the original problem of some bad files being created by filesink.<br>
<br>
RECAP:<br>
I have a GTK window with g_signal_connect for "key_press_event" to end<br>
the program when Esc is pressed.<br>
The mux sink pad is a request pad so I add a callback for pad-added on<br>
the mux before the pipeline is linked up:<br>
g_signal_connect (data->mux, "pad-added", G_CALLBACK (cb_new_mux_pad),<br>
data);<br>
<br>
In this callback, keep a pointer to mux sink pad for later:<br>
static void cb_new_mux_pad (GstElement *element, GstPad *pad, GstAppData<br>
*data)<br>
{<br>
     data->mux_pad = pad;<br>
}<br>
<br>
Set pipeline to play and then run gtk_main()<br>
<br>
On exit, call gtk_main_quit() then add a callback on the filesink sink pad:<br>
pad = gst_element_get_static_pad (data->filesink, "sink");<br>
gst_pad_add_probe (pad,<br>
GST_PAD_PROBE_TYPE_BLOCK|GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM,<br>
(GstPadProbeCallback) cb_pad_event, data, NULL);<br>
gst_object_unref (pad);<br>
<br>
Send an EOS into the mux sink pad we already have a reference to:<br>
gst_pad_send_event (data->mux_pad, gst_event_new_eos ());<br>
<br>
In the probe pad callback, just set some flag (data->EOS) that we can<br>
check for it later:<br>
static GstPadProbeReturn cb_pad_event (GstPad *pad, GstPadProbeInfo<br>
*info, GstAppData *data)<br>
{<br>
   GstEvent *event;<br>
   event = GST_PAD_PROBE_INFO_EVENT(info);<br>
   if (event->type == GST_EVENT_EOS){<br>
       data->EOS = TRUE;<br>
   }<br>
   return GST_PAD_PROBE_DROP;<br>
}<br>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
</blockquote></div><br></div>