Hi,<br><br><div class="gmail_quote">On Thu, Nov 4, 2010 at 11:35 AM, HaroldJRoth <span dir="ltr"><<a href="mailto:dlafferty@gmail.com">dlafferty@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div><div></div>GstBaseSink doesn't drop the buffers. If it did, the queue element would<br></div> not be able to fill up. </blockquote><div><br>right.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">I'm pretty sure that the "sync" is set to false.<br> </blockquote><div><br>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.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> So, I'm guessing that my GstBaseSink specialisation does not properly pull<br> an element out of the queue buffer. Either my GstBaseSink should signal<br> that its ready to take another, or my GstBaseSink should signal that an item<br> has been removed. Currently, my GstBaseSink carries out the default<br> behaviour, which results in it getting Paused by what I beleive to be a<br> signal coming from the queue.<br></blockquote><div><br>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.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <br> BTW, do you know of a mechanism for viewing the signal processing in the<br> GstBaseSink?<br></blockquote><div><br>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).<br> <br><a href="http://www.gstreamer.net/data/doc/gstreamer/head/gstreamer/html/GstObject.html#GstObject-deep-notify">http://www.gstreamer.net/data/doc/gstreamer/head/gstreamer/html/GstObject.html#GstObject-deep-notify</a><br> <br>Regards<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div><div></div><div class="h5"><br> <br> <br> Marco Ballesio wrote:<br> ><br> >> E.g.<br> >><br> >> GstBuffer * buffer = gst_buffer_new();<br> >> GST_BUFFER_SIZE (buffer) = g_data_packet.pkt_len;<br> >> GST_BUFFER_MALLOCDATA (buffer) = (guint8*)g_malloc<br> >> (g_data_packet.pkt_len);<br> >> GST_BUFFER_DATA (buffer) = GST_BUFFER_MALLOCDATA (buffer);<br> >><br> >> GST_DEBUG ("feed buffer %p, len -%u", buffer, g_data_packet.pkt_len);<br> >><br> >> // @todo change to memcpy or something sensible<br> >> for (int i = 0 ; i < g_data_packet.pkt_len; i++) {<br> >> GST_BUFFER_DATA(buffer)[i] = g_data_packet.data[i];<br> >> }<br> >> GST_BUFFER_TIMESTAMP(buffer) =GST_CLOCK_TIME_NONE;<br> >><br> ><br> > I suggest you to fix this event if the "sync=false" works , unless it is<br> > really what you want.<br> ><br> ><br> >><br> >> of b) should I revise the GstBaseSink to restart the pipeline? (Don't<br> >> know<br> >> what the code would look like)<br> >><br> ><br> > I'm not a great expert about dynamic pipelines, but afaik you should add<br> > all<br> > the elements when the pipeline is in NULL (or PAUSED) state, then trigger<br> > the state changes to PLAYING.<br> ><br> > At least in my experience, violations may bring you to unpredictable<br> > results<br> > (and extra-hackish-code to write for manually dealing with state changes).<br> ><br> > Regards<br> ><br> ><br> <br> </div></div>The elements in my pipeline are fixed. I don't add or remove elements. I<br> am talking about sending a signal from the GstBaseSink to it upstream, and<br> adjacent, queue. However, I don't think I can get away with telling the<br> queue to state transition from PAUSED to PLAYING, as its buffer is full.<br> --<br> View this message in context: <a href="http://gstreamer-devel.966125.n4.nabble.com/Queue-Flow-Control-req-d-by-GstBaseSink-or-GST-BUFFER-TIMESTAMP-problems-tp3025912p3026734.html" target="_blank">http://gstreamer-devel.966125.n4.nabble.com/Queue-Flow-Control-req-d-by-GstBaseSink-or-GST-BUFFER-TIMESTAMP-problems-tp3025912p3026734.html</a><br> <div class="im">Sent from the GStreamer-devel mailing list archive at Nabble.com.<br> <br> ------------------------------------------------------------------------------<br> </div>The Next 800 Companies to Lead America's Growth: New Video Whitepaper<br> David G. Thomson, author of the best-selling book "Blueprint to a<br> Billion" shares his insights and actions to help propel your<br> business during the next growth cycle. Listen Now!<br> <a href="http://p.sf.net/sfu/SAP-dev2dev" target="_blank">http://p.sf.net/sfu/SAP-dev2dev</a><br> <div><div></div><div class="h5">_______________________________________________<br> gstreamer-devel mailing list<br> <a href="mailto:gstreamer-devel@lists.sourceforge.net">gstreamer-devel@lists.sourceforge.net</a><br> <a href="https://lists.sourceforge.net/lists/listinfo/gstreamer-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/gstreamer-devel</a><br> </div></div></blockquote></div><br>