a3813bdc06067fdde80be6d9ea8c7f7704079974
[glsdk/gstreamer0-10.git] / docs / design / part-TODO.txt
1 API/ABI
2 -------
4 - implement return values from events in addition to the gboolean. This should
5   be done by making the event contain a GstStructure with input/output values,
6   similar to GstQuery. A typical use case is performing a non-accurate seek to a
7   keyframe, after the seek you want to get the new stream time that will
8   actually be used to update the slider bar.
10 - make gst_pad_push_event() return a GstFlowReturn so that we can resend
11   NEWSEGMENT and other events.
13 - GstEvent, GstMessage register like GstFormat or GstQuery.
15 - query POSITION/DURATION return accuracy. Just a flag or accuracy percentage.
17 - add some sort of time/frame stepping functionality, either with a flag on
18   the seek event or some new seek event type. The idea would be to operate on
19   the current playback position instead of the current configured segment when
20   doing the seek.
21   Idea is that frame stepping forwards can be done in the sinks, ie, just
22   dropping N frames/time, sending more complicated queries upstream which can
23   ideally handle those cases more efficiently too.
25 - use | instead of + as divider in serialization of Flags
26   (gstvalue/gststructure)
28 - rethink how we handle dynamic replugging wrt segments and other events that
29   already got pushed and need to be pushed again. Might need GstFlowReturn from
30   gst_pad_push_event().
32 - keep track of seeks with a counter so that we can match seek events received
33   in the demuxer srcpads. This is needed because a normal seek on a pipeline
34   will send the seek event on all sinks, which results in the demuxer receiving
35   the seek twice. If there is no way to see that the seek is the same, it will
36   perform the seek twice.
37   It would also be nice to have this same sequence number in the segment event
38   that resulted from the seek so that everything seek related can be tracked
39   properly.
41 - Optimize negotiation. We currently do a get_caps() call when we link pads,
42   which could potentially generate a huge list of caps and all their
43   combinations, we need to avoid generating these huge lists by generating them
44   incrementaly when needed. We can do this with a gst_pad_iterate_caps() call.
45   We also need to incrementally return intersections etc, for this.
47 - When an element goes to PAUSED there is no way to figure out the running time
48   when this happened. One could think that we can store this time in the
49   base_time field of the element but that causes problems when the element is
50   still using the base_time before really PAUSING. We seem to need a new element
51   field for this. The running time when an element is paused can be usefull to
52   clip late buffers instead of prerolling on them.
54 - Elements in a bin have no clue about the final state of the parent element
55   since the bin sets the target state on its children in small steps. This
56   causes problems for elements that like to know the final state (rtspsrc going
57   to PAUSED or READY is different in that we can avoid sending the useless
58   PAUSED request).
60 - Make serialisation of structures more consistent, readable and nicer code-wise.
62 - When a seekable live source does a flushing seek, it needs a new base_time to
63   timestamp new data. The pipeline however does not know that there is a live
64   source in the pipeline and thus does not select a new base_time automatically.
65   There needs to be a mechanism for a live source to request a new base_time or
66   pipeline restart.
68 - pad block has several issues: 
69   * can't block on selected things, like push, pull, pad_alloc, events, ...
70   * can't check why the block happened. We should also be able to get the item/
71     reason that blocked the pad. 
72   * it only blocks on datapassing. When EOS, the block never happens but ideally
73     should because pad block should inform the app when there is no dataflow.
74   * blocking should only happen from one thread. If one thread does pad_alloc
75     and another a push, the push might be busy while the block callback is done.
76   * maybe this name is overloaded. We need to look at some more use cases before
77     trying to fix this.
80 IMPLEMENTATION
81 --------------
83 - implement more QOS, see part-qos.txt.
85 - implement BUFFERSIZE.
87 - implement pad_block with probes? see above.
90 DESIGN
91 ------
93 - unlinking pads in the PAUSED state needs to make sure the stream thread is not
94   executing code. Can this be done with a flush to unlock all downstream chain
95   functions? Do we do this automatically or let the app handle this?