mobile/docs/design/draft-push-pull.txt

   1 DRAFT push-pull scheduling
   2 --------------------------
   3
   4 Status
   5
   6   DRAFT. DEPRECATED by better current implementation.
   7
   8 Observations:
   9
  10   - The main scheduling mode is chain based scheduling where the source
  11     element pushes buffers through the pipeline to the sinks. this is
  12     called the push model
  13
  14   - In the pull model, some plugin pulls buffers from an upstream peer
  15     element before consuming and/or pushing them further downstream.
  16
  17
  18 Usages of pull based scheduling:
  19
  20   - sinks that pull in data, possibly at fixed intervals driven by some
  21     hardware device (audiocard, videodevice, ...).
  22
  23   - Efficient random access to resources. Especially useful for certain
  24     types of demuxers.
  25
  26
  27 API for pull-based scheduling:
  28
  29   - an element that wants to pull data from a peer element needs to call
  30     the pull_range() method. This methods requires an offset and a size.
  31     It is possible to leave the offset and size at -1, indicating that
  32     any offset or size is acceptable, this of course removes the advantages
  33     of getrange based scheduling.
  34
  35
  36 Types of pull based scheduling:
  37
  38   - some sources can do random access (file source, ...)
  39
  40   - some sources can read a random number of bytes but not at a random
  41     offset. (audio cards, ...) Audio cards using a ringbuffer can
  42     however do random access in the ringbuffer.
  43
  44   - some sources can do random access in a range of bytes but not in
  45     another range. (a caching network source).
  46
  47   - some sources can do a fixed size data and without an offset.
  48     (video sources, ...)
  49
  50
  51 Current scheduling decision:
  52
  53   - core selects scheduling type starting on sinks by looking at existence
  54     of loop function on sinkpad and calling _check_pull_range() on the
  55     source pad to activate the pads in push/pull mode.
  56
  57   - element proxies pull mode pad activation to peer pad.
  58
  59 Problems:
  60
  61   - core makes a tough desicion without knowing anything about the
  62     element. Some elements are able to deal with a pull_range()
  63     without offset while others need full random  access.
  64
  65
  66 Requirements:
  67
  68   - element should be able to select scheduling method itself based on
  69     how it can use the peer element pull_range. This includes if the
  70     peer can operate with or without offset/size. This also means that
  71     the core does not need to select the scheduling method anymore and
  72     allows for more efficient scheduling methods adjusted for the
  73     particular element.
  74
  75
  76 Proposition:
  77
  78   - pads are activated without the core selecting a method.
  79
  80   - pads queries scheduling mode of peer pad. This query is rather
  81     finegrained and allows the element to know if the peer supports
  82     offsets and sizes in the get_range function. A proposition for
  83     the query is outlined in draft-query.txt.
  84
  85   - pad selects scheduling mode and informs the peer pad of this
  86     decision.
  87
  88
  89 Things to query:
  90
  91   - pad can do real random access (downstream peer can ask for offset != -1)
  92      - min offset
  93      - suggest sequential access
  94      - max offset
  95      - align: all offsets should be aligned with this value.
  96   - pad can give ranges from A to B length (peer can ask for A <= length <= B)
  97      - min length
  98      - suggested length
  99      - max length
 100
 101 Use cases:
 102
 103   - An audio source can provide random access to the samples queued in its
 104     DMA buffer, it however suggests sequential access method.
 105     An audio source can provide a random number of samples but prefers
 106     reading from the hardware using a fixed segment size.
 107
 108   - A caching network source would suggest sequential access but is seekable
 109     in the cached region. Applications can query for the already downloaded
 110     portion and update the GUI, a seek can be done in that area.
 111
 112   - a live video source can only provide buffers sequentialy. It exposes
 113     offsets as -1. lengths are also -1.
 114
 115
 116
 117
 118
 119