Multiurisrcbin element issues with remove/add functionality

Environment

• Hardware Platform (Jetson / GPU) AGX orin
• DeepStream Version 7.1
• JetPack Version (valid for Jetson only) 6.2 (L4T 36.4.3)

Issue Description

I’ve setup a pipeline of 3 cameras using multiurisrcbin and it works as intended initially. However, after testing REST API remove/add functionality on one of the already started cameras, I’m experiencing the following issues:

  • Initially, camera removal and addition works properly without FPS loss in most cases
  • Sometimes the FPS drops from 10 FPS to around 4.7 FPS (possibly due to muxing issues)
  • After one or maximum two more remove/add operations on the same camera, my pipeline receives an EOS message and shuts down

API Calls Used

For reference, here are the API calls I’m using to remove and add the camera streams:

Remove Camera API Call:

curl -XPOST 'http://localhost:9000/api/v1/stream/remove' -d '{
  "key": "sensor",
  "value": {
      "camera_id": "CAMERA_NAME",
      "camera_name": "CAMERA_NAME",
      "camera_url": "rtsp://x.x.x.x,
      "change": "camera_remove",
      "metadata": {
          "resolution": "1280 x720",
          "codec": "h264",
          "framerate": 10
      }
  },
  "headers": {
      "source": "vst",
      "created_at": "2021-06-01T14:34:13.417Z"
  }
}'

Add Camera API Call:

curl -XPOST 'http://localhost:9000/api/v1/stream/add' -d '{
  "key": "sensor",
  "value": {
      "camera_id": "CAMERA_NAME",
      "camera_name": "CAMERA_NAME",
      "camera_url": "rtsp://x.x.x.x,
      "change": "camera_add",
      "metadata": {
          "resolution": "1280 x720",
          "codec": "h264",
          "framerate": 10
      }
  },
  "headers": {
      "source": "vst",
      "created_at": "2021-06-01T14:34:13.417Z"
  }
}'

Debug Logs

When removing a camera source with debug enabled, I get these errors:

uri:/api/v1/stream/remove
method:POST
0:00:41.213847908  1570 0xffff50004270 WARN                 rtspsrc gstrtspsrc.c:6526:gst_rtsp_src_receive_response:<src> receive interrupted
0:00:41.213904389  1570 0xffff50004270 WARN                 rtspsrc gstrtspsrc.c:6624:gst_rtspsrc_try_send:<src> receive interrupted
0:00:41.213925157  1570 0xffff50004270 WARN                 rtspsrc gstrtspsrc.c:9037:gst_rtspsrc_pause:<src> PAUSE interrupted
0:00:41.327538335  1570 0xffff24006640 ERROR          v4l2allocator gstv4l2allocator.c:1398:gst_v4l2_allocator_qbuf:<nvv4l2decoder3:pool:src:allocator> failed queueing buffer 4: Bad file descriptor
0:00:41.327603551  1570 0xffff24006640 ERROR         v4l2bufferpool gstv4l2bufferpool.c:1498:gst_v4l2_buffer_pool_qbuf:<nvv4l2decoder3:pool:src> could not queue a buffer 4
0:00:41.327647744  1570 0xffff24006640 ERROR          v4l2allocator gstv4l2allocator.c:1398:gst_v4l2_allocator_qbuf:<nvv4l2decoder3:pool:src:allocator> failed queueing buffer 1: Bad file descriptor
0:00:41.327660576  1570 0xffff24006640 ERROR         v4l2bufferpool gstv4l2bufferpool.c:1498:gst_v4l2_buffer_pool_qbuf:<nvv4l2decoder3:pool:src> could not queue a buffer 1
0:00:41.418268697  1570 0xffff50008fe0 ERROR          v4l2allocator gstv4l2allocator.c:1398:gst_v4l2_allocator_qbuf:<nvv4l2decoder3:pool:src:allocator> failed queueing buffer 3: Bad file descriptor
0:00:41.418329049  1570 0xffff50008fe0 ERROR         v4l2bufferpool gstv4l2bufferpool.c:1498:gst_v4l2_buffer_pool_qbuf:<nvv4l2decoder3:pool:src> could not queue a buffer 3
0:00:41.419896548  1570 0xffff50008fe0 WARN           v4l2allocator gstv4l2allocator.c:840:gst_v4l2_allocator_stop:<nvv4l2decoder3:pool:src:allocator> error releasing buffers buffers: Bad file descriptor

And right before EOS I get:

