-TODO:
------
-
-short term API stability
-------------------------
-
-Changes that probably impact the API, carefull discussion (IRC) + design doc is required
-before changes are accepted.
-
-target release ! description
- !
- ? ! expose and API to query the supported seek formats/flags on
- ! 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)
- !
- ? ! add event for segment playback/looping and seeking (docs/random/wtay/segments)
- ! (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)
- !
- ? ! implement user defined GstFormat values, make a format factory etc..
- ! (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 :))
-
-
-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 (longterm) optimisations
---------------------------------
-
-These optimisations can be done without changing the existing API.
-
-
- ? ! 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)
- !
projects / platform / upstream / gstreamer.git / blobdiff