doc reparagraphing and DEBUG_FUNCPTRing

Original commit message from CVS:
doc reparagraphing and DEBUG_FUNCPTRing

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>
 

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");

gst/tcp/gstmultifdsink.c

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

gst/videoscale/gstvideoscale.c

@@ -20,7 +20,6 @@
 
 /**
  * SECTION:element-videoscale
- * @short_description: rescale video
  * @see_also: videorate, ffmpegcolorspace
  *
  * <refsect2>
@@ -32,23 +31,25 @@
  * </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.
+ * 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
+ * Decode an Ogg/Theora and display the video using ximagesink. Since
- * perform scaling, the video scaling will be performed by videoscale when you resize the
+ * ximagesink cannot perform scaling, the video scaling will be performed by
- * video window.
+ * 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>
  *