doc reparagraphing and DEBUG_FUNCPTRing

Original commit message from CVS:
doc reparagraphing and DEBUG_FUNCPTRing

diff --git a/docs/libs/tmpl/gstcolorbalance.sgml b/docs/libs/tmpl/gstcolorbalance.sgml
index 7ac9f04e8fefcfaf1cf2fa31ba3c0e66aef92a35..ccb0ae227be29dbf423aa52d71d00530ba11ef15 100644 (file)
--- a/docs/libs/tmpl/gstcolorbalance.sgml
+++ b/docs/libs/tmpl/gstcolorbalance.sgml
@@ -23,6 +23,15 @@ interface for adjusting color balance settings
 </para>
 
 
+<!-- ##### SIGNAL GstColorBalance::value-changed ##### -->
+<para>
+
+</para>
+
+@gstcolorbalance: the object which received the signal.
+@arg1: 
+@arg2: 
+
 <!-- ##### STRUCT GstColorBalanceClass ##### -->
 <para>
 

diff --git a/gst-libs/gst/rtp/gstbasertpaudiopayload.c b/gst-libs/gst/rtp/gstbasertpaudiopayload.c
index f8c7a410d50419726eab9c4442954e1b1c1cc238..b8afbf9df89d3c5efa0bfedd2d9fd888f2eebf8a 100644 (file)
--- a/gst-libs/gst/rtp/gstbasertpaudiopayload.c
+++ b/gst-libs/gst/rtp/gstbasertpaudiopayload.c
@@ -69,12 +69,13 @@ gst_basertpaudiopayload_class_init (GstBaseRTPAudioPayloadClass * klass)
   gobject_class = (GObjectClass *) klass;
   gstelement_class = (GstElementClass *) klass;
   gstbasertppayload_class = (GstBaseRTPPayloadClass *) klass;
-  gobject_class->finalize = gst_basertpaudiopayload_finalize;
+  gobject_class->finalize =
+      GST_DEBUG_FUNCPTR (gst_basertpaudiopayload_finalize);
 
   parent_class = g_type_class_ref (GST_TYPE_BASE_RTP_PAYLOAD);
 
   gstbasertppayload_class->handle_buffer =
-      gst_basertpaudiopayload_handle_buffer;
+      GST_DEBUG_FUNCPTR (gst_basertpaudiopayload_handle_buffer);
 
   GST_DEBUG_CATEGORY_INIT (basertpaudiopayload_debug, "basertpaudiopayload", 0,
       "base audio RTP payloader");

diff --git a/gst/tcp/gstmultifdsink.c b/gst/tcp/gstmultifdsink.c
index 6e71b458c9ed61a667cb61140c4e2edfab0262ee..f937c2607e9a8250433036e25de591be137c5f2f 100644 (file)
--- a/gst/tcp/gstmultifdsink.c
+++ b/gst/tcp/gstmultifdsink.c
@@ -25,61 +25,69 @@
  *
  * <refsect2>
  * <para>
- * This plugin writes incoming data to a set of filedescriptors. The filedescriptors
- * can be added to multifdsink by emiting the "add" signal. For each descriptor added
+ * This plugin writes incoming data to a set of filedescriptors. The
+ * filedescriptors can be added to multifdsink by emiting the "add" signal. For
+ * each descriptor added
  * the "client-added" signal will be called.
  * </para>
  * <para>
- * Clients can be removed from multifdsink by emiting the "remove" signal. For each 
- * descriptor removed the "client-removed" signal will be called. The "client-removed" 
- * signal can also be fired when multifdsink decides that a client is not active anymore
- * or, depending on the value of the "recover-policy" if the client is reading to slow.
- * In all cases, multifdsink will never ever close a filedescriptor itself, the application
- * has to do that itself in the "client-fd-removed" signal, for example. 
- * Note that multifdsink still has a reference to the file descriptor when the 
- * "client-removed" signal is emited so that "get-stats" can be performed on the 
- * descriptor; It is therefore not allowed to close the file descriptor in the 
- * "client-removed" signal, use the "client-fd-removed" signal to close the fd. 
+ * Clients can be removed from multifdsink by emiting the "remove" signal. For
+ * each descriptor removed the "client-removed" signal will be called. The
+ * "client-removed" signal can also be fired when multifdsink decides that a
+ * client is not active anymore or, depending on the value of the
+ * "recover-policy" if the client is reading to slow.
+ * In all cases, multifdsink will never ever close a filedescriptor itself, the
+ * application has to do that itself in the "client-fd-removed" signal, for
+ * example.
+ * Note that multifdsink still has a reference to the file descriptor when the
+ * "client-removed" signal is emited so that "get-stats" can be performed on
+ * the descriptor; It is therefore not allowed to close the file descriptor in
+ * the "client-removed" signal, use the "client-fd-removed" signal to close the
+ * fd.
  * </para>
  * <para>
- * Multifdsink internally keeps a queue of the incomming buffers and uses a separate
- * thread to send the buffers to the clients. This ensures that no client write can
- * block the pipeline and that clients can read with different speeds. 
+ * Multifdsink internally keeps a queue of the incomming buffers and uses a
+ * separate thread to send the buffers to the clients. This ensures that no
+ * client write can block the pipeline and that clients can read with different
+ * speeds.
  * </para>
  * <para>
