From: Thibault Saunier Date: Tue, 23 Jun 2020 00:10:10 +0000 (-0400) Subject: doc: Fix link in tcp multi*sinks. X-Git-Tag: 1.19.3~511^2~546 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=e9d3e4d7ea22f234b57dfefce9b34ae795a80a8e;p=platform%2Fupstream%2Fgstreamer.git doc: Fix link in tcp multi*sinks. --- diff --git a/gst/tcp/gstmultifdsink.c b/gst/tcp/gstmultifdsink.c index ea7b285..e151dfc 100644 --- a/gst/tcp/gstmultifdsink.c +++ b/gst/tcp/gstmultifdsink.c @@ -39,7 +39,7 @@ * each descriptor removed, the #GstMultiFdSink::client-removed signal will be called. The * #GstMultiFdSink::client-removed signal can also be fired when multifdsink decides that a * client is not active anymore or, depending on the value of the - * #GstMultiFdSink:recover-policy property, if the client is reading too slowly. + * #GstMultiHandleSink:recover-policy property, if the client is reading too slowly. * In all cases, multifdsink will never close a file descriptor itself. * The user of multifdsink is responsible for closing all file descriptors. * This can for example be done in response to the #GstMultiFdSink::client-fd-removed signal. @@ -54,7 +54,7 @@ * client write can block the pipeline and that clients can read with different * speeds. * - * When adding a client to multifdsink, the #GstMultiFdSink:sync-method property will define + * When adding a client to multifdsink, the #GstMultiHandleSink:sync-method property will define * which buffer in the queued buffers will be sent first to the client. Clients * can be sent the most recent buffer (which might not be decodable by the * client if it is not a keyframe), the next keyframe received in @@ -63,7 +63,7 @@ * Multifdsink will always keep at least one keyframe in its internal buffers * when the sync-mode is set to latest-keyframe. * - * There are additional values for the #GstMultiFdSink:sync-method + * There are additional values for the #GstMultiHandleSink:sync-method * property to allow finer control over burst-on-connect behaviour. By selecting * the 'burst' method a minimum burst size can be chosen, 'burst-keyframe' * additionally requires that the burst begin with a keyframe, and @@ -72,7 +72,7 @@ * * Multifdsink can be instructed to keep at least a minimum amount of data * expressed in time or byte units in its internal queues with the - * #GstMultiFdSink:time-min and #GstMultiFdSink:bytes-min properties respectively. + * #GstMultiHandleSink:time-min and #GstMultiHandleSink:bytes-min properties respectively. * These properties are useful if the application adds clients with the * #GstMultiFdSink::add-full signal to make sure that a burst connect can * actually be honored. @@ -82,12 +82,12 @@ * fast, no data will be send to the client until multifdsink receives more * data. If the client, however, reads too slowly, data for that client will be * queued up in multifdsink. Two properties control the amount of data - * (buffers) that is queued in multifdsink: #GstMultiFdSink:buffers-max and - * #GstMultiFdSink:buffers-soft-max. A client that falls behind by - * #GstMultiFdSink:buffers-max is removed from multifdsink forcibly. + * (buffers) that is queued in multifdsink: #GstMultiHandleSink:buffers-max and + * #GstMultiHandleSink:buffers-soft-max. A client that falls behind by + * #GstMultiHandleSink:buffers-max is removed from multifdsink forcibly. * - * A client with a lag of at least #GstMultiFdSink:buffers-soft-max enters the recovery - * procedure which is controlled with the #GstMultiFdSink:recover-policy property. + * A client with a lag of at least #GstMultiHandleSink:buffers-soft-max enters the recovery + * procedure which is controlled with the #GstMultiHandleSink: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 diff --git a/gst/tcp/gstmultihandlesink.c b/gst/tcp/gstmultihandlesink.c index 4c0e8a1..f1d3d2c 100644 --- a/gst/tcp/gstmultihandlesink.c +++ b/gst/tcp/gstmultihandlesink.c @@ -21,83 +21,6 @@ * Boston, MA 02110-1301, USA. */ -/** - * SECTION:element-multihandlesink - * @title: multihandlesink - * @see_also: tcpserversink - * - * This plugin writes incoming data to a set of file descriptors. The - * file descriptors can be added to multihandlesink by emitting the #GstMultiHandleSink::add signal. - * For each descriptor added, the #GstMultiHandleSink::client-added signal will be called. - * - * A client can also be added with the #GstMultiHandleSink::add-full signal - * that allows for more control over what and how much data a client - * initially receives. - * - * Clients can be removed from multihandlesink by emitting the #GstMultiHandleSink::remove signal. For - * each descriptor removed, the #GstMultiHandleSink::client-removed signal will be called. The - * #GstMultiHandleSink::client-removed signal can also be fired when multihandlesink decides that a - * client is not active anymore or, depending on the value of the - * #GstMultiHandleSink:recover-policy property, if the client is reading too slowly. - * In all cases, multihandlesink will never close a file descriptor itself. - * The user of multihandlesink is responsible for closing all file descriptors. - * This can for example be done in response to the #GstMultiHandleSink::client-fd-removed signal. - * Note that multihandlesink still has a reference to the file descriptor when the - * #GstMultiHandleSink::client-removed signal is emitted, so that "get-stats" can be performed on - * the descriptor; it is therefore not safe to close the file descriptor in - * the #GstMultiHandleSink::client-removed signal handler, and you should use the - * #GstMultiHandleSink::client-fd-removed signal to safely close the fd. - * - * Multisocketsink internally keeps a queue of the incoming 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 multihandlesink, the #GstMultiHandleSink:sync-method property will define - * which buffer in the queued buffers will be sent first to the client. Clients - * can be sent the most recent buffer (which might not be decodable by the - * client if it is not a keyframe), the next keyframe received in - * multihandlesink (which can take some time depending on the keyframe rate), or the - * last received keyframe (which will cause a simple burst-on-connect). - * Multisocketsink will always keep at least one keyframe in its internal buffers - * when the sync-mode is set to latest-keyframe. - * - * There are additional values for the #GstMultiHandleSink:sync-method - * property to allow finer control over burst-on-connect behaviour. By selecting - * the 'burst' method a minimum burst size can be chosen, 'burst-keyframe' - * additionally requires that the burst begin with a keyframe, and - * 'burst-with-keyframe' attempts to burst beginning with a keyframe, but will - * prefer a minimum burst size even if it requires not starting with a keyframe. - * - * Multisocketsink can be instructed to keep at least a minimum amount of data - * expressed in time or byte units in its internal queues with the - * #GstMultiHandleSink:time-min and #GstMultiHandleSink:bytes-min properties respectively. - * These properties are useful if the application adds clients with the - * #GstMultiHandleSink::add-full signal to make sure that a burst connect can - * actually be honored. - * - * When streaming data, clients are allowed to read at a different rate than - * the rate at which multihandlesink receives data. If the client is reading too - * fast, no data will be send to the client until multihandlesink receives more - * data. If the client, however, reads too slowly, data for that client will be - * queued up in multihandlesink. Two properties control the amount of data - * (buffers) that is queued in multihandlesink: #GstMultiHandleSink:buffers-max and - * #GstMultiHandleSink:buffers-soft-max. A client that falls behind by - * #GstMultiHandleSink:buffers-max is removed from multihandlesink forcibly. - * - * A client with a lag of at least #GstMultiHandleSink:buffers-soft-max enters the recovery - * procedure which is controlled with the #GstMultiHandleSink: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 at the most recent keyframe in the - * buffer queue. - * - * multihandlesink will by default synchronize on the clock before serving the - * buffers to the clients. This behaviour can be disabled by setting the sync - * property to FALSE. Multisocketsink will by default not do QoS and will never - * drop late buffers. - */ #ifdef HAVE_CONFIG_H #include "config.h" @@ -817,7 +740,7 @@ done: CLIENTS_UNLOCK (sink); } -/* can be called both through the signal (i.e. from any thread) or when +/* can be called both through the signal (i.e. from any thread) or when * stopping, after the writing thread has shut down */ static void gst_multi_handle_sink_clear (GstMultiHandleSink * mhsink) @@ -1146,7 +1069,7 @@ is_sync_frame (GstMultiHandleSink * sink, GstBuffer * buffer) } /* find the keyframe in the list of buffers starting the - * search from @idx. @direction as -1 will search backwards, + * search from @idx. @direction as -1 will search backwards, * 1 will search forwards. * Returns: the index or -1 if there is no keyframe after idx. */ @@ -1283,7 +1206,7 @@ find_limits (GstMultiHandleSink * sink, max_hit = FALSE; i = 0; - /* loop through the buffers, when a limit is ok, mark it + /* loop through the buffers, when a limit is ok, mark it * as -1, we have at least one buffer in the queue. */ do { GstBuffer *buf; @@ -1348,7 +1271,7 @@ find_limits (GstMultiHandleSink * sink, } /* parse the unit/value pair and assign it to the result value of the - * right type, leave the other values untouched + * right type, leave the other values untouched * * Returns: FALSE if the unit is unknown or undefined. TRUE otherwise. */ @@ -1793,7 +1716,7 @@ restart: } /* now look for sync points and make sure there is at least one - * sync point in the queue. We only do this if the LATEST_KEYFRAME or + * sync point in the queue. We only do this if the LATEST_KEYFRAME or * BURST_KEYFRAME mode is selected */ if (mhsink->def_sync_method == GST_SYNC_METHOD_LATEST_KEYFRAME || mhsink->def_sync_method == GST_SYNC_METHOD_BURST_KEYFRAME) { diff --git a/gst/tcp/gstmultisocketsink.c b/gst/tcp/gstmultisocketsink.c index e064ccb..da7eaf5 100644 --- a/gst/tcp/gstmultisocketsink.c +++ b/gst/tcp/gstmultisocketsink.c @@ -38,7 +38,7 @@ * each descriptor removed, the #GstMultiSocketSink::client-removed signal will be called. The * #GstMultiSocketSink::client-removed signal can also be fired when multisocketsink decides that a * client is not active anymore or, depending on the value of the - * #GstMultiSocketSink:recover-policy property, if the client is reading too slowly. + * #GstMultiHandleSink:recover-policy property, if the client is reading too slowly. * In all cases, multisocketsink will never close a socket itself. * The user of multisocketsink is responsible for closing all sockets. * This can for example be done in response to the #GstMultiSocketSink::client-socket-removed signal. @@ -53,7 +53,7 @@ * client write can block the pipeline and that clients can read with different * speeds. * - * When adding a client to multisocketsink, the #GstMultiSocketSink:sync-method property will define + * When adding a client to multisocketsink, the #GstMultiHandleSink:sync-method property will define * which buffer in the queued buffers will be sent first to the client. Clients * can be sent the most recent buffer (which might not be decodable by the * client if it is not a keyframe), the next keyframe received in @@ -62,7 +62,7 @@ * Multisocketsink will always keep at least one keyframe in its internal buffers * when the sync-mode is set to latest-keyframe. * - * There are additional values for the #GstMultiSocketSink:sync-method + * There are additional values for the #GstMultiHandleSink:sync-method * property to allow finer control over burst-on-connect behaviour. By selecting * the 'burst' method a minimum burst size can be chosen, 'burst-keyframe' * additionally requires that the burst begin with a keyframe, and @@ -71,7 +71,7 @@ * * Multisocketsink can be instructed to keep at least a minimum amount of data * expressed in time or byte units in its internal queues with the - * #GstMultiSocketSink:time-min and #GstMultiSocketSink:bytes-min properties respectively. + * #GstMultiHandleSink:time-min and #GstMultiHandleSink:bytes-min properties respectively. * These properties are useful if the application adds clients with the * #GstMultiSocketSink::add-full signal to make sure that a burst connect can * actually be honored. @@ -81,12 +81,12 @@ * fast, no data will be send to the client until multisocketsink receives more * data. If the client, however, reads too slowly, data for that client will be * queued up in multisocketsink. Two properties control the amount of data - * (buffers) that is queued in multisocketsink: #GstMultiSocketSink:buffers-max and - * #GstMultiSocketSink:buffers-soft-max. A client that falls behind by - * #GstMultiSocketSink:buffers-max is removed from multisocketsink forcibly. + * (buffers) that is queued in multisocketsink: #GstMultiHandleSink:buffers-max and + * #GstMultiHandleSink:buffers-soft-max. A client that falls behind by + * #GstMultiHandleSink:buffers-max is removed from multisocketsink forcibly. * - * A client with a lag of at least #GstMultiSocketSink:buffers-soft-max enters the recovery - * procedure which is controlled with the #GstMultiSocketSink:recover-policy property. + * A client with a lag of at least #GstMultiHandleSink:buffers-soft-max enters the recovery + * procedure which is controlled with the #GstMultiHandleSink: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