Possible inconsistencies between python and C API

[Antonio Ospite-2]

Hi,

I wanted to brush up my GStreamer game and I though I'd write some
example elements in python to fixate some concepts without the
distracting C boilerplate.

In particular I was writing a demuxer and a parser and I noticed what
I think may be inconsistencies between the C API and the python
bindings:

1. GstBase.Adapter.map() and GstBase.Adapter.take() do not take
   a size/nbytes argument in the python bindings[1,2] as they do in the
   C API[3,4]. This was confusing at first but it is not a great
   shortcoming as the GstBase.Adapter.take_*() functions seem to work
   fine and can be used instead.

2. GstBase.BaseParse.do_handle_frame() has the "skipsize (int)"
   parameter which is an input-only parameter in python[5], while in
   C it is an output parameter[6], so it looks like it's not possible to
   pass a "skipsize" value to the caller to skip some data.  I would
   have expected to pass "skipsize" in the return value of the python
   function.
   
   This affects the generality of BaseParse in python, in my parser
   element I have to skip some header and only pass the payload
   downstream, and I didn't find an alternative way to do it in python
   with BaseParse.

   There could be a similar problem with the "dest_value" parameter of
   GstBase.BaseParse.do_convert() but I don't use that function.

3. To overcome 2. I tried, just as an experiment, to skip some data in
   the parser element with frame.buffer.remove_memory_range(0, skipsize)
   but that does not work with non-writeable buffers and it looks
   like there is no Gst.Buffer.make_writeable[7] or
   Gst.MiniObject.make_writeable[8].

4. I cannot see Gst.Pad.set_caps() in the stable doc[9], I see some use
   of it in some old tests in gst-python but I don't know if they are
   actually supposed to work.

If these are indeed bugs I can file proper reports on gitlab.

Ah, I am using GStreamer 1.14.4 from Debian unstable.

Thank you,
   Antonio

[1] http://lazka.github.io/pgi-docs/GstBase-1.0/classes/Adapter.html#GstBase.Adapter.map
[2] http://lazka.github.io/pgi-docs/GstBase-1.0/classes/Adapter.html#GstBase.Adapter.take
[3] https://developer.gnome.org/gstreamer-libs/stable/GstAdapter.html#gst-adapter-map
[4] https://developer.gnome.org/gstreamer-libs/stable/GstAdapter.html#gst-adapter-take
[5] http://lazka.github.io/pgi-docs/GstBase-1.0/classes/BaseParse.html#GstBase.BaseParse.do_handle_frame
[6] https://developer.gnome.org/gstreamer-libs/stable/gstreamer-libs-GstBaseParse.html#GstBaseParseClass
[7] http://lazka.github.io/pgi-docs/Gst-1.0/classes/Buffer.html#methods
[8] http://lazka.github.io/pgi-docs/Gst-1.0/classes/MiniObject.html#methods
[9] http://lazka.github.io/pgi-docs/Gst-1.0/classes/Pad.html#methods

--
Antonio Ospite
https://ao2.it
https://twitter.com/ao2it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Antonio Ospite-2]

On Thu, 13 Dec 2018 11:10:02 +0100
Antonio Ospite <[hidden email]> wrote:

> Hi,
>
> I wanted to brush up my GStreamer game and I though I'd write some
> example elements in python to fixate some concepts without the
> distracting C boilerplate.
>

I ended up writing the elements in C, but I would still be interested to
have the issues with pyhton bindings fixed, read below for some
questions.

> In particular I was writing a demuxer and a parser and I noticed what
> I think may be inconsistencies between the C API and the python
> bindings:
>
> 1. GstBase.Adapter.map() and GstBase.Adapter.take() do not take
>    a size/nbytes argument in the python bindings[1,2] as they do in the
>    C API[3,4]. This was confusing at first but it is not a great
>    shortcoming as the GstBase.Adapter.take_*() functions seem to work
>    fine and can be used instead.
>
> 2. GstBase.BaseParse.do_handle_frame() has the "skipsize (int)"
>    parameter which is an input-only parameter in python[5], while in
>    C it is an output parameter[6], so it looks like it's not possible to
>    pass a "skipsize" value to the caller to skip some data.  I would
>    have expected to pass "skipsize" in the return value of the python
>    function.
>    
>    This affects the generality of BaseParse in python, in my parser
>    element I have to skip some header and only pass the payload
>    downstream, and I didn't find an alternative way to do it in python
>    with BaseParse.
>
>    There could be a similar problem with the "dest_value" parameter of
>    GstBase.BaseParse.do_convert() but I don't use that function.
>
> 3. To overcome 2. I tried, just as an experiment, to skip some data in
>    the parser element with frame.buffer.remove_memory_range(0, skipsize)
>    but that does not work with non-writable buffers and it looks
>    like there is no Gst.Buffer.make_writable[7] or
>    Gst.MiniObject.make_writable[8].
>
> 4. I cannot see Gst.Pad.set_caps() in the stable doc[9], I see some use
>    of it in some old tests in gst-python but I don't know if they are
>    actually supposed to work.
>

