Is there room for a GstSeekableBin?

[Sven Heyll]

As a general rant about gstreamer: The Gstreamer design seems strongly
influenced by media player applications where one would only ever pause or
seek the whole pipeline.

Actually I thought that I could just set one of possibly many uridecodebins
to "GST_STATE_PAUSED" while the rest of the pipeline continues to
run(PLAYING).
But this did not work and it takes me way to long to implement something
with this functionality (and it feels like a hack).

So when used in a broader sense with very dynamic pipelines, it would be
kind of nice to be able to attach/detach/pause/resume players, recorders,
RTP endpoints, etc in a flexible manner.

Root of my problem might be that the states defined in gstreamer really are
a mix of "low-level" initialisation and "high-level" playback control (as a
result of being historically influenced by being a media player support
library).
I think this is actually a design flaw in gstreamer. The mixture of the
orthognonal aspects "pipeline management, clock distribution, linking" and
"playback/recording control".
Actually GST_STATE_PLAYING should be renamed to GST_STATE_DATAFLOW_ACTIVE,
and GST_STATE_PAUSED to GST_STATE_DATAFLOW_POSSIBLE.
And the play/pause/resume stuff, that in general cannot be a property or
method of all pipeline elements, should be done via dynamic parameters or
object properties.

One could imagine a GstSeekableBin that cares about base-time and
runnning-time calculations, and controls ghost pads that drop or send
silence when appropriate,
that has dynamic parameters or properties and signals for
pausing/resuming/seeking/skipping/gaps/loops etc.

What do you think?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130806/8c7170cc/attachment.html>