New adventures in 0.11 and python

[Thomas Vander Stichele]

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
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Tim-Philipp Müller-2]

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 <[hidden email]>
 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

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Peteris Krisjanis-2]

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

Interesting, for this one patch was committed on Thursday:
http://cgit.freedesktop.org/gstreamer/gstreamer/commit/?h=0.11&id=42a6e487c854d9cdcd8e99f0a15cecd53748bd3d

See
http://cgit.freedesktop.org/gstreamer/gstreamer/tree/gst/gstparse.c?h=0.11#n273.

However, maybe that wasn't enough, because there are bunch of
introspected parse_launch sub-variants, which all require
investigation don't they need '(transfer floating)'. Fixing
gst_parse_launch with (transfer floating) worked for me.

I'm hoping to update my notes from hackfest tomorrow and post URL
here. Then I hope to kick start some sort of Gst Porting guide for
Python.

Cheers,
Peter.
_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Christian Fredrik Kalager Schaller]

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

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Jason Gerard DeRose-2]

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 <[hidden email]> 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
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel