diff --git a/docs/libs/tmpl/gstcolorbalance.sgml b/docs/libs/tmpl/gstcolorbalance.sgml index 7ac9f04e8f..ccb0ae227b 100644 --- a/docs/libs/tmpl/gstcolorbalance.sgml +++ b/docs/libs/tmpl/gstcolorbalance.sgml @@ -23,6 +23,15 @@ interface for adjusting color balance settings + + + + + +@gstcolorbalance: the object which received the signal. +@arg1: +@arg2: + diff --git a/gst-libs/gst/rtp/gstbasertpaudiopayload.c b/gst-libs/gst/rtp/gstbasertpaudiopayload.c index f8c7a410d5..b8afbf9df8 100644 --- 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 6e71b458c9..f937c2607e 100644 --- a/gst/tcp/gstmultifdsink.c +++ b/gst/tcp/gstmultifdsink.c @@ -25,61 +25,69 @@ * * * - * 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. * * - * 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. * * - * 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. * * - * 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). * * - * 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. * * - * 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. * * - * 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. * * * Example pipeline: * * gst-launch -v videotestsrc ! multifdsink * - * 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. * * * diff --git a/gst/videoscale/gstvideoscale.c b/gst/videoscale/gstvideoscale.c index 70c9bb4620..4a5a676861 100644 --- 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 * * @@ -31,24 +30,26 @@ * get more robust behaviour without any cost if no scaling is needed. * * - * 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. * * Example pipelines * * * gst-launch -v filesrc location=videotestsrc.ogg ! oggdemux ! theoradec ! ffmpegcolorspace ! videoscale ! ximagesink * - * 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. * * * * gst-launch -v filesrc location=videotestsrc.ogg ! oggdemux ! theoradec ! videoscale ! video/x-raw-yuv, width=50 ! xvimagesink * - * 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. * * *