New adventures in 0.11 and python

Jason Gerard DeRose jderose at novacut.com
Mon Jan 30 11:41:36 PST 2012


My Novacut porting branch is here:

https://code.launchpad.net/~jderose/novacut/gst0.11

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.

On Sun, Jan 29, 2012 at 8:38 AM, Thomas Vander Stichele <
thomas at apestaart.org> 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
>
>
>
>
> --
>
> too tired to eat
> too hungry to sleep
>
> savon - Saving your work to svn
> https://apestaart.org/thomas/trac/
>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20120130/73efc1e4/attachment.htm>


More information about the gstreamer-devel mailing list