• Hardware Platform (Jetson / GPU): Jetson Orin NX 8GB • DeepStream Version: 7.1 • JetPack Version (valid for Jetson only): 6.2 • TensorRT Version: 10.3.0.30 • Issue Type (questions, new requirements, bugs): Question — using nvdsanalytics with line-crossing when the line points are inverted • How to reproduce the issue:
Hello everyone,
I’m currently observing some unexpected behavior while using the nvdsanalytics plugin for line crossing detection.
Specifically, when I configure the line with the same points but in inverted order, I obtain two different results, even though the direction vector (when drawn) remains visually the same.
Here’s an example of the two configurations I used:
In both cases, the line points are the same, but the first and last points are swapped.
When I tested objects crossing the line toward the Southeast direction (according to the visualized vector), I noticed the following:
With Configuration A, only 4/8 crossings were detected.
With Configuration B, 8/8 crossings were correctly detected.
Given that the drawn direction appears identical in both configurations, I would like to understand if this behavior is expected.
It seems to behave somewhat like a cross-product between the line and the direction vector , but I’m not sure if this is the intended logic.
Could someone please clarify:
Is this behavior officially documented somewhere?
How exactly does nvdsanalytics internally compute line crossing detections based on point order?
Where can I find the source code (or any detailed documentation) that handles the line crossing logic in DeepStream?
Any additional insights or pointers would be greatly appreciated!
I can’t reproduce this with DS7.1 on Jetson Orin. Here are the test details. you can see, the count of “LineCrossing Cumulative Exit1” is the same with the count of " LineCrossing Cumulative Exit". config_nvdsanalytics.txt (1.9 KB) log.txt (337.0 KB)
If you have a different results, To debug this issue, could you share the cfg and test videos? Thanks!
I’m currently using the standard YOLOv8s .pt model converted to ONNX(not cfg). Unfortunately, I can’t share the video, but I’d like to highlight an issue I encountered regarding line crossing behavior in nvdsanalytics.
Specifically, when using the same configuration, I observed different results depending on the order of the two points defining the line. Inverting these points seems to affect whether the crossing is detected or not. This behavior appears to be dependent on the scenario and possibly influenced by trigonometric orientation, rather than being invariant to the point order.
Is this expected behavior?
Is there a reference or code snippet available that shows how nvdsanalytics determines whether a line has been crossed? I’d like to better understand how the direction or order of the line points influences the internal detection logic.
In line-crossing- settng, the first two points are used for direction, the second two points for virtual line. it is not expected that the count becomes different if only changing the order of virtual line points.
Since nvdsanalytics low-level implement is not opensource, I can’t share more algo details. could you modify the native sample deepstream-nvdsanalytics-test to reproduce this issue? if so, please share the cfg.
As discussed, I’m sending you the video we talked about and wanted to share some new findings.
Assuming our previous assumptions still hold, it seems we may have encountered a bug in a specific scenario: inverting the endpoints of the crossing line leads to different results, which shouldn’t happen.
Additionally, I noticed some unexpected behavior when changing the muxer resolution:
Case 1: muxer width = 960, height = 544
→ We get 10 line-crossing events for both setting A and B.
→ Although there are 2 false positives, the issue with the line point inversion does not occur.
Case 2: muxer width = 960, height = 560
→ We get only 7 line-crossing events for both setting A and B.
→ Only one person is missed, but no ambiguity is observed when inverting the line points.
We’re using the nvdcf_perf tracker, the video resolution is 1920x1080, and the detection model is based on YOLOv8s weights.
I’ve shared the video and engine config files via private message, as you suggested.
Thanks in advance for your support!
Thanks for the sharing! Testing the video, model and cfg you shared on Orin with Ds7.1, the count of A and B are always the same. please refer to the cfg and logs. please make sure video, model and cfgs are correct. could you share the configuration file of deepstream-app and your test logs? Thanks! streammux-1920x1080.txt (708.0 KB) streammux-960x544.txt (710.2 KB) streammux-960x560.txt (1002.7 KB) deepstream_app_config.txt (1.8 KB)
I noticed that we’re using different tracker configurations — specifically, different width and height values. This might be related to the issue we’ve been discussing.
I’m currently testing two configurations:
Tracker width = 640, height = 480
Tracker width = 960, height = 540
In both cases, the same bug still appears — the line-crossing behavior remains inconsistent when inverting the line points.
Let me know if you think the tracker input dimensions could be affecting this, or if there’s another factor I should check.
let’s focus on the original issue in the issue description first. Testing with the same video, cfg, model, I still can’t reproduce the issue. that is, the count of A and B is always the same. could you help to reproduce this issue? could you share your log? Thanks! that is, the count of A and B is different sometimes. config_tracker_NvDCF_perf.txt (5.0 KB) deepstream_app_config.txt (1.5 KB)1.txt (4.1 KB)
Sure thing, im sending you both the log file and the config_infer_primary. As for tracker, config_nvds_analytics and video, they are the one that i alredy sent you in the previous messages.
Please let me know if you need other files regarding this issue.
As always thanks in advance and regards! log.txt (534.6 KB) config_infer_primary_yoloV8_HighPerformance.txt (836 Bytes)
Thanks for the sharing! I can reproduce this issue. When the start point of direction is on the virtual line, it will trgger a bug.
Here is a workaround. please use the following configurations instead. I only modify 336 to 330. namely start point of direction is not on the virtual line.
Thanks for the confirmation and for providing the workaround!
I’d like to ask a few clarifications to better handle this case in production:
A. Will this issue be addressed in future DeepStream releases, or should we always apply this kind of workaround manually?
B. Based on your explanation, it seems the bug is triggered only when the base of the direction vector lies on the virtual line. Can you confirm if placing the tip of the vector on the line (with the base behind it) avoids the issue?
C. Are there any other specific recommendations or caveats we should consider when drawing the direction vector to ensure reliable line-crossing detection?
Thanks again for your support and for helping clarify this behavior!
Have you verified the workaround? Thanks!
A. yes. fixing this issue is on our roadmap.
B,C. you are right. please don’t set base or tip of direction vector on the virtual line.
