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

[Marco Ballesio]

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?


> 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


>
>
> --
> View this message in context:
> http://gstreamer-devel.966125.n4.nabble.com/Queue-Flow-Control-req-d-by-GstBaseSink-or-GST-BUFFER-TIMESTAMP-problems-tp3025912p3025912.html
> Sent from the GStreamer-devel mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Achieve Improved Network Security with IP and DNS Reputation.
> Defend against bad network traffic, including botnets, malware,
> phishing sites, and compromised hosts - saving your company time,
> money, and embarrassment.   Learn More!
> http://p.sf.net/sfu/hpdev2dev-nov
> _______________________________________________
> 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/4a019f2b/attachment.htm>