New adventures in 0.11 and python
t.i.m at zen.co.uk
Sun Jan 29 09:00:26 PST 2012
On Sun, 2012-01-29 at 16:38 +0100, Thomas Vander Stichele wrote:
> 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.
Should probably be (transfer floating), but also see the following
> 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)
> "/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 ?
Yeah, known issue. I'm sure there was a bug report related to it, but I
can't find it right now. See the following commit:
Author: Peteris Krisjanis <pecisk at gmail.com>
Date: Sat Oct 15 22:52:25 2011 +0300
introspection: add Value annotations for GST_SECOND, GST_MSECOND,
GST_USECOND, GST_NSECOND constants
gobject-introspection won't parse them properly otherwise.
Still need to force the right type though (either GstClockTime or
guint64), but Type: xyz has no effect for me here, so someone with
a newer g-i needs to test this.
Some other defines are also missing, e.g. GST_CLOCK_TIME_NONE.
(The additional commentary in the commit message was by me IIRC, not the
the author of the patch, fwiw.)
IIRC the g-i folks added a way to force a certain value, but that's not
sufficient, we also need to be able to force the right type apparently.
But I wasn't sure if that was fixed in newer g-i versions.
> 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
There's also https://bugzilla.gnome.org/show_bug.cgi?id=657640 and
possibly some more reports, fwiw.
More information about the gstreamer-devel