gst/gstutils.c: Docs enhancement: make it crystal clear what the gst_pad_add_*_probe...

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

diff --git a/ChangeLog b/ChangeLog
index fc1573f..39e6977 100644 (file)
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,11 @@
 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:
          Document how applications can stop recording from
          live sources (see #330996).

diff --git a/gst/gstutils.c b/gst/gstutils.c
index 8f685b4..531ce7d 100644 (file)
--- a/gst/gstutils.c
+++ b/gst/gstutils.c
@@ -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