Pipeline freeze after multiple pad probe

[MichaelHsu170]

Hi all,

My pipeline is illustrated as the following.

===========================================================================
               videotestsrc--convert--queue--h264--queue_mux_v--muxer--queue--filesink
audiotestsrc--convert--resample--queue--aac--queue_mux_a--
===========================================================================

I need to save the video/audio streaming into different files, splited by a fixed time interval, so I block both of the src pads of GstElement queue_mux_v and queue_mux_a to replace elements from muxer with new ones, and then resume the flow.
A timeout is set in the main function, and inside its callback function probes are added onto source pads of GstElement h264 and aac, respectively.

===========================================================================
typedef struct _CustomData {
  GMainLoop *main_loop;  /* GLib's Main Loop */
  GstElement *pipeline_main;
  gulong probe_v;
  gulong probe_a;
} CustomData;

GstPadProbeReturn on_probe_v_cb(GstPad *pad, GstPadProbeInfo *info, gpointer user_data)
{
  g_print("event_probe_v\n");
  CustomData *data = (CustomData*)user_data;
  // data->probe_v = GST_PAD_PROBE_INFO_ID(info);

  g_print("probe_return_v\n");
  return GST_PAD_PROBE_OK;
}

GstPadProbeReturn on_probe_a_cb(GstPad *pad, GstPadProbeInfo *info, gpointer user_data)
{
  g_print("event_probe_a\n");
  CustomData *data = (CustomData*)user_data;
  // data->probe_a = GST_PAD_PROBE_INFO_ID(info);

  g_print("probe_return_a\n");
  return GST_PAD_PROBE_OK;
}

gboolean on_timeout(gpointer arg) {
  g_print("timer timeout\n");
  CustomData *data = (CustomData*)arg;

  GstElement *bin;
  GstPad *pad;

  bin = gst_bin_get_by_name(GST_BIN(data->pipeline_main), "queue_mux_h264");
  pad = gst_element_get_static_pad(bin, "src");
  data->probe_v = gst_pad_add_probe(pad, GST_PAD_PROBE_TYPE_BLOCK_DOWNSTREAM, on_probe_v_cb, arg, NULL);
  gst_object_unref(pad);

  bin = gst_bin_get_by_name(GST_BIN(data->pipeline_main), "queue_mux_aac");
  pad = gst_element_get_static_pad(bin, "src");
  data->probe_a = gst_pad_add_probe(pad, GST_PAD_PROBE_TYPE_BLOCK_DOWNSTREAM, on_probe_a_cb, arg, NULL);
  gst_object_unref(pad);

  g_print("timeout_return\n");
  return FALSE;
}

int main(int argc, char *argv[]) {
  ...
  CustomData data;
  ...
  g_timeout_add(3000, on_timeout, &data);
  ...
}
===========================================================================

EOS will be fired through muxer--queue-filesink in any of the probe callback functions. In filesink's probe callback function, the muxer-queue-filesink will be replaced, and then probes will be removed to resume the flow
.
The PROBLEM now is that once the src pad of either queue_mux_v or queue_mux_a get blocked, the pipeline seems to be blocked as well. I cannot see the g_print inside the callback function of another probe.
E.g. output of the program is
===========================================================================
timer timeout
timeout_return
event_probe_v
probe_return_v
===========================================================================

However, What I expect is
===========================================================================
timer timeout
timeout_return
event_probe_v
probe_return_v
event_probe_a
probe_return_a
===========================================================================

How can I solve the problem?
Many thanks!!!

[Vivia Nikolaidou]

Hi,

Have you looked at the splitmuxsink element? Looks like it will do
what you're trying to do with the pad probes.

If that doesn't help:

1) When you return PAD_PROBE_OK from a blocking pad probe, it will
continue to block.

2) Have you considered what will happen if the splitting will happen
at a frame that's not a keyframe? In that case, the beginning of the
next file will be corrupted. splitmuxsink will solve that issue for
you.

Best regards,

Vivia

On 9 March 2017 at 08:21, MichaelHsu170 <[hidden email]> wrote:

