gst/gstutils.c: Docs enhancement: make it crystal clear what the gst_pad_add_*_probe() callbacks should look like.

Original commit message from CVS:
* gst/gstutils.c:
Docs enhancement: make it crystal clear what the
gst_pad_add_*_probe() callbacks should look like.
This commit is contained in:
Tim-Philipp Müller 2006-02-24 16:54:27 +00:00
parent 32aff01e8d
commit ae0d1ee4a9
2 changed files with 10 additions and 3 deletions

View file

@ -1,3 +1,9 @@
2006-02-24 Tim-Philipp Müller <tim at centricular dot net>
* gst/gstutils.c:
Docs enhancement: make it crystal clear what the
gst_pad_add_*_probe() callbacks should look like.
2006-02-24 Tim-Philipp Müller <tim at centricular dot net>
* libs/gst/base/gstbasesrc.c:

View file

@ -2627,9 +2627,10 @@ gst_atomic_int_set (gint * atomic_int, gint value)
*
* Adds a "data probe" to a pad. This function will be called whenever data
* passes through a pad. In this case data means both events and buffers. The
* probe will be called with the data as an argument. Note that the data will
* have a reference count greater than 1, so it will be immutable -- you must
* not change it.
* probe will be called with the data as an argument, meaning @handler should
* have the same callback signature as the 'have-data' signal of #GstPad.
* Note that the data will have a reference count greater than 1, so it will
* be immutable -- you must not change it.
*
* For source pads, the probe will be called after the blocking function, if any
* (see gst_pad_set_blocked_async()), but before looking up the peer to chain