Gst-nvstreammux New (Beta)

The Gst-nvstreammux plugin forms a batch of frames from multiple input sources. When connecting a source to nvstreammux (the muxer), a new pad must be requested from the muxer using gst_element_get_request_pad() and the pad template sink_%u. For more information, see link_element_to_streammux_sink_pad() in the DeepStream app source code. The muxer forms a batched buffer of batch-size frames. (batch-size is specified using the gst object property.) The muxer forwards the frames from that source as a part of the muxer’s output batched buffer. The frames are returned to the source when muxer gets back its output buffer. The muxer pushes the batch downstream when the batch is filled or the batch formation timeout calculated from the overall and stream specific “fps” control configuration keys in provided streammux config file is reached. The timeout starts running when the first buffer for a new batch is collected. The default overall max and min fps for batch generation are 120 and 5 respectively. The muxer’s default batching uses a round-robin algorithm to collect frames from the sources. It tries to collect an average of ( batch-size/num-source ) frames per batch from each source (if all sources are live and their frame rates are all the same). The number varies for each source, though, depending on the sources’ frame rates. The muxer attaches an NvDsBatchMeta metadata structure to the output batched buffer. This meta contains information about the frames copied into the batch (e.g. source ID of the frame, original resolutions of the input frames, original buffer PTS of the input frames). The source connected to the Sink_N pad will have pad_index N in NvDsBatchMeta. The muxer supports addition and deletion of sources at run time. When the muxer receives a buffer from a new source, it sends a GST_NVEVENT_PAD_ADDED event. When a muxer sink pad is removed, the muxer sends a GST_NVEVENT_PAD_DELETED event. Both events contain the source ID of the source being added or removed (see sources/includes/gst-nvevent.h). Downstream elements can reconfigure when they receive these events. Additionally, the muxer also sends a GST_NVEVENT_STREAM_EOS to indicate EOS from the source. The muxer supports calculation of NTP timestamps for source frames. It supports two modes. In the system timestamp mode, the muxer attaches the current system time as NTP timestamp. In the RTCP timestamp mode, the muxer uses RTCP Sender Report to calculate NTP timestamp of the frame when the frame was generated at source. The NTP timestamp is set in ntp_timestamp field of NvDsFrameMeta. The mode can be toggled by setting the attach-sys-ts property. For more details, refer to :doc: DS_NTP_Timestamp section NTP Timestamp in DeepStream.

Note

New nvstreammux is being released as a beta feature (limited support). Users will be able to use the new streammux by setting the environment variable export USE_NEW_NVSTREAMMUX=yes. The existing nvsteammux shall be employed by default.

Inputs and Outputs

• Inputs

  • NV12/RGBA buffers from an arbitrary number of sources

  • mono S16LE/F32LE audio buffers from an arbitrary number of sources

• Control Parameters

  • batch-size

  • config-file-path [config-keys detailed below]

  • num-surfaces-per-frame

  • attach-sys-ts

• Output

  • NV12/RGBA batched video buffer NvBufSurface or batch audio buffer NvBufAudio

  • GstNvBatchMeta (meta containing information about individual frames in the batched buffer)

Features

The following table summarizes the features of the plugin.

Gst-nvstreammux plugin features

Feature	Description	Release
New streammux with numerous config-keys supported in a separate mux config-file.	Introducing new streammux	DS 5.0
Buffer TimeStamp Synchronization support	Please check sync-inputs and max-latency property documentation	DS 6.0

Note: New nvstreammux do not scale batched buffers to a single resolution. A batch can have buffers from different streams of different resolutions. So with new mux, a single resolution for the batched buffer is invalid and the muxer’s source-pad-caps is not valid either.

Gst Properties

The following table describes the Gst-nvstreammux plugin’s Gst properties.

Gst-nvstreammux gst-properties

Property	Meaning	Type and Range	Example Notes
batch-size	Maximum number of frames in a batch.	Integer, 0 to 4,294,967,295	batch-size=30
num-surfaces-per-frame	If non-zero, muxer scales input frames to this width.	Integer, 0 to 4,294,967,295	num-surfaces-per-frame=1 (Default)
config-file-path	Absolute or relative (to DS config-file location) path of configuration file for the Gst-nvstreammux element	String	config-file-path=config_mux_source30.txt
sync-inputs	Synchronize Inputs. Boolean property to force timestamp sychronization of input frames.	Boolean, 0 or 1	sync-inputs=0 (Default)
max-latency	The maximum upstream latency in nanoseconds. When sync-inputs=1, buffers coming in after max-latency shall be dropped.	Integer, 0 to 4,294,967,295	max-latency=0 (Default)

Differences between default and new streammux with respect to the GStreamer plugin properties are discussed in the table below:

Gst-nvstreammux differences from default nvstreammux

