Possible inconsistencies between python and C API

[Antonio Ospite]

On Thu, 13 Dec 2018 11:10:02 +0100
Antonio Ospite <ao2 at ao2.it> 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?