New adventures in 0.11 and python

Christian Fredrik Kalager Schaller uraeus at linuxrising.org
Mon Jan 30 03:04:46 PST 2012


Hi Thomas,
Yeah, you are seeing some of the same type of issues that we all faced,
a combination of missing annotations in GStreamer and GI bugs. Some
things got fixed just before the hackfest like
(https://bugzilla.gnome.org/show_bug.cgi?id=666098)

and some are still open as you see in the bugs Peter and Tim linked too.

I think part of the challenge is that until know there hasn't been a
strong push for GStreamer+Gobject-introspection (with either 0.10 or
0.11) and thus there is a lot of work that needs doing. Also I think it
is fair to say that gobject-introspection has been developed with
primarily GTK+ in mind, so we are finding a lot of missing features and
bugs in gobject-introspection since we are not always doing things 100%
like GTK+. 

Hopefully with yourself, Peter, Edward, Sebastian, Thibault, Jason and
myself all testing and trying to help bugfix the introspection stuff we
can get it up and running stably soon. Also Will Thompson and Tomeu
Vizoso might be willing to help us with fixes/patches for
gobject-introspection itself.

As for filing bug reports, I think you should, I know how frustrating it
is to file bug reports when 'nothing' works, but since we all use it
different things, I think we can not rely on issues being fixed and
resolved without a bug report (and preferably a patch).

Christian


On Sun, 2012-01-29 at 16:38 +0100, Thomas Vander Stichele wrote:
> Hi everyone,
> 
> after last week's hackfest, where I almost completed a refactoring of
> multisocketsink and multifdsink, I wanted to test my changes from Python
> to make sure things work.
> 
> However, I run into a few small issues that seem so simple to hit I'd be
> surprised if no one else has hit them.  I'm not sure if anyone else
> seriously used 0.11 with python? 
> 
> I checked out transmageddon's gtk3 branch, but it doesn't use some of
> the things that I use and see problems with (parse_launch,
> GST_CLOCK_TIME_NONE, ...)
> 
> I can't find a pitivi branch anywhere using 0.11 - it'd be nice if
> people shared what work they did during the hackfest and where it can be
> found for inspiration.
> 
> A list of issues I ran into:
> 
> 1) parse_launch
> 
> e = Gst.parse_launch("fakesrc"); print e
> 
> just segfaults.  Looking inside gdb, the object python is trying to
> print doesn't contain a valid GObject.  Does this work for anyone else ?
> 
> If I change transfer-ownership from full to none, things work, so there
> must be a leak somewhere.
> 
> 2) get_state
> 
> get_state now always requires the timeout parameter.
> Gst.CLOCK_TIME_NONE ought to mean 'infinite'; instead I get:
> 
>   File "/home/thomas/Downloads/multi.py", line 32, in <module>
>     print pipeline_src.get_state(timeout=Gst.CLOCK_TIME_NONE)
>   File
> "/home/thomas/gst/0.11/prefix/lib64/python2.7/site-packages/gi/types.py", line 43, in function
>     return info.invoke(*args, **kwargs)
> ValueError: -1 not in range 0 to 18446744073709551615
> 
> (this is similar to some of the _NONE mess in gst-python 0.10 IIRC)
> 
> If I change the .gir file manually to specify that the type of that
> constant is guint64 instead of gint, my code works.  However, I can't
> figure out how to annotate that in gstclock.h  Value: (whatever) works
> to change the value, but I doubt Type: guint64 is parsed correctly
> there.  Is it possible to do this at all ? Is anyone else able to call
> get_state with infinite timeout ?
> 
> 3) For some reason, changing the state from python claims success, but
> the C-level code doesn't actually go through the state change function
> of the subclass.  I am adding prints right now to figure out where it
> might be going wrong.
> 
> These problems are so basic, triggered by four line files, that I'm not
> sure if it yet makes sure to file bug reports.  I want to check first if
> anyone else is getting anything useful done with python and 0.11 at the
> moment, or if I will have to dive in and learn about gir, pygobject, and
> annotations....
> 
> Thomas
> 
> 
> 
> 




More information about the gstreamer-devel mailing list