How to predict which properties will be live-changeable ?

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

How to predict which properties will be live-changeable ?

Florent THIERY-2
Hi

I have started developing an utility named gst-gengui [1], whose aim
is to help people test their plugins, or simply live-control pipelines
(think of ladspa elements for instance).

In other terms, when you put in ./gst-gengui audiotestsrc name=src !
ladspa-hard-gate name=filter ! audioconvert ! alsasink, you can
control some parameters right away.

What it does is basically look for specially named elements in a
pipeline (written in gst-launch-like syntax or from a separate config
file), inspect the elements (gets the elements' properties
caracteristics like type, min, max, ...) and create a GUI composed of
type-specific widgets. For instance, for gobject.TYPE_INT, it will
create a value changing widget whose callback is to call
element.set_property("property", new_value).

This works really nice for instance for elements like videobalance:
changing the brightness value is applied at once.

However, for other parameters like bitrate or filesrc locations,  the
pipeline needs restarting. Is there any way to predict/detect if an
element needs pipeline restarting for parameter changing ? I can of
course use some hard-coded info like a static array defining
properties that need restarting after value changes, but it could be
better to embed this kind of info in the plugins themselves.

Are there any plans for this kind of extension for the properties
object ? Maybe there already is something ? Should i systematically
restart pipelines on value change (a bit sad for live processing
though...) ?

Also, thanks for any feedback on this project.

Cheers

Florent


[1] http://code.google.com/p/gst-gengui/

------------------------------------------------------------------------------
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: How to predict which properties will be live-changeable ?

Tim-Philipp Müller-2
On Sun, 2009-04-05 at 20:11 +0200, Florent wrote:

> However, for other parameters like bitrate or filesrc locations,  the
> pipeline needs restarting. Is there any way to predict/detect if an
> element needs pipeline restarting for parameter changing ? I can of
> course use some hard-coded info like a static array defining
> properties that need restarting after value changes, but it could be
> better to embed this kind of info in the plugins themselves.
>
> Are there any plans for this kind of extension for the properties
> object ? Maybe there already is something ? Should i systematically
> restart pipelines on value change (a bit sad for live processing
> though...) ?

Looks like you want this:
http://bugzilla.gnome.org/show_bug.cgi?id=571559

Cheers
 -Tim



------------------------------------------------------------------------------
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: How to predict which properties will be live-changeable ?

David Schleef-2
In reply to this post by Florent THIERY-2
On Sun, Apr 05, 2009 at 08:11:08PM +0200, Florent wrote:
> I have started developing an utility named gst-gengui [1], whose aim
> is to help people test their plugins, or simply live-control pipelines
> (think of ladspa elements for instance).

I was planning to add something like this to gst-gtk-widgets and
call it gst-launch-gtk or similar.  If your stuff was gtk-based,
I'd recommend adding it there.



dave...


------------------------------------------------------------------------------
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: How to predict which properties will be live-changeable ?

Florent THIERY-2
In reply to this post by Tim-Philipp Müller-2
> Looks like you want this:
> http://bugzilla.gnome.org/show_bug.cgi?id=571559

Okay, great, so there will such an extension...

------------------------------------------------------------------------------
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: How to predict which properties will be live-changeable ?

Florent THIERY-2
In reply to this post by David Schleef-2
> I was planning to add something like this to gst-gtk-widgets and
> call it gst-launch-gtk or similar.

Oh, i didn't know of this. Does your project involve more than just
the player widget ?

My project is based on candies/clutter, which is somewhat close to gtk
(but gl). I will try to see if i can do both. But clutter opens a lot
of interesting possibilities for OSD, animations, custom graphical
widgets ... And ultimately, touch control.

Thanks for your comments...

Florent

------------------------------------------------------------------------------
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: How to predict which properties will be live-changeable ?

David Schleef-2
On Sun, Apr 05, 2009 at 09:53:36PM +0200, Florent wrote:
> > I was planning to add something like this to gst-gtk-widgets and
> > call it gst-launch-gtk or similar.
>
> Oh, i didn't know of this. Does your project involve more than just
> the player widget ?

Not currently.  Just telling you what I was thinking about doing.
The gst-launch-gtk tool is getting more important since osxvideosink
no longer works in non-GstXOverlay mode.

> My project is based on candies/clutter, which is somewhat close to gtk
> (but gl). I will try to see if i can do both. But clutter opens a lot
> of interesting possibilities for OSD, animations, custom graphical
> widgets ... And ultimately, touch control.

I've always assumed that we'd eventually have a bunch of gst-widgets
packages for gtk, qt, etc., as people write them.  Obviously, they
will likely have lots of code that is nearly identical, so it would
make sense to develop them collaboratively and copy/modify code
freely.



dave...


------------------------------------------------------------------------------
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: How to predict which properties will be live-changeable ?

Stefan Sauer
In reply to this post by Florent THIERY-2
Florent schrieb:

>> Looks like you want this:
>> http://bugzilla.gnome.org/show_bug.cgi?id=571559
>>    
>
> Okay, great, so there will such an extension...
>
> ------------------------------------------------------------------------------
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>  
I was once wondering also if we could mark up string-properties in away
to tell that they are file-names or uris.

