doc: fix element section documentations
Element sections were not rendered anymore after the hotdoc port, fixing this revealed a few incorrect links.
This commit is contained in:
parent
779704b885
commit
1c85065d16
@ -25,8 +25,9 @@
|
|||||||
*
|
*
|
||||||
* This element overlays the current clock time on top of a video
|
* This element overlays the current clock time on top of a video
|
||||||
* stream. You can position the text and configure the font details
|
* stream. You can position the text and configure the font details
|
||||||
* using the properties of the #GstBaseTextOverlay class. By default, the
|
* using its properties.
|
||||||
* time is displayed in the top left corner of the picture, with some
|
*
|
||||||
|
* By default, the time is displayed in the top left corner of the picture, with some
|
||||||
* padding to the left and to the top.
|
* padding to the left and to the top.
|
||||||
*
|
*
|
||||||
* ## Example launch lines
|
* ## Example launch lines
|
||||||
|
@ -25,9 +25,10 @@
|
|||||||
*
|
*
|
||||||
* This element overlays the buffer time stamps of a video stream on
|
* This element overlays the buffer time stamps of a video stream on
|
||||||
* top of itself. You can position the text and configure the font details
|
* top of itself. You can position the text and configure the font details
|
||||||
* using the properties of the #GstBaseTextOverlay class. By default, the
|
* using its properties.
|
||||||
* time stamp is displayed in the top left corner of the picture, with some
|
*
|
||||||
* padding to the left and to the top.
|
* By default, the time stamp is displayed in the top left corner of the picture,
|
||||||
|
* with some padding to the left and to the top.
|
||||||
*
|
*
|
||||||
* |[
|
* |[
|
||||||
* gst-launch-1.0 -v videotestsrc ! timeoverlay ! autovideosink
|
* gst-launch-1.0 -v videotestsrc ! timeoverlay ! autovideosink
|
||||||
|
@ -40,7 +40,7 @@
|
|||||||
* its output while playing.
|
* its output while playing.
|
||||||
*
|
*
|
||||||
* If you want to control the manner in which incoming data gets converted,
|
* If you want to control the manner in which incoming data gets converted,
|
||||||
* see the #GstAudioAggregatorPad:converter-config property, which will let
|
* see the #GstAudioAggregatorConvertPad:converter-config property, which will let
|
||||||
* you for example change the way in which channels may get remapped.
|
* you for example change the way in which channels may get remapped.
|
||||||
*
|
*
|
||||||
* The input pads are from a GstPad subclass and have additional
|
* The input pads are from a GstPad subclass and have additional
|
||||||
|
@ -26,7 +26,7 @@
|
|||||||
* This plugin writes incoming data to a custom GIO #GOutputStream.
|
* This plugin writes incoming data to a custom GIO #GOutputStream.
|
||||||
*
|
*
|
||||||
* It can, for example, be used to write a stream to memory with a
|
* It can, for example, be used to write a stream to memory with a
|
||||||
* #GMemoryOuputStream or to write to a file with a #GFileOuputStream.
|
* #GMemoryOutputStream or to write to a file with a #GFileOutputStream.
|
||||||
*
|
*
|
||||||
* ## Example code
|
* ## Example code
|
||||||
*
|
*
|
||||||
|
@ -45,7 +45,7 @@
|
|||||||
* decodebin3 differs from the previous decodebin (decodebin2) in important ways:
|
* decodebin3 differs from the previous decodebin (decodebin2) in important ways:
|
||||||
*
|
*
|
||||||
* * supports publication and selection of stream information via
|
* * supports publication and selection of stream information via
|
||||||
* GstStreamCollection messages and #GST_EVENT_SELECT_STREAM events.
|
* GstStreamCollection messages and #GST_EVENT_SELECT_STREAMS events.
|
||||||
*
|
*
|
||||||
* * dynamically switches stream connections internally, and
|
* * dynamically switches stream connections internally, and
|
||||||
* reuses decoder elements when stream selections change, so that in
|
* reuses decoder elements when stream selections change, so that in
|
||||||
|
@ -29,11 +29,6 @@
|
|||||||
* (= 408 bytes) and keep the remaining 3 bytes. These will then be prepended to
|
* (= 408 bytes) and keep the remaining 3 bytes. These will then be prepended to
|
||||||
* the next input data.
|
* the next input data.
|
||||||
*
|
*
|
||||||
* The element implements the properties and sink caps configuration as specified
|
|
||||||
* in the #GstRawBaseParse documentation. The properties configuration can be
|
|
||||||
* modified by using the sample-rate, num-channels, channel-positions, format,
|
|
||||||
* and pcm-format properties.
|
|
||||||
*
|
|
||||||
* Currently, this parser supports raw data in a-law, mu-law, or linear PCM format.
|
* Currently, this parser supports raw data in a-law, mu-law, or linear PCM format.
|
||||||
*
|
*
|
||||||
* To facilitate operation with the unalignedaudioparse element, rawaudioparse
|
* To facilitate operation with the unalignedaudioparse element, rawaudioparse
|
||||||
|
@ -30,11 +30,6 @@
|
|||||||
* the second one etc. until the remaining unparsed bytes aren't enough to form
|
* the second one etc. until the remaining unparsed bytes aren't enough to form
|
||||||
* a complete frame, and it will then continue as described in the earlier case.
|
* a complete frame, and it will then continue as described in the earlier case.
|
||||||
*
|
*
|
||||||
* The element implements the properties and sink caps configuration as specified
|
|
||||||
* in the #GstRawBaseParse documentation. The properties configuration can be
|
|
||||||
* modified by using the width, height, pixel-aspect-ratio, framerate, interlaced,
|
|
||||||
* top-field-first, plane-strides, plane-offsets, and frame-size properties.
|
|
||||||
*
|
|
||||||
* If the properties configuration is used, plane strides and offsets will be
|
* If the properties configuration is used, plane strides and offsets will be
|
||||||
* computed by using gst_video_info_set_format(). This can be overridden by passing
|
* computed by using gst_video_info_set_format(). This can be overridden by passing
|
||||||
* GstValueArrays to the plane-offsets and plane-strides properties. When this is
|
* GstValueArrays to the plane-offsets and plane-strides properties. When this is
|
||||||
@ -72,7 +67,6 @@
|
|||||||
* ]|
|
* ]|
|
||||||
* Read raw data from a local file and parse it as video data with 320x240 pixels
|
* Read raw data from a local file and parse it as video data with 320x240 pixels
|
||||||
* and I420 video format. The queue element here is to force push based scheduling.
|
* and I420 video format. The queue element here is to force push based scheduling.
|
||||||
* See the documentation in #GstRawBaseParse for the reason why.
|
|
||||||
*
|
*
|
||||||
*/
|
*/
|
||||||
|
|
||||||
|
@ -26,8 +26,8 @@
|
|||||||
* @title: multisocketsink
|
* @title: multisocketsink
|
||||||
* @see_also: tcpserversink
|
* @see_also: tcpserversink
|
||||||
*
|
*
|
||||||
* This plugin writes incoming data to a set of file descriptors. The
|
* This plugin writes incoming data to a set of sockets. The
|
||||||
* file descriptors can be added to multisocketsink by emitting the #GstMultiSocketSink::add signal.
|
* sockets can be added to multisocketsink by emitting the #GstMultiSocketSink::add signal.
|
||||||
* For each descriptor added, the #GstMultiSocketSink::client-added signal will be called.
|
* For each descriptor added, the #GstMultiSocketSink::client-added signal will be called.
|
||||||
*
|
*
|
||||||
* A client can also be added with the #GstMultiSocketSink::add-full signal
|
* A client can also be added with the #GstMultiSocketSink::add-full signal
|
||||||
@ -39,14 +39,14 @@
|
|||||||
* #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.
|
* #GstMultiSocketSink:recover-policy property, if the client is reading too slowly.
|
||||||
* In all cases, multisocketsink will never close a file descriptor itself.
|
* In all cases, multisocketsink will never close a socket itself.
|
||||||
* The user of multisocketsink is responsible for closing all file descriptors.
|
* The user of multisocketsink is responsible for closing all sockets.
|
||||||
* This can for example be done in response to the #GstMultiSocketSink::client-fd-removed signal.
|
* This can for example be done in response to the #GstMultiSocketSink::client-socket-removed signal.
|
||||||
* Note that multisocketsink still has a reference to the file descriptor when the
|
* Note that multisocketsink still has a reference to the socket when the
|
||||||
* #GstMultiSocketSink::client-removed signal is emitted, so that "get-stats" can be performed on
|
* #GstMultiSocketSink::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 descriptor; it is therefore not safe to close the socket in
|
||||||
* the #GstMultiSocketSink::client-removed signal handler, and you should use the
|
* the #GstMultiSocketSink::client-removed signal handler, and you should use the
|
||||||
* #GstMultiSocketSink::client-fd-removed signal to safely close the fd.
|
* #GstMultiSocketSink::client-socket-removed signal to safely close the socket.
|
||||||
*
|
*
|
||||||
* Multisocketsink internally keeps a queue of the incoming buffers and uses a
|
* 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
|
* separate thread to send the buffers to the clients. This ensures that no
|
||||||
|
Loading…
x
Reference in New Issue
Block a user