Please provide complete information as applicable to your setup.
• Hardware Platform (Jetson / GPU) Jetson Orin AGX Development Kit 64GB
• DeepStream Version 6.3
• JetPack Version (valid for Jetson only) 5.1.2
• TensorRT Version 5.1.2
• Issue Type( questions, new requirements, bugs) Smart recording presents a delay when starting a recording
• How to reproduce the issue ?
Launch deepstream-testsr sample with a local RTSP: deepstream-testsr-app rtsp://localhost:8554/stream0 --sink-type=1 --enc-type=1 --sr-mode=1 --pgie-type=0
• Requirement details( This is for new requirement. Including the module name-for which plugin or for which sample application, the function description)
For our case scenario we are trying to use smart recording to start and stop recordings that will last from 3 to 20 seconds at most. It also possible that a recording is started after 2 or 3 seconds since the last one was stopped. These recordings will start and stop via cloud messages triggered by our main application.
We currently have 4 RTSP sources that stream the output of 4 cameras. These streams are created using GstRstpServer in python, which are accessed locally by our deepstream.
Here I leave the gstreamer pipeline that reads from the one of our cameras, the other ones just change the device value:
v4l2src device=/dev/video0 ! video/x-raw,width=640,height=480,framerate=30/1 ! videoconvert ! x264enc bitrate=2048 speed-preset=ultrafast tune=zerolatency ! h264parse ! rtph264pay name=pay0 pt=96
Here is our deepstream config:
[application]
enable-perf-measurement=1
perf-measurement-interval-sec=5
#gie-kitti-output-dir=streamscl
[source0]
enable=1
#Type - 1=CameraV4L2 2=URI 3=MultiURI 4=RTSP
type=4
uri=rtsp://streamlink:8554/stream0
gpu-id=0
nvbuf-memory-type=0
smart-record=1
smart-rec-cache=5
smart-rec-default-duration=30
smart-rec-container=0
smart-rec-dir-path=/media/shared/
smart-rec-file-prefix=cam0
source-id=0
[source1]
enable=1
type=4
uri=rtsp://streamlink:8554/stream1
gpu-id=0
nvbuf-memory-type=0
smart-record=1
smart-rec-cache=5
smart-rec-default-duration=30
smart-rec-container=0
smart-rec-dir-path=/media/shared/
smart-rec-file-prefix=cam1
source-id=1
[source2]
enable=1
type=4
uri=rtsp://streamlink:8554/stream2
gpu-id=0
nvbuf-memory-type=0
smart-record=1
smart-rec-cache=5
smart-rec-default-duration=30
smart-rec-container=0
smart-rec-dir-path=/media/shared/
smart-rec-file-prefix=cam2
source-id=2
[source3]
enable=1
type=4
uri=rtsp://streamlink:8554/stream3
gpu-id=0
nvbuf-memory-type=0
smart-record=1
smart-rec-cache=5
smart-rec-default-duration=30
smart-rec-container=0
smart-rec-dir-path=/media/shared/
smart-rec-file-prefix=cam3
source-id=3
[sink0]
enable=1
type=1
sync=0
source-id=0
gpu-id=0
nvbuf-memory-type=0
[message-consumer]
enable=1
proto-lib=/opt/nvidia/deepstream/deepstream/lib/libnvds_redis_proto.so
conn-str=redis;6379
subscribe-topic-list=smart-recording
[osd]
enable=1
gpu-id=0
border-width=1
text-size=15
text-color=1;1;1;1;
text-bg-color=0.3;0.3;0.3;1
font=Serif
show-clock=0
clock-x-offset=800
clock-y-offset=820
clock-text-size=12
clock-color=1;0;0;0
nvbuf-memory-type=0
[streammux]
gpu-id=0
##Boolean property to inform muxer that sources are live
live-source=1
batch-size=4
##time out in usec, to wait after the first buffer is available
##to push the batch even if the complete batch is not formed
batched-push-timeout=33000
## Set muxer output width and height
width=640
height=480
##Enable to maintain aspect ratio wrt source, and allow black borders, works
##along with width, height properties
enable-padding=0
nvbuf-memory-type=0
## If set to TRUE, system timestamp will be attached as ntp timestamp
## If set to FALSE, ntp timestamp from rtspsrc, if available, will be attached
# attach-sys-ts-as-ntp=1
# config-file property is mandatory for any gie section.
# Other properties are optional and if set will override the properties set in
# the infer config file.
[primary-gie]
enable=1
gpu-id=0
batch-size=4
#Required by the app for OSD, not a plugin property
bbox-border-color0=1;0;0;1
bbox-border-color1=0;1;1;1
bbox-border-color2=0;0;1;1
bbox-border-color3=0;1;0;1
interval=0
gie-unique-id=1
nvbuf-memory-type=0
config-file=config_infer_primary.yml
[tests]
file-loop=0
Upon calling NvDsSRStart, we observed that the video file gets created instantly, but it will take some time to actually get filled with incoming frames. This time seems arbitrary, as it can range from almost being instant to taking 22 seconds in our tests.
This behavour results in the following problems:
-
Video duration almost never matches the expected duration, and in our case makes it so that every video presents different length.
-
There are some cases where the stop call is done before any frame has been appended to the video, which results in the following error:
** ERROR: RunUserCallback:207: No video stream found
We already tested running deepstream-testsr with a single rtsp with the following command:
deepstream-testsr-app rtsp://localhost:8554/stream0 --sink-type=1 --enc-type=1 --sr-mode=1 --pgie-type=0
This seems to be stable when SMART_REC_INTERVAL and SMART_REC_DURATION are set to 10 or more, there is always a working mp4 but its duration will vary everytime.
Dropping these values to 5 makes it so that the error get thrown again randomly.
We want to know if there is any way to avoid, reduce or control this head delay upon recording start, as it completely messes up with our application.
RSTP streams are hosted in the same network as the deepstream application, therefore we assume this behaviour is not related to internet latency or lag of any kind.
Thanks in advance