Hello Ronald,
On Mon, 17 Jan 2005 22:48:39 +0100, Ronald S. Bultje
<rbultje@...> wrote:
> On Mon, 2005-01-17 at 18:34, ecmproute wrote:
> > 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.
>
> No, not across elements. Elements can, at best, implement an 'unlinked'
> signal handler, but this is A) hardly used and B) not blocking in any
> way.
>
> However, what can make a difference is pipeline buildup, that is, if the
> pipeline is still iterating. If a pad is unlinked, the scheduler will
> rebuild groups (since one group was divided in two) while still
> iterating, which can implicate a lot of locks, interrupts and other
> things, that can take up to seconds to resolve (depending on the
> element). Therefore, you want to unlink in PAUSED.
This is the exact info that is required. In fact, if you can, you can
cut paste the exact words
in the application development manual for the section regarding
linking and unlinking elements.
But I guess app dev manual is not exhaustive. The best
place in IMO is the API reference section for gst_element_unlink or
specifically gst_pad_unlink. Because we are not talking of this API
alone. And this kind of information does not have to be plugin
specific, right?
Providing this kind of information will also help build
test cases for gstreamer. I know it is a huge effort, but my point is
that in the long run, this will also help you avoid a good number of
questions in IRC and mails that have already been answered by you
guys.
And you are the only people out there who knows the
exact behaviour as you are the designers, and developers.
>
> Ronald
> --
> Ronald S. Bultje <rbultje@...>
>
>
--
Scorproy
|