Delay in NvDsAnalytics Line Crossing Events

We are using DeepStream 5.1 in production for use cases like person counting, vehicle counting, and so forth. We have added a probe that will crop the image of the person/vehicle as soon as the line is crossed. We know that the line is crossed using the NvDsAnalytics plugin. Our videos are currently being recorded as 5 FPS.

Problem: Sometimes (10-15% of the time), the images are cropped at a much later point after the person/vehicle has crossed the line. By this time, the person has already moved far away and the resolution of the image crop is much smaller. We used filesink to visualize the videos and apparently, the NvDsAnalytics/OSD plugin sends the event of line counting when the person has already crossed the line and moved on further. There is a delay in the bounding box color change from red → blue. I’ve attached the tracker YML file in case that helps.

%YAML:1.0

  NvDCF:
    # [General]
    useUniqueID: 1    # Use 64-bit long Unique ID when assignining tracker ID. Default is [true]
    maxTargetsPerStream: 99 # Max number of targets to track per stream. Recommended to set >10. Note: this value should account for the targets being tracked in shadow mode as well. Max value depends on the GPU memory capacity

    # [Feature Extraction]
    useColorNames: 1     # Use ColorNames feature
    useHog: 1            # Use Histogram-of-Oriented-Gradient (HOG) feature
    useHighPrecisionFeature: 1   # Use high-precision in feature extraction. Default is [true]

    # [DCF]
    filterLr: 0.15 # learning rate for DCF filter in exponential moving average. Valid Range: [0.0, 1.0]
    filterChannelWeightsLr: 0.22 # learning rate for the channel weights among feature channels. Valid Range: [0.0, 1.0]
    gaussianSigma: 0.75 # Standard deviation for Gaussian for desired response when creating DCF filter [pixels]
    featureImgSizeLevel: 3 # Size of a feature image. Valid range: {1, 2, 3, 4, 5}, from the smallest to the largest
    SearchRegionPaddingScale: 1 # Search region size. Determines how large the search region should be scaled from the target bbox.  Valid range: {1, 2, 3}, from the smallest to the largest

    # [MOT] [False Alarm Handling]
    maxShadowTrackingAge: 15  # Max length of shadow tracking (the shadow tracking age is incremented when (1) there's detector input yet no match or (2) tracker confidence is lower than minTrackerConfidence). Once reached, the tracker will be terminated.
    probationAge: 0           # Once the tracker age (incremented at every frame) reaches this, the tracker is considered to be valid
    earlyTerminationAge: 15    # Early termination age (in terms of shadow tracking age) during the probation period. If reached during the probation period, the tracker will be terminated prematurely.

    # [Tracker Creation Policy] [Target Candidacy]
    minDetectorConfidence: 0.4  # If the confidence of a detector bbox is lower than this, then it won't be considered for tracking
    minTrackerConfidence: 0.2  # If the confidence of an object tracker is lower than this on the fly, then it will be tracked in shadow mode. Valid Range: [0.0, 1.0]
    minTargetBboxSize: 5      # If the width or height of the bbox size gets smaller than this threshold, the target will be terminated.
    minDetectorBboxVisibilityTobeTracked: 0.5  # If the detector-provided bbox's visibility (i.e., IOU with image) is lower than this, it won't be considered.
    minVisibiilty4Tracking: 0.5  # If the visibility of the tracked object (i.e., IOU with image) is lower than this, it will be terminated immediately, assuming it is going out of scene.

    # [Tracker Termination Policy]
    targetDuplicateRunInterval: 5 # The interval in which the duplicate target detection removal is carried out. A Negative value indicates indefinite interval. Unit: [frames]
    minIou4TargetDuplicate: 0.9 # If the IOU of two target bboxes are higher than this, the newer target tracker will be terminated.

    # [Data Association] Matching method
    useGlobalMatching: 0   # If true, enable a global matching algorithm (i.e., Hungarian method). Otherwise, a greedy algorithm wll be used.
    usePersistentThreads: 0 # If true, create data association threads once and re-use them

    # [Data Association] Thresholds in matching scores to be considered as a valid candidate for matching
    minMatchingScore4Overall: 0.0   # Min total score
    minMatchingScore4SizeSimilarity: 0.2    # Min bbox size similarity score
    minMatchingScore4Iou: 0.1       # Min IOU score
    minMatchingScore4VisualSimilarity: 0.2    # Min visual similarity score

    # [Data Association] Weights for each matching score term
    matchingScoreWeight4VisualSimilarity: 0.7  # Weight for the visual similarity (in terms of correlation response ratio)
    matchingScoreWeight4SizeSimilarity: 0.0    # Weight for the Size-similarity score
    matchingScoreWeight4Iou: 0.1               # Weight for the IOU score
    matchingScoreWeight4Age: 0.2               # Weight for the tracker age

    # [State Estimator]
    useTrackSmoothing: 1    # Use a state estimator
    stateEstimatorType: 1   # The type of state estimator among { moving_avg:1, kalman_filter:2 }

    # [State Estimator] [MovingAvgEstimator]
    trackExponentialSmoothingLr_loc: 0.9       # Learning rate for new location
    trackExponentialSmoothingLr_scale: 0.9     # Learning rate for new scale
    trackExponentialSmoothingLr_velocity: 0.9  # Learning rate for new velocity

    # [State Estimator] [Kalman Filter]
    kfProcessNoiseVar4Loc: 0.1   # Process noise variance for location in Kalman filter
    kfProcessNoiseVar4Scale: 0.04   # Process noise variance for scale in Kalman filter
    kfProcessNoiseVar4Vel: 0.04   # Process noise variance for velocity in Kalman filter
    kfMeasurementNoiseVar4Trk: 9   # Measurement noise variance for tracker's detection in Kalman filter
    kfMeasurementNoiseVar4Det: 9   # Measurement noise variance for detector's detection in Kalman filter

    # [Past-frame Data]
    useBufferedOutput: 0   # Enable storing of past-frame data in a buffer and report it back

    # [Instance-awareness]
    useInstanceAwareness: 1 # Use instance-awareness for multi-object tracking
    lambda_ia: 2            # Regularlization factor for each instance
    maxInstanceNum_ia: 4    # The number of nearby object instances to use for instance-awareness


• Hardware Platform: T4/Jetson
• DeepStream Version: 5.1
• JetPack Version (valid for Jetson only): 4.5.1

Can you check the CPU usage? Can you share some video to let us understand the issue?

I am hesitant to share the video as it belongs to my customer. I will check CPU usage and let you know, since we’re using NvDCF, that shouldn’t matter, correct?

On another note, is this a known issue? Has anyone faced it yet? I have changed some of the tracker parameters, I’m wondering if this is an effect of the new parameters.

I got the permission to share the video, I have shared it to personal message. Please let me know if you got a chance to look at it. Thanks.