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.