DRAFT push-pull scheduling

Status

DRAFT. DEPRECATED by better current implementation.

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 useful 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 method 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, …) Audio cards using a ringbuffer can however do random access in the ringbuffer.
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 and 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_range() 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 tough desicion without knowing anything about the element. Some elements are able to deal with a pull_range() without offset while others need full random access.

Requirements:

element should be able to select scheduling method itself based on how it can use the peer element pull_range(). 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 efficient 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_range() function. A proposition for the query is outlined in draft-query.txt.
pad selects scheduling mode and informs the peer pad of this decision.

Things to query:

Use cases:

An audio source can provide random access to the samples queued in its DMA buffer, it however suggests sequential access method. An audio source can provide a random number of samples but prefers reading from the hardware using a fixed segment size.
A caching network source would suggest sequential access but is seekable in the cached region. Applications can query for the already downloaded portion and update the GUI, a seek can be done in that area.
a live video source can only provide buffers sequentialy. It exposes offsets as -1. lengths are also -1.