mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-11-11 20:01:35 +00:00
a1cde30977
Original commit message from CVS: * docs/design/part-TODO.txt: * docs/design/part-segments.txt: * docs/design/part-streams.txt: Small updates.
78 lines
3.3 KiB
Text
78 lines
3.3 KiB
Text
API/ABI
|
|
-------
|
|
|
|
- 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.
|
|
|
|
- make gst_pad_push_event() return a GstFlowReturn so that we can resend
|
|
NEWSEGMENT and other events.
|
|
|
|
- GstEvent, GstMessage register like GstFormat or GstQuery.
|
|
|
|
- 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.
|
|
|
|
- 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.
|
|
|
|
- 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.
|
|
|
|
|
|
IMPLEMENTATION
|
|
--------------
|
|
|
|
- implement more QOS, see part-qos.txt.
|
|
|
|
- implement BUFFERSIZE.
|
|
|
|
- implement pad_block with probes.
|
|
|
|
|
|
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?
|
|
|