pad: rename GstProbeType and GstProbeReturn to GstPadProbe{Type,Return}
[platform/upstream/gstreamer.git] / docs / random / TODO-pre-0.9
1 TODO:
2 -----
3
4 short term core 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   0.4.1        ! expose and API to query the supported seek formats/flags on
13   (done)       ! 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   0.4.1        ! add event for segment playback/looping and seeking (docs/random/wtay/segments)
19   (done)       !  (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    0.6.0       ! create a design doc for a timecache implementation, 
30    (done)      ! (docs/wtay/random/timecache)
31                !  (API: MEDIUM, needs lots of discussion, plugin implementation MEDIUM to HARD)
32                ! (done: implemented using GstIndex base class + subclasses)
33                !
34     ?          ! implement a QoS event and a policy for handling the event.
35                !  (API: kindof EASY, plugins MEDIUM to very HARD)
36                !
37    0.4.1       ! implement user defined GstFormat values, make a format factory etc..
38    (done)      !  (API: MEDIUM, plugins MEDIUM)
39                !
40     ?          ! strip the API to a bare bones minimal set of functions, leave the automatic
41                ! stuff to the app instead of forcing a policy in the core.
42                ! create a library with useful higher level function for people who don't want
43                ! to deal with the lowlevel stuff.
44                ! (HARD, need to negotiate with people :))
45                !
46     ?          ! use GMarkup to load/save objects, remove dependency on libxml2
47                ! (MEDIUM) breaks API/ABI compatibility
48                !
49                
50
51 shortterm core feature enhancements
52 -----------------------------------
53
54    0.4.1       ! Implement PAD_DISABLED. This requires simple checks in the scheduler so that
55                ! it doesn't try to pull/push data from/to a disabled pad.
56                ! When an element goes to the PAUSED state, all of its pads should be disabled. 
57                ! This should also work for ghostpads.
58                !  (API: MEDIUM to moderatly HARD, requires some scheduler understanding)
59
60
61 short term usability
62 --------------------
63
64 Writing docs is NOT boring, you learn a lot, you get insight in stuff, you help a lot
65 of people, hey! you might even find YOUR book on a shelf in a bookstore!!
66
67
68     ?          ! plugin writers guide
69                ! (we have almost nothing, so any start is welcomed)
70                ! (MEDIUM)
71                !
72     ?          ! app writers guide needs to cover common tips and tricks and HOWTOs
73                ! (MEDIUM)
74  
75
76 short to midterm policy definition
77 ----------------------------------
78
79 Policy definition is closely related to a HOWTO but sometimes needs some thinking.
80
81
82     ?          ! document thread safety guidelines, what stuff needs locking in the app, what
83                ! is done in the core.
84                ! most of this stuff is in the heads of various people but needs to be written
85                ! down so that people get more insights into the design and vision of GStreamer.
86                ! (MEDIUM, some research and discussion needed)
87                !
88     ?          ! a step by step guide to the implementation of various events in a plugin, what can you
89                ! do, when is data passing forbidden etc..
90                ! (MEDIUM, some research needed)
91                ! 
92     ?          ! figure out a policy for the NEW_MEDIA event
93                ! (MEDIUM to HARD)
94                !
95     ?          ! figure out how to better handle clock resync
96                ! (MEDIUM to HARD)
97                !
98             
99
100 midterm feature enhancement
101 ---------------------------
102    
103   0.6.0        | Define and implement a syntax in gst_parse to handle filtered pad connections.
104   (done)       | (MEDIUM)
105                |
106     ?          | Figure out a way to set properties on schedulers (and bins?) from gst_parse.
107                | (MEDIUM)
108                |
109     ?          | Make gst-inspect do inspection of plugins, schedulers, autopluggers, types.
110                | An idea would be to make -inspect output an XML representation of the objects
111                | and use XSLT to transform this into text, HTML, docbook, ...
112                | (MEDIUM to EASY)
113                |
114
115
116 midterm (longterm) optimisations
117 --------------------------------
118
119 These optimisations can be done without changing the existing API.
120
121
122  (in progress) ! implement an optimal scheduler that uses chaining when possible
123                ! (HARD, requires detailed knowledge of element scheduling)
124                !
125     ?          ! alternatively optimisations to the current scheduler can be done such
126                ! as: do nothing when the pipeline structure (or chain) has not changed
127                ! (MEDIUM)
128                !
129     ?          ! GstQueue is a little mess. implement a better queue (lockfree?), refactor
130                ! queueing policy (max buffer, max time, levels etc..)
131                ! (MEDIUM to farily EASY)
132
133
134 longterm feature enhancements
135 -----------------------------
136
137 Various features that are not critical yet.
138
139     ?          ! factory aliases. map a generic name like "videosink" to and actual
140                ! user configurable plugin (aasink, sdlsink, xvideosink, ...)
141                ! (MEDIUM)
142                !
143     ?          ! property proxy in compount elements. not sure if it's possible at all.
144                ! what with elements with the same property?
145                ! (MEDIUM, needs some thinking)
146                !
147     ?          ! Make _pad_select work for muxers
148                ! (MEDIUM to HARD)
149
150
151 needs consensus
152 ---------------
153
154 Some stuff that needs to be figured out based on a pro/con comparison.
155
156     ?          ! can we decide on the fact that downstream events are traveling using the
157                ! scheduler? do we need to reevaluate that design decision?
158                ! (MEDIUM, needs pros vs cons document)
159
160
161 benchmarks
162 ----------
163
164 Benchmarks are always good to get acceptance in a wider comunity or to identify performance 
165 problems that need fixing.
166
167     ?          ! do a latency comparison with popular other frameworks, document GStreamer
168                ! overhead.
169                ! (MEDIUM to somewhat EASY)
170                !