mirrors/gstreamer
mirrors/gstreamer
1
1
Fork 0
mirror of https://gitlab.freedesktop.org/gstreamer/gstreamer.git synced 2024-11-27 12:11:13 +00:00
Code Issues 1 Projects Releases Wiki Activity

doc: Fix link in tcp multi*sinks.

Browse source
This commit is contained in:
Thibault Saunier 2020-06-22 20:10:10 -04:00
parent 99545b9bea
commit e9d3e4d7ea
3 changed files with 23 additions and 100 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

18
gst/tcp/gstmultifdsink.c
View file

@ -39,7 +39,7 @@
* each descriptor removed, the #GstMultiFdSink::client-removed signal will be called. The * 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 * #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 * 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. * In all cases, multifdsink will never close a file descriptor itself.
* The user of multifdsink is responsible for closing all file descriptors. * 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. * 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 * client write can block the pipeline and that clients can read with different
* speeds. * 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 * 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 * 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 * 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 * Multifdsink will always keep at least one keyframe in its internal buffers
* when the sync-mode is set to latest-keyframe. * 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 * property to allow finer control over burst-on-connect behaviour. By selecting
* the 'burst' method a minimum burst size can be chosen, 'burst-keyframe' * the 'burst' method a minimum burst size can be chosen, 'burst-keyframe'
* additionally requires that the burst begin with a keyframe, and * 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 * 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 * 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 * These properties are useful if the application adds clients with the
* #GstMultiFdSink::add-full signal to make sure that a burst connect can * #GstMultiFdSink::add-full signal to make sure that a burst connect can
* actually be honored. * actually be honored.
@ -82,12 +82,12 @@
* fast, no data will be send to the client until multifdsink receives more * 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 * 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 * queued up in multifdsink. Two properties control the amount of data
* (buffers) that is queued in multifdsink: #GstMultiFdSink:buffers-max and * (buffers) that is queued in multifdsink: #GstMultiHandleSink:buffers-max and
* #GstMultiFdSink:buffers-soft-max. A client that falls behind by * #GstMultiHandleSink:buffers-soft-max. A client that falls behind by
* #GstMultiFdSink:buffers-max is removed from multifdsink forcibly. * #GstMultiHandleSink:buffers-max is removed from multifdsink forcibly.
* *
* A client with a lag of at least #GstMultiFdSink:buffers-soft-max enters the recovery * A client with a lag of at least #GstMultiHandleSink:buffers-soft-max enters the recovery
* procedure which is controlled with the #GstMultiFdSink:recover-policy property. * 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 * 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 * received buffer as the next buffer for the client, RESYNC_SOFT_LIMIT
* positions the client to the soft limit in the buffer queue and * positions the client to the soft limit in the buffer queue and

77
gst/tcp/gstmultihandlesink.c
View file

@ -21,83 +21,6 @@
* Boston, MA 02110-1301, USA. * 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 #ifdef HAVE_CONFIG_H
#include "config.h" #include "config.h"

18
gst/tcp/gstmultisocketsink.c
View file

@ -38,7 +38,7 @@
* each descriptor removed, the #GstMultiSocketSink::client-removed signal will be called. The * 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 * #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 * 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. * In all cases, multisocketsink will never close a socket itself.
* The user of multisocketsink is responsible for closing all sockets. * 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. * 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 * client write can block the pipeline and that clients can read with different
* speeds. * 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 * 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 * 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 * 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 * Multisocketsink will always keep at least one keyframe in its internal buffers
* when the sync-mode is set to latest-keyframe. * 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 * property to allow finer control over burst-on-connect behaviour. By selecting
* the 'burst' method a minimum burst size can be chosen, 'burst-keyframe' * the 'burst' method a minimum burst size can be chosen, 'burst-keyframe'
* additionally requires that the burst begin with a keyframe, and * 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 * 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 * 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 * These properties are useful if the application adds clients with the
* #GstMultiSocketSink::add-full signal to make sure that a burst connect can * #GstMultiSocketSink::add-full signal to make sure that a burst connect can
* actually be honored. * actually be honored.
@ -81,12 +81,12 @@
* fast, no data will be send to the client until multisocketsink receives more * 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 * 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 * queued up in multisocketsink. Two properties control the amount of data
* (buffers) that is queued in multisocketsink: #GstMultiSocketSink:buffers-max and * (buffers) that is queued in multisocketsink: #GstMultiHandleSink:buffers-max and
* #GstMultiSocketSink:buffers-soft-max. A client that falls behind by * #GstMultiHandleSink:buffers-soft-max. A client that falls behind by
* #GstMultiSocketSink:buffers-max is removed from multisocketsink forcibly. * #GstMultiHandleSink:buffers-max is removed from multisocketsink forcibly.
* *
* A client with a lag of at least #GstMultiSocketSink:buffers-soft-max enters the recovery * A client with a lag of at least #GstMultiHandleSink:buffers-soft-max enters the recovery
* procedure which is controlled with the #GstMultiSocketSink:recover-policy property. * 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 * 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 * received buffer as the next buffer for the client, RESYNC_SOFT_LIMIT
* positions the client to the soft limit in the buffer queue and * positions the client to the soft limit in the buffer queue and