[Config Support]: LPR starts late

[federicotravaini]

Describe the problem you are having

For some moving vehicles, LPR starts too late after the event begins. For example, the car event started at 14:46:40, but plate recognition only started at 14:46:54, about 14 seconds later (even if the plate was recognized at 14:46:40)

Version

0.17.1

Frigate config file

mqtt:
  host: 192.168.13.127
  port: 1883
  user: .
  password: .

tls:
  enabled: false

logger:
  default: info
  logs:
    frigate.data_processing.common.license_plate: debug

semantic_search:
  enabled: false
  reindex: false
  model_size: small

model:
  path: plus://******************************

lpr:
  enabled: true
  recognition_threshold: 0.6
  match_distance: 2
  debug_save_plates: true
  #replace_rules:
  #  - pattern: '[- ]'
  #    replacement: ''
  #  - pattern: '[_%#*=]'
  #    replacement: ''
  known_plates:
    SUDOPT_CALYPSO:
      - HC402KM
      - ^H[CG][- ]?4[0O]2[KM]{2}$

# there are more than 30 other plates defined with regex


ffmpeg:
  hwaccel_args: preset-vaapi

detectors:
  coral:
    type: edgetpu
    device: usb

objects:
  track:
    - car
    - license_plate
  filters:
    car:
      threshold: 0.7
      min_area: 200000
    license_plate:
      threshold: 0.7
      min_area: 2000

snapshots:
  enabled: true
  retain:
    default: 1


record:
  enabled: true
  alerts:
    retain:
      days: 1
  detections:
    retain:
      days: 1

go2rtc:
  streams:
    inside: 
      rtsp://10.39.40.76:554/cam/realmonitor?channel=1&subtype=0
    outside: 
      rtsp://10.39.40.73:554/cam/realmonitor?channel=1&subtype=0

cameras:
  inside:
    ffmpeg:
      inputs:
        - path: rtsp://localhost:8554/inside
          roles:
            - detect
            - record
    detect:
      enabled: true
      fps: 10
      min_initialized: 1
    motion:
      mask: 0.74,0.034,0.742,0.089,0.97,0.087,0.968,0.031
      threshold: 80
      contour_area: 50
      improve_contrast: true
    review:
      detections:
        labels:
          - license_plate
          - car

  outside:
    ffmpeg:
      inputs:
        - path: rtsp://localhost:8554/outside
          roles:
            - detect
            - record
    detect:
      min_initialized: 1
      enabled: true
      fps: 10
    motion:
      mask: 0.682,0.093,0.68,0.034,0.967,0.029,0.969,0.102
      threshold: 80
      contour_area: 10
      improve_contrast: true
    objects: {}
    review:
      detections:
        labels:
          - license_plate
          - car

version: 0.17-0

face_recognition:
  enabled: false
  model_size: small
classification:
  bird:
    enabled: false

Relevant Frigate log output

Event: 1774532800.526267-4d9ip7
  Camera: outside

  2026-03-26 14:46:40 [DEBUG] outside: Skipping LPR for non-stationary car object 1774532800.526267-4d9ip7 with no position changes. (Detected in
  2 concurrent frames, threshold to run is 3 frames)
  2026-03-26 14:46:54 [DEBUG] outside: Skipping LPR for non-stationary car object 1774532800.526267-4d9ip7 with no position changes. (Detected in
  2 concurrent frames, threshold to run is 3 frames)
  2026-03-26 14:46:54 [DEBUG] outside: Running plate recognition for id: 1774532800.526267-4d9ip7.
  2026-03-26 14:46:54 [DEBUG] outside: Saving plates for event 1774532800.526267-4d9ip7
  2026-03-26 14:46:58 [DEBUG] Selected rep from best cluster: 'G-419KM' (conf: 0.838)
  2026-03-26 14:46:58 [DEBUG] Final clustered plate: 'G-419KM' (conf: 0.838)
  2026-03-26 14:47:03 [DEBUG] outside: car object 1774532800.526267-4d9ip7 has been stationary for > 5 seconds, skipping LPR.

Relevant go2rtc log output

No relevant go2rtc log output. The issue appears to be in Frigate LPR timing/clustering, not in go2rtc stream handling.

Frigate stats

{
    "service": {
      "version": "0.17.1-416a9b7",
      "uptime": 20667
    },
    "detectors": {
      "coral": {
        "inference_speed": 14.55
      }
    },
    "cpu_usages": {
      "frigate.full_system": {
        "cpu": "39.9",
        "mem": "66.0"
      },
      "go2rtc": {
        "cpu": "11.4",
        "mem": "0.5"
      },
      "frigate": {
        "cpu": "10.8",
        "mem": "7.9"
      }
    },
    "gpu_usages": {
      "intel-vaapi": {
        "gpu": "8.8%"
      }
    }
  }

Operating system

Other Linux

Install method

Docker Compose

docker-compose file or Docker CLI command

services:
  frigate:
    image: ghcr.io/blakeblackshear/frigate:0.17.1
    #https://github.com/blakeblackshear/frigate/pkgs/container/frigate
    privileged: true
    hostname: frigate
    restart: unless-stopped
    shm_size: 4096mb
    devices:
      - /dev/bus/usb:/dev/bus/usb # passes the USB Coral, needs to be modified for other versions
      - /dev/dri:/dev/dri
    volumes:
      - /dev/bus/usb:/dev/bus/usb
      - /etc/localtime:/etc/localtime:ro
      - /home/pt/docker/frigate-dev/config:/config:rw
      - /home/pt/docker/frigate-dev/media:/media/frigate:rw
    ports:
      - 5000:5000 # web interface
      - 1935:1935 # RTMP feeds
      - 8555:8555/tcp # WebRTC over tcp
      - 8555:8555/udp # WebRTC over udp
      - 8554:8554
      - 8971:8971
    environment:
      - PLUS_API_KEY=*************
      - LIBVA_DRIVER_NAME=i965
