Closed YoungjaeDev closed 8 months ago
@youngjae-avikus I've tried running your example on my Jetson device(s) with the NVIDIA supplied models and I'm unable to reproduce your failure. I've had it running for several hours. I've tried to run the example with your YOLOv3 model, but I'm unable to get it to work. My console output is...
Output yolo blob names :
yolo_83
yolo_95
yolo_107
Total number of yolo layers: 257
Building yolo network complete!
Building the TensorRT Engine...
Killed
Can you try with the NIVIDIA models on your dGPU platform to see if it's model or platform dependent? I've also noticed that the inference results using NVIDIA's models are terrible. Very few objects detected so the Tracker is doing little in my case. I tried with different Tiler output dimensions as follows, but no imporovement.
int TILER_WIDTH = DSL_STREAMMUX_1K_HD_WIDTH*3;
int TILER_HEIGHT = DSL_STREAMMUX_1K_HD_HEIGHT;
// Window Sink Dimensions - used to create the sink, however, in this
int WINDOW_WIDTH = DSL_STREAMMUX_1K_HD_WIDTH;
int WINDOW_HEIGHT = DSL_STREAMMUX_1K_HD_HEIGHT/3;
@rjhowell44
It seems that the problem of yolov3 not running is libnvdsinfer_custom_impl_Yolo.so
. I ran it with so built in CUDA 11.4(DGPU), so would you like to rebuild it in 10.2(JETSON)? about below folder...
Can you try with the NIVIDIA models on your dGPU platform to see if it's model or platform dependent? I've also noticed that the inference results using NVIDIA's models are terrible. Very few objects detected so the Tracker is doing little in my case. I tried with different Tiler output dimensions as follows, but no imporovement.
In my opinion, in order to perform well in a tiled image, it is basically trained with a tiled image size. Also, for another reason, yolov3 input image size is 416x416. So eventually, whatever the tiled image size, it resizes to 416x416
When it is non-tile, the original image is 1920x1080, and when it enters Yolov3, it is a conventionally trained method, so if it is well trained, detection is good.
However, if the tiled image in 3 sheets enters one input, 5840x1080 enters and change to 416x416 (YOLOV3). Then, since the squeeze is tripled on a width basis than 1920x1080, the ratio will be resized to a stranage image and the detection will be rather inferior in performance
In conclusion, it is perfectly normal that the performance is lower than before when it is applied in tiled ...
To better detect the 5840x1080 image, I think it need to do 3 slice predictions with 1920x1080 using the preproc plug-in (additionally, Full reference)
@youngjae-avikus I did not use your libnvdsinfer_custom_impl_Yolo.so
... I built and used the library under the /opt/nvidia/deepstream/deepstream/sources
with CUDA_VER=10.2
.
Please try with the NVIDIA model on your dGPU... and please try on your Jetson platform with both models as well. I'm almost certain this will be another NVIDIA issue and we'll need to provide them with as much information as possible.
@rjhowell44
I didn't know exactly what you were referring to. Are you saying that both dgpu and Jetson are different about the model performance provided by nvidia? Or do you mean that the performance is significantly reduced when you apply tiled input it?
@youngjae-avikus I'm saying that I can NOT reproduce the error on Jetson with the NVIDIA café model. Having the Streammuxer connected to Tiler works fine. I'm asking if you can test on dGPU with the NVIDIA model, and on Jetson with your YOLOv3 model. We need to know if the issue is observed on dGPU only? or your model only?
@youngjae-avikus I'm saying that I can NOT reproduce the error on Jetson with the NVIDIA café model. Having the Streammuxer connected to Tiler works fine. I'm asking if you can test on dGPU with the NVIDIA model, and on Jetson with your YOLOv3 model. We need to know if the issue is observed on dGPU only? or your model only?
OK. I understand that
@rjhowell44 Have you tested the RTSP source?
When operating with the nvidia default caffe model using dGPU, there is no error on three video inputs, but there is still a problem with three RTSPs I'll go to work next Monday and verify what I'm doing at Jetson. The dGPU is running in the docker, so I don't know if there's something wrong with this... That's weird
@youngjae-avikus Sorry, I was confused. I thought you were saying that the issues was caused by adding the Tiler to the Stream-muxer. Are you using the same RTSP URI for all three sources? I believe this might be the issue? For my cameras, I need to use different channels such as.
rtsp://username:password@192.168.0.14:554/Streaming/Channels/101
rtsp://username:password@192.168.0.14:554/Streaming/Channels/102
rtsp://username:password@192.168.0.14:554/Streaming/Channels/103
@rjhowell44
Up to four RTSP cameras that I use are supported up to Multicast, so I did the following when running the program
@youngjae-avikus sorry but I do not understand... you stated "so I did the following when running the program" ... but there is nothing following your comment? What is "the following"?
Also, you initially stated that you wanted to tile three different streams before running inference... tile them together as a single panoramic view . Would you not be using three different cameras? Why would you tile multiple streams from the same camera? I'm trying to understand you use case.
@rjhowell44
You're right ! it's just that before the three cameras were built in the field, I ran three same streams for the stress test and dsl_pipeline_streammux_tiler_add work. However, even if the RTSP stream is excluded, the combination of YOLOV3 + 3-VIDEO also caused SIGFPE to occur and left an issue :)
@youngjae-avikus What error do you get with 3 video (non-RTSP) streams... something other than "nas_rtp_connect" error? can you share the log here?
@youngjae-avikus What error do you get with 3 video (non-RTSP) streams... something other than "nas_rtp_connect" error? can you share the log here?
@rjhowell44 The error is caused by the same SIGFPE as above. I am currently on a business trip, so I will be able to check it again on Wednesday Is there anything else you would like to request?
@youngjae-avikus I see... I was confused. This error seems related to the multi-object tracker and the results produced by your YOLOv3 model. The nas_rtsp_connect was misleading.
Does "The nas_rtsp_connect was misleading" mean that the code I wrote is problematic? Or do you think it's a build issue for yolov3.so?
@youngjae-avikus I'm not sure what this is. If we look at the three cases
It seems that there is something in the metadata produced by the PGIE that is causing issues for the tracker.
Can you add an ODE-Handler with a Print Action to the source pad of the PGIE so we can look at the metadata before it gets to the Tracker? One think I do know is that the Tiler sets the frame width and height to 0 which may or may not be an issue.
@youngjae-avikus I'm not sure what this is. If we look at the three cases
- untiled batched input with YOLOv3 - no issue
- tiled input with Cafe model - minimal detections - no issue
- tiled input with YOLOv3 - significant number of detections - floating point exception.
It seems that there is something in the metadata produced by the PGIE that is causing issues for the tracker.
Can you add an ODE-Handler with a Print Action to the source pad of the PGIE so we can look at the metadata before it gets to the Tracker? One think I do know is that the Tiler sets the frame width and height to 0 which may or may not be an issue.
I did pending for a long time, but I'll check the issue up again
env: deepstream 6.0.1 devel docker
Problem Problems arise when 3URI or 3RTSP (both tests) + streammux_tiler The model was also run with yolov3 and yolov5, and both resulted in exceptions. The timing of the exception is irregular, so it takes about 2-3 minutes, and it may occur after that. Here is my code...
The system is in good condition