Please provide complete information as applicable to your setup.
• Hardware Platform (Jetson / GPU) RTX 3090 • DeepStream Version 6.2 • JetPack Version (valid for Jetson only) • TensorRT Version • NVIDIA GPU Driver Version (valid for GPU only) • Issue Type( questions, new requirements, bugs) questions • How to reproduce the issue ? (This is for bugs. Including which sample app is using, the configuration files content, the command line used and other details for reproducing) • Requirement details( This is for new requirement. Including the module name-for which plugin or for which sample application, the function description)
when i change attach-sys-ts to 0, frame’s NTP timestamp always 0.
the wireshark result as below, It does get the rtcp package， but my deepstream app not
when i launch my deepstream app, i has some warnings, it seems streammux does’t get ntp timestamp at the beginning
Warning: gst-library-error-quark: Either host or Source 0 seems to be out of NTP sync SYS TIME = 2023-11-22T07:00:28.407Z CALCULATED NTP TIME = 1970-01-01T00:00:00.000Z (5): gstnvstreammux_ntp.cpp(108): check_if_sys_rtcp_time_is_ntp_sync (): /GstPipeline:pipeline0/GstNvStreamMux:Stream-muxer
which sample are you testing? which the whole media pipeline? could you share the detailed reproducing steps? how do you know frame’s NTP timestamp always 0?
could you share more logs? please do the following setting first, then run the app again, then share log. you can use zip to compress the log. Thanks!
export GST_DEBUG=nvstreammux:6
export GST_DEBUG_FILE=/tmp/gst.log
Hi i found the 1.log in line 56: 0:00:07.694262966 e[335m 3748e[00m 0x7f61bc007920 e[37mDEBUG e[00m e[00m nvstreammux_ntp gstnvstreammux_ntp.cpp:66:gst_nvds_ntp_calculator_new:<Stream-muxer>e[00m Setting NTP correction mode disabled.
that means the frame-duration default to -1? I have not set streammux frame-duration. But the ds streammux doc shows frame-duration default to 0.
Anyway, i set set streammux frame-duration to 0 , the 2.log in line 52 shows correction mode are setting to automatic mode, the ntp_time_epoch_ns always 1970-01-01T00:00:00.000Z(0)
the source code comes from function gst_nvstreammux_chain , from deepstream 6.3 gst-plugins gst-nvmultistream2 gstnvstreammux.cpp, the core func is gst_pad_peer_query or gst_nvquery_ntp_sync_parse, ntpdata was not successfully parsed
“1970-01-01T00:00:00.000Z” is got from gst_nvquery_ntp_sync_parse, which will parse ntp in jitterbuffer’s data callback. I will try tor reproduce this issue. to narrow down this issue, could you try a local rtsp source which has no timezone issue?
gratitude！ My version is deepstream 6.2, and the configure_source_for_ntp_sync python binding is not available yet. I successfully obtained the rtcp ntp timestamp by referring to this link.
Hi! @fanzh I met a new problems, the same deepstream python code for different rtsp source,
the rtsp source1 for my deepstream code can get the rtcp ntp timestamp. But when i change a new rtsp source2 from an new camera, the ntp timestamp value turn to 0.
The strange thing is that the tshark packet capture result is normal
the rtsp source1
sudo tshark -i eno1 -f "src host <rtsp source1>" -Y "rtcp"
Running as user "root" and group "root". This could be dangerous.
Capturing on 'eno1'
331 0.872048653 <rtsp source1> → <my host> RTCP 114 Sender Report Source description
2547 6.847002735 <rtsp source1> → <my host> RTCP 114 Sender Report Source description
4111 12.045429221 <rtsp source1> → <my host> RTCP 114 Sender Report Source description
the rtsp source2
sudo tshark -i eno1 -f "src host <rtsp source1>" -Y "rtcp"
Running as user "root" and group "root". This could be dangerous.
Capturing on 'eno1'
331 0.872048653 <rtsp source1> → <my host> RTCP 114 Sender Report Source description
2547 6.847002735 <rtsp source1> → <my host> RTCP 114 Sender Report Source description
4111 12.045429221 <rtsp source1> → <my host> RTCP 114 Sender Report Source description
GST_HELPER_LIB = ctypes.CDLL(
"/opt/nvidia/deepstream/deepstream/lib/libnvdsgst_helper.so"
)
def create_source_bin(index, uri):
print('Creating source bin')
# Create a source GstBin to abstract this bin's content from the rest of the
# pipeline
bin_name = 'source-bin-%02d' % index
print(bin_name)
nbin = Gst.Bin.new(bin_name)
if not nbin:
sys.stderr.write(' Unable to create source bin \n')
# Source element for reading from the uri.
# We will use decodebin and let it figure out the container format of the
# stream and the codec and plug the appropriate demux and decode plugins.
uri_decode_bin = Gst.ElementFactory.make('uridecodebin', 'uri-decode-bin')
if not uri_decode_bin:
sys.stderr.write(' Unable to create uri decode bin \n')
# We set the input uri to the source element
uri_decode_bin.set_property('uri', uri)
GST_HELPER_LIB.configure_source_for_ntp_sync(hash(uri_decode_bin))
# Connect to the 'pad-added' signal of the decodebin which generates a
# callback once a new pad for raw data has been created by the decodebin
uri_decode_bin.connect('pad-added', cb_newpad, nbin)
uri_decode_bin.connect('child-added', decodebin_child_added, nbin)
# We need to create a ghost pad for the source bin which will act as a proxy
# for the video decoder src pad. The ghost pad will not have a target right
# now. Once the decode bin creates the video decoder and generates the
# cb_newpad callback, we will set the ghost pad target to the video decoder
# src pad.
Gst.Bin.add(nbin, uri_decode_bin)
bin_pad = nbin.add_pad(
Gst.GhostPad.new_no_target('src', Gst.PadDirection.SRC))
if not bin_pad:
sys.stderr.write(' Failed to add ghost pad in source bin \n')
return None
return nbin
the rtsp source2 from new camera tshark detail is that
sudo tshark -i eno1 -f "src host <rtsp source2>" -Y "rtcp"
-T fields -e rtcp.timestamp.ntp
Running as user "root" and group "root". This could be dangerous.
Capturing on 'eno1'
Dec 5, 2023 17:29:09.425999999 CST
Dec 5, 2023 17:29:14.424999999 CST
Dec 5, 2023 17:29:19.422999999 CST
Dec 5, 2023 17:29:24.420999999 CST