networks: {}

Object Detector

Coral

Screenshots of the Frigate UI's System metrics pages

Any other information that may be helpful

No response

[inkeep-ai-assistant[bot]]

---

The delay you're seeing is related to how LPR handles position tracking for moving vehicles. Your logs show the message "Skipping LPR for non-stationary car object ... with no position changes. (Detected in 2 concurrent frames, threshold to run is 3 frames)" - this indicates Frigate requires the license plate to be detected in at least 3 consecutive frames before running recognition. (1)

This frame threshold behavior is by design for moving vehicles. Frigate continuously refines the recognition process for moving vehicles, keeping the most confident result. When a vehicle becomes stationary, LPR continues to run for a short time after to attempt recognition. (1)

A few things to check:

1. Plate size may be too small initially
The min_area setting defines the minimum area (in pixels) a license plate must be before recognition runs. Your global setting is min_area: 2000 for license_plate. If the plate appears small when the car first enters the frame, LPR won't trigger until it gets larger. (1)

2. Detection threshold timing
Since you're using a Frigate+ model with license_plate as a tracked object, the plate needs to meet your threshold: 0.7 filter before LPR can process it. Early in the event, the plate may not be scoring high enough. (1)

3. Frame rate consideration
You're running at fps: 10. For moving vehicles, the documentation suggests 5 fps (increase to 10 if vehicles move quickly across your frame). Higher than 10 is unnecessary and is not recommended. (1)

Potential adjustments:

• Lower your license_plate threshold slightly (e.g., 0.6) to allow earlier detection
• Reduce min_area for license_plate if plates are small when entering the frame
• Verify your camera resolution provides clear plate visibility at the point where vehicles enter

The 14-second delay aligns with the car becoming stationary at 14:46:54, which is when the frame threshold was finally met and recognition ran successfully.

📚 Sources:

1. License Plate Recognition (LPR)

---

Have another question? Just tag @inkeep.

[federicotravaini]

I agree that the main signal in the logs is:

Skipping LPR for non-stationary car object ... (Detected in 2 concurrent frames, threshold to run is 3 frames)

That does seem to indicate that the delay is primarily caused by the internal frame-position gating before LPR starts.

The only point I am less certain about is the statement that the delay aligns with the car becoming stationary at 14:46:54.

From my logs for event 1774532800.526267-4d9ip7 (panamera_event_1774532800.log), what I can say is:

• event start: 14:46:40
• first Running plate recognition: 14:46:54
• debug plate crops saved from 14:46:54 to 14:47:03
• car object ... has been stationary for > 5 seconds only at 14:47:03

So from my side, it looks safer to say that LPR only started at 14:46:54 because the frame threshold was finally met, rather than concluding that the vehicle had already become stationary exactly at that timestamp.

At this point, my understanding is that this is expected behavior from the current LPR startup logic for moving vehicles, and not an issue with detector saturation, since the system was not under heavy load.

If that is correct, then the main takeaway for me is that there is probably no additional config change to make LPR start earlier beyond what I already have (min_initialized: 1, fps: 10), unless I lower license_plate.threshold, lower license_plate.min_area, or improve the camera framing so the plate becomes large and stable earlier in the scene.

---

One additional question: could the size of the known_plates list also contribute noticeably to LPR latency?

In my live config I currently have a fairly large known_plates set, with many canonical entries and many regex-based entries. I am wondering whether matching against a larger ruleset can materially increase the time between the first usable OCR reads and the final recognized plate / label, or whether that impact should be negligible compared to the frame-gating behavior.

If it can have a measurable effect, I can try temporarily reducing the known plate set to see whether recognition becomes faster.

[hawkeye217]

Setting min_initialized to anything less than 2 is not recommended. When you do so, Frigate's object tracker will promote a detection to a fully tracked object after just a single detection hit, with no temporal confirmation whatsoever. This is problematic because object detectors - especially when running on high-resolution LPR camera feeds - regularly produce spurious single-frame false positives: reflections, headlight glare, signs, or transient artifacts that momentarily score above the confidence threshold but don't persist across frames. With min_initialized: 2, Frigate requires the object to be detected in at least two consecutive frames before initializing a track, which acts as a lightweight temporal filter that eliminates the vast majority of these one-off false detections. The value of 2 is the minimum sane threshold that confirms an object actually exists in the scene rather than being detector noise, while still being responsive enough to catch vehicles that may only be visible for a short window.

known_plates will not contribute to recognition latency, Frigate just does post-recognition filtering based on any of these values.

The biggest contributor to latency is usually your device and model size as well as any other enrichments that are running. The default with nothing specified in the config is small, which is what is recommended on 0.17.

Can you post a screenshot of your enrichment metrics page?

[hawkeye217]

Can you show a screenshot of your camera's firmware settings for video and audio?

[federicotravaini]

is this what you need?

[hawkeye217]

Yes. That all looks good. Your camera settings are very conservative.

[easy-and-simple]

In camera configuration you have included this line objects: {}, that probably is making the problem you have because it is not clear what it means. This is the only difference in both camera settings, so remove this line -> objects: {} from configuration of outside camera

[federicotravaini]

In camera configuration you have included this line objects: {}, that probably is making the problem you have because it is not clear what it means. This is the only difference in both camera settings, so remove this line -> objects: {} from configuration of outside camera

I removed that line already but had nothing to do with the issues.