[gst-devel] stuck pipeline
Dan Taylor
dtaylor at startrac.com
Thu Apr 9 01:07:05 CEST 2009
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?
More information about the gstreamer-devel
mailing list