Chinese License Plate Detection and Recognition: A Two-Stage YOLOv5 and CRNN Pipeline

The gap this fills: Chinese plate formats are not one problem

Generic OCR models handle Latin characters and digits. Chinese plates break that assumption in two ways. First, the character set includes province abbreviations and Chinese glyphs, so a model trained on Latin text has no output vocabulary for most of the string. Second, plate geometry varies by category. The README lists twelve supported types, and several are double-layer: 双层黄牌, 双层白牌, and 双层绿牌 occupy two text rows instead of one. A single-line detector that crops a tight box around a double-layer plate will cut the string in half.

The project targets engineers who need to read plates from images or video and want a pipeline they can run locally rather than call as a hosted API. The README also points to an Android NCNN port, a TensorRT repository, and an OpenVINO demo, which suggests the intended audience includes edge and embedded deployment, not just desktop inference. The repository description states support for 12 Chinese plate types and double-layer plates, and the checklist enumerates them: single-line blue, single-line yellow, new-energy, white police, coach, armed police, double-layer yellow, double-layer white, embassy, Hong Kong-Macau 粤Z, double-layer green, and civil aviation.

What the material does not give is any accuracy figure, per-category breakdown, or dataset description beyond the statement that models were trained on public datasets. Treat the twelve-item list as a claim about coverage, not about error rates.

Two models, two jobs: detection then recognition

The architecture is a cascade. A YOLOv5 detector locates plates and produces bounding boxes. A second model, described in the demo command as plate_rec_color.pth, reads the cropped plate and appears to emit both the character string and a colour attribute, judging by the filename. The detection training code lives in a readme subdirectory of this repository; the recognition training code lives in a separate repository, crnn_plate_recognition, which the README links. That split matters: the recognition half is a CRNN (convolutional recurrent network) trained independently, so you cannot fine-tune the full pipeline from one training script.

The README credits two upstream projects in its references section, yolov5-face and CRNN_Chinese_Characters_Rec, which indicates the detector derives from the face-detection fork of YOLOv5 and the recogniser derives from a Chinese character CRNN implementation. Neither the detection head modifications nor the recognition vocabulary construction is described in the README itself. If you need to know how double-layer plates are handled internally (separate classes, a row-splitting step after detection, or a recognition model that outputs two lines), the README does not say. That is a real documentation gap for anyone planning to retrain.

The data flow for inference is straightforward: image or video frame in, detector boxes out, each box cropped and passed to the recogniser, results written to an output directory or a result video file. The command-line arguments in the demo confirm this shape, with separate flags for the detection model and the recognition model.

Running the demo: the exact commands and what they expect

The README gives a direct image test. Running detect_plate.py with no arguments is stated to work, and the equivalent explicit form is:

python detect_plate.py --detect_model weights/plate_detect.pt --rec_model weights/plate_rec_color.pth --image_path imgs --output result

Input is a folder of images (imgs), output goes to a folder (result). For video, the same script takes a --video flag instead of --image_path:

python detect_plate.py --detect_model weights/plate_detect.pt --rec_model weights/plate_rec_color.pth --video 2.mp4

The README states the result is saved as result.mp4. Note that the video demo links to an external file host with an extraction code, so the sample video is not in the repository.

Deployment variants change the model format but not the argument names. The ONNX path is:

python onnx_infer.py --detect_model weights/plate_detect.onnx --rec_model weights/plate_rec_color.onnx --image_path imgs --output result_onnx

The OpenVINO path is:

python openvino_infer.py --detect_model weights/plate_detect.onnx --rec_model weights/plate_rec.onnx --image_path imgs --output result_openvino

Two details are worth flagging. The OpenVINO command names plate_rec.onnx while the ONNX command names plate_rec_color.onnx, so the recognition checkpoints differ between the two examples. Whether that is intentional (a colour-free variant) or a typo in the README cannot be determined from the material. Second, the environment requirement is stated as python >=3.6 and pytorch >=1.7, and the OpenVINO demo is pinned to version 2022.2. The ONNX demo weights are distributed through a Baidu netdisk link rather than in the repository, so the ONNX route requires an extra download step outside git.

Where this breaks down

The most concrete limitation is distribution. There are no releases. The README shows no version tags, no changelog, and no compatibility matrix. You pin to a commit hash on main or you track a moving branch. For a component that sits in an inference path, that is a maintenance decision you have to make deliberately.

The second limitation is the training split. Detection training is documented in this repository's readme folder, but recognition training lives in a different repository. If your plate categories are under-represented in the public training data, you will be running two training workflows with two sets of instructions, and the README does not describe how to keep the detector's class definitions in sync with the recogniser's character vocabulary.

