The best way to control a plugin from application?

[joh-4]

Hi all!

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 streasms to the plugin, then it should start to running the other streams.

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?

By the way, I do know that I can setup mutiple bins and let them process each stream independetly. However, it is not my option right now.

Thank you in advance!

--Justin



------------------------------------------------------------------------------

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Tim-Philipp Müller-2]

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[joh-4]

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 <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

------------------------------------------------------------------------------

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Tim-Philipp Müller-2]

On Thu, 2009-06-25 at 14:19 -0700, joh wrote:

> 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?)

Yes, signal callbacks are always called synchronously in the same thread
context as the g_signal_emit(). Messages posted on the bus are usually
processed asynchronously by the application, but may be intercepted
synchronously as well if needed. One advantage of signals is that the
emitting code can collect a return value, this is not possible with
messages, they're always one-way. When to use what is mostly a matter of
taste. If in doubt, you should probably use a message; even if they're
processed asynchronously, that's usually still fast enough. Depends on
your exact use case of course.

Cheers
 -Tim



------------------------------------------------------------------------------
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel