Hi,<br><br><div class="gmail_quote">On Thu, Nov 4, 2010 at 1:32 PM, HaroldJRoth <span dir="ltr">&lt;<a href="mailto:dlafferty@gmail.com">dlafferty@gmail.com</a>&gt;</span> wrote:<br>..snip..<div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<br>
That said, I took your advice on the GST_DEBUG, and found my GstBaseSink<br>
blocked in the preroll.  E.g.<br>
<br>
basesink gstbasesink.c:1914:gst_base_sink_get_sync_times:&lt;videoSnoop&gt; [00m<br>
got times start: 0:00:00.000000000, stop: 0:00:00.040000000, do_sync 1<br>
basesink gstbasesink.c:2197:gst_base_sink_do_preroll:&lt;videoSnoop&gt; [00m<br>
prerolling object 0x7ff498185c30<br>
basesink gstbasesink.c:2984:gst_base_sink_preroll_object:&lt;videoSnoop&gt; [00m<br>
prerolling object 0x7ff498185c30<br>
basesink gstbasesink.c:2148:gst_base_sink_wait_preroll:&lt;videoSnoop&gt; [00m<br>
waiting in preroll for flush or PLAYING<br>
<br></blockquote><div>so you&#39;re not successfully completing the transition to PLAYING state because you&#39;re prerolling. You may try and implement the virtual method preroll to make it returning GST_FLOW_OK.<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>
Since I set the overall pipeline to PLAYING, I&#39;m confused why a PLAYING<br>
message is not received.<br>
<br></blockquote><div><br>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&#39;t synchronise to the clock as described here:<br>
<br><a href="http://www.gstreamer.net/data/doc/gstreamer/head/gstreamer-libs/html/GstBaseSink.html">http://www.gstreamer.net/data/doc/gstreamer/head/gstreamer-libs/html/GstBaseSink.html</a><br><br>(search for &quot;prerolling correctly&quot; ;)<br>
<br>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.<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 any sample &#39;render&#39; implementations.  </blockquote><div><br>Imo no &quot;real&quot; sinks could handle properly the clock sync with the timestamps you&#39;re passing. Btw, if you like challenges, I think fakesink is the closest thing to what you need:<br>
<br><a href="http://cgit.freedesktop.org/gstreamer/gstreamer/tree/plugins/elements/gstfakesink.c">http://cgit.freedesktop.org/gstreamer/gstreamer/tree/plugins/elements/gstfakesink.c</a><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;">
Mine does not seem<br>
to release the GstBuffer after it is called.  Nor does it do any internal<br>
locking.  E.g<br>
<br>
static GstFlowReturn render (GstBaseSink *sink, GstBuffer* buf) {<br>
  GstTaMediaSnoop *mediaSnoop;<br>
  mediaSnoop = GST_TAMEDIASNOOP (sink);<br>
<br>
  //Dump the frame on the heap<br>
  gchar *bufferData = malloc(buf-&gt;size + 8);<br>
  if(!bufferData) {<br>
    GST_WARNING(&quot;Warning - taMediaSnoop element could not malloc data\n&quot;);<br>
    return GST_FLOW_ERROR;<br>
  }<br>
  memcpy(bufferData, buf-&gt;data, buf-&gt;size);<br></blockquote><div><br>I don&#39;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&#39;ll need some more signaling from the app).<br>
<br>Btw maybe an appsink would even be simpler in this case.<br><br>Regards<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
  guint64 timestamp = GST_BUFFER_TIMESTAMP(buf);<br>
  memcpy(bufferData + buf-&gt;size, &amp;timestamp, 8);<br>
<br>
  //And tell the application where it is<br>
  g_signal_emit(G_OBJECT(mediaSnoop), signalIds[FRAME_READY_SIGNAL], 0,<br>
buf-&gt;size, bufferData);<br>
  //NOTE: It is left to the application to free the frame when it is done!<br>
  //gst_buffer_unref(buf);<br>
<br>
  /* just push out the incoming buffer without touching it */<br>
  return GST_FLOW_OK;<br>
} </blockquote><div><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;"><font color="#888888">
<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-tp3025912p3026862.html" target="_blank">http://gstreamer-devel.966125.n4.nabble.com/Queue-Flow-Control-req-d-by-GstBaseSink-or-GST-BUFFER-TIMESTAMP-problems-tp3025912p3026862.html</a><br>

</font><div><div></div><div class="h5">Sent from the GStreamer-devel mailing list archive at Nabble.com.<br>
<br>
------------------------------------------------------------------------------<br>
The Next 800 Companies to Lead America&#39;s Growth: New Video Whitepaper<br>
David G. Thomson, author of the best-selling book &quot;Blueprint to a<br>
Billion&quot; 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>
_______________________________________________<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>