New adventures in 0.11 and python

[Tim-Philipp Müller]

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
gobject-introspection/pygi bug:

 https://bugzilla.gnome.org/show_bug.cgi?id=657202


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

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:

 commit 795e836ce3e63b2382be0cb5981f014bb061263e
 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
> annotations....

There's also https://bugzilla.gnome.org/show_bug.cgi?id=657640 and
possibly some more reports, fwiw.

Cheers
 -Tim