OK, maybe 4 is not a bug, as gst_pad_set_caps() is not really a GstPad
API but a compatibility wrapper defined in gstreamer::gst/gstcompat.h

The lack of Gst.Pad.set_caps can be overcome with code like the
following:

  caps = Gst.Caps.from_string('image/jpeg')
  event = Gst.Event.new_caps(caps)
  ret = self.srcpad.push_event(event)

So I can at least write a parser in python if I do not skip any data.

However I noticed another issue with the
GstBase.BaseParse.do_set_sink_caps() virtual method, which does not
appear to be called in python.

> If these are indeed bugs I can file proper reports on gitlab.
>

Should I report these issues against gst-python?
https://gitlab.freedesktop.org/gstreamer/gst-python

Do you prefer one report per issue?

Thanks,
   Antonio

> Ah, I am using GStreamer 1.14.4 from Debian unstable.
>
> Thank you,
>    Antonio
>
> [1] http://lazka.github.io/pgi-docs/GstBase-1.0/classes/Adapter.html#GstBase.Adapter.map
> [2] http://lazka.github.io/pgi-docs/GstBase-1.0/classes/Adapter.html#GstBase.Adapter.take
> [3] https://developer.gnome.org/gstreamer-libs/stable/GstAdapter.html#gst-adapter-map
> [4] https://developer.gnome.org/gstreamer-libs/stable/GstAdapter.html#gst-adapter-take
> [5] http://lazka.github.io/pgi-docs/GstBase-1.0/classes/BaseParse.html#GstBase.BaseParse.do_handle_frame
> [6] https://developer.gnome.org/gstreamer-libs/stable/gstreamer-libs-GstBaseParse.html#GstBaseParseClass
> [7] http://lazka.github.io/pgi-docs/Gst-1.0/classes/Buffer.html#methods
> [8] http://lazka.github.io/pgi-docs/Gst-1.0/classes/MiniObject.html#methods
> [9] http://lazka.github.io/pgi-docs/Gst-1.0/classes/Pad.html#methods
>

--
Antonio Ospite
https://ao2.it
https://twitter.com/ao2it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Sebastian Dröge-3]

On Wed, 2019-01-02 at 13:30 +0100, Antonio Ospite wrote:

> On Thu, 13 Dec 2018 11:10:02 +0100
> Antonio Ospite <[hidden email]> wrote:
>
> > Hi,
> >
> > I wanted to brush up my GStreamer game and I though I'd write some
> > example elements in python to fixate some concepts without the
> > distracting C boilerplate.
> >
>
> I ended up writing the elements in C, but I would still be interested
> to have the issues with pyhton bindings fixed, read below for some
> questions.

Please create an issue for any API problems (one for each) in
gst-python:
  https://gitlab.freedesktop.org/gstreamer/gst-python/issues/new

Thanks!

> > In particular I was writing a demuxer and a parser

Performance-wise it's not a good idea to write GStreamer elements in
Python, because of the global interpreter lock. C, C++ and Rust seem
better choices at this point.

--
Sebastian Dröge, Centricular Ltd · https://www.centricular.com


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

[Antonio Ospite-2]

On Thu, 03 Jan 2019 16:00:59 +0200
Sebastian Dröge <[hidden email]> wrote:

> On Wed, 2019-01-02 at 13:30 +0100, Antonio Ospite wrote:
> > On Thu, 13 Dec 2018 11:10:02 +0100
> > Antonio Ospite <[hidden email]> wrote:
> >
> > > Hi,
> > >
> > > I wanted to brush up my GStreamer game and I though I'd write some
> > > example elements in python to fixate some concepts without the
> > > distracting C boilerplate.
> > >
> >
> > I ended up writing the elements in C, but I would still be interested
> > to have the issues with pyhton bindings fixed, read below for some
> > questions.
>
> Please create an issue for any API problems (one for each) in
> gst-python:
>   https://gitlab.freedesktop.org/gstreamer/gst-python/issues/new
>
> > > In particular I was writing a demuxer and a parser
>
> Performance-wise it's not a good idea to write GStreamer elements in
> Python, because of the global interpreter lock. C, C++ and Rust seem
> better choices at this point.
>

I see, and memory is also less "controllable" from pyhton, but I still
find value in using python for learning and prototyping, so I went
ahead and filed the reports to gst-python.

Thank you,
   Antonio

--
Antonio Ospite
https://ao2.it
https://twitter.com/ao2it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel