mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2025-01-10 17:35:59 +00:00
have a real TODO, move old TODO
Original commit message from CVS: have a real TODO, move old TODO
This commit is contained in:
Thomas Vander Stichele
parent
c903606ae4
commit
a624500066
2 changed files with 175 additions and 169 deletions
174
TODO
174
TODO
|
|
@ -1,170 +1,6 @@
|
|||
TODO:
|
||||
-----
|
||||
TODO
|
||||
----
|
||||
|
||||
short term core API stability
|
||||
-----------------------------
|
||||
|
||||
Changes that probably impact the API, carefull discussion (IRC) + design doc is required
|
||||
before changes are accepted.
|
||||
|
||||
target release ! description
|
||||
!
|
||||
0.4.1 ! expose and API to query the supported seek formats/flags on
|
||||
(done) ! pads, somthing like an extra arg to gst_pad_set_convert_function
|
||||
! and gst_pad_set_event_function with some function to query the
|
||||
! flags and formats. more ideas in docs/random/wtay/query_events
|
||||
! (API: medium dificulty)
|
||||
!
|
||||
0.4.1 ! add event for segment playback/looping and seeking (docs/random/wtay/segments)
|
||||
(done) ! (API: medium dificulty, plugins: HARD to very HARD)
|
||||
!
|
||||
? ! add event to adjust rate (reverse playback, slow motion, frame skipping)
|
||||
! (docs/random/wtay/rate_event)
|
||||
! (API: medium dificulty, plugins: HARD to very HARD)
|
||||
!
|
||||
? ! add method in the scheduler to set the entry point (frame stepping?)
|
||||
! (docs/random/wtay/scheduler_entry)
|
||||
! (API: moderatly EASY, scheduler implementation MEDIUM)
|
||||
!
|
||||
0.6.0 ! create a design doc for a timecache implementation,
|
||||
(done) ! (docs/wtay/random/timecache)
|
||||
! (API: MEDIUM, needs lots of discussion, plugin implementation MEDIUM to HARD)
|
||||
! (done: implemented using GstIndex base class + subclasses)
|
||||
!
|
||||
? ! implement a QoS event and a policy for handling the event.
|
||||
! (API: kindof EASY, plugins MEDIUM to very HARD)
|
||||
!
|
||||
0.4.1 ! implement user defined GstFormat values, make a format factory etc..
|
||||
(done) ! (API: MEDIUM, plugins MEDIUM)
|
||||
!
|
||||
? ! strip the API to a bare bones minimal set of functions, leave the automatic
|
||||
! stuff to the app instead of forcing a policy in the core.
|
||||
! create a library with usefull higher level function for people who don't want
|
||||
! to deal with the lowlevel stuff.
|
||||
! (HARD, need to negotiate with people :))
|
||||
!
|
||||
? ! use GMarkup to load/save objects, remove dependency on libxml2
|
||||
! (MEDIUM) breaks API/ABI compatibility
|
||||
!
|
||||
|
||||
|
||||
shortterm core feature enhancements
|
||||
-----------------------------------
|
||||
|
||||
0.4.1 ! Implement PAD_DISABLED. This requires simple checks in the scheduler so that
|
||||
! it doesn't try to pull/push data from/to a disabled pad.
|
||||
! When an element goes to the PAUSED state, all of its pads should be disabled.
|
||||
! This should also work for ghostpads.
|
||||
! (API: MEDIUM to moderatly HARD, requires some scheduler understanding)
|
||||
|
||||
|
||||
short term usability
|
||||
--------------------
|
||||
|
||||
Writing docs is NOT boring, you learn a lot, you get insight in stuff, you help a lot
|
||||
of people, hey! you might even find YOUR book on a shelf in a bookstore!!
|
||||
|
||||
|
||||
? ! plugin writers guide
|
||||
! (we have almost nothing, so any start is welcomed)
|
||||
! (MEDIUM)
|
||||
!
|
||||
? ! app writers guide needs to cover common tips and tricks and HOWTOs
|
||||
! (MEDIUM)
|
||||
|
||||
|
||||
short to midterm policy definition
|
||||
----------------------------------
|
||||
|
||||
Policy definition is closely related to a HOWTO but sometimes needs some thinking.
|
||||
|
||||
|
||||
? ! document thread safety guidelines, what stuff needs locking in the app, what
|
||||
! is done in the core.
|
||||
! most of this stuff is in the heads of various people but needs to be written
|
||||
! down so that people get more insights into the design and vision of GStreamer.
|
||||
! (MEDIUM, some research and discussion needed)
|
||||
!
|
||||
? ! a step by step guide to the implementation of various events in a plugin, what can you
|
||||
! do, when is data passing forbidden etc..
|
||||
! (MEDIUM, some research needed)
|
||||
!
|
||||
? ! figure out a policy for the NEW_MEDIA event
|
||||
! (MEDIUM to HARD)
|
||||
!
|
||||
? ! figure out how to better handle clock resync
|
||||
! (MEDIUM to HARD)
|
||||
!
|
||||
|
||||
|
||||
midterm feature enhancement
|
||||
---------------------------
|
||||
|
||||
0.6.0 | Define and implement a syntax in gst_parse to handle filtered pad connections.
|
||||
(done) | (MEDIUM)
|
||||
|
|
||||
? | Figure out a way to set properties on schedulers (and bins?) from gst_parse.
|
||||
| (MEDIUM)
|
||||
|
|
||||
? | Make gst-inspect do inspection of plugins, schedulers, autopluggers, types.
|
||||
| An idea would be to make -inspect output an XML representation of the objects
|
||||
| and use XSLT to transform this into text, HTML, docbook, ...
|
||||
| (MEDIUM to EASY)
|
||||
|
|
||||
|
||||
|
||||
midterm (longterm) optimisations
|
||||
--------------------------------
|
||||
|
||||
These optimisations can be done without changing the existing API.
|
||||
|
||||
|
||||
(in progress) ! implement an optimal scheduler that uses chaining when possible
|
||||
! (HARD, requires detailed knowledge of element scheduling)
|
||||
!
|
||||
? ! alternatively optimisations to the current scheduler can be done such
|
||||
! as: do nothing when the pipeline structure (or chain) has not changed
|
||||
! (MEDIUM)
|
||||
!
|
||||
? ! GstQueue is a little mess. implement a better queue (lockfree?), refactor
|
||||
! queueing policy (max buffer, max time, levels etc..)
|
||||
! (MEDIUM to farily EASY)
|
||||
|
||||
|
||||
longterm feature enhancements
|
||||
-----------------------------
|
||||
|
||||
Various features that are not critical yet.
|
||||
|
||||
? ! factory aliases. map a generic name like "videosink" to and actual
|
||||
! user configurable plugin (aasink, sdlsink, xvideosink, ...)
|
||||
! (MEDIUM)
|
||||
!
|
||||
? ! property proxy in compount elements. not sure if it's possible at all.
|
||||
! what with elements with the same property?
|
||||
! (MEDIUM, needs some thinking)
|
||||
!
|
||||
? ! Make _pad_select work for muxers
|
||||
! (MEDIUM to HARD)
|
||||
|
||||
|
||||
needs consensus
|
||||
---------------
|
||||
|
||||
Some stuff that needs to be figured out based on a pro/con comparison.
|
||||
|
||||
? ! can we decide on the fact that downstream events are traveling using the
|
||||
! scheduler? do we need to reevaluate that design decision?
|
||||
! (MEDIUM, needs pros vs cons document)
|
||||
|
||||
|
||||
benchmarks
|
||||
----------
|
||||
|
||||
Benchmarks are always good to get acceptance in a wider comunity or to identify performance
|
||||
problems that need fixing.
|
||||
|
||||
? ! do a latency comparison with popular other frameworks, document GStreamer
|
||||
! overhead.
|
||||
! (MEDIUM to somewhat EASY)
|
||||
!
|
||||
Thomas:
|
||||
- figure out if gstgetbits can be removed; otherwise decide on plugin vs lib
|
||||
- figure out if dataprotocol can be used lib-only; make it install as a lib
|
||||
|
|
|
|||
170
docs/random/TODO-pre-0.9
Normal file
170
docs/random/TODO-pre-0.9
Normal file
|
|
@ -0,0 +1,170 @@
|
|||
TODO:
|
||||
-----
|
||||
|
||||
short term core API stability
|
||||
-----------------------------
|
||||
|
||||
Changes that probably impact the API, carefull discussion (IRC) + design doc is required
|
||||
before changes are accepted.
|
||||
|
||||
target release ! description
|
||||
!
|
||||
0.4.1 ! expose and API to query the supported seek formats/flags on
|
||||
(done) ! pads, somthing like an extra arg to gst_pad_set_convert_function
|
||||
! and gst_pad_set_event_function with some function to query the
|
||||
! flags and formats. more ideas in docs/random/wtay/query_events
|
||||
! (API: medium dificulty)
|
||||
!
|
||||
0.4.1 ! add event for segment playback/looping and seeking (docs/random/wtay/segments)
|
||||
(done) ! (API: medium dificulty, plugins: HARD to very HARD)
|
||||
!
|
||||
? ! add event to adjust rate (reverse playback, slow motion, frame skipping)
|
||||
! (docs/random/wtay/rate_event)
|
||||
! (API: medium dificulty, plugins: HARD to very HARD)
|
||||
!
|
||||
? ! add method in the scheduler to set the entry point (frame stepping?)
|
||||
! (docs/random/wtay/scheduler_entry)
|
||||
! (API: moderatly EASY, scheduler implementation MEDIUM)
|
||||
!
|
||||
0.6.0 ! create a design doc for a timecache implementation,
|
||||
(done) ! (docs/wtay/random/timecache)
|
||||
! (API: MEDIUM, needs lots of discussion, plugin implementation MEDIUM to HARD)
|
||||
! (done: implemented using GstIndex base class + subclasses)
|
||||
!
|
||||
? ! implement a QoS event and a policy for handling the event.
|
||||
! (API: kindof EASY, plugins MEDIUM to very HARD)
|
||||
!
|
||||
0.4.1 ! implement user defined GstFormat values, make a format factory etc..
|
||||
(done) ! (API: MEDIUM, plugins MEDIUM)
|
||||
!
|
||||
? ! strip the API to a bare bones minimal set of functions, leave the automatic
|
||||
! stuff to the app instead of forcing a policy in the core.
|
||||
! create a library with usefull higher level function for people who don't want
|
||||
! to deal with the lowlevel stuff.
|
||||
! (HARD, need to negotiate with people :))
|
||||
!
|
||||
? ! use GMarkup to load/save objects, remove dependency on libxml2
|
||||
! (MEDIUM) breaks API/ABI compatibility
|
||||
!
|
||||
|
||||
|
||||
shortterm core feature enhancements
|
||||
-----------------------------------
|
||||
|
||||
0.4.1 ! Implement PAD_DISABLED. This requires simple checks in the scheduler so that
|
||||
! it doesn't try to pull/push data from/to a disabled pad.
|
||||
! When an element goes to the PAUSED state, all of its pads should be disabled.
|
||||
! This should also work for ghostpads.
|
||||
! (API: MEDIUM to moderatly HARD, requires some scheduler understanding)
|
||||
|
||||
|
||||
short term usability
|
||||
--------------------
|
||||
|
||||
Writing docs is NOT boring, you learn a lot, you get insight in stuff, you help a lot
|
||||
of people, hey! you might even find YOUR book on a shelf in a bookstore!!
|
||||
|
||||
|
||||
? ! plugin writers guide
|
||||
! (we have almost nothing, so any start is welcomed)
|
||||
! (MEDIUM)
|
||||
!
|
||||
? ! app writers guide needs to cover common tips and tricks and HOWTOs
|
||||
! (MEDIUM)
|
||||
|
||||
|
||||
short to midterm policy definition
|
||||
----------------------------------
|
||||
|
||||
Policy definition is closely related to a HOWTO but sometimes needs some thinking.
|
||||
|
||||
|
||||
? ! document thread safety guidelines, what stuff needs locking in the app, what
|
||||
! is done in the core.
|
||||
! most of this stuff is in the heads of various people but needs to be written
|
||||
! down so that people get more insights into the design and vision of GStreamer.
|
||||
! (MEDIUM, some research and discussion needed)
|
||||
!
|
||||
? ! a step by step guide to the implementation of various events in a plugin, what can you
|
||||
! do, when is data passing forbidden etc..
|
||||
! (MEDIUM, some research needed)
|
||||
!
|
||||
? ! figure out a policy for the NEW_MEDIA event
|
||||
! (MEDIUM to HARD)
|
||||
!
|
||||
? ! figure out how to better handle clock resync
|
||||
! (MEDIUM to HARD)
|
||||
!
|
||||
|
||||
|
||||
midterm feature enhancement
|
||||
---------------------------
|
||||
|
||||
0.6.0 | Define and implement a syntax in gst_parse to handle filtered pad connections.
|
||||
(done) | (MEDIUM)
|
||||
|
|
||||
? | Figure out a way to set properties on schedulers (and bins?) from gst_parse.
|
||||
| (MEDIUM)
|
||||
|
|
||||
? | Make gst-inspect do inspection of plugins, schedulers, autopluggers, types.
|
||||
| An idea would be to make -inspect output an XML representation of the objects
|
||||
| and use XSLT to transform this into text, HTML, docbook, ...
|
||||
| (MEDIUM to EASY)
|
||||
|
|
||||
|
||||
|
||||
midterm (longterm) optimisations
|
||||
--------------------------------
|
||||
|
||||
These optimisations can be done without changing the existing API.
|
||||
|
||||
|
||||
(in progress) ! implement an optimal scheduler that uses chaining when possible
|
||||
! (HARD, requires detailed knowledge of element scheduling)
|
||||
!
|
||||
? ! alternatively optimisations to the current scheduler can be done such
|
||||
! as: do nothing when the pipeline structure (or chain) has not changed
|
||||
! (MEDIUM)
|
||||
!
|
||||
? ! GstQueue is a little mess. implement a better queue (lockfree?), refactor
|
||||
! queueing policy (max buffer, max time, levels etc..)
|
||||
! (MEDIUM to farily EASY)
|
||||
|
||||
|
||||
longterm feature enhancements
|
||||
-----------------------------
|
||||
|
||||
Various features that are not critical yet.
|
||||
|
||||
? ! factory aliases. map a generic name like "videosink" to and actual
|
||||
! user configurable plugin (aasink, sdlsink, xvideosink, ...)
|
||||
! (MEDIUM)
|
||||
!
|
||||
? ! property proxy in compount elements. not sure if it's possible at all.
|
||||
! what with elements with the same property?
|
||||
! (MEDIUM, needs some thinking)
|
||||
!
|
||||
? ! Make _pad_select work for muxers
|
||||
! (MEDIUM to HARD)
|
||||
|
||||
|
||||
needs consensus
|
||||
---------------
|
||||
|
||||
Some stuff that needs to be figured out based on a pro/con comparison.
|
||||
|
||||
? ! can we decide on the fact that downstream events are traveling using the
|
||||
! scheduler? do we need to reevaluate that design decision?
|
||||
! (MEDIUM, needs pros vs cons document)
|
||||
|
||||
|
||||
benchmarks
|
||||
----------
|
||||
|
||||
Benchmarks are always good to get acceptance in a wider comunity or to identify performance
|
||||
problems that need fixing.
|
||||
|
||||
? ! do a latency comparison with popular other frameworks, document GStreamer
|
||||
! overhead.
|
||||
! (MEDIUM to somewhat EASY)
|
||||
!
|
||||
Loading…
Reference in a new issue