After long time , the stream is over

Continuing the discussion from After long time , the fps drop to zero:

Please provide complete information as applicable to your setup.
• Hardware Platform (Jetson / GPU):Xavier VX
• DeepStream Version:6.3
• JetPack Version (valid for Jetson only):5.1.3
• Issue Type( questions, new requirements, bugs):bugs

samiliar to the above question, my log is
Jan 24 09:57:12 Linux ZHYstream_V2[1827010]: Opening in BLOCKING MODE
Jan 24 09:57:12 Linux ZHYstream_V2[1827010]: gstnvtracker: Loading low-level lib at /opt/nvidia/deepstream/deepstream/lib/libnvds_nvmultiobjecttracker.so
Jan 24 09:57:12 Linux ZHYstream_V2[1827010]: [NvMultiObjectTracker] Initialized
Jan 24 09:57:16 Linux ZHYstream_V2[1827010]: WARNING: [TRT]: Using an engine plan file across different models of devices is not recommended and is likely to affect performance or even cause errors.
Jan 24 09:57:16 Linux ZHYstream_V2[1827010]: Deserialize yoloLayer plugin: yolo
Jan 24 09:57:19 Linux ZHYstream_V2[1827010]: 0:00:07.638330112 #033[335m1827010#033[00m 0xffff44a4a690 #033[36mINFO #033[00m #033[00m nvinfer gstnvinfer.cpp:682:gst_nvinfer_logger:#033[00m NvDsInferContext[UID 1]: Info from NvDsInferContextImpl::deserializeEngineAndBackend() <nvdsinfer_context_impl.cpp:1988> [UID = 1]: deserialized trt engine from :/home/zhyuav/ZHYstream_V2/model/spjk/model_b1_gpu0_fp16.engine
Jan 24 09:57:19 Linux ZHYstream_V2[1827010]: 0:00:07.713606208 #033[335m1827010#033[00m 0xffff44a4a690 #033[36mINFO #033[00m #033[00m nvinfer gstnvinfer.cpp:682:gst_nvinfer_logger:#033[00m NvDsInferContext[UID 1]: Info from NvDsInferContextImpl::generateBackendContext() <nvdsinfer_context_impl.cpp:2091> [UID = 1]: Use deserialized engine model: /home/zhyuav/ZHYstream_V2/model/spjk/model_b1_gpu0_fp16.engine
Jan 24 09:57:19 Linux ZHYstream_V2[1827010]: 0:00:07.727376320 #033[335m1827010#033[00m 0xffff44a4a690 #033[36mINFO #033[00m #033[00m nvinfer gstnvinfer_impl.cpp:328:notifyLoadModelStatus:#033[00m [UID 1]: Load new model:/home/zhyuav/ZHYstream_V2/model/spjk/config_infer_primary_yoloV5.txt sucessfully
Jan 24 09:57:20 Linux ZHYstream_V2[1827010]: NvMMLiteOpen : Block : BlockType = 261
Jan 24 09:57:20 Linux ZHYstream_V2[1827010]: NvMMLiteBlockCreate : Block : BlockType = 261
Jan 24 09:57:20 Linux ZHYstream_V2[1827010]: NvMMLiteOpen : Block : BlockType = 4
Jan 24 09:57:20 Linux ZHYstream_V2[1827010]: ===== NvVideo: NVENC =====
Jan 24 09:57:20 Linux ZHYstream_V2[1827010]: NvMMLiteBlockCreate : Block : BlockType = 4
Jan 24 09:57:23 Linux ZHYstream_V2[1827010]: H264: Profile = 100, Level = 0
Jan 24 09:57:23 Linux ZHYstream_V2[1827010]: NVMEDIA: Need to set EMC bandwidth : 705000
Jan 24 09:57:23 Linux ZHYstream_V2[1827010]: NVMEDIA: Need to set EMC bandwidth : 705000
Jan 24 09:57:23 Linux ZHYstream_V2[1827010]: NvVideo: bBlitMode is set to TRUE
Jan 24 18:27:04 Linux ZHYstream_V2[1827010]: FMO streams not supported for T210 onwards
Jan 24 18:53:06 Linux ZHYstream_V2[1827010]: WARNING from element rtph264depay0: Could not decode stream.
Jan 24 18:53:06 Linux ZHYstream_V2[1827010]: Warning: Could not decode stream.
Jan 24 19:32:35 Linux ZHYstream_V2[1827010]: NvMMLiteOpen : Block : BlockType = 261
Jan 24 19:32:35 Linux ZHYstream_V2[1827010]: NvMMLiteBlockCreate : Block : BlockType = 261
Jan 24 19:32:35 Linux ZHYstream_V2[1827010]: FMO streams not supported for T210 onwards
Jan 24 19:32:36 Linux ZHYstream_V2[1827010]: INFO: [Implicit Engine Info]: layers num: 5
Jan 24 19:32:36 Linux ZHYstream_V2[1827010]: 0 INPUT kFLOAT data 3x960x960
Jan 24 19:32:36 Linux ZHYstream_V2[1827010]: 1 OUTPUT kFLOAT num_detections 1
Jan 24 19:32:36 Linux ZHYstream_V2[1827010]: 2 OUTPUT kFLOAT detection_boxes 56700x4
Jan 24 19:32:36 Linux ZHYstream_V2[1827010]: 3 OUTPUT kFLOAT detection_scores 56700
Jan 24 19:32:36 Linux ZHYstream_V2[1827010]: 4 OUTPUT kFLOAT detection_classes 56700
Jan 24 19:32:36 Linux ZHYstream_V2[1827010]: Opening in BLOCKING MODE
Jan 24 19:32:36 Linux ZHYstream_V2[1827010]: Opening in BLOCKING MODE
Jan 24 19:32:36 Linux ZHYstream_V2[1827010]: Stream format not found, dropping the frame
Jan 24 19:32:36 Linux ZHYstream_V2[1827010]: message repeated 48 times: [ Stream format not found, dropping the frame]

