The previous commit broke those by trying to pass weak refs
through pygobject, but we should probably have tested the elements
beyond instantiation: weakref.WeakMethod returns a callable, but
that callable when called only returns the ephemeral bound method,
which is the object we want to call, but pygobject has no support
for that.
Instead, fix the memory leaks we were going after by decoupling the
lifecycle of the callback and that of the pad, by passing functors
to pygobject.
This makes sure that we do not try to use GstPbutils before Gst is init
and in case GstPbutils is imported while Gst is not imported, use the
`GstPbutils.pb_utils_init()` function to have the oportunity to
initialize the overrides.
Not that we also introduce a `GstPbutils.init()` variant because
`GstPbutils.pb_utils_init()` is an ugly name.
The C API provides the gst_pad_set_caps() helper which makes it easier
to set caps on pads (see gst/gstcompat.h in gstreamer core).
Add such handy helper to the python bindings too.
The implementation follows as close as possible the one in gstcompat.h
with two changes:
1. the type check on the pad has been removed because self is
guaranteed to be a Gst.Pad in python.
2. the null check on the caps has been extended to be a type check.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-python/issues/19
This patch makes the tests pass running uninstalled and installed, with
python2 and python3 on linux, windows and osx.
The main gist is to use the new python-module to do the lifting done
by pythondetector, and with that add support for python2 and windows.
We need a 64 bit integer, and previously the test failed because it was
already created from longs in various cases (e.g. when reading from a
GstStructure).
- Make sure to never have root folder in sys.path when running meson,
as pythondetector won't be able to access gi._overridesdir
- Generate a mesonconfig.py file that will be used by the testsuite to
know where meson generated files, making `python -m unittest` working.
This is needed to support matrix. Otherwise, getting
a matrix would remove the rows envelopess, which would
make the "cast" fails, since it would not know if the
internal rows are ValueArray or ValueList. I think reading,
modifying and setting back the matrix is an important use
case.
This patch adds overrides to support IntRange, Int64Range, DoubleRange,
FractionRange, Array and List. For integer ranges, it maps this
to python 'range'. Gst.IntRange() and Gst.Int64Range() are simple cast
to let the underlying code know which GType to use. To set such range in
python you will do:
structure["range"] = Gst.IntRange(range(0,10,2)))
Same for the 64 bit variant. And when you do:
r = structure.get_value("range")
A range will be returned directly, without the wrapper. For DoubleRange
and FractionRange, there is no native support in python. So the usage
will be:
structure["range"] = Gst.DoubleRange(0,10.0)
structure["range"] =
Gst.FractionRange(Gst.Fraction(1/30), Gst.Fraction(1/5)
When getting this value, Gst.DoubleRange and Gst.FractionRange class are
returned. They both have start/stop members. The naming was taken from
range type.
For Array and List, both uses the native list type, though they can be
constructed from any python sequence. So again, the class is just like
a cast, to let it pick the right GType and python list are being
returned.
structure["list"] = Gst.ValueList([1,2,3,4])
structure["array"] = Gst.ValueArray([1,2,3,4)
Using string and tuple could also work. Since Gst.ValueList/Array are
sequence, you can convert one to the other with:
list = Gst.ValueList([1,2,3,4])
array = Gst.ValueArray (list)
https://bugzilla.gnome.org/show_bug.cgi?id=753754
PyMethodDef arrays are supposed to end with an entry full of NULL/0 values.
This is missing in gst-python in the file gstmodule.c.
This causes out of bounds memory reads which can be seen / tested by compiling
gst-python with address sanitizer (-fsanitize=address in CFLAGS/LDFLAGS).
https://bugzilla.gnome.org/show_bug.cgi?id=762766
Python2 core checks that the first argument of a method is of the type
of the object if it does not have any info about the method, so when
using Gst not initialized it raiser a TypeError and not a
Gst.NotInitialized as expected.
+ And fix a typo
Summary:
We know that the bindings will get an extra ref but we know that
it is not actually needed, so we are safe to decrease the refcount
by one in that particular context making sure we give PyGI its
ref back when we are done.
Reviewers: Mathieu_Du
Differential Revision: http://phabricator.freedesktop.org/D41https://bugzilla.gnome.org/show_bug.cgi?id=746329
