Gstreamer-element-queue/queue2/multiqueue

本文链接：https://blog.csdn.net/knowledgebao/article/details/86214932

queue/queue2/multiqueue

queue:

queue只有一个src pad和一个sink pad，会在src pad上创建一个线程，减少src和sink的关联。queue有三个限制参数buffers、bytes、time(单位纳秒ns)。有最大阀值和最小阀值供6个参数。最大默认值：200 buffers、10MB、one second，最小默认值都是0.

当三个限制参数某一个达到最大值的时候，会阻塞上游的链路传输（可以通过设置属性 “leaky” property 来处理阻塞情况，分为上游丢弃或下游丢弃或不丢弃阻塞）。“overrun” signal会被发送，当数据达到最高阀值的时候，“underrun” signal 会被发送，当数据达到最低阀值的时候。

“current-level-buffers” property可以获取当前buffers的个数。notify::current-level-buffers signal 可以监听buffers的变动。bytes和time也有类似的属性和信号。

queue2:

和queue的区别如下：

默认值不同：最大值：100 buffers, 2MB, two seconds，最小值默认都是0.
增加了temp-template属性比如：/tmp/gstreamer-XXXXXX，设置此属性后，数据会被保存到文件中，具体文件名可以通过属性temp-location获取。
一些属性发生了变化，比如：只有“overrun” 信号，增加循环buf，增加GST_MESSAGE_BUFFERING消息等

multiqueue：

和queue的区别如下：

src pad和sink pad由1个变成了多个。When requesting a given sinkpad with gst_element_request_pad(), the associated srcpad for that stream will be created. 如果stream超过一个，对应的queue也会增长，保证不会饿死。
当src pad没有下游连接的时候，sink pad的内容也会发给src pad。sink pad和src pad总是成对出现，创建sink pad的时候回同步创建src pad。当src pad和下游处于unlink的时候，buffers和envet由sink pad发送给src pad的时候必须按照先后顺序发送。针对这样情况有一个属性“sync-by-running-time”，当此属性设置为true时，非link的stream也会参考link的stream的runing time来同步。
默认值不同：最大值：5 buffers, 10MB, two second ，最小值默认都是0.
The “underrun” signal is emitted when all of the queues are empty. The “overrun” signal is emitted when one of the queues is filled.
当有多个src pad的时候，对应多个线程，类似于多个queue，其中max-size-buffers等也有多份，只不过都相同而已。

queue：内存单队列

Object Hierarchy

    GObject
    ╰── GInitiallyUnowned
        ╰── GstObject
            ╰── GstElement
                ╰── GstQueue

Properties

guint	current-level-buffers	Read	当前队列中buffers大小
guint	current-level-bytes	Read	当前队列中bytes大小
guint64	current-level-time	Read	当前队列中包含数据time大小，单位ns
gboolean	flush-on-eos	Read / Write	是否支持eos events处理。
GstQueueLeaky	leaky	Read / Write	queue满时的处理策略。阻塞，扔新数据，扔旧数据
guint	max-size-buffers	Read / Write	queue中允许的最大buffers
guint	max-size-bytes	Read / Write	queue中允许的最大bytes
guint64	max-size-time	Read / Write	queue中允许的最大time，单位ns
guint	min-threshold-buffers	Read / Write	queue中允许发送的最小buffers
guint	min-threshold-bytes	Read / Write	queue中允许发送的最小bytes
guint64	min-threshold-time	Read / Write	queue中允许发送的最小time
gboolean	silent	Read / Write	是否支持发送信号，默认为FALSE

Signals

void	overrun	Run First	queue满时发送的信号，silent必须为TRUE(下同)
void	pushing	Run First	queue由空闲变为有数据时发送的信号。
void	running	Run First	当queue阻塞且由满变为有空闲的时候发送。或pushing满足的时候也发送。
void	underrun	Run First	queue三个限制条件都低于给定值时发送的信号

Types and Values

struct

GstQueue

Opaque GstQueue structure.透明结构体，无需了解

enum

GstQueueLeaky

GST_QUEUE_NO_LEAK阻塞

GST_QUEUE_LEAK_UPSTREAM丢新数据

GST_QUEUE_LEAK_DOWNSTREAM丢旧数据

Description

Data is queued until one of the limits specified by the “max-size-buffers”, “max-size-bytes” and/or “max-size-time”properties has been reached. Any attempt to push more buffers into the queue will block the pushing thread until more space becomes available.

The queue will create a new thread on the source pad to decouple the processing on sink and source pad.

You can query how many buffers are queued by reading the “current-level-buffers” property. You can track changes by connecting to the notify::current-level-buffers signal (which like all signals will be emitted from the streaming thread). The same applies to the “current-level-time” and “current-level-bytes” properties.

The default queue size limits are 200 buffers, 10MB of data, or one second worth of data, whichever is reached first.

As said earlier, the queue blocks by default when one of the specified maximums (bytes, time, buffers) has been reached. You can set the “leaky” property to specify that instead of blocking it should leak (drop) new or old buffers.

The “underrun” signal is emitted when the queue has less data than the specified minimum thresholds require (by default: when the queue is empty). The “overrun” signal is emitted when the queue is filled up. Both signals are emitted from the context of the streaming thread.

Synopsis

Element Information

plugin	coreelements
author	Erik Walthinsen <omega@cse.ogi.edu>
class	Generic

Element Pads

name	sink
direction	sink
presence	always
details	ANY

name	src
direction	source
presence	always
details	ANY

queue2：文件单队列

Object Hierarchy

    GObject
    ╰── GInitiallyUnowned
        ╰── GstObject
            ╰── GstElement
                ╰── GstQueue2

Properties

guint	current-level-buffers	Read	参考queue
guint	current-level-bytes	Read	参考queue
guint64	current-level-time	Read	参考queue
gint	high-percent	Read / Write	废弃，Deprecated: use high-watermark instead
gint	low-percent	Read / Write	废弃，Deprecated: use low-watermark instead
guint	max-size-buffers	Read / Write	参考queue
guint	max-size-bytes	Read / Write	参考queue
guint64	max-size-time	Read / Write	参考queue
guint64	ring-buffer-max-size	Read / Write	循环buf的最大个数，为0不用循环buf
gchar *	temp-location	Read	文件名，系统根据temp-template生成
gboolean	temp-remove	Read / Write	使用完成后，清除临时文件
gchar *	temp-template	Read / Write	设置生成文件模板，类似：/tmp/gstreamer-XXXXXX
gboolean	use-buffering	Read / Write	是否发送 GST_MESSAGE_BUFFERING消息。
gboolean	use-rate-estimate	Read / Write	Estimate the bitrate of the stream to calculate time level.
gint64	avg-in-rate	Read	The average input data rate.
gboolean	use-tags-bitrate	Read / Write	Use a bitrate from upstream tags to estimate buffer duration if not provided.
gdouble	high-watermark	Read / Write	触发GST_MESSAGE_BUFFERING消息的上限[0~1],默认0.99
gdouble	low-watermark	Read / Write	触发GST_MESSAGE_BUFFERING消息的下限[0~1],默认0.01

Signals

void

overrun

Run First

参考queue

Types and Values

struct

GstQueue2

Opaque GstQueue2 structure.透明结构体，无需了解

Description

The queue will create a new thread on the source pad to decouple the processing on sink and source pad.

You can query how many buffers are queued by reading the “current-level-buffers” property.

The default queue size limits are 100 buffers, 2MB of data, or two seconds worth of data, whichever is reached first.

If you set temp-template to a value such as /tmp/gstreamer-XXXXXX, the element will allocate a random free filename and buffer data in the file. By using this, it will buffer the entire stream data on the file independently of the queue size limits, they will only be used for buffering statistics.

The temp-location property will be used to notify the application of the allocated filename.

Synopsis

Element Information

plugin	coreelements
author	Erik Walthinsen <omega@cse.ogi.edu>, Wim Taymans <wim.taymans@gmail.com>
class	Generic

