multiqueue

Multiqueue is similar to a normal queue 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 (sink%u) and 'sometimes' src pads (src%u). 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.
  1. 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.
  1. 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.

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. extra-size-buffers,

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.

Hierarchy

GObject
    ╰──GInitiallyUnowned
        ╰──GstObject
            ╰──GstElement
                ╰──multiqueue

Factory details

Authors: – Edward Hervey

Classification: – Generic

Rank – none

Plugin – coreelements

Package – GStreamer

Pad Templates

sink_%u

ANY

Presence – request

Direction – sink

Object type – GstMultiQueuePad

src_%u

ANY

Presence – sometimes

Direction – src

Object type – GstMultiQueuePad

Signals

overrun 

overrun_callback (GstElement * multiqueue,
                  gpointer udata)
def overrun_callback (multiqueue, udata):
    #python callback for the 'overrun' signal
function overrun_callback(multiqueue: GstElement * multiqueue, udata: gpointer udata): {
    // javascript callback for the 'overrun' signal
}

Reports that one of the queues in the multiqueue is full (overrun). A queue is full if the total amount of data inside it (num-buffers, time, size) is higher than the boundary values which can be set through the GObject properties.

This can be used as an indicator of pre-roll.

Parameters:

multiqueue –

the multiqueue instance

udata –
No description available

Flags: Run First

underrun 

underrun_callback (GstElement * multiqueue,
                   gpointer udata)
def underrun_callback (multiqueue, udata):
    #python callback for the 'underrun' signal
function underrun_callback(multiqueue: GstElement * multiqueue, udata: gpointer udata): {
    // javascript callback for the 'underrun' signal
}

This signal is emitted from the streaming thread when there is no data in any of the queues inside the multiqueue instance (underrun).

This indicates either starvation or EOS from the upstream data sources.

Parameters:

multiqueue –

the multiqueue instance

udata –
No description available

Flags: Run First

Properties

extra-size-buffers 

“extra-size-buffers” guint

Amount of buffers the queues can grow if one of them is empty (0=disable) (NOT IMPLEMENTED)

Flags : Read / Write

Default value : 5

extra-size-bytes 

“extra-size-bytes” guint

Amount of data the queues can grow if one of them is empty (bytes, 0=disable) (NOT IMPLEMENTED)

Flags : Read / Write

Default value : 10485760

extra-size-time 

“extra-size-time” guint64

Amount of time the queues can grow if one of them is empty (in ns, 0=disable) (NOT IMPLEMENTED)

Flags : Read / Write

Default value : 3000000000

high-percent 

“high-percent” gint

High threshold percent for buffering to finish.

Flags : Read / Write

Default value : 99

high-watermark 

“high-watermark” gdouble

High threshold watermark for buffering to finish.

Flags : Read / Write

Default value : 0.99

Since : 1.10

low-percent 

“low-percent” gint

Low threshold percent for buffering to start.

Flags : Read / Write

Default value : 1

low-watermark 

“low-watermark” gdouble

Low threshold watermark for buffering to start.

Flags : Read / Write

Default value : 0.01

Since : 1.10

max-size-buffers 

“max-size-buffers” guint

Max. number of buffers in the queue (0=disable)

Flags : Read / Write

Default value : 5

max-size-bytes 

“max-size-bytes” guint

Max. amount of data in the queue (bytes, 0=disable)

Flags : Read / Write

Default value : 10485760

max-size-time 

“max-size-time” guint64

Max. amount of data in the queue (in ns, 0=disable)

Flags : Read / Write

Default value : 2000000000

min-interleave-time 

“min-interleave-time” guint64

Minimum extra buffering for deinterleaving (size of the queues) when use-interleave=true

Flags : Read / Write

Default value : 250000000

stats 

“stats” GstStructure *

Various multiqueue statistics. This property returns a GstStructure with name "application/x-gst-multi-queue-stats" with the following fields:

  • "queues" GST_TYPE_ARRAY Contains one GstStructure named "queue_%d" (where %d is the queue's ID) per internal queue:
    • "buffers" G_TYPE_UINT The queue's current level of buffers
    • "bytes" G_TYPE_UINT The queue's current level of bytes
    • "time" G_TYPE_UINT64 The queue's current level of time

Flags : Read

Default value : 

application/x-gst-multi-queue-stats;

Since : 1.18

sync-by-running-time 

“sync-by-running-time” gboolean

If enabled multiqueue will synchronize deactivated or not-linked streams to the activated and linked streams by taking the running time. Otherwise multiqueue will synchronize the deactivated or not-linked streams by keeping the order in which buffers and events arrived compared to active and linked streams.

Flags : Read / Write

Default value : false

unlinked-cache-time 

“unlinked-cache-time” guint64

Extra buffering in time for unlinked streams (if 'sync-by-running-time')

Flags : Read / Write

Default value : 250000000

use-buffering 

“use-buffering” gboolean

Enable the buffering option in multiqueue so that BUFFERING messages are emitted based on low-/high-percent thresholds.

Flags : Read / Write

Default value : false

use-interleave 

“use-interleave” gboolean

Adjust time limits based on input interleave

Flags : Read / Write

Default value : false

The results of the search are