mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-10-07 11:12:17 +00:00
design: live-source: improve grammar and add missing markup
This commit is contained in:
parent
b333c4c0fa
commit
e0e4bf4bdb
1 changed files with 15 additions and 15 deletions
|
@ -3,13 +3,13 @@
|
||||||
A live source is a source that cannot be arbitrarily `PAUSED` without
|
A live source is a source that cannot be arbitrarily `PAUSED` without
|
||||||
losing data.
|
losing data.
|
||||||
|
|
||||||
A live source such as an element capturing audio or video need to be
|
A live source such as an element capturing audio or video, needs to be
|
||||||
handled in a special way. It does not make sense to start the dataflow
|
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
|
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
|
between going from `PAUSED` to `PLAYING`, making the previously captured
|
||||||
buffers irrelevant.
|
buffers irrelevant.
|
||||||
|
|
||||||
A live source therefore only produces buffers in the PLAYING state. This
|
A live source therefore only produces buffers in the `PLAYING` state. This
|
||||||
has implications for sinks waiting for a buffer to complete the preroll
|
has implications for sinks waiting for a buffer to complete the preroll
|
||||||
state since such a buffer might never arrive.
|
state since such a buffer might never arrive.
|
||||||
|
|
||||||
|
@ -18,36 +18,36 @@ the bin/pipeline that this element will not be able to produce data in
|
||||||
the `PAUSED` state. `NO_PREROLL` should be returned for both READY→PAUSED
|
the `PAUSED` state. `NO_PREROLL` should be returned for both READY→PAUSED
|
||||||
and PLAYING→PAUSED.
|
and PLAYING→PAUSED.
|
||||||
|
|
||||||
When performing a get\_state() on a bin with a non-zero timeout value,
|
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
|
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.
|
because otherwise, the `get_state()` function would block on the sinks.
|
||||||
|
|
||||||
A gstbin therefore always performs a zero timeout get\_state() on its
|
A gstbin therefore always performs a zero timeout `get_state()` on its
|
||||||
elements to discover the `NO_PREROLL` (and ERROR) elements before
|
elements to discover the `NO_PREROLL` (and ERROR) elements before
|
||||||
performing a blocking wait.
|
performing a blocking wait.
|
||||||
|
|
||||||
## Scheduling
|
## Scheduling
|
||||||
|
|
||||||
Live sources will not produce data in the paused state. They block in
|
Live sources will not produce data in the `PAUSED` state. They block in
|
||||||
the getrange function or in the loop function until they go to PLAYING.
|
the `get_range()` function or in the loop function until they go to PLAYING.
|
||||||
|
|
||||||
## Latency
|
## Latency
|
||||||
|
|
||||||
The live source timestamps its data with the time of the clock at the
|
The live source timestamps its data with the time of the clock when
|
||||||
time the data was captured. Normally it will take some time to capture
|
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
|
the first sample of data and the last one. This means that when the
|
||||||
buffer arrives at the sink, it will already be late and will be dropped.
|
buffer arrives at the sink, it will already be late and will be dropped.
|
||||||
|
|
||||||
The latency is the time it takes to construct one buffer of data. This
|
The latency is the time it takes to construct one buffer of data and it's
|
||||||
latency is exposed with a `LATENCY` query.
|
exposed with a `LATENCY` query.
|
||||||
|
|
||||||
See [latency](design/latency.md)
|
See [latency](design/latency.md)
|
||||||
|
|
||||||
## Timestamps
|
## Timestamps
|
||||||
|
|
||||||
Live sources always timestamp their buffers with the running\_time of
|
Live sources always timestamp their buffers with the `running_time` of
|
||||||
the pipeline. This is needed to be able to match the timestamps of
|
the pipeline. This is needed to be able to match the timestamps of
|
||||||
different live sources in order to synchronize them.
|
different live sources in order to synchronize them.
|
||||||
|
|
||||||
This is in contrast to non-live sources, which timestamp their buffers
|
This is in contrast to non-live sources, which timestamp their buffers
|
||||||
starting from running\_time 0.
|
starting from `running_time` 0.
|
||||||
|
|
Loading…
Reference in a new issue