uri:/api/v1/stream/remove
method:POST
0:00:56.789463455  1570 0xffff1c006640 ERROR          v4l2allocator gstv4l2allocator.c:1398:gst_v4l2_allocator_qbuf:<nvv4l2decoder4:pool:src:allocator> failed queueing buffer 3: Bad file descriptor
0:00:56.789530394  1570 0xffff1c006640 ERROR         v4l2bufferpool gstv4l2bufferpool.c:1498:gst_v4l2_buffer_pool_qbuf:<nvv4l2decoder4:pool:src> could not queue a buffer 3
0:00:56.789574359  1570 0xffff1c006640 ERROR          v4l2allocator gstv4l2allocator.c:1398:gst_v4l2_allocator_qbuf:<nvv4l2decoder4:pool:src:allocator> failed queueing buffer 4: Bad file descriptor
0:00:56.789592533  1570 0xffff1c006640 ERROR         v4l2bufferpool gstv4l2bufferpool.c:1498:gst_v4l2_buffer_pool_qbuf:<nvv4l2decoder4:pool:src> could not queue a buffer 4
End-Of-Stream reached
Setting pipeline to NULL state...
0:00:56.884911997  1570 0xaaaaedecc520 ERROR          v4l2allocator gstv4l2allocator.c:1398:gst_v4l2_allocator_qbuf:<nvv4l2decoder4:pool:src:allocator> failed queueing buffer 2: Bad file descriptor
0:00:56.884965914  1570 0xaaaaedecc520 ERROR         v4l2bufferpool gstv4l2bufferpool.c:1498:gst_v4l2_buffer_pool_qbuf:<nvv4l2decoder4:pool:src> could not queue a buffer 2
0:00:56.886487435  1570 0xaaaaedecc520 WARN           v4l2allocator gstv4l2allocator.c:840:gst_v4l2_allocator_stop:<nvv4l2decoder4:pool:src:allocator> error releasing buffers buffers: Bad file descriptor
0:00:56.887670614  1570 0xffff50008fe0 ERROR                default gstnvstreammux_pads.cpp:338:push:<src_bin_muxer> push failed [-3]

0:00:56.936155070  1570 0xffff5000a0d0 WARN            videodecoder gstvideodecoder.c:3158:gst_video_decoder_prepare_finish_frame:<nvv4l2decoder0> decreasing timestamp (0:00:51.416019804 < 0:00:52.913709970)
Stopping the server..!! 
Stopped the server..!! 
Pipeline stopped

Additional Information

  • The EOS only happens after restarting a camera 2 or 3 times, not on the initial remove/add cycle
  • For testing simplicity, my current pipeline is just multiurisrcbin with 3 cameras linked to fakesink with a probe connected to retrieve batched meta for FPS counting
  • Changing to another camera source shows same behaviour

Is this usual behavior, or is something wrong with my setup? Also, any suggestions on how to solve the occasional FPS drop issue would be appreciated.

Can you simplify your source code and attach it? If it is C/C++ code, please attach the Makefile together. Thanks

So, here is my current testing pipeline.

simple_test_pipeline.txt (9.9 KB)

It may be that the pts of your stream are jumping, result in the “max-latency” parameter to misjudge. You can try to set the value to smaller.

I tested the same pipeline on both my Jetson AGX Orin and an x86-64 Ubuntu machine with the following results:

Testing Results

  • I simplified the pipeline by removing all parameters except live-source and batch-size for multiurisrcbin.
    Results remained the same - no change in behavior
  • The exact same code worked as intended on my x86-64 Ubuntu machine
  • Both tests used identical RTSP sources, though the x86-64 test had higher latency due to greater physical distance between devices (170ms instead of 1.4ms)

On the Jetson AGX Orin, I’m receiving these warnings that don’t appear on the x86-64 machine:

0:00:43.780249088  4164 0xffff7c004270 WARN          nvvideoconvert gstnvvideoconvert.c:2101:gst_nvvideoconvert_fixate_caps:<nvvidconv> nvbuf-memory-type property is set based on SRC caps. Property config setting (if any) is overridden!!
0:00:43.780329692  4164 0xffff7c004270 WARN          nvvideoconvert gstnvvideoconvert.c:2106:gst_nvvideoconvert_fixate_caps:<nvvidconv> gpu-id property is set based on SRC caps. Property config setting (if any) is overridden!!

Could the different behavior be related to architectural differences between platforms, or is it possibly due to the latency differences? Still need to fix AGX Orin issue

