[gst-devel] Question on reference handling of GstEvents

[Edward Hervey]

Hi,

On Thu, 2008-01-03 at 09:53 +0000, Tim Müller wrote:
> On Wed, 2008-01-02 at 22:33 -0500, José Alburquerque wrote:
> 
> Hi Jose,
> 
> > As I understand it, the gst_element_send_event() function 
> > takes "ownership" of the GstEvent and, as the docs say, it is necessary 
> > to "reference" it if a copy of the GstEvent is wanted.  My question is:  
> > In general, do all functions taking GstEvents take "ownership" of 
> > GstEvents this way?
> 
> No, see e.g. gst_event_parse_*().
> 
> >   The only real function I have found that accepts a 
> > GstEvent is the one I just mentioned.  Are there others?
> 
> Yes, e.g. gst_pad_{push|send}_event(), gst_pad_event_default().
> 
> > I'm trying to decide how to handle the referencing of GstEvents in the
> >  bindings so I'm trying to get a sense of what happens with GstEvents. 
> >  Any help will be greatly appreciated.
> 
> Generally, all functions that push or send events or buffers to another
> pad or an element take ownership of that event or buffer.  Others do
> usually not (with exceptions such as gst_adapter_push()).  This only
> applies to events and buffers, but not for example queries, where the
> called function never takes ownership (IIRC).

  We had to do the same special handling with gst-python. If you look at
gst-python/gst/*.defs you can see which parameters of which functions
need to be handled like that (grep for "(keep-refcount)").

  The way it's done in the python bindings is that we keep a refcount on
GStreamer objects for as long as there's a corresponding python object.
  So in the specials cases above, we INCREMENT the refcount of the
argument before calling the given method. This means that after the
function returns we guarantee that our python object still has a
reference on the object (which will be dropped when python no longer
uses that object).

  Hope this helps.

    Edward

> 
> Cheers
>  -Tim
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel