2005-06-23 10:37:09 +00:00
|
|
|
Live sources
|
|
|
|
|
------------
|
|
|
|
|
|
2007-02-15 11:32:02 +00:00
|
|
|
A live source is a source that cannot be arbitrarily PAUSED without losing
|
|
|
|
|
data.
|
|
|
|
|
|
2005-06-23 10:37:09 +00:00
|
|
|
A live source such as an element capturing audio or video need to be handled
|
|
|
|
|
in a special way. It does not make sense to start the dataflow in the PAUSED
|
|
|
|
|
state for those devices as the user might wait a long time between going from
|
|
|
|
|
PAUSED to PLAYING, making the previously captured buffers irrelevant.
|
|
|
|
|
|
|
|
|
|
A live source therefore only produces buffers in the PLAYING state. This has
|
|
|
|
|
implications for sinks waiting for a buffer to complete the preroll state
|
|
|
|
|
since such a buffer might never arrive.
|
|
|
|
|
|
|
|
|
|
Live sources return NO_PREROLL when going to the PAUSED state to inform the
|
|
|
|
|
bin/pipeline that this element will not be able to produce data in the
|
2007-03-07 17:13:17 +00:00
|
|
|
PAUSED state. NO_PREROLL should be returned for both READY->PAUSED and
|
|
|
|
|
PLAYING->PAUSED.
|
2005-06-23 10:37:09 +00:00
|
|
|
|
|
|
|
|
When performing a get_state() on a bin with a non-zero timeout value, the
|
|
|
|
|
bin must be sure that there are no live sources in the pipeline because else
|
|
|
|
|
the get_state() function would block on the sinks.
|
|
|
|
|
|
|
|
|
|
A gstbin therefore always performs a zero timeout get_state() on its
|
|
|
|
|
elements to discover the NO_PREROLL (and ERROR) elements before performing
|
2005-10-08 16:49:15 +00:00
|
|
|
a blocking wait.
|
2005-06-23 10:37:09 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
Scheduling
|
|
|
|
|
----------
|
|
|
|
|
|
2007-02-15 11:32:02 +00:00
|
|
|
Live sources will not produce data in the paused state. They block in the
|
2005-06-23 10:37:09 +00:00
|
|
|
getrange function or in the loop function until they go to PLAYING.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Latency
|
|
|
|
|
-------
|
|
|
|
|
|
|
|
|
|
The live source timestamps its data with the time of the clock at the
|
|
|
|
|
time the data was captured. Normally it will take some time to capture
|
|
|
|
|
the first sample of data and the last sample. This means that when the
|
|
|
|
|
buffer arrives at the sink, it will already be late and will be dropped.
|
|
|
|
|
|
2006-10-16 13:53:55 +00:00
|
|
|
The latency is the time it takes to construct one buffer of data. This latency
|
2007-02-15 11:32:02 +00:00
|
|
|
is exposed with a LATENCY query.
|
|
|
|
|
|
|
|
|
|
See part-latency.txt.
|
2007-09-11 23:27:42 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
Timestamps
|
|
|
|
|
----------
|
|
|
|
|
|
|
|
|
|
Live sources always timestamp their buffers with the running_time of the
|
|
|
|
|
pipeline. This is needed to be able to match the timestamps of different live
|
|
|
|
|
sources in order to synchronize them.
|
|
|
|
|
|
|
|
|
|
This is in contrast to non-live sources, which timestamp their buffers starting
|
|
|
|
|
from running_time 0.
|
|
|
|
|
|
