DS plugin nvmultiurisrcbin problems with internal_id

Accelerated Computing Intelligent Video Analytics DeepStream SDK
,
18

I used the word “replace” incorrectly. My intention wasn’t to remove the existing source_id variable and substitute it with camera_id.

My actual goal is to introduce camera_id as a new variable and have users start using it instead of source_id, which would remain in the system for compatibility purposes.

Since it can now be obtained through the get-stream-info method, could you describe in detail how you plan to obtain and use this camera_id in a specific scenario? Thanks

Let me provide a concrete example of why extending camera_id usage is crucial:

Current Problem with source_id:

I created an pipeline using the REST API and added 3 file sources sequentially on-demand to the pipeline with sync=false on fakesink.

Here’s what happens:

  1. Source added → source_id is generated (unknown at this point)

  2. Frames start processing immediately through probes

  3. Hundreds of frames processed before I can call get-stream-info to discover which camera_id belongs to which source_id

  4. Data loss: All those initial frames are processed without knowing their camera_id

Additional nvdsanalytics complexity: Since nvdsanalytics also depends on source_id, I have to:

  1. Start the source

  2. Wait to get the source_id

  3. Rebuild the YAML/INI configuration file with the correct source_id

  4. Reload nvdsanalytics to apply ROIs correctly

Even when done quickly, this introduces significant latency while hundreds of frames are already being processed without proper ROI configuration.

Before REST API vs Now:

  • Before: Users manually controlled source_id - they knew exactly which source_id belonged to which source before start source

  • Now: The source_id becomes available once the source is already running, making it unknown until we query for it

Solution with camera_id: If camera_id were available in metadata:

  1. Pre-configure: Load ROIs in nvdsanalytics using known camera_id values BEFORE starting sources

  2. Immediate processing: When frames reach probes, camera_id would be immediately available in metadata

  3. No external queries: No need to call REST API during processing to map source_id to camera_id

  4. Zero latency: No frames lost or processed incorrectly during startup

This would eliminate the current race condition between source startup and configuration discovery.

Thanks.

2 Likes