DeepStream 9.0 NVIDIA GPU Driver 595.80 RTX 3050
build in docker.
The Issue: Based on my observation, nvurisrcbin utilizes a single shared circular buffer (Cache) for the Smart Record module. When I attempt to trigger multiple start_recording calls, the system enters a “BLOCKING MODE,” which causes significant I/O latency and often leads to the Could not read from resource error, effectively dropping frames for the second recording task.
Specific Concerns:
-
Cache Overwrite: In a high-concurrency scenario, if the
smart-rec-cachesize is limited, the time window for the second video (Video B) might be overwritten by the time I/O operations for the first video (Video A) are finalized. -
Blocking I/O: The current architecture seems to force a synchronous block on the pipeline when writing to the physical disk, preventing parallel recording sessions for the same source.
Questions:
-
Is there a recommended architectural pattern in DeepStream to handle multiple overlapping recording sessions from a single RTSP source without causing
BLOCKING MODEor buffer contention? -
Should I be implementing a custom “Tee” architecture where I split the stream into multiple recording-only pipelines, or is there a way to offload the raw buffer handling to a custom memory pool/callback before it triggers the I/O block?
-
Does the
Smart Recordmodule support concurrentSession IDsfor the same source, or is this fundamentally a single-session-at-a-time limitation of the underlyingsr_context?
I am looking for a scalable approach for traffic law enforcement applications where event detection occurs in rapid succession. Any insights or architectural best practices would be greatly appreciated.