Default nvstreammux Properties	New nvstreammux Properties
batch-size	batch-size
num-surfaces-per-frame	num-surfaces-per-frame
batched-push-timeout	N/A; Streammux config file could be used to regulate output framerate.
width	N/A; Scaling and color conversion support Deprecated.
height	N/A; Scaling and color conversion support Deprecated.
enable-padding	N/A; Scaling and color conversion support Deprecated.
gpu-id	N/A; Accelerated Scaling and color conversion support Deprecated.
live-source	Deprecated
nvbuf-memory-type	N/A
buffer-pool-size	N/A
attach-sys-ts	attach-sys-ts
N/A	config-file-path
sync-inputs	sync-inputs
max-latency	max-latency

Mux Config Properties

Details on Streammux config-file groups and keys are summarized the following table.

Gst-nvstreammux config-file properties

Group	config-key	Description
[property]	algorithm-type	Defines the batching algorithm; uint 1 : Round-robbin if all sources have same priority key setting. Otherwise higher priority streams will be batched until no more buffers from them. Default: 1
	batch-size	The desired batch size; uint. This value will override plugin property and DS config file key “batch-size” for nvstreammux If batch-size not specified in the config-file, plugin property batch-size shall override the default. Default: 1 (or == number of sources if adaptive-batching=1)
	overall-max-fps-n	Numerator of the desired overall muxer output max frame rate fps_n/fps_d; uint Default:120/1
	overall-max-fps-d	Denominator of the desired overall muxer output max frame rate fps_n/fps_d; uint
	overall-min-fps-n	Numerator of the desired overall muxer output min frame rate fps_n/fps_d; uint Default: 5/1
	overall-min-fps-d	Denominator of the desired overall muxer output max frame rate fps_n/fps_d; uint
	max-same-source-frames	Max number of any stream’s frames allowed to be muxed per output batch buffer; uint The minimum of this value and key (max-num-frames-per-batch) will be used. Default: 1
	adaptive-batching	Enable (1) or disable (0) adaptive batching; uint Default: 1 If enabled, batch-size is == number of sources X num-surfaces-per-frame.
[source-config-N]	max-fps-n	Numerator of this source’s max frame rate fps_n/fps_d; uint Default: 60/1
	max-fps-d	Denominator of this source’s max frame rate fps_n/fps_d; uint
	min-fps-n	Numerator of this source’s min frame rate fps_n/fps_d; uint
	min-fps-d	Denominator of this source’s min frame rate fps_n/fps_d; uint
	priority	The priority of this stream; uint Default: 0 (highest priority) A higher value is a lower priority.
	max-num-frames-per-batch	Max number of this stream’s frames allowed to be muxed per output batch buffer; uint The minimum of this value and key (max-same-source-frames) will be used.

NvStreamMux Tuning Solutions for specific usecases

1. Aim

1. nvstreammux provide many knobs to tune the way batching algorithm works. This is essential to support a wide range of applications/use-cases the muxer supports. More documentation is available at Mux Config Properties .

2. Tuning nvstreammux for specific usecases that we work with customers are good learning exercises.

3. Details discussed here include observations, the configs, pipeline changes, etc that worked well for specific use-cases.

4. Users/Contributors - Please feel free to create a New forum Topic with the contribution here

2. Important Tuning parameters

To ensure smooth streaming experience, configure/tune the below parameters properly.

Gst-nvstreammux Tuning parameters

Tuning Use-Case or Mux Config Property used	Notes
nvstreammux/sync-inputs	sync-inputs=1 ensure nvstreammux to queue early buffers. This could be useful in the audio muxer which could be faster than video muxer when reading from files as audio frames are lighter than video frames.
nvstreammux/config-file-path	min-overall-fps and max-overall-fps need to be properly set. The min-overall-fps shall be set to the highest framerate of all sources. b) max-overall-fps shall be >= min-overall-fps Check Mux Config Properties for more information.
nvstreammux/max-latency	Please set/tune the latency parameter to a value > than 1/fps of the slowest stream. Applicable only when sync-inputs=1
Inputs with different frame rates	Highest frame-rate to be considered for overall-min-fps value. e.g. for 2 inputs with 15fps and 30fps each, overall-min-fps=30
Input with varying frame rate	Individual stream’s frame-rate may vary based on network condition. Highest possible to be considered for overall-min-fps value.e.g. For single stream with varying frame-rate of 15fps to 30fps, overall-min-fps=30
Inputs with different bitrates	Nvstreammux will not need specific handling for individual stream bitrates.
Inputs with different resolutions	Please read the section 3. Heterogeneous batching
Dynamic addition/removal of input stream	This is supported by adaptive-batching. With adaptive-batching=1, the Gst application needs to create/destroy sinkpads dynamically for addition/removal respectively.
flvmux/qtmux/latency	The latency parameter (Gst-Property on these plugins when used) shall be set/tuned to a value > nvstreammux/max-latency. The recommended value is 2 X nvstreammux/max-latency User could set “latency=18446744073709551614” (max) to avoid tuning for this parameter.

3. Video + Audio muxing Usecases

When nvstreammux is fed streams with different frame-rates, tuning is necessary to ensure standard muxer behavior. A sample pipeline diagram below illustrates the use of common components like nvstreammux, nvstreamdemux, flv/qtmux, etc. in a video + audio muxing use-case for reference.

When the same pipeline includes two nvstreammux modules to mux video and audio from different sources of different video framerate, depending on the type of sources, behaviour could differ. Some of the scenarios and recommended tuning guidance are discussed below.

