[gst-devel] A few quesions about gstreamer

ecmproute ecmproute at gmail.com
Mon Jan 17 09:35:25 CET 2005


Hello Ronald,

On Mon, 17 Jan 2005 10:13:06 +0100, Ronald S. Bultje
<rbultje at ronald.bitfreak.net> wrote:
> Hi,
> 
> On Sun, 2005-01-16 at 18:52, ecmproute wrote:
> >          One of the things that I am thinking of doing in order to
> > help the spread and use of GStreamer, is to create a simple table, or
> > add in already existing documentation, which would say which API is
> > functional in which states, and what actually happens in terms of
> > states when that API is called. I would make my point clearer with an
> > example, though the example may not be correct:
> > gst_element_unlink:
> > State Information:
> > 1) The two elements to be unlinked should be in X state. If the
> > elements are inside a bin/thread, the state of the container should be
> > Y.
> > 2) If any of the elements/container bin/thread is not in the X state,
> > the operation might fail/the state of both the elements will be taken
> > to X.
> >
> > Now to provide this kind of information, is there any easy way to generalize?
> 
> Those things are currently best solved by trial and error. In playbin, I
> think we can link elements and add elements to groups while in the
> PLAYING state. However, in order to unlink elements and remove elements
> from groups, we have to be in PAUSED (or it'll crash).
> 
Does that mean, for example, the usage and behaviour of
gst_element_unlink might defer across different elements? I understand
that gst_element_unlink basically boils down to gst_pad_unlink, which
might be a function pointer in the element itself. Is there any set of
specific rules in the context of states, that must be implemented by
any element, when it provides a function pointer for api's like
gst_pad_unlink.

> Ronald
> --
> Ronald S. Bultje <rbultje at ronald.bitfreak.net>
> 
> 


-- 
Scorproy




More information about the gstreamer-devel mailing list