X-Git-Url: http://review.tizen.org/git/?a=blobdiff_plain;f=TODO;h=e69de29bb2d1d6434b8b29ae775ad8c2e48c5391;hb=dac5966da6a0f53d0443dfa1ac239289028c415d;hp=b549ee26791ad16fba19c7b3ae5942276c74ae4d;hpb=4802fe1caa341adeee16c7a67e642afca6a2b243;p=platform%2Fupstream%2Fgstreamer.git diff --git a/TODO b/TODO index b549ee2..e69de29 100644 --- a/TODO +++ b/TODO @@ -1,158 +0,0 @@ -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. - | (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) - !