Because I can’t reproduce your problem on my side, let’s try to narrow it down by unifying the environment.

  1. build a server by reffering to our Build rtsp server. You can use our /opt/nvidia/deepstream/deepstream/samples/streams/sample_1080p_h264.mp4 to generate the rtsp source.

  2. run our deepstream\sources\apps\sample_apps\deepstream-server sample without any change

  3. remove/add source

I tried your suggestion and tested using the provided sample video with the RTSP server and deepstream-server application without changing the configuration. The only thing I did was add a new streammux parameter and use performance mode because I don’t have a screen available on the Jetson device.

It appears to work, but the performance statistics show it as if a new camera was added. In my Python code, I believe it reuses the same source ID. Could this be the issue?

I tried running the same code I provided previously, just with the RTSP server and sample RTSP sources, and the issue was still present. However, it worked correctly on an x86-64 Ubuntu machine.

Interestingly, after I tried running it inside a Triton multiarch image instead of the samples multiarch image, this issue did not recur. This suggests there might be something wrong with the packages. I don’t want to run a Triton image in a production environment though.

Edit: could be something wrong with my docker image as well. I tried changing to new empty image and problem as far as simple pipeline goes disappeared

uri:/api/v1/stream/remove
method:POST
**PERF : FPS_0 (0.00)   FPS_1 (17.47)   FPS_2 (29.63)   FPS_3 (15.73)   FPS_4 (29.64)
uri:/api/v1/stream/add
method:POST
**PERF : FPS_0 (0.00)   FPS_1 (17.29)   FPS_2 (29.64)   FPS_3 (15.29)   FPS_4 (27.59)
Opening in BLOCKING MODE 
NvMMLiteOpen : Block : BlockType = 261 
NvMMLiteBlockCreate : Block : BlockType = 261 
**PERF : FPS_0 (0.00)   FPS_1 (17.12)   FPS_2 (29.63)   FPS_3 (14.88)   FPS_4 (25.62)
**PERF : FPS_0 (0.00)   FPS_1 (16.95)   FPS_2 (29.63)   FPS_3 (14.49)   FPS_4 (23.91)
**PERF : FPS_0 (0.00)   FPS_1 (16.79)   FPS_2 (29.64)   FPS_3 (14.11)   FPS_4 (22.42)
**PERF : FPS_0 (0.00)   FPS_1 (16.63)   FPS_2 (29.63)   FPS_3 (13.76)   FPS_4 (21.10)
**PERF : FPS_0 (0.00)   FPS_1 (16.47)   FPS_2 (29.63)   FPS_3 (13.43)   FPS_4 (19.93)   FPS_5 (29.98)
**PERF : FPS_0 (0.00)   FPS_1 (16.31)   FPS_2 (29.62)   FPS_3 (13.11)   FPS_4 (18.88)   FPS_5 (29.48)
**PERF : FPS_0 (0.00)   FPS_1 (16.16)   FPS_2 (29.63)   FPS_3 (12.80)   FPS_4 (17.93)   FPS_5 (29.64)
**PERF : FPS_0 (0.00)   FPS_1 (16.01)   FPS_2 (29.63)   FPS_3 (12.51)   FPS_4 (17.08)   FPS_5 (29.72)
**PERF : FPS_0 (0.00)   FPS_1 (15.87)   FPS_2 (29.62)   FPS_3 (12.23)   FPS_4 (16.30)   FPS_5 (29.37)
**PERF : FPS_0 (0.00)   FPS_1 (15.72)   FPS_2 (29.63)   FPS_3 (11.97)   FPS_4 (15.59)   FPS_5 (29.47)
**PERF : FPS_0 (0.00)   FPS_1 (15.58)   FPS_2 (29.63)   FPS_3 (11.71)   FPS_4 (14.94)   FPS_5 (29.54)
**PERF : FPS_0 (0.00)   FPS_1 (15.44)   FPS_2 (29.62)   FPS_3 (11.47)   FPS_4 (14.35)   FPS_5 (29.47)
**PERF : FPS_0 (0.00)   FPS_1 (15.30)   FPS_2 (29.63)   FPS_3 (11.23)   FPS_4 (13.79)   FPS_5 (29.53)
**PERF : FPS_0 (0.00)   FPS_1 (15.17)   FPS_2 (29.63)   FPS_3 (11.01)   FPS_4 (13.28)   FPS_5 (29.57)
**PERF : FPS_0 (0.00)   FPS_1 (15.04)   FPS_2 (29.62)   FPS_3 (10.79)   FPS_4 (12.81)   FPS_5 (29.52)
**PERF : FPS_0 (0.00)   FPS_1 (14.91)   FPS_2 (29.63)   FPS_3 (10.59)   FPS_4 (12.37)   FPS_5 (29.55)
**PERF : FPS_0 (0.00)   FPS_1 (14.78)   FPS_2 (29.62)   FPS_3 (10.39)   FPS_4 (11.96)   FPS_5 (29.51)
**PERF : FPS_0 (0.00)   FPS_1 (14.66)   FPS_2 (29.63)   FPS_3 (10.19)   FPS_4 (11.57)   FPS_5 (29.54)
**PERF : FPS_0 (0.00)   FPS_1 (14.53)   FPS_2 (29.63)   FPS_3 (10.01)   FPS_4 (11.21)   FPS_5 (29.57)
**PERF : FPS_0 (0.00)   FPS_1 (14.41)   FPS_2 (29.62)   FPS_3 (9.83)    FPS_4 (10.87)   FPS_5 (29.47)
**PERF : FPS_0 (0.00)   FPS_1 (14.29)   FPS_2 (29.63)   FPS_3 (9.66)    FPS_4 (10.55)   FPS_5 (29.50)
**PERF : FPS_0 (0.00)   FPS_1 (14.17)   FPS_2 (29.63)   FPS_3 (9.49)    FPS_4 (10.25)   FPS_5 (29.53)
**PERF : FPS_0 (0.00)   FPS_1 (14.06)   FPS_2 (29.62)   FPS_3 (9.33)    FPS_4 (9.96)    FPS_5 (29.50)
**PERF : FPS_0 (0.00)   FPS_1 (13.95)   FPS_2 (29.63)   FPS_3 (9.17)    FPS_4 (9.69)    FPS_5 (29.52)
**PERF : FPS_0 (0.00)   FPS_1 (13.83)   FPS_2 (29.63)   FPS_3 (9.02)    FPS_4 (9.44)    FPS_5 (29.54)
uri:/api/v1/stream/remove
method:POST
uri:/api/v1/stream/add
method:POST
**PERF : FPS_0 (0.00)   FPS_1 (13.72)   FPS_2 (29.62)   FPS_3 (8.88)    FPS_4 (9.20)    FPS_5 (29.24)
Opening in BLOCKING MODE 
NvMMLiteOpen : Block : BlockType = 261 
NvMMLiteBlockCreate : Block : BlockType = 261 
**PERF : FPS_0 (0.00)   FPS_1 (13.62)   FPS_2 (29.63)   FPS_3 (8.74)    FPS_4 (8.97)    FPS_5 (27.97)
**PERF : FPS_0 (0.00)   FPS_1 (13.51)   FPS_2 (29.63)   FPS_3 (8.60)    FPS_4 (8.75)    FPS_5 (26.81)
**PERF : FPS_0 (0.00)   FPS_1 (13.41)   FPS_2 (29.62)   FPS_3 (8.47)    FPS_4 (8.54)    FPS_5 (25.74)
**PERF : FPS_0 (0.00)   FPS_1 (13.30)   FPS_2 (29.63)   FPS_3 (8.34)    FPS_4 (8.34)    FPS_5 (24.75)
**PERF : FPS_0 (0.00)   FPS_1 (13.20)   FPS_2 (29.63)   FPS_3 (8.22)    FPS_4 (8.15)    FPS_5 (23.83)
**PERF : FPS_0 (0.00)   FPS_1 (13.10)   FPS_2 (29.62)   FPS_3 (8.10)    FPS_4 (7.97)    FPS_5 (22.98)
**PERF : FPS_0 (0.00)   FPS_1 (13.00)   FPS_2 (29.63)   FPS_3 (7.98)    FPS_4 (7.80)    FPS_5 (22.19)
**PERF : FPS_0 (0.00)   FPS_1 (12.91)   FPS_2 (29.62)   FPS_3 (7.86)    FPS_4 (7.63)    FPS_5 (21.45)
**PERF : FPS_0 (0.00)   FPS_1 (12.81)   FPS_2 (29.63)   FPS_3 (7.75)    FPS_4 (7.47)    FPS_5 (20.76)
**PERF : FPS_0 (0.00)   FPS_1 (12.72)   FPS_2 (29.63)   FPS_3 (7.65)    FPS_4 (7.32)    FPS_5 (20.11)
**PERF : FPS_0 (0.00)   FPS_1 (12.62)   FPS_2 (29.62)   FPS_3 (7.54)    FPS_4 (7.17)    FPS_5 (19.50)   FPS_6 (28.97)
**PERF : FPS_0 (0.00)   FPS_1 (12.53)   FPS_2 (29.63)   FPS_3 (7.44)    FPS_4 (7.03)    FPS_5 (18.92)   FPS_6 (29.47)
**PERF : FPS_0 (0.00)   FPS_1 (12.44)   FPS_2 (29.63)   FPS_3 (7.34)    FPS_4 (6.90)    FPS_5 (18.38)   FPS_6 (29.64)
**PERF : FPS_0 (0.00)   FPS_1 (12.35)   FPS_2 (29.62)   FPS_3 (7.24)    FPS_4 (6.77)    FPS_5 (17.87)   FPS_6 (29.47)
**PERF : FPS_0 (0.00)   FPS_1 (12.26)   FPS_2 (29.63)   FPS_3 (7.15)    FPS_4 (6.64)    FPS_5 (17.39)   FPS_6 (29.57)
**PERF : FPS_0 (0.00)   FPS_1 (12.18)   FPS_2 (29.63)   FPS_3 (7.06)    FPS_4 (6.52)    FPS_5 (16.93)   FPS_6 (29.64)
**PERF : FPS_0 (0.00)   FPS_1 (12.09)   FPS_2 (29.62)   FPS_3 (6.97)    FPS_4 (6.41)    FPS_5 (16.50)   FPS_6 (29.54)
**PERF : FPS_0 (0.00)   FPS_1 (12.01)   FPS_2 (29.63)   FPS_3 (6.88)    FPS_4 (6.29)    FPS_5 (16.09)   FPS_6 (29.60)
**PERF : FPS_0 (0.00)   FPS_1 (11.93)   FPS_2 (29.63)   FPS_3 (6.80)    FPS_4 (6.18)    FPS_5 (15.69)   FPS_6 (29.64)
**PERF : FPS_0 (0.00)   FPS_1 (11.84)   FPS_2 (29.62)   FPS_3 (6.71)    FPS_4 (6.08)    FPS_5 (15.32)   FPS_6 (29.57)
**PERF : FPS_0 (0.00)   FPS_1 (11.76)   FPS_2 (29.63)   FPS_3 (6.63)    FPS_4 (5.98)    FPS_5 (14.96)   FPS_6 (29.61)
**PERF : FPS_0 (0.00)   FPS_1 (11.68)   FPS_2 (29.62)   FPS_3 (6.55)    FPS_4 (5.88)    FPS_5 (14.62)   FPS_6 (29.55)
**PERF : FPS_0 (0.00)   FPS_1 (11.61)   FPS_2 (29.62)   FPS_3 (6.48)    FPS_4 (5.79)    FPS_5 (14.30)   FPS_6 (29.58)
**PERF : FPS_0 (0.00)   FPS_1 (11.53)   FPS_2 (29.63)   FPS_3 (6.40)    FPS_4 (5.69)    FPS_5 (13.99)   FPS_6 (29.61)
**PERF : FPS_0 (0.00)   FPS_1 (11.45)   FPS_2 (29.62)   FPS_3 (6.33)    FPS_4 (5.60)    FPS_5 (13.69)   FPS_6 (29.57)
**PERF : FPS_0 (0.00)   FPS_1 (11.38)   FPS_2 (29.62)   FPS_3 (6.26)    FPS_4 (5.52)    FPS_5 (13.40)   FPS_6 (29.59)
**PERF : FPS_0 (0.00)   FPS_1 (11.30)   FPS_2 (29.63)   FPS_3 (6.19)    FPS_4 (5.43)    FPS_5 (13.13)   FPS_6 (29.62)
**PERF : FPS_0 (0.00)   FPS_1 (11.23)   FPS_2 (29.62)   FPS_3 (6.12)    FPS_4 (5.35)    FPS_5 (12.87)   FPS_6 (29.58)

I think the I found the real cause of my issue. I was using USE_NEW_NVSTREAMUX = yes env variable and then I removed this parameter the issue was solved. Why is this the case though?

When you use the USE_NEW_NVSTREAMUX = yes, the pipeline will use the new nvstreammux plugin. It’s different from the nvstreammux plugin.
Could you try to refer to our deepstream-server sample to implement your own sample?