index af73ca13b0333938ad865d2aad5d42742e476dd6..a3813bdc06067fdde80be6d9ea8c7f7704079974 100644 (file)
+API/ABI
+-------
-- changing an object's name after construction is not allowed. Checks are performed
- when adding objects to parents that no duplicate names are used, changing the name
- to a duplicate name after adding it is therefore allowed and voids internal
- consistency.
+- implement return values from events in addition to the gboolean. This should
+ be done by making the event contain a GstStructure with input/output values,
+ similar to GstQuery. A typical use case is performing a non-accurate seek to a
+ keyframe, after the seek you want to get the new stream time that will
+ actually be used to update the slider bar.
-- only emit EOS in PLAYING. Make sure elements reemit the EOS message when going to
- PLAYING again.
+- make gst_pad_push_event() return a GstFlowReturn so that we can resend
+ NEWSEGMENT and other events.
-- implement return values from events in addition to the gboolean. This should be
- done by making the event contain a GstStructure with input/output values, similar
- to GstMessage.
+- GstEvent, GstMessage register like GstFormat or GstQuery.
-- implement iterators for traversing elements upstream or dowstream.
+- query POSITION/DURATION return accuracy. Just a flag or accuracy percentage.
+
+- add some sort of time/frame stepping functionality, either with a flag on
+ the seek event or some new seek event type. The idea would be to operate on
+ the current playback position instead of the current configured segment when
+ doing the seek.
+ Idea is that frame stepping forwards can be done in the sinks, ie, just
+ dropping N frames/time, sending more complicated queries upstream which can
+ ideally handle those cases more efficiently too.
+
+- use | instead of + as divider in serialization of Flags
+ (gstvalue/gststructure)
+
+- rethink how we handle dynamic replugging wrt segments and other events that
+ already got pushed and need to be pushed again. Might need GstFlowReturn from
+ gst_pad_push_event().
+
+- keep track of seeks with a counter so that we can match seek events received
+ in the demuxer srcpads. This is needed because a normal seek on a pipeline
+ will send the seek event on all sinks, which results in the demuxer receiving
+ the seek twice. If there is no way to see that the seek is the same, it will
+ perform the seek twice.
+ It would also be nice to have this same sequence number in the segment event
+ that resulted from the seek so that everything seek related can be tracked
+ properly.
+
+- Optimize negotiation. We currently do a get_caps() call when we link pads,
+ which could potentially generate a huge list of caps and all their
+ combinations, we need to avoid generating these huge lists by generating them
+ incrementaly when needed. We can do this with a gst_pad_iterate_caps() call.
+ We also need to incrementally return intersections etc, for this.
+
+- When an element goes to PAUSED there is no way to figure out the running time
+ when this happened. One could think that we can store this time in the
+ base_time field of the element but that causes problems when the element is
+ still using the base_time before really PAUSING. We seem to need a new element
+ field for this. The running time when an element is paused can be usefull to
+ clip late buffers instead of prerolling on them.
+
+- Elements in a bin have no clue about the final state of the parent element
+ since the bin sets the target state on its children in small steps. This
+ causes problems for elements that like to know the final state (rtspsrc going
+ to PAUSED or READY is different in that we can avoid sending the useless
+ PAUSED request).
+
+- Make serialisation of structures more consistent, readable and nicer code-wise.
+
+- When a seekable live source does a flushing seek, it needs a new base_time to
+ timestamp new data. The pipeline however does not know that there is a live
+ source in the pipeline and thus does not select a new base_time automatically.
+ There needs to be a mechanism for a live source to request a new base_time or
+ pipeline restart.
+
+- pad block has several issues:
+ * can't block on selected things, like push, pull, pad_alloc, events, ...
+ * can't check why the block happened. We should also be able to get the item/
+ reason that blocked the pad.
+ * it only blocks on datapassing. When EOS, the block never happens but ideally
+ should because pad block should inform the app when there is no dataflow.
+ * blocking should only happen from one thread. If one thread does pad_alloc
+ and another a push, the push might be busy while the block callback is done.
+ * maybe this name is overloaded. We need to look at some more use cases before
+ trying to fix this.
+
+
+IMPLEMENTATION
+--------------
+
+- implement more QOS, see part-qos.txt.
+
+- implement BUFFERSIZE.
+
+- implement pad_block with probes? see above.
+
+
+DESIGN
+------
- unlinking pads in the PAUSED state needs to make sure the stream thread is not
executing code. Can this be done with a flush to unlock all downstream chain
- functions?
-
-- implement clock selection as explained in part-gstpipeline.txt
+ functions? Do we do this automatically or let the app handle this?