mirrors/gstreamer
mirrors/gstreamer
1
1
Fork 0
mirror of https://gitlab.freedesktop.org/gstreamer/gstreamer.git synced 2024-07-10 00:25:53 +00:00
Code Issues 1 Projects Releases Wiki Activity

design: live-source: improve grammar and add missing markup

Browse source
This commit is contained in:
Reynaldo H. Verdejo Pinochet 2016-12-24 00:15:21 -08:00
parent b333c4c0fa
commit e0e4bf4bdb
1 changed files with 15 additions and 15 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

30
markdown/design/live-source.md
View file

@ -3,13 +3,13 @@
A live source is a source that cannot be arbitrarily `PAUSED` without
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
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.
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
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
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
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
performing a blocking wait.
## Scheduling
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.
Live sources will not produce data in the `PAUSED` state. They block in
the `get_range()` 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
The live source timestamps its data with the time of the clock when
the data was captured. Normally, it will take some time to capture
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.
The latency is the time it takes to construct one buffer of data. This
latency is exposed with a `LATENCY` query.
The latency is the time it takes to construct one buffer of data and it's
exposed with a `LATENCY` query.
See [latency](design/latency.md)
## 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
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.
starting from `running_time` 0.