TODO

   1 TODO:
   2 -----
   3
   4 short term API stability
   5 ------------------------
   6
   7 Changes that probably impact the API, carefull discussion (IRC) + design doc is required
   8 before changes are accepted.
   9
  10 target release ! description
  11                !
  12     ?          ! expose and API to query the supported seek formats/flags on
  13                ! pads, somthing like an extra arg to gst_pad_set_convert_function
  14                ! and gst_pad_set_event_function with some function to query the
  15                ! flags and formats. more ideas in docs/random/wtay/query_events
  16                !  (API: medium dificulty)
  17                !
  18     ?          ! add event for segment playback/looping and seeking (docs/random/wtay/segments)
  19                !  (API: medium dificulty, plugins: HARD to very HARD)
  20                !
  21     ?          ! add event to adjust rate (reverse playback, slow motion, frame skipping)
  22                ! (docs/random/wtay/rate_event)
  23                !  (API: medium dificulty, plugins: HARD to very HARD)
  24                !
  25     ?          ! add method in the scheduler to set the entry point (frame stepping?)
  26                ! (docs/random/wtay/scheduler_entry)
  27                !  (API: moderatly EASY, scheduler implementation MEDIUM)
  28                !
  29     ?          ! create a design doc for a timecache implementation,
  30                !  (docs/wtay/random/timecache)
  31                !  (API: MEDIUM, needs lots of discussion, plugin implementation MEDIUM to HARD)
  32                !
  33     ?          ! implement a QoS event and a policy for handling the event.
  34                !  (API: kindof EASY, plugins MEDIUM to very HARD)
  35                !
  36     ?          ! implement user defined GstFormat values, make a format factory etc..
  37                !  (API: MEDIUM, plugins MEDIUM)
  38                !
  39     ?          ! strip the API to a bare bones minimal set of functions, leave the automatic
  40                ! stuff to the app instead of forcing a policy in the core.
  41                ! create a library with usefull higher level function for people who don't want
  42                ! to deal with the lowlevel stuff.
  43                ! (HARD, need to negotiate with people :))
  44
  45
  46 short term usability
  47 --------------------
  48
  49 Writing docs is NOT boring, you learn a lot, you get insight in stuff, you help a lot
  50 of people, hey! you might even find YOUR book on a shelf in a bookstore!!
  51
  52
  53     ?          ! plugin writers guide
  54                ! (we have almost nothing, so any start is welcomed)
  55                ! (MEDIUM)
  56                !
  57     ?          ! app writers guide needs to cover common tips and tricks and HOWTOs
  58                ! (MEDIUM)
  59
  60
  61 short to midterm policy definition
  62 ----------------------------------
  63
  64 Policy definition is closely related to a HOWTO but sometimes needs some thinking.
  65
  66
  67     ?          ! document thread safety guidelines, what stuff needs locking in the app, what
  68                ! is done in the core.
  69                ! most of this stuff is in the heads of various people but needs to be written
  70                ! down so that people get more insights into the design and vision of GStreamer.
  71                ! (MEDIUM, some research and discussion needed)
  72                !
  73     ?          ! a step by step guide to the implementation of various events in a plugin, what can you
  74                ! do, when is data passing forbidden etc..
  75                ! (MEDIUM, some research needed)
  76                !
  77     ?          ! figure out a policy for the NEW_MEDIA event
  78                ! (MEDIUM to HARD)
  79
  80
  81 midterm (longterm) optimisations
  82 --------------------------------
  83
  84 These optimisations can be done without changing the existing API.
  85
  86
  87     ?          ! implement an optimal scheduler that uses chaining when possible
  88                ! (HARD, requires detailed knowledge of element scheduling)
  89                !
  90     ?          ! alternatively optimisations to the current scheduler can be done such
  91                ! as: do nothing when the pipeline structure (or chain) has not changed
  92                ! (MEDIUM)
  93                !
  94     ?          ! GstQueue is a little mess. implement a better queue (lockfree?), refactor
  95                ! queueing policy (max buffer, max time, levels etc..)
  96                ! (MEDIUM to farily EASY)
  97
  98
  99 longterm feature enhancements
 100 -----------------------------
 101
 102 Various features that are not critical yet.
 103
 104     ?          ! factory aliases. map a generic name like "videosink" to and actual
 105                ! user configurable plugin (aasink, sdlsink, xvideosink, ...)
 106                ! (MEDIUM)
 107                !
 108     ?          ! property proxy in compount elements. not sure if it's possible at all.
 109                ! what with elements with the same property?
 110                ! (MEDIUM, needs some thinking)
 111                !
 112     ?          ! Make _pad_select work for muxers
 113                ! (MEDIUM to HARD)
 114
 115
 116 needs consensus
 117 ---------------
 118
 119 Some stuff that needs to be figured out based on a pro/con comparison.
 120
 121     ?          ! can we decide on the fact that downstream events are traveling using the
 122                ! scheduler? do we need to reevaluate that design decision?
 123                ! (MEDIUM, needs pros vs cons document)
 124
 125
 126 benchmarks
 127 ----------
 128
 129 Benchmarks are always good to get acceptance in a wider comunity or to identify performance
 130 problems that need fixing.
 131
 132     ?          ! do a latency comparison with popular other frameworks, document GStreamer
 133                ! overhead.
 134                ! (MEDIUM to somewhat EASY)
 135                !