Btw. buzztard generates UIs for gstreamer plugins. So if you make a
gtk-version I'll contribute. I use spin buttons for ints, sliders for
float/double, comboboxes for enums, checkboxes for boolean and entries
for strings.

Stefan

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: How to predict which properties will be live-changeable ?

Florent THIERY-2
> I was once wondering also if we could mark up string-properties in away
> to tell that they are file-names or uris.

Isn't the property's name itself (location / uri) sufficiently
standard to use it as identifier ?

> Btw. buzztard generates UIs for gstreamer plugins.

Do you say that it also uses an introspection mecanism
(pipeline->get_plugins->get_properties->create_widgets_for_properties)?

>So if you make a
> gtk-version I'll contribute. I use spin buttons for ints, sliders for
> float/double, comboboxes for enums, checkboxes for boolean and entries
> for strings.

Great, i'll try do do the same with gtk then :) Will keep you posted !

Florent

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: How to predict which properties will be live-changeable ?

Stefan Sauer
Florent schrieb:
>> I was once wondering also if we could mark up string-properties in away
>> to tell that they are file-names or uris.
>
> Isn't the property's name itself (location / uri) sufficiently
> standard to use it as identifier ?

its a bit weak. how do you know that location is not an uri, or that its not
e.g. the location in the sense of a geo coordinate.

>
>> Btw. buzztard generates UIs for gstreamer plugins.
>
> Do you say that it also uses an introspection mecanism
> (pipeline->get_plugins->get_properties->create_widgets_for_properties)?

this is the code
http://buzztard.svn.sourceforge.net/viewvc/buzztard/trunk/buzztard/src/ui/edit/machine-properties-dialog.c?revision=2336&view=markup

and these are two sample images
http://buzztard.svn.sourceforge.net/viewvc/buzztard/trunk/buzztard/docs/help/bt-edit/C/figures/machine-properties.png?revision=2085&view=markup
http://www.buzztard.org/index.php/File:Bt-edit-0.4.0-01.png

>
>> So if you make a
>> gtk-version I'll contribute. I use spin buttons for ints, sliders for
>> float/double, comboboxes for enums, checkboxes for boolean and entries
>> for strings.
>
> Great, i'll try do do the same with gtk then :) Will keep you posted !
>
> Florent
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel


------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: How to predict which properties will be live-changeable ?

Florent THIERY-2
Hello,

I spent some time this week-end on doing a gtk app for gst-gengui, and
i must say it was both very quick to do and efficient. It's my first
gtk app, and i'm already loving it :)

>>> gtk-version I'll contribute. I use spin buttons for ints, sliders for
>>> float/double, comboboxes for enums, checkboxes for boolean and entries
>>> for strings.

I used spin and scale widgets for numbers (int/floats are supported),
fileselector popup for location (if you use a filesrc in your
pipeline), comboboxes for enums, checkboxes for enums and entries for
strings. Thanks for the hints :)

You can see a screenshot at http://code.google.com/p/gst-gengui/

I used the following for enums, and i fear it is not clean at all :

if property.__gtype__.has_value_table:
   values = property.enum_class.__enum_values__
   for index in values:
       self.values_list.append(values[index].value_name)

(code: EnumProperty in gstintrospector.py). What's the right way to
get the number/values correspondances for enums in python ?

About the non-live-changeable parameters, i just use a condition for
theoraenc bitrate as an example (i stop and restart the pipeline
between the parameter change) and it works but is a bit dirty. What's
strange is that you can change the value of bitrate for theoraenc
(using set_property), the new value is the correct one (i do a
get_property after changing the parameter), but of course no real
change. Maybe if the plugin refused a parameter change, i could
determine (try/except) if you can change the property on the fly. I
think i'll stick to an elements list while waiting for the new spec to
be added and all the plugins ported. Also, does anyone know why the
default bitrate value (and reported real value) for theoraenc bitrate
is 0 ?

Last, i have some performance and stability problems with the
automatic video embedding for multi-video pipelines (i used the
remuxer.py example from pygst doc for the embedding):
- sometimes, the videos are being redirected only when i click on the app itself
- sometimes, the videos have black borders, sometimes not
- sometimes, there is an artifact (videotestsrc texture portion remains)
- i sometimes get bad segfaults/stacktraces
- performance is poor (when i fullsize the window, widgets are not
updated, etc...)
- this doesn't happen on simpler pipelines
- using queues don't change anything

Could someone take a look and confirm these problems ? If there are
better/safer ways to embed the video textures for multi-redirections,
i'd be glad to fix this.

@David: how can i use the gtk video widget you have done from pygtk ?

>> Isn't the property's name itself (location / uri) sufficiently
>> standard to use it as identifier ?
> its a bit weak. how do you know that location is not an uri, or that its not
> e.g. the location in the sense of a geo coordinate.

Hm. Do you intend to create a dedicated data type for local resources ?

Thanks for any help regarding testing/debugging/features suggestions.

Florent

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: How to predict which properties will be live-changeable ?

David Schleef-2
On Mon, Apr 13, 2009 at 10:33:51PM +0200, Florent wrote:
> @David: how can i use the gtk video widget you have done from pygtk ?

Write python bindings for it.  Shouldn't be too difficult.



dave...


------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel