<div dir="ltr"><div class="gmail_quote"><div>Hi Nicolas,</div><div>Thanks for the response. That does clear up some confusion. I think I am still having trouble separating when something is a "plugin" API vs an application level API.</div><div><br></div><div>Say I have a pipeline A ! B ! tee name=mytee ! C ! D1 mytee. ! D2</div><div><br></div><div>1. As the pipeline goes to playing state, the pipeline itself will calculate and apply the appropriate latency.</div><div><br></div><div>2. If say, I dynamically remove C, or if it makes more sense, say I change a property on C (and lets assume I do this properly), that *might* result in a message on the pipeline bus of GST_MESSAGE_LATENCY, correct? </div><div><br></div><div>3. At which point, the application could/should check to see if it (the application) needs to distribute a new latency value. The quote is "The application should recalculate and distribute a new latency." So my question is on how the application should recalculate the new latency. Should the application use gst_query_new_latency() on the *pipeline* itself (as an "element")? Or should it be a query explicitly on each sink (D1 & D2)? Or does the application need to query each element in the pipeline directly (like what is automatically done by the pipeline as it first goes to playing state)? Or something else entirely?</div><div><br></div><div>4. Assuming we do step 3 correctly, the application would then use gst_pipeline_set_latency() to distribute the new value, correct?</div><div><br></div><div>Apologies if I'm just missing something obvious and making this harder than it really is.</div><div>Thanks again,</div><div>-jim</div><div><br></div><div> </div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Hi Jim,<br>
<br>
See answers below.<br>
<br>
<br>
Le mar. 15 sept. 2020 17 h 30, jim nualart <<a href="mailto:jim@austinmodern.com" target="_blank">jim@austinmodern.com</a>> a ?crit :<br>
<br>
> Hi All,<br>
><br>
> I'm hoping someone can chime in here with a little bit of explanation, as<br>
> I think I have gotten myself somewhat confused on this topic.<br>
><br>
> I've read the following:<br>
> (from here,<br>
> <a href="https://gstreamer.freedesktop.org/documentation/application-development/advanced/clocks.html#latency-compensation" rel="noreferrer" target="_blank">https://gstreamer.freedesktop.org/documentation/application-development/advanced/clocks.html#latency-compensation</a><br>
> )<br>
> Before the pipeline goes to the PLAYING state, it will, in addition to<br>
> selecting a clock and calculating a base-time, calculate the latency in the<br>
> pipeline. It does this by doing a LATENCY query on all the sinks in the<br>
> pipeline. The pipeline then selects the maximum latency in the pipeline and<br>
> configures this with a LATENCY event.<br>
><br>
> So this is "automatic" and the application itself does not need to be<br>
> involved at this point ... correct so far?<br>
><br>
> Now, what if I want to know what the latency value is (of what was<br>
> configured automatically by the pipeline)?<br>
> Can I use gst_pipeline_get_latency()?<br>
> Am I correct that this function would return the currently *configured*<br>
> pipeline latency?<br>
> Or should I use a query with gst_query_new_latency()?<br>
> Though, I think this function would get me the current *actual* latency<br>
> (vs what is configured), right?<br>
><br>
<br>
The latency query will give you the reported latency. Running that query on<br>
different sink element (that query is executed  sink to source) usually<br>
gives different values. By default, GstPipeline will select the maximum.<br>
<br>
The applied latency is reported through an event. By default the same event<br>
is sent to all sinks, but special application may use different values.<br>
This is why reading the applied latency is not so straight forward.<br>
<br>
<br>
> Finally, if I want to change the latency value, is that done<br>
> via gst_pipeline_set_latency() or gst_query_set_latency() ?<br>
><br>
<br>
The first once will force a global latency to the specified latency. It is<br>
controlled by applications indeed.<br>
<br>
The second is used by elements, when contributing to the latency query.<br>
This a "plugin" API.<br>
<br>
You can also use the latency tracer to get a log of per element reported<br>
latency.<br>
<br>
<br>
GST_TRACERS="latency(flags=reported)" GST_DEBUG=GST_TRACER:7 ...<br>
<br>
<br>
> Much thanks in advance,<br>
> -jim<br>
> _______________________________________________<br>
> gstreamer-devel mailing list<br>
> <a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a><br>
> <a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20200916/8ba848b4/attachment-0001.htm" rel="noreferrer" target="_blank">https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20200916/8ba848b4/attachment-0001.htm</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org" target="_blank">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
<br>
<br>
------------------------------<br>
<br>
End of gstreamer-devel Digest, Vol 116, Issue 31<br>
************************************************<br>
</blockquote></div></div>