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

[Marco Ballesio]

Hi,

On Thu, Nov 4, 2010 at 1:32 PM, HaroldJRoth <dlafferty at gmail.com> wrote:
..snip..


>
> That said, I took your advice on the GST_DEBUG, and found my GstBaseSink
> blocked in the preroll.  E.g.
>
> basesink gstbasesink.c:1914:gst_base_sink_get_sync_times:<videoSnoop> [00m
> got times start: 0:00:00.000000000, stop: 0:00:00.040000000, do_sync 1
> basesink gstbasesink.c:2197:gst_base_sink_do_preroll:<videoSnoop> [00m
> prerolling object 0x7ff498185c30
> basesink gstbasesink.c:2984:gst_base_sink_preroll_object:<videoSnoop> [00m
> prerolling object 0x7ff498185c30
> basesink gstbasesink.c:2148:gst_base_sink_wait_preroll:<videoSnoop> [00m
> waiting in preroll for flush or PLAYING
>
> so you're not successfully completing the transition to PLAYING state
because you're prerolling. You may try and implement the virtual method
preroll to make it returning GST_FLOW_OK.


>
> Since I set the overall pipeline to PLAYING, I'm confused why a PLAYING
> message is not received.
>
>
A pipeline goes to playing when all of its elements complete the transition
to that state. In your case the sink element does not complete the
transition because it waits for prerolling to complete forever. The reason
for this is, quite obviously, because it can't synchronise to the clock as
described here:

http://www.gstreamer.net/data/doc/gstreamer/head/gstreamer-libs/html/GstBaseSink.html

(search for "prerolling correctly" ;)

again, I suggest you to properly set the timestamps in your buffer, but
maybe just implementing the preroll() virtual function will do the trick
here.


>
> BTW, do you know of any sample 'render' implementations.


Imo no "real" sinks could handle properly the clock sync with the timestamps
you're passing. Btw, if you like challenges, I think fakesink is the closest
thing to what you need:

http://cgit.freedesktop.org/gstreamer/gstreamer/tree/plugins/elements/gstfakesink.c



> Mine does not seem
> to release the GstBuffer after it is called.  Nor does it do any internal
> locking.  E.g
>
> static GstFlowReturn render (GstBaseSink *sink, GstBuffer* buf) {
>  GstTaMediaSnoop *mediaSnoop;
>  mediaSnoop = GST_TAMEDIASNOOP (sink);
>
>  //Dump the frame on the heap
>  gchar *bufferData = malloc(buf->size + 8);
>  if(!bufferData) {
>    GST_WARNING("Warning - taMediaSnoop element could not malloc data\n");
>    return GST_FLOW_ERROR;
>  }
>  memcpy(bufferData, buf->data, buf->size);
>

I don't know what actually your app is supposed to do, but maybe referencing
the buffer passed from the pipeline and unreferencing it after the
application is done would save you from extra mallocs + memory copies
(indeed you'll need some more signaling from the app).

Btw maybe an appsink would even be simpler in this case.

Regards


>  guint64 timestamp = GST_BUFFER_TIMESTAMP(buf);
>  memcpy(bufferData + buf->size, &timestamp, 8);
>
>  //And tell the application where it is
>  g_signal_emit(G_OBJECT(mediaSnoop), signalIds[FRAME_READY_SIGNAL], 0,
> buf->size, bufferData);
>  //NOTE: It is left to the application to free the frame when it is done!
>  //gst_buffer_unref(buf);
>
>  /* just push out the incoming buffer without touching it */
>  return GST_FLOW_OK;
> }





>
> --
> View this message in context:
> http://gstreamer-devel.966125.n4.nabble.com/Queue-Flow-Control-req-d-by-GstBaseSink-or-GST-BUFFER-TIMESTAMP-problems-tp3025912p3026862.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/9465ecea/attachment.htm>