> Hi all,
>
> My pipeline is illustrated as the following.
>
> ===========================================================================
>
> videotestsrc--convert--queue--h264--queue_mux_v--muxer--queue--filesink
> audiotestsrc--convert--resample--queue--aac--queue_mux_a--
> ===========================================================================
>
> I need to save the video/audio streaming into different files, splited by a
> fixed time interval, so I block both of the src pads of GstElement
> queue_mux_v and queue_mux_a to replace elements from muxer with new ones,
> and then resume the flow.
> A timeout is set in the main function, and inside its callback function
> probes are added onto source pads of GstElement h264 and aac, respectively.
>
> ===========================================================================
> typedef struct _CustomData {
>   GMainLoop *main_loop;  /* GLib's Main Loop */
>   GstElement *pipeline_main;
>   gulong probe_v;
>   gulong probe_a;
> } CustomData;
>
> GstPadProbeReturn on_probe_v_cb(GstPad *pad, GstPadProbeInfo *info, gpointer
> user_data)
> {
>   g_print("event_probe_v\n");
>   CustomData *data = (CustomData*)user_data;
>   // data->probe_v = GST_PAD_PROBE_INFO_ID(info);
>
>   g_print("probe_return_v\n");
>   return GST_PAD_PROBE_OK;
> }
>
> GstPadProbeReturn on_probe_a_cb(GstPad *pad, GstPadProbeInfo *info, gpointer
> user_data)
> {
>   g_print("event_probe_a\n");
>   CustomData *data = (CustomData*)user_data;
>   // data->probe_a = GST_PAD_PROBE_INFO_ID(info);
>
>   g_print("probe_return_a\n");
>   return GST_PAD_PROBE_OK;
> }
>
> gboolean on_timeout(gpointer arg) {
>   g_print("timer timeout\n");
>   CustomData *data = (CustomData*)arg;
>
>   GstElement *bin;
>   GstPad *pad;
>
>   bin = gst_bin_get_by_name(GST_BIN(data->pipeline_main), "queue_mux_h264");
>   pad = gst_element_get_static_pad(bin, "src");
>   data->probe_v = gst_pad_add_probe(pad,
> GST_PAD_PROBE_TYPE_BLOCK_DOWNSTREAM, on_probe_v_cb, arg, NULL);
>   gst_object_unref(pad);
>
>   bin = gst_bin_get_by_name(GST_BIN(data->pipeline_main), "queue_mux_aac");
>   pad = gst_element_get_static_pad(bin, "src");
>   data->probe_a = gst_pad_add_probe(pad,
> GST_PAD_PROBE_TYPE_BLOCK_DOWNSTREAM, on_probe_a_cb, arg, NULL);
>   gst_object_unref(pad);
>
>   g_print("timeout_return\n");
>   return FALSE;
> }
>
> int main(int argc, char *argv[]) {
>   ...
>   CustomData data;
>   ...
>   g_timeout_add(3000, on_timeout, &data);
>   ...
> }
> ===========================================================================
>
> EOS will be fired through muxer--queue-filesink in any of the probe callback
> functions. In filesink's probe callback function, the muxer-queue-filesink
> will be replaced, and then probes will be removed to resume the flow
> .
> The PROBLEM now is that once the src pad of either queue_mux_v or
> queue_mux_a get blocked, the pipeline seems to be blocked as well. I cannot
> see the g_print inside the callback function of another probe.
> E.g. output of the program is
> ===========================================================================
> timer timeout
> timeout_return
> event_probe_v
> probe_return_v
> ===========================================================================
>
> However, What I expect is
> ===========================================================================
> timer timeout
> timeout_return
> event_probe_v
> probe_return_v
> event_probe_a
> probe_return_a
> ===========================================================================
>
> How can I solve the problem?
> Many thanks!!!
>
>
>
> --
> View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Pipeline-freeze-after-multiple-pad-probe-tp4682132.html
> Sent from the GStreamer-devel mailing list archive at Nabble.com.
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[MichaelHsu170]

Hi

I've tried it. It's working.
Thank you so much!