2005-11-10 15:07:46 +00:00
|
|
|
API/ABI
|
|
|
|
-------
|
2005-03-22 11:32:59 +00:00
|
|
|
|
2006-05-10 13:53:48 +00:00
|
|
|
- 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.
|
2005-03-22 11:32:59 +00:00
|
|
|
|
2007-08-07 09:56:08 +00:00
|
|
|
- make gst_pad_push_event() return a GstFlowReturn so that we can resend
|
|
|
|
NEWSEGMENT and other events.
|
|
|
|
|
2005-10-28 18:14:24 +00:00
|
|
|
- GstEvent, GstMessage register like GstFormat or GstQuery.
|
2005-11-03 20:14:24 +00:00
|
|
|
|
2005-11-09 12:01:46 +00:00
|
|
|
- query POSITION/DURATION return accuracy. Just a flag or accuracy percentage.
|
|
|
|
|
2006-05-10 13:53:48 +00:00
|
|
|
- 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
|
2008-11-04 16:10:04 +00:00
|
|
|
ideally handle those cases more efficiently too. Some ideas are in
|
|
|
|
docs/design/draft-framestep.txt
|
2005-11-15 15:44:46 +00:00
|
|
|
|
2006-05-10 13:53:48 +00:00
|
|
|
- use | instead of + as divider in serialization of Flags
|
|
|
|
(gstvalue/gststructure)
|
2005-11-10 15:07:46 +00:00
|
|
|
|
2007-08-07 09:56:08 +00:00
|
|
|
- rethink how we handle dynamic replugging wrt segments and other events that
|
2007-11-06 10:21:01 +00:00
|
|
|
already got pushed and need to be pushed again. Might need GstFlowReturn from
|
|
|
|
gst_pad_push_event().
|
2007-08-07 09:56:08 +00:00
|
|
|
|
2007-11-06 10:21:01 +00:00
|
|
|
- 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.
|
|
|
|
|
2007-08-07 09:56:08 +00:00
|
|
|
- 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.
|
|
|
|
|
2007-08-24 21:53:39 +00:00
|
|
|
- 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).
|
|
|
|
|
2007-10-22 15:37:43 +00:00
|
|
|
- Make serialisation of structures more consistent, readable and nicer code-wise.
|
|
|
|
|
2007-11-06 10:21:01 +00:00
|
|
|
- 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.
|
2008-10-10 14:31:03 +00:00
|
|
|
* the same goes for segment seeks that don't push in-band EOS events. Maybe
|
|
|
|
segment seeks should also send an EOS event when they're done.
|
2007-11-06 10:21:01 +00:00
|
|
|
* 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.
|
|
|
|
|
2008-07-31 13:06:56 +00:00
|
|
|
- rethink the way we do upstream renegotiation. Currently it's done with
|
|
|
|
pad_alloc but this has many issues such as only being able to suggest 1 format
|
|
|
|
and the need to allocate a buffer of this suggested format (some elements such
|
|
|
|
as capsfilter only know about the format, not the size). We would ideally like
|
|
|
|
to let upstream renegotiate a new format just like it did when it started.
|
|
|
|
This could, for example, easily be triggered with a RENEGOTIATE event.
|
|
|
|
|
2008-11-05 11:17:24 +00:00
|
|
|
- Remove the XML serialisation stuff.
|
|
|
|
|
2008-12-15 15:27:06 +00:00
|
|
|
- Remove the result format value in queries.
|
|
|
|
|
2007-02-15 11:32:02 +00:00
|
|
|
|
2005-11-10 15:07:46 +00:00
|
|
|
IMPLEMENTATION
|
|
|
|
--------------
|
|
|
|
|
2006-04-28 12:58:15 +00:00
|
|
|
- implement more QOS, see part-qos.txt.
|
2005-11-19 18:28:40 +00:00
|
|
|
|
|
|
|
- implement BUFFERSIZE.
|
2005-11-10 15:07:46 +00:00
|
|
|
|
2007-11-06 10:21:01 +00:00
|
|
|
- implement pad_block with probes? see above.
|
2005-11-23 13:14:46 +00:00
|
|
|
|
2005-11-10 15:07:46 +00:00
|
|
|
|
|
|
|
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? Do we do this automatically or let the app handle this?
|
|
|
|
|