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 usefull 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 | ! |
---|