[Gstreamer-bugs] Re: gstqueue.c: on a full queue, writer thread not unblocked if upstream queue flushed

[Benjamin Otte]

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
>
>