My Novacut porting branch is here: <a href="https://code.launchpad.net/~jderose/novacut/gst0.11">https://code.launchpad.net/~jderose/novacut/gst0.11</a> I tried to make it clear in the commit messages whenever a commit was about a specific API change or PyGI issue. I'm also going to summarize my porting notes later today and will post them here and on my blog. It's getting closer to being usable, though. Peter was a machine fixing all the (transfer floating) issues, which seemed to make up the majority of the trouble using gst 0.11 from PyGI. <div class="gmail_quote"> On Sun, Jan 29, 2012 at 8:38 AM, Thomas Vander Stichele <<a href="mailto:thomas@apestaart.org">thomas@apestaart.org</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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 -- too tired to eat too hungry to sleep savon - Saving your work to svn <a href="https://apestaart.org/thomas/trac/" target="_blank">https://apestaart.org/thomas/trac/</a> _______________________________________________ gstreamer-devel mailing list <a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a> </blockquote></div>