3.1 Video and Audio muxing; file sources of different fps

In a single pipeline, we could have file sources with different video framerate, but same audio framerate (typical for most camera footages with reduced video framerate to save bandwidth while keeping the less heavy audio sampling rate intact).

Note:

1) In this scenario, video buffers might get mux’d slower than audio buffers. When this happens GstAggregator based flvmux or qtmux could block the pipeline when the difference between video and audio buffer-timestamps are higher than the set “latency” parameter.

2)  When dealing with file sources/ live sources of different framerates, we need nvstreammux tuned for min-overall-fps. Without this, the muxing always happens at the slowest stream’s framerate adding latency to the video buffers.

3) When dealing with file sources of different frame rates and RTMP sources of different framerates, we recommend users to turn on sync-inputs=1 on nvstreammux and tune proper max-latency to ensure video and audio buffers from a single source are regulated and are flowing together in the pipeline after streammux. This is essential for the proper working of GstAggregator based muxers like flvmux, qtmux. etc.

4. To ensure smooth streaming experience, configure/tune the parameters discussed in Section 2. Important Tuning parameters properly.

3.2 Video and Audio muxing; RTMP/RTSP sources

When using live sources:

1. make sure that nvstreammux/sync-inputs is set to 1.

2) When using RTMP sources, in-built upstream latency query does not work. Thus user need to provide/tune a non-zero nvstreammux/max-latency setting.

3. Tune for nvstreammux/max-latency and other parameters as discussed in Section 2. Important Tuning parameters.

4 Troubleshooting

4.1 GstAggregator plugin -> filesink does not write data into the file

Please try increasing the GstAggregator based flvumx/qtmux “latency” setting. Try “latency=18446744073709551614” - the max value to see if it works and then you could tune for an optimal latency according to the type of media source in use.

Also, set environment variable “export GST_DEBUG=3” for WARNING logs. Please also check Section 4.2 nvstreammux WARNING “Lot of buffers are being dropped”.

4.2 nvstreammux WARNING “Lot of buffers are being dropped”

Please try increasing the max-latency setting to allow late buffers. Please also ensure to set min-overall-fps and max-overall-fps with the nvstreammux config file.

Known Issues and FAQ

1. Observing video and/or audio stutter (low framerate)

Solution:

You’ll need to configure max-latency parameter on nvstreammux when stutters are observed or when pipeline latency is known to be “non-realtime”.

2. Sink plugin shall not move asynchronously to PAUSED

Solution:

When using new nvstreammux in a GStreamer pipeline, the sink elements shall be configured to set the plugin property async to false.

3. Heterogeneous batching

New nvstreammux do not transform/scale batched buffers to a single color-format/resolution unlike the default nvstreammux. A batch can have buffers from different streams of different resolutions and formats. So with new mux, a single resolution for this heterogeneous batched buffer is invalid and the muxer’s source-pad-caps is not valid either.

When we have plugins that could transform the input buffers (example: change resolution or color format of video buffers in the batch) between nvstreammux and nvstreamdemux, we need to ensure nvstreammux output is homogeneous (meaning buffers from all sources in the batch shall have same resolution and color format). This is a limitation in the new nvstreammux and shall be addressed in upcoming releases.

Solution:

In this scenario, DeepStream recommends adding nvvideoconvert + capsfiler before each nvstreammux sink pad (enforcing same resolution and format of all sources connecting to new nvstreammux). This ensure that the heterogeneous nvstreammux batch output have buffers of same caps (resolution and format).

Example; video use-case:

gst-launch-1.0 \
uridecodebin ! nvvideoconvert ! “video/x-raw(memory:NVMM), width=1920, height=1080, format=NV12” ! m.sink_0 \
uridecodebin ! nvvideoconvert ! “video/x-raw(memory:NVMM), width=1920, height=1080, format=NV12” ! m.sink_1 \
nvstreammux name=m batch-size=2 ! fakesink async=0

Where the fixed caps: "1920 X 1080; NV12" ensure every buffer in the batch is transformed to this same caps.

Example; audio use-case:

gst-launch-1.0 \
uridecodebin ! audioconvert ! audioresample ! “audio/x-raw, format=S16LE, layout=interleaved, channels=1, rate=48000” ! m.sink_0 \
uridecodebin ! audioconvert ! audioresample ! “audio/x-raw, format=S16LE, layout=interleaved, channels=1, rate=48000” ! m.sink_1 \
nvstreammux name=m batch-size=2 ! fakesink async=0

Where the fixed caps: "48kHz; mono S16LE interleaved" ensure every buffer in the batch is transformed to this same caps.

4. Adaptive Batching

nvstreammux supports dynamic batching ? This is in the context of use-cases where we don’t know the exact number of inputs initially. Once the pipeline starts, inputs may get connected / disconnected.

Answer:

Yes, nvstreammux support dynamic batch-size when adaptive-batching=1,[property] group in the mux config-file.

When adaptive-batching is enabled, batch-size is equal to the number of source pads on the muxer.

By default this is enabled.

Please refer to Mux Config Properties for more information.