gst_query_parse_latency

[Nicolas Dufresne]

Le jeudi 15 mai 2014 à 15:14 +0200, Arnaud Loonstra a écrit :
> 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

There is multiple kind of latency. In GStreamer latency query we only
care about the latency introduced by accumulation. As an example, a
parser may have to accumulate till beginning of next frame before it can
let a frame out. This account for 1 frame latency (which need to be
translated in time).

There also exists the processing latency. That varies a lot on modern
computer, and can also change depending on presence of queues, multiple
CPUs, speed of CPUs and configuration. We don't really measure this
latency. Instead we measure the lateness and use QoS trick to try and
catch up.

Some poeple will use the GST_SCHEDULING log level, to trace all calls to
chain functions. Then you may use log timestamp to measure the
processing time. Note that because of queues, the trace might be
interleaved.

Nicolas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20140515/dcf4a63d/attachment.sig>