[gst-devel] stuck pipeline

[Dan T. <dt...@st...>]

I still haven't been able to pin down how the not having the specified
program number in a transport stream blocks normal glib timers and
idles.

I am trying something different, and need some hints.

If a specified program number is NOT present in a transport stream
Program Association Table (PAT), then the demultiplexer never adds
source pads, so sending an EOS (which is somewhat logical) doesn't go
anywhere.

I can/have generated a signal, but the signal handler is part of the
pipeline, so it cannot set the pileline to GST_STATE_NULL (and, since
the timers and idles are not working, it cannot schedule a separate
event).

I've tried using the signal handler to send an EOS to the as-yet
disconnected downstream parts of the pipeline, but that is getting error
messages:

  event = gst_event_new_eos ();

  if (audio_backend != NULL) {
    GstPad *unlinked_pad = gst_bin_find_unlinked_pad (audio_backend,
GST_PAD_SINK);

    if (unlinked_pad != NULL) {
      fprintf(stderr, "%s: sending EOS to audio_backend\n",
__FUNCTION__);
      gst_pad_send_event(unlinked_pad, event);
    } else {
      fprintf(stderr, "%s: no unlinked pad in audio_backend\n",
__FUNCTION__);
    }
  }

  /* same checks/calls for video backend */

  gst_event_unref (event);

gives me the following output:

cb_pnum_missing: sending EOS to audio_backend
cb_pnum_missing: sending EOS to video_backend

(avMediaDaemon:28762): GStreamer-CRITICAL **: gst_mini_object_unref:
assertion `mini_object->refcount > 0' failed

(avMediaDaemon:28762): GLib-GObject-WARNING **: invalid unclassed
pointer in cast to `GstMiniObject'

(avMediaDaemon:28762): GStreamer-CRITICAL **: gst_mini_object_unref:
assertion `mini_object->refcount > 0' failed

Any ideas, either why the lack of a program within a transport stream
hangs a glib main loop or how I can shut down the stuck pipeline?