mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-11-05 17:09:48 +00:00
c94f6bf5bf
Original commit message from CVS: * docs/design/draft-push-pull.txt: * docs/design/part-MT-refcounting.txt: * docs/design/part-TODO.txt: * docs/design/part-caps.txt: * docs/design/part-events.txt: * docs/design/part-gstbus.txt: * docs/design/part-gstpipeline.txt: * docs/design/part-messages.txt: * docs/design/part-push-pull.txt: * docs/design/part-query.txt: Some more docs.
90 lines
2.5 KiB
Text
90 lines
2.5 KiB
Text
DRAFT push-pull scheduling
|
|
--------------------------
|
|
|
|
Observations:
|
|
|
|
- The main scheduling mode is chain based scheduling where the source
|
|
element pushes buffers through the pipeline to the sinks. this is
|
|
called the push model
|
|
|
|
- In the pull model, some plugin pulls buffers from an upstream peer
|
|
element before consuming and/or pushing them further downstream.
|
|
|
|
|
|
Usages of pull based scheduling:
|
|
|
|
- sinks that pull in data, possibly at fixed intervals driven by some
|
|
hardware device (audiocard, videodevice, ...).
|
|
|
|
- Efficient random access to resources. Especially usefull for certain
|
|
types of demuxers.
|
|
|
|
|
|
API for pull-based scheduling:
|
|
|
|
- an element that wants to pull data from a peer element needs to call
|
|
the pull_range() method. This methods requires an offset and a size.
|
|
It is possible to leave the offset and size at -1, indicating that
|
|
any offset or size is acceptable, this of course removes the advantages
|
|
of getrange based scheduling.
|
|
|
|
|
|
Types of pull based scheduling:
|
|
|
|
- some sources can do random access (file source, ...)
|
|
|
|
- some sources can read a random number of bytes but not at a random
|
|
offset. (audio cards, ...)
|
|
|
|
- some sources can do random access in a range of bytes but not in
|
|
another range. (a caching network source).
|
|
|
|
- some sources can do a fixed size data but without an offset.
|
|
(video sources, ...)
|
|
|
|
|
|
Current scheduling decision:
|
|
|
|
- core selects scheduling type starting on sinks by looking at existence
|
|
of loop function on sinkpad and calling _check_pull_region() on the
|
|
source pad to activate the pads in push/pull mode.
|
|
|
|
- element proxies pull mode pad activation to peer pad.
|
|
|
|
Problems:
|
|
|
|
- core makes a touch desicion without knowing anything about the
|
|
element.
|
|
|
|
|
|
Requirements:
|
|
|
|
- element should be able to select scheduling method itself based on
|
|
how it can use the peer element pull_region. This includes if the
|
|
peer can operate with or without offset/size. This also means that
|
|
the core does not need to select the scheduling method anymore and
|
|
allows for more afficient scheduling methods adjusted for the
|
|
particular element.
|
|
|
|
|
|
Proposition:
|
|
|
|
- pads are activated without the core selecting a method.
|
|
|
|
- pads queries scheduling mode of peer pad. This query is rather
|
|
finegrained and allows the element to know if the peer supports
|
|
offsets and sizes in the get_region function.
|
|
|
|
- pad selects scheduling mode and informs the peer pad of this
|
|
decision.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|