source: trunk/third/gstreamer/TODO @ 18714

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)
               !
    ?          ! create a design doc for a timecache implementation, 
               !  (docs/wtay/random/timecache)
               !  (API: MEDIUM, needs lots of discussion, plugin implementation MEDIUM to HARD)
               !
    ?          ! 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 :))
               

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)

midterm feature enhancement
---------------------------
   
    ?          | Define and implement a syntax in gst_parse to handle filtered pad connections.
               | (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)
               !