<div dir="ltr"><div>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.</div><div><div><br></div><div>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).<br>
</div></div><div>But this did not work and it takes me way to long to implement something with this functionality (and it feels like a hack).<br></div><div><br></div><div>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.<br>
</div><div><br></div><div>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).</div>
<div>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".</div><div>Actually GST_STATE_PLAYING should be renamed to GST_STATE_DATAFLOW_ACTIVE, and GST_STATE_PAUSED to GST_STATE_DATAFLOW_POSSIBLE.</div>
<div>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.</div><div><br></div><div>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,</div>
<div>that has dynamic parameters or properties and signals for pausing/resuming/seeking/skipping/gaps/loops etc.</div><div><br></div><div>What do you think?</div></div>