[gst-devel] The best way to control a plugin from application?

[joh]

Hi Tim,

Thank you for the quick and precise answers.

I have another fundamental question.  When should I use g_signal_x or
gst_message_x in my plug-in to emit a signal? I guess only difference at the
application is handling the signal at specific callback function or bus
message handler.

The gstreamer app. developers' guide said, bus message passing is
asynchronous to pipeline. Which means time critical operation should not be
controlled through bus messages. Then, what about the g_signal_ ? Does it
guarantee the synchronization between pipeline and application? (execute a
callback function within the pipeline thread?)

I am very new to linux and gobject programing. Please teach me.

Thank you,
Jusitn




On Thu, Jun 25, 2009 at 1:31 AM, Tim-Philipp Müller <t.i.m at zen.co.uk> wrote:

> On Wed, 2009-06-24 at 17:27 -0700, joh wrote:
>
> Hi,
>
> > I am writing a plugin which processes multiple streams upon request of
> > application.
> >
> > For example, my plugin has a list which contains three video streams.
> > Initially, the plugin processes one stream, but not all of them. When
> > my application "some how" requests other streams to the plugin, then
> > it should start to running the other streams.
>
> It sounds like request pads might be what you're looking for. You should
> be able to add/remove request sink pads while the pipeline is running if
> implemented properly. tee, adder and videomixer support that, for
> example (IIRC).
>
>
> > Here is the question: how can I let the plugin start to work while
> > main pipeline is running?
> > I was thinking about the way setting a property, so that it triggers
> > the action. However, the property is not supposed to be used for this
> > purpose. Right? Are there better ways to do this?
>
> It depends. You could use it for this purpose (it could be an 'active
> streams' bitmask, for example, which isn't really much different from
> setting the active audio stream in playbin via a property).
>
> An alternative are 'action signals' where the app/caller uses
> g_signal_emit_by_name (element, "do-something", arguments) -
> appsrc/appsink in -base and camerabin in -bad use these to trigger
> certain actions, for example.
>
> If it's a static plugin/element that is part of your application (and
> not installed into the system gstreamer plugin directory) then you may
> just as well expose API/functions to control it directly though. Nothing
> wrong with that IMHO.
>
>  Cheers
>  -Tim
>
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20090625/0447d795/attachment.htm>