[gst-devel] Queue Flow Control req'd by GstBaseSink or GST_BUFFER_TIMESTAMP problems?

Marco Ballesio gibrovacco at gmail.com
Thu Nov 4 11:01:10 CET 2010


Hi,

On Thu, Nov 4, 2010 at 11:35 AM, HaroldJRoth <dlafferty at gmail.com> wrote:

> GstBaseSink doesn't drop the buffers.  If it did, the queue element would
> not be able to fill up.


right.


> I'm pretty sure that the "sync" is set to false.
>

if you're using the default value, it's TRUE. You may try and set the
max-lateness property but using GST_CLOCK_TIME_NONE for your timestamps
makes the basesink log out a message (you can see it with
GST_DEBUG=basesink:5) and not to drop anything.


> So, I'm guessing that my GstBaseSink specialisation does not properly pull
> an element out of the queue buffer.  Either my GstBaseSink should signal
> that its ready to take another, or my GstBaseSink should signal that an
> item
> has been removed.  Currently, my GstBaseSink carries out the default
> behaviour, which results in it getting Paused by what I beleive to be a
> signal coming from the queue.
>

it's likely that basesink behaves that way because of the timestamps you're
feeding it with and its default working mode. Either you set your sink's
sync property to FALSE or (better) you  fix the timestamps in the source
element.


>
> BTW, do you know of a mechanism for viewing the signal processing in the
> GstBaseSink?
>

GST_DEBUG=basesink:5 is the best I'm aware of. You can also do like
gst-launch and connect an handler to the deep-notify signal in your pipeline
(you'll get plenty of data).

http://www.gstreamer.net/data/doc/gstreamer/head/gstreamer/html/GstObject.html#GstObject-deep-notify

Regards


>
>
>
> Marco Ballesio wrote:
> >
> >> E.g.
> >>
> >> GstBuffer * buffer = gst_buffer_new();
> >> GST_BUFFER_SIZE (buffer) = g_data_packet.pkt_len;
> >> GST_BUFFER_MALLOCDATA (buffer) = (guint8*)g_malloc
> >> (g_data_packet.pkt_len);
> >> GST_BUFFER_DATA (buffer) = GST_BUFFER_MALLOCDATA (buffer);
> >>
> >> GST_DEBUG ("feed buffer %p, len -%u", buffer, g_data_packet.pkt_len);
> >>
> >> // @todo change to memcpy or something sensible
> >> for (int i = 0 ; i < g_data_packet.pkt_len; i++) {
> >>        GST_BUFFER_DATA(buffer)[i] = g_data_packet.data[i];
> >> }
> >> GST_BUFFER_TIMESTAMP(buffer)   =GST_CLOCK_TIME_NONE;
> >>
> >
> > I suggest you to fix this event if the "sync=false" works , unless it is
> > really what you want.
> >
> >
> >>
> >> of b) should I revise the GstBaseSink to restart the pipeline?  (Don't
> >> know
> >> what the code would look like)
> >>
> >
> > I'm not a great expert about dynamic pipelines, but afaik you should add
> > all
> > the elements when the pipeline is in NULL (or PAUSED) state, then trigger
> > the state changes to PLAYING.
> >
> > At least in my experience, violations may bring you to unpredictable
> > results
> > (and extra-hackish-code to write for manually dealing with state
> changes).
> >
> > Regards
> >
> >
>
> The elements in my pipeline are fixed.  I don't add or remove elements.  I
> am talking about sending a signal from the GstBaseSink to it upstream, and
> adjacent, queue.  However, I don't think I can get away with telling the
> queue to state transition from PAUSED to PLAYING, as its buffer is full.
> --
> View this message in context:
> http://gstreamer-devel.966125.n4.nabble.com/Queue-Flow-Control-req-d-by-GstBaseSink-or-GST-BUFFER-TIMESTAMP-problems-tp3025912p3026734.html
> Sent from the GStreamer-devel mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
> David G. Thomson, author of the best-selling book "Blueprint to a
> Billion" shares his insights and actions to help propel your
> business during the next growth cycle. Listen Now!
> http://p.sf.net/sfu/SAP-dev2dev
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20101104/192f8720/attachment.htm>


More information about the gstreamer-devel mailing list