[BUG] nvmultiurisrcbin RTSP: nvv4l2decoder → internal nvstreammux deadlock

[manuelstein]

Describe the bug
With a healthy live RTSP camera (H.264 1920×1080) as the source — whether added via the
REST API after PLAYING or provided in uri-list at startup — no frame ever leaves the
bin. Buffer-counting pad probes placed on the internal elements show:

rtph264depay.src = 12    nvv4l2decoder.sink = 1    nvv4l2decoder.src = 0    nvstreammux(src_bin_muxer).src = 0

GST_DEBUG=nvv4l2decoder:5,v4l2videodec:5 confirms the decoder negotiates caps and parses
SPS, then stalls:

v4l2videodec gst_v4l2_video_dec_sink_getcaps:<nvv4l2decoder0> Returning sink caps
  video/x-h264, width=1920, height=1080, stream-format=byte-stream, alignment=au, parsed=true, profile=main, level=4
v4l2videodec gst_h264_parse_process_nal:<nvv4l2decoder0> GOT SPS frame
v4l2videodec gst_v4l2_h264_stream_parser:<nvv4l2decoder0> sps width = 1920 height = 1088
# ... no capture-plane setup, no decoded output ...

About 15 s later the application deadlocks: the GMainLoop stops servicing timers for
minutes while the thread count stays flat (a deadlock, not a busy loop). rtspsrc then logs
only:

rtspsrc gst_rtspsrc_loop_interleaved:<src> timeout, sending keep-alive

and the RTSP server's outbound byte counter to our reader freezes — i.e. the pipeline
stopped draining the socket (backpressure from the stuck decoder).

We also see, at startup, the looping test camera producing non-monotonic RTP timestamps:

rtpjitterbuffer rtp_jitter_buffer_calculate_pts: backward timestamps at server, schedule resync

Isolation (this is the key part)

Pipeline	Result
nvmultiurisrcbin ! fakesink (no downstream graph)	same deadlock → not caused by downstream elements
rtspsrc ! rtph264depay ! h264parse ! fakesink (no decoder)	continuous data (server sent +37.5 MB) → source is healthy
rtspsrc ! rtph264depay ! h264parse ! nvv4l2decoder ! fakesink (decoder, no mux)	continuous data + decoded frames (server sent +11 MB) → decoder is healthy
nvmultiurisrcbin (decoder → internal nvstreammux)	deadlock, 0 decoded frames

So the source and nvv4l2decoder are both fine standalone; only the
decoder → internal nvstreammux coupling inside nvmultiurisrcbin deadlocks.

Mitigations attempted — none worked

• rtsp-reconnect-interval=10 (default is 0) — source connects, still 0 decoded frames.
• USE_NEW_NVSTREAMMUX=no — deadlock persists.
• max-batch-size=1 — deadlock persists.
• live-source=1 (already set), drop-pipeline-eos=1, async-handling=TRUE,
  disable-audio=TRUE — no effect.

Steps/Code to reproduce bug
Reproduce (inside the DS 9.0 container)

# Deadlocks: nothing decoded
gst-launch-1.0 nvmultiurisrcbin port=9000 ip-address=localhost \
  batched-push-timeout=33333 max-batch-size=4 live-source=1 drop-pipeline-eos=1 \
  rtsp-reconnect-interval=10 width=1920 height=1080 \
  uri-list=rtsp://<your-rtsp>/cam1 ! fakesink sync=0

# Works (manual decode path, same source):
gst-launch-1.0 rtspsrc location=rtsp://<your-rtsp>/cam1 protocols=tcp \
  ! rtph264depay ! h264parse ! nvv4l2decoder ! fakesink sync=0

Expected behavior
no deadlock

Environment details (please complete the following information):
• Hardware Platform (Jetson / GPU): GPU (x86_64, dGPU)
• DeepStream Version: 9.0
• TensorRT Version: 10.14.x (DS 9.0 default)
• NVIDIA GPU Driver Version: 595.71.05
• CUDA Version: 13.x (DS 9.0 default)
• Issue Type: bug
• Containerized: yes (DeepStream 9.0 base image), Kubernetes

Additional context

1. Is there a known deadlock between nvv4l2decoder's capture-plane allocation and
   nvmultiurisrcbin's internal nvstreammux in DS 9.0?
2. Does a live source emitting non-monotonic RTP timestamps (looping server) trigger the
   internal mux to stall on the first batch? Is there a property to relax this?
3. Is there a supported configuration that makes nvmultiurisrcbin deliver frames from a
   live RTSP source, or is the recommended path explicit nvurisrcbin + app-owned
   nvstreammux?

---

By submitting this issue, you agree to follow our code of conduct and our contribution guidelines.