Till which speed of the car does the software read the number plates

I have a 2MP 30fps camera for monitoring the service road where cars usually move at a speed of 20 - 60 Km/h

Can I get satisfactory results if I use this camera or should I go with 60fps camera or with other higher features?

Yes, 30fps is sufficient for very high-speed traffic (150km+). For LPR, we really only need to capture 2 or 3 frames of a license plate to achieve high-accuracy. For low speed applications, 5 fps is usually perfectly sufficient. Usually the limitation is the CPU or GPU processing the input data. So, make sure that you have a sufficiently fast PC dedicated to LPR in order to capture the vehicles at your target speed.

-Matt

Thanks a lot for the Clarification

@Matt Can you advice on what specs would be required?
I raised a similar question here but not had a response yet:

This will happen when OpenALPR has more frames to process than the CPU resources allow. This is actually the normal mode of operation on most of our dedicated installs – if we did not use 100% CPU then we would be operating inefficiently, unless resources were in excess.

There’s two adjustments you can make to reduce OpenALPR CPU usage:

  1. Set the analysis_threads parameter to fewer (e.g., 1). This will limit how many CPU cores OpenALPR uses for plate recognition
  2. Disable make/model recognition if you’re not using it.
  3. Limit the input video frames/second to a lower number. For example, if you limited the input video to 4fps, and OpenALPR could process 16fps, we would only be using ~25% of a CPU.
  4. On Linux you can set the analysis_priority = -1 to give other processes priority over the agent

The key values to look at are in the alpr.log.
2018-07-17 14:54:04 alprd 139798032885504: DEBUG - camera 2090267338: video fps: 20 motion: 52.3% rec. fps: 18.2 (91%)

These numbers are a metric for:

  1. How much input video we’re receiving. This should always match what you’re expecting (i.e., if the camera is configured for 30fps, this should be steady 30fps). This would only dip if there were bandwidth issues or lack of processing resources to decode the stream.
  2. This is the amount of motion in the scene (number of moving pixels over the total).
  3. This is what percentage of those moving pixels were processed.

For CPU processing, we only look at rectangular regions where motion occurred. For GPU processing, we always process the full resolution image if there is any motion at all. If there was no motion, we skip the frame.

Keep in mind that skipping frames may not necessarily reduce overall accuracy. For low-speed applications, 5 fps of processing may be perfectly acceptable. For higher speed installs (e.g., 90+mph on a highway) you will likely need 20+ fps and a good camera setup to capture clear plate images.

Excellent response Matt, Thanks! I see for the GPU configuration you have some advertising here https://www.openalpr.com/nvidia.html

According to the current release notes a GPU is the way to go if you are going to be analyzing multiple streams and you want to maintain accuracy at high speeds. ref from release notes for 2.5.103 “Massive Nvidia GPU performance improvement 100%+ faster throughput (fps) on desktop GPU, even larger improvement on Jetson”

Are there any limitations when using a windows environment with a GPU configuration as opposed to Linux?

Currently the Nvidia support is Linux only. That is mainly because we are waiting for Windows support from Nvidia for a dependent library. I have been told that this may be added early next year.