- * When adding a client to multifdsink, the "sync-method" property will define which
- * buffer will be sent first to the client. Clients can be sent respectively the most
- * recent buffer (which might not be decodable by the client when it is not a keyframe),
- * the next keyframe received in multifdsink (which can take some time depending on the 
- * keyframe rate, or the last received keyframe (which will cause a burst-on-connect).
+ * When adding a client to multifdsink, the "sync-method" property will define
+ * which buffer will be sent first to the client. Clients can be sent
+ * respectively the most recent buffer (which might not be decodable by the
+ * client when it is not a keyframe), the next keyframe received in multifdsink
+ * (which can take some time depending on the keyframe rate, or the last
+ * received keyframe (which will cause a burst-on-connect).
  * </para>
  * <para>
- * When streaming data, clients are allowed to read at a different rate than the rate 
- * at which multifdsink receives data. If the client is reading too fast, no data will
- * be send to the client until multifdsink receives more data. If the client however
- * reads too slow, data for that client will bunch up in multifdsink. Two properties
- * control the amount of data (buffers) that is queued in multifdsink: "buffers-max"
- * and "buffers-soft-max". A client with a lag of "buffers-max" is removed from
- * multifdsink forcibly.
+ * When streaming data, clients are allowed to read at a different rate than
+ * the rate at which multifdsink receives data. If the client is reading too
+ * fast, no data will be send to the client until multifdsink receives more
+ * data. If the client however reads too slow, data for that client will bunch
+ * up in multifdsink. Two properties control the amount of data (buffers) that
+ * is queued in multifdsink: "buffers-max" and "buffers-soft-max". A client
+ * with a lag of "buffers-max" is removed from multifdsink forcibly.
  * </para>
  * <para>
- * A client with a lag of at least "buffers-soft-max" enters the recovery procedure 
- * which is controled with the "recover-policy" property. A recover policy of NONE will
- * do nothing, RESYNC_LATEST will send the most recently received buffer as the next
- * buffer for the client, RESYNC_SOFT_LIMIT positions the client to the soft limit
- * in the buffer queue and RESYNC_KEYFRAME positions the client to the most recent 
- * keyframe in the buffer queue.
+ * A client with a lag of at least "buffers-soft-max" enters the recovery
+ * procedure which is controled with the "recover-policy" property. A recover
+ * policy of NONE will do nothing, RESYNC_LATEST will send the most recently
+ * received buffer as the next buffer for the client, RESYNC_SOFT_LIMIT
+ * positions the client to the soft limit in the buffer queue and
+ * RESYNC_KEYFRAME positions the client to the most recent keyframe in the
+ * buffer queue.
  * </para>
  * <para>
- * multifdsink will synchronize on the clock before serving the buffers to the clients.
+ * multifdsink will synchronize on the clock before serving the buffers to the
+ * clients.
  * </para>
  * <para>
  * Example pipeline:
  * <programlisting>
  * gst-launch -v videotestsrc ! multifdsink
  * </programlisting>
- * This pipeline will not do a lot since it is not possible from a gst-launch line
- * to add filedescriptors to multifdsink.
+ * This pipeline will not do a lot since it is not possible from a gst-launch
+ * line to add filedescriptors to multifdsink.
  * </para>
  * </refsect2>
  *

diff --git a/gst/videoscale/gstvideoscale.c b/gst/videoscale/gstvideoscale.c
index 70c9bb46206caf94ce03e202d3df1f4bec55420f..4a5a676861b2c44501b9b7f76765de2113e732a7 100644 (file)
--- a/gst/videoscale/gstvideoscale.c
+++ b/gst/videoscale/gstvideoscale.c
@@ -20,7 +20,6 @@
 
 /**
  * SECTION:element-videoscale
- * @short_description: rescale video
  * @see_also: videorate, ffmpegcolorspace
  *
  * <refsect2>
@@ -31,24 +30,26 @@
  * get more robust behaviour without any cost if no scaling is needed.
  * </para>
  * <para>
- * This element supports a wide range of color spaces including various YUV and 
- * RGB formats and is therefore generally able to operate anywhere in a pipeline.
+ * This element supports a wide range of color spaces including various YUV and
+ * RGB formats and is therefore generally able to operate anywhere in a
+ * pipeline.
  * </para>
  * <title>Example pipelines</title>
  * <para>
  * <programlisting>
  * gst-launch -v filesrc location=videotestsrc.ogg ! oggdemux ! theoradec ! ffmpegcolorspace ! videoscale ! ximagesink
  * </programlisting>
- * Decode an Ogg/Theora and display the video using ximagesink. Since ximagesink cannot
- * perform scaling, the video scaling will be performed by videoscale when you resize the
- * video window.
+ * Decode an Ogg/Theora and display the video using ximagesink. Since
+ * ximagesink cannot perform scaling, the video scaling will be performed by
+ * videoscale when you resize the video window.
  * To create the test Ogg/Theora file refer to the documentation of theoraenc.
  * </para>
  * <para>
  * <programlisting>
  * gst-launch -v filesrc location=videotestsrc.ogg ! oggdemux ! theoradec ! videoscale ! video/x-raw-yuv, width=50 ! xvimagesink
  * </programlisting>
- * Decode an Ogg/Theora and display the video using xvimagesink with a width of 50.
+ * Decode an Ogg/Theora and display the video using xvimagesink with a width of
+ * 50.
  * </para>
  * </refsect2>
  *