[gst-devel] Re: [gst-cvs] company gstreamer: gstreamer/gst/

[Benjamin Otte]

On 9 Apr 2003, Wim Taymans wrote:

> > - added functions for setting/getting locked state of elements.
> > gst_element_lock_state syncs the pads state with the state of its parent.
>
> The LOCKED_STATE was supposed to be a flag on the element,
> setting/clearing the flag is not supposed to trigger an action on the
> element but merely instruct the parent container to not bother changing
> the state of the element.
>
> Also, the unlock_state function could be implemented with:
>
>   GST_FLAG_UNSET (element, GST_ELEMENT_STATE_LOCKED);
>   gst_element_set_state (element,
>                          gst_element_get_state (
>                            gst_element_get_parent (element)));
>
It's basically implemented that way. I modeled it after
gst_bin_change_state, where the bin tries to reset the old state when a
state change fails.

> The later function could be wrapped in
>
>   gst_element_sync_state_with_parent (element);
>
> which could be more usefull IMO.
>
I wasn't sure if we wanted to do explicit state sync or if this should be
done implicitly while changing locked_state.
I also wasn't sure if we want one function for locking and a seperate
function for unlocking the state, or if we'd just use
  gst_element_set_locked_state (element, locked_state)
I modeled it after gtk, where they support two functions for every flag.

> Do we really need all these new methods, they don't really add
> functionality.. You know I don't like methods and code that don't add
> functionality (== bloat).
>
I think it's a bad idea if applications (and locking state should be done
by applications mostly, right?) set flags directly on elements, because
we'll never be able to use flags with side effects then.

> The requirement that pads should be linked in the PAUSED state is a
> scheduler decision, in fact, the optimal scheduler can perfectly link
> PLAYING elements (if not, it's a bug). This breaks gnonlin. We might
> need a scheduler property, though, so that the app can figure out what
> is supported and what is going to give best performance.
>
I always assumed that linking is only supported in PAUSED or below. I
learned this from one of you guys when writing the autoplugger, that
pauses everytime before linking.
In fact the current code base enforces this by not activating pads when
they are linked. (I only added these checks, because i kept getting
GST_PAS_IS_ACTIVE failed messages and had to hunt it down to this fact.)
So if we do indeed support linking in PLAYING, we should make sure it
works and remove these checks.
But I think it is very bad if an app has to figure out if it has to pause
the elements before linking. This should be done automatically by the lib
or it should be enforced.

> Can you please discuss these things first before commiting.
>
These changes all seemed obvious and needed to me, like bugfixes. I
wouldn't just commit any significant changes.
Sorry., that they weren't.

Benjamin