index ae51a46d16c73765f0d8c45bbdae85002b632b1b..a3813bdc06067fdde80be6d9ea8c7f7704079974 100644 (file)
(gstvalue/gststructure)
- rethink how we handle dynamic replugging wrt segments and other events that
- already got pushed and need to be pushed again.
+ 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
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
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 BUFFERSIZE.
-- implement pad_block with probes.
+- implement pad_block with probes? see above.
DESIGN