The situation is that during the ten hour run of the program, the printed logs are as shown above. After 19:32, no more logs related to the pipeline are printed and there is no output video stream?

My pipeline is uridecodebin ->streammux ->nvinfer ->tracker ->osd ->… ->rtmpsink.
Q1: Why did this situation occur?
Q2:How should I solve it?

  1. Have you enable TCP as the low level protocol?
  2. Have you checked with your RTSP server vendor?
  3. This is not rtspsrc log, please provide the rtspsrc log. You can enable the rtspsrc log by “export GST_DEBUG=rtspsrc:7” command.

Q1:no, my element in pipeline is uridecodebin, so I don’t set many params, except rtsp “location”;
Q2/3:Sorry, I don’t have any logs for RTSPSRC. After this issue occurred, we attempted to pull the stream from the RTSP server using VLC, which was able to display it. However, since the problem occurred, it has not been reproduced yet. Currently, there are only many RTSP decode errors in the logs: NAL unit type 26/27 for printing

DeepStream app is just the RTSP client, the video stream is sent by the RTSP server. There are two possible reasons of the decoder error

  1. The RTSP server generates and sends the non-standard H264 stream. The DeepStream does not support it. You may need to ask your RTSP server vendor for how to generate standard H264 stream.
  2. The video stream is corrupted by the packet loss during the RTSP transferring. You need to use TCP protocol to avoid the packet loss.

Thank you for your prompt reply. I have sent an email to the source manufacturer of the RTSP stream to inquire; I have a few more questions to ask:
Q1: Is it impossible to set the uridecode bin plugin to use TCP format for transmission? Do I need to modify my decoding plugin to rtpsrc ->rtph264deptay ->h264parse?
Q2: In my syslog system log, the sentence “Linux kernel: [3955264.847851] nvmap_alloc_mandle: PID 1827010: ZHYstream_V2: Warning: All NvMap Allocations must have a tag to identify the subsystem allocating memory. Release pass the tag to the API call NvRmMemHanldeAllocAttr() or relevant.” My RTSP video stream has a bitrate of 12288 and a resolution of 3840 * 2160. Is it possible that hardware decoding is not supported, causing the above problem in the deepstream pipeline?

You can query the rtspsrc element from uridecodebin by the “child-added” signal callback. This is a basic GStreamer operation, you can google by yourself. You can also refer to the sample deepstream_tao_apps/apps/tao_detection/deepstream_det_app.c at master · NVIDIA-AI-IOT/deepstream_tao_apps for how we query the “nvv4l2decoder” from the uridecodebin.

Xavier NX supports 8k resolution. Please refer to
Jetson Modules, Support, Ecosystem, and Lineup | NVIDIA Developer

Thank you for your reply. My pipeline program has been applied to analyze multiple RTSP video streams. When I used gst-discover-1.0-v $RTSP_PATH to analyze the detailed information of the video stream (as shown in the figure), I found that my program can only run stably on video streams with encoding level 4.1, and RTSP video streams with encoding levels 5, 5.1, and 5.2 are not working. Do you know what this encoding level means? Can I configure different levels of parsing in the pipeline?


Please refer to the spec document H.264 : Advanced video coding for generic audiovisual services appendix A.3

ok,so Can I configure different levels of parsing in the pipeline?

The 3840x2160 resolution should be level 5.1.

What do you mean by “configure”?

Because I think this level difference affects the stability of the program, is that correct?

No. I think you can google the meaning of “level” if you don’t have time to read the H264 spec document.

The level is calculated from the video resolution.

This is DeepStream forum, let’s focus on DeepStream related topics.

1 Like

okk,I will follow up on the response from the RTSP streaming service provider.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.