mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-12-16 13:26:36 +00:00
0757f3df2e
Original commit message from CVS: * docs/design/draft-push-pull.txt: * docs/design/draft-query.txt: * gst/base/gstbasesrc.c: (gst_basesrc_get_range_unlocked), (gst_basesrc_start): Added draft for new query API. Added draft for better selecting scheduling methods. Make basesrc ignore length if the subclass does not support it.
91 lines
2.6 KiB
Text
91 lines
2.6 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. A proposition for
|
|
the query is outlined in draft-query.txt.
|
|
|
|
- pad selects scheduling mode and informs the peer pad of this
|
|
decision.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|