Element Pads

name	sink
direction	sink
presence	always
details	ANY

name	src
direction	source
presence	always
details	ANY

multiqueue：内存多队列

Object Hierarchy

    GObject
    ╰── GInitiallyUnowned
        ╰── GstObject
            ╰── GstElement
                ╰── GstMultiQueue

Properties

guint	extra-size-buffers	Read / Write	暂时未实现
guint	extra-size-bytes	Read / Write	暂时未实现
guint64	extra-size-time	Read / Write	暂时未实现
gint	high-percent	Read / Write	类似high-watermark，取值范围[0,100]，queue2此值以放弃
gint	low-percent	Read / Write	类似low-watermark，取值范围[0,100]，queue2此值以放弃
guint	max-size-buffers	Read / Write	参考queue
guint	max-size-bytes	Read / Write	参考queue
guint64	max-size-time	Read / Write	参考queue
gboolean	sync-by-running-time	Read / Write	`设置为true时，非link的stream也会参考link的stream的runing time来同步`
gboolean	use-buffering	Read / Write	参考queue2
guint64	unlinked-cache-time	Read / Write	Extra buffering in time for unlinked streams (if 'sync-by-running-time').Default value: 250000000
gboolean	use-interleave	Read / Write	Adjust time limits based on input interleave.是否使用interleave.multiqueue: New "use-interleave" property which allows the size of the queues to be optimized based on the input streams interleave. This should only be used with input streams which are properly timestamped. It will be used in the future decodebin3 element.
gdouble	high-watermark	Read / Write	参考queue2
gdouble	low-watermark	Read / Write	参考queue2
guint64	min-interleave-time	Read / Write	Minimum extra buffering for deinterleaving (size of the queues) when use-interleave=true.

Signals

void	overrun	Run First	参考queue,任意一个满都触发
void	underrun	Run First	参考queue,所有都不足才触发

Types and Values

struct

GstMultiQueue

Opaque GstMultiQueue structure.透明结构体，无需了解

Description

Multiqueue is similar to a normal GstQueue with the following additional features:

1) Multiple streamhandling

The element handles queueing data on more than one stream at once. To achieve such a feature it has request sink pads (sinku) and 'sometimes' src pads (srcu). When requesting a given sinkpad with gst_element_request_pad(), the associated srcpad for that stream will be created. Example: requesting sink1 will generate src1.

2) Non-starvation on multiple stream

If more than one stream is used with the element, the streams' queues will be dynamically grown (up to a limit), in order to ensure that no stream is risking data starvation. This guarantees that at any given time there are at least N bytes queued and available for each individual stream. If an EOS event comes through a srcpad, the associated queue will be considered as 'not-empty' in the queue-size-growing algorithm.

3) Non-linked srcpads graceful handling

In order to better support dynamic switching between streams, the multiqueue (unlike the current GStreamer queue) continues to push buffers on non-linked pads rather than shutting down. In addition, to prevent a non-linked stream from very quickly consuming all available buffers and thus 'racing ahead' of the other streams, the element must ensure that buffers and inlined events for a non-linked stream are pushed in the same order as they were received, relative to the other streams controlled by the element. This means that a buffer cannot be pushed to a non-linked pad any sooner than buffers in any other stream which were received before it.

“extra-size-bytes” and “extra-size-time” are currently unused.

The default queue size limits are 5 buffers, 10MB of data, or two second worth of data, whichever is reached first. Note that the number of buffers will dynamically grow depending on the fill level of other queues.

The “underrun” signal is emitted when all of the queues are empty. The “overrun” signal is emitted when one of the queues is filled. Both signals are emitted from the context of the streaming thread.

When using “sync-by-running-time” the unlinked streams will be throttled by the highest running-time of linked streams. This allows further relinking of those unlinked streams without them being in the future (i.e. to achieve gapless playback). When dealing with streams which have got different consumption requirements downstream (ex: video decoders which will consume more buffer (in time) than audio decoders), it is recommended to group streams of the same type by using the pad "group-id" property. This will further throttle streams in time within that group.