gst_query_parse_latency

[Arnaud Loonstra]

On 05/15/2014 02:15 PM, Nicolas Dufresne wrote:
> Le jeudi 15 mai 2014 à 13:50 +0200, Arnaud Loonstra a écrit :
>> minlat: 0:00:00.033333333/ maxlat: 0:00:00.133333332
>
> Seems fair result. Latency is worst case for min, and the maximum
> latency that can be buffered. It's not the effective latency, which
> should be lower then the min, otherwise we'd be late. So latency will
> not change if the pipepeline is not reconfigured. See
> GST_MESSAGE_LATENCY, for notification of when the latency changes.
>
> Nicolas

So perhaps I understand the latency incorrect. This is than not the time 
it takes for a buffer to reach the end of the pipeline? I wanted to 
calculate the time it takes to mux, encode, etc... As this will take 
time. Is this the latency the latency as a result of first getting the 
data to fill a full frame?

I just added a jpegenc and jpegdec in the pipeline and the latency 
remains the same.

minlat: 0:00:00.033333333/ maxlat: 0:00:00.133333332

Rg,

Arnaud

-- 
w: http://www.sphaero.org
t: http://twitter.com/sphaero
g: http://github.com/sphaero
i: freenode: sphaero_z25