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

[HaroldJRoth]

Marco Ballesio wrote:
> 
> Hi,
> 
> On Wed, Nov 3, 2010 at 8:24 PM, HaroldJRoth <dlafferty at gmail.com> wrote:
> 
>>
>> I'm working with a custom plugin that extends GstBaseSink.  I add this
>> and
>> a
>> queue to my pipeline.  E.g.
>>
>> gst_bin_add(GST_BIN(mGstPipeline), mVideoQueue);
>> gst_bin_add(GST_BIN(mGstPipeline), mVideoSnoop);
>> gst_element_link(mVideoQueue, mVideoSnoop);
>>
>> I link this queue/GstBaseSink pair to a decodebin2 manually when a video
>> pad
>> appears.  E.g.
>>
>> mDecoderOutput = gst_element_factory_make("decodebin2", "decoder");
>> g_signal_connect(mDecoderOutput, "new-decoded-pad",
>> G_CALLBACK(cb_newpad),
>> this);
>>
>> The difficulty I find is that my GstBaseSink causes the pipeline to
>> pause.
>> It doesn't grab the buffers and so the queue fills up.  This pauses the
>> stream both upstream and downstream.
>>
>> What I'm wondering is whether this is
>>
>> a)  Because I'm using an appsrc, but I'm not setting the timestamp
>> properly.
>>
> 
> likely basesink is dropping the buffers. What if you sent your sink's
> property "sync" to false?
> 

GstBaseSink doesn't drop the buffers.  If it did, the queue element would
not be able to fill up.  I'm pretty sure that the "sync" is set to false. 
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.

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



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.