The third is the model weights themselves. The README states the models were trained on public datasets and that higher-accuracy models are available through a WeChat contact. That means the published weights are a baseline, not a ceiling, and the path to better accuracy is a commercial conversation rather than a documented fine-tuning recipe.

Finally, consider the wrong-tool case. If your plates are not Chinese, the twelve-category classifier and the Chinese character vocabulary are dead weight. If you need a maintained, versioned OCR library with an SLA, this is not it. And if you need permissive licensing for a closed-source product, GPL-3.0 is the blocker before any technical question arises.

Alternatives and the difference in approach

The README itself points to sibling repositories by the same author: yolov8-plate, yolov7_plate, and yolo26-plate, plus a separate Car_recognition project that detects vehicles and plates together. The most useful comparison is yolo26-plate, announced in the What's New section with a date of 2026.02.13. The difference is the detector backbone generation: this repository uses YOLOv5, while yolo26-plate uses a newer YOLO generation. The recognition stage is not described in the README for either, so whether the CRNN half is shared or replaced is not stated. If you are starting fresh and have no reason to prefer YOLOv5, the newer detector repository is the one the author is actively pointing to.

A second alternative is the Android NCNN port, linked as a separate repository. That is not a different algorithm; it is the same pipeline reimplemented for mobile inference. The relevant difference is deployment target, not accuracy. If your product runs on a phone, the port saves you an export step.

For the recognition stage specifically, the upstream CRNN_Chinese_Characters_Rec project is cited as a reference. Going directly to that upstream gives you a recogniser without the plate-detection wrapper, which is the right move if you already have a detector and only need the character model. The trade-off is that you lose the integration and the colour output that plate_rec_color suggests.

None of these alternatives is described in enough detail in the README to compare accuracy. The honest summary is that the choice is about detector generation and deployment target, not about measured performance.

Licence and the cost of keeping it current

The repository is GPL-3.0. That is a copyleft licence: if you distribute a product that incorporates this code, the licence terms attach to the distributed work. Whether your specific use counts as distribution, and how the licence interacts with the separately hosted recognition training repository and the ONNX weights on a file-sharing link, is a question for a lawyer, not for this article. What can be said plainly is that GPL-3.0 is incompatible with shipping a closed-source binary that links this code, so if that is your requirement, stop here.

Maintenance cost is harder to estimate because the material does not support it. There are no releases, so there is no upgrade path in the usual sense. The last push is dated 2026-06-05, which indicates the repository is not abandoned, but activity is not the same as a support commitment. The README's contact section offers commercial work and higher-accuracy models, which implies the author's attention is partly directed at paid engagements rather than at a public support channel. The QQ group numbers listed include two marked as full, which tells you the community exists but says nothing about response quality.

Practically, budget for pinning a commit, vendoring the weights you need, and testing any future pull yourself. There is no changelog to read before you upgrade, so an upgrade is a re-test, not a version bump.

Who should take this on

This repository is a reasonable starting point for a student project, an internal prototype, or a research baseline where you need Chinese plate OCR running today and can accept a two-stage pipeline you will have to understand from the code rather than the README. The twelve-category checklist is unusually broad for a public project, and the double-layer support is the part most alternatives skip.

It is the wrong choice for a production system that needs a versioned dependency, a documented accuracy figure per plate category, or a permissive licence. It is also the wrong choice if your plates are not Chinese, or if you need the detector and recogniser to be trainable from a single script.

Before committing, verify three things against your own data. First, run the image demo on samples of every plate category you care about, including at least one double-layer type, because the README gives no accuracy breakdown. Second, confirm which recognition checkpoint your deployment target expects, since the ONNX and OpenVINO examples name different files. Third, check whether the detection classes in weights/plate_detect.pt line up with the categories you need, because retraining the detector means retraining against the readme folder instructions while the recogniser is trained in a separate repository.

Editorial conclusion

Adopt this repository if you need a runnable starting point for Chinese plate OCR and can accept GPL-3.0 obligations, and verify first that your target plate categories appear in the twelve-item support list, that the ONNX or TensorRT export path matches your deployment target, and that the recognition model weights you download actually correspond to the colour-aware checkpoint named in the demo command. Do not adopt it if you need a maintained library with versioned releases, an API contract, or permissive licensing for a closed product. The repository has no releases, so the main branch is the only thing you can pin to.

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. we0091234/Chinese_license_plate_detection_recognition on GitHub