Tee and nvstreamdemux changes between DeepStream 6.0 and 6.2

Accelerated Computing Intelligent Video Analytics DeepStream SDK
1

Hardware platform: Jetson Xavier NX
Software version:
config A: Jetpack 4.6.4 + DeepStream 6.0.1 + TensorRT 8.2.1.9
config B: Jetpack 5.1 + DeepStream 6.2.0 + TensorRT 8.5.2.2
Issue type: question

Hi!
I’m trying to build a pipeline which splits the batched stream into two sub-streams and then demuxes the batched sub-streams, but have trouble migrating from DeepStream 6.0 to DeepStream 6.2.

My pipeline (see sample pipeline 1 below) works with DeepStream 6.0 (config A) but not with DeepStream 6.2 (config B).
Curiously,
-changing the order from tee->demux to demux->tee makes the pipeline work (see sample pipeline 2 below).
-changing the number of sub-streams from 2 to 1 makes the pipeline work (see sample pipeline 3 below).
Now, what I would like to know:
-what is wrong with sample pipeline 1 ?
-which gstreamer element causes the issue, and in what way has it changed between DeepStream versions 6.0 and 6.2 ?
-is there any official documentation (where?) that details the changes that caused the issue?

Note: I use “deepstream-6.2” folder in the paths (for models and video files) of the sample pipelines below.
When running with DeepStream 6.0, the folder paths need to be adjusted to “deepstream-6.0”.

Pipeline 1 (tee then 2x demux)(works with config A, but never completes with config B)
(when interrupting with ctrl+c on config B, console says ‘pipeline doesnt want to preroll’):

 gst-launch-1.0 -vvv \
 filesrc location=/opt/nvidia/deepstream/deepstream-6.2/samples/streams/sample_720p.h264 ! \
 h264parse ! nvv4l2decoder ! m.sink_0 nvstreammux name=m batch-size=1 width=1920 height=1080 ! \
 nvinfer config-file-path=/opt/nvidia/deepstream/deepstream-6.2/samples/configs/deepstream-app/config_infer_primary.txt ! \
 nvvideoconvert ! nvdsosd ! nvvideoconvert ! 'video/x-raw(memory:NVMM),format=I420' ! \
 t.sink tee name=t \
 t.src_0 ! d0.sink nvstreamdemux name=d0 \
 t.src_1 ! d1.sink nvstreamdemux name=d1 \
 d0.src_0 ! nvv4l2h264enc ! h264parse ! filesink location=test3.mp4 \
 d1.src_0 ! nvv4l2h264enc ! h264parse ! filesink location=test4.mp4

Pipeline 2 (first demux then tee)(works with config A and B):

 gst-launch-1.0 -vvv \
 filesrc location=/opt/nvidia/deepstream/deepstream-6.2/samples/streams/sample_720p.h264 ! \
 h264parse ! nvv4l2decoder ! m.sink_0 nvstreammux name=m batch-size=1 width=1920 height=1080 ! \
 nvinfer config-file-path=/opt/nvidia/deepstream/deepstream-6.2/samples/configs/deepstream-app/config_infer_primary.txt ! \
 nvvideoconvert ! nvdsosd ! nvvideoconvert ! 'video/x-raw(memory:NVMM),format=I420' ! \
 d.sink nvstreamdemux name=d \
 d.src_0 ! t.sink tee name=t \
 t.src_0 ! nvv4l2h264enc ! h264parse ! filesink location=test1.mp4 \
 t.src_1 ! nvv4l2h264enc ! h264parse ! filesink location=test2.mp4

Pipeline 3 (tee then 1x demux)(works with config A and B):

 gst-launch-1.0 -vvv \
 filesrc location=/opt/nvidia/deepstream/deepstream-6.2/samples/streams/sample_720p.h264 ! \
 h264parse ! nvv4l2decoder ! m.sink_0 nvstreammux name=m batch-size=1 width=1920 height=1080 ! \
 nvinfer config-file-path=/opt/nvidia/deepstream/deepstream-6.2/samples/configs/deepstream-app/config_infer_primary.txt ! \
 nvvideoconvert ! nvdsosd ! nvvideoconvert ! 'video/x-raw(memory:NVMM),format=I420' ! \
 t.sink tee name=t \
 t.src_0 ! d0.sink nvstreamdemux name=d0 \
 d0.src_0 ! nvv4l2h264enc ! h264parse ! filesink location=test3.mp4
3

Why do you want to use nvstreamdemux since you only have one source with pipeline 1? Could you describe your use case？

4

Thanks for your reply!
In my application, the number of sources is actually a variable, and the pipeline is dynamically constructed using nvstreammux … nvstreamdemux, as appropriate.
Pipeline 1 is just meant for illustrating the problem in a readable, reproducible form.
To my understanding, a pipeline with nvstreammux … nvstreamdemux should work both for single source scenarios as well as for multi source scenarios.

5

OK. Your question is somewhat similar to the following topic: 256605. We are currently analyzing this issue and will verify it together once it is resolved.