[Gstreamer-bugs] Re: gstqueue.c: on a full queue, writer thread not unblocked if upstream queue flushed
Benjamin Otte
in7y118 at public.uni-hamburg.de
Wed Mar 26 19:14:55 PST 2003
Hi Martin,
Could you (if you use 0.6 and not cvs)
- open a bug about this in bugzilla
- attach this patch (or better yet a patch that signals not_full in
gst_queue_locked_flush (and fix gst_queue_dispose, too))
And if you use current cvs HEAD:
- checkout the patch I just submited to gstqueue.[ch]
And in the future, please use bugzilla or -devel. The gstreamer-maint list
is only for bugzilla notification.
Cheers,
Benjamin
On Wed, 26 Mar 2003, Martin Janzen wrote:
>
> [Not sure this belongs on gstreamer-devel; but let me know if that would
> be a better place for this than gstreamer-maint...]
>
> I ran into a small problem the other day, and I believe it was related
> to a bug in the GStreamer queue. It's pretty trivial, and I have a
> patch; but before I post this to Bugzilla I want to check that I am
> using the framework correctly.
>
> Background: I have an element which extracts PTS (Presentation Time
> Stamp) values from an MPEG-2 transport stream. If a large discontinuity
> in the PTS values occurs, the element needs to adjust its
> PTS-to-GST-clock mapping, and then to flush either the upstream
> (transport buffer) or downstream (frame buffer) queue (or maybe both;
> still under construction!).
>
> Flushing the downstream queue is easy, of course:
>
> gst_pad_push (myelement->srcpad,
> GST_BUFFER (gst_event_new_flush ()));
>
> And if I understand correctly, flushing the upstream one is not much
> more difficult; something like this:
>
> GstPad *peer = gst_pad_get_peer (myelement->sink_pad);
> GstElement *src = gst_pad_get_parent (src);
> if (GST_IS_QUEUE (src)) {
> gst_element_set_state (src, GST_STATE_PAUSED);
> gst_pad_send_event (peer, gst_event_new_flush ());
> gst_element_set_state (src, GST_STATE_PLAYING);
> }
>
> (Arguably this code shouldn't be in my element itself; instead, the
> element could generate a discontinuity notification/signal/event of some
> sort, which causes, um, something else to flush the queue. But for
> testing...)
>
> Anyway, the problem I found is that, if the upstream queue is full and a
> writer thread is blocked waiting for the queue to empty, that thread
> will stay blocked forever.
>
> It seems clear that the gst_queue_handle_src_event() event function
> which flushes the queue should also wake up the writer thread. It's a
> trivial fix -- see attached patch -- and I've tested it successfully;
> but I just want to make sure that sending events upstream as I've done
> above is acceptable practice, and that the GStreamer framework is in
> fact supposed to support this sort of thing. Comments, anyone...?
>
> --
> Martin Janzen
> janzen at pixelmetrix dot com
>
>
More information about the Gstreamer-bugs
mailing list