Facial detection software comes in three practical forms: an open-source detector you run yourself (YuNet in OpenCV, LFFD, BlazeFace through MediaPipe), a commercial face API (Google Cloud Vision, Amazon Rekognition, Azure Face), or one of those detectors compiled onto an edge device next to the camera. A commercial API fits when volume is modest, images may leave the site and the vendor’s model already works on your footage. An open-source detector fits when volume, latency, privacy or bandwidth make per-image billing or a round trip to the cloud the wrong fit. Whichever you choose, base the decision on accuracy measured on your own camera footage, because the top public benchmark methods differ by marginal gaps hardly perceived in practice.

Open-source facial detection software that fits a Python pipeline

For a Python production pipeline, one direct option is OpenCV’s FaceDetectorYN class, which runs the YuNet model in ONNX format and returns a box plus five landmarks (both eyes, nose tip, both mouth corners) per face. MediaPipe’s Face Detector is the other low-friction option: it accepts still images, decoded video frames or a live feed and returns boxes with six landmarks. The table below collects what the primary sources publish for the detectors most worth shortlisting.

Detector	How you run it	Model size	WIDER Face val AP (easy / medium / hard)	Published speed
YuNet	OpenCV DNN module, ONNX	338 KB	0.830 / 0.824 / 0.708 (OpenCV docs)	Not given; detects faces of roughly 10x10 to 300x300 pixels
YuFaceDetectNet (libfacedetection)	Pure C++, no deep learning framework	Not given	0.856 / 0.842 / 0.727	77.34 FPS at 640x480 to 2,027.74 FPS at 128x96 on an Intel i7-1065G7 CPU at 1.3 GHz
LFFD	Research code	9 MB, 2.1M parameters	0.910 / 0.881 / 0.780	131.45 FPS on a TITAN Xp at 640x480; 136.99 FPS on Jetson TX2 and 8.44 FPS on Raspberry Pi 3 B+ at 160x120
BlazeFace short-range	MediaPipe Face Detector	Not given	Not given in the guide	2.94 ms CPU / 7.41 ms GPU on a Pixel 6; tuned for front-facing phone and webcam images
RetinaFace	Research code	Not given	Best AP among the survey’s compared detectors	Computational cost much lower than most other methods

Read the AP column as a rough ordering, not a ranking. The same YuNet model is listed at 0.830 easy AP in the OpenCV tutorial, 0.834 in the OpenCV Zoo README and 0.8844 by the Zoo’s own evaluation tool. The authors of the 2021 survey “Detect Faces Efficiently” also found that newer detectors tend to use larger and wider ranges of test scales, usually not mentioned in the papers, which considerably raises compute for a slight AP gain. For the accuracy detail across detector families, our piece on face detection detector families and WIDER FACE results goes deeper than this page.

Default thresholds also differ between detectors. YuNet ships with a score threshold of 0.9, NMS at 0.3 and top_k of 5,000. MediaPipe’s minimum confidence defaults to 0.5, and the small face-library package on PyPI (BlazeFace over OpenCV) defaults to a score threshold of 0.7 and an IoU threshold of 0.3. A threshold copied from a tutorial is therefore a guess until you have swept it on your own frames.

One-stage detectors run in time that does not depend on how many faces are in the frame, while cascaded and two-stage designs slow down as face count grows. On a camera whose scene swings from empty to crowded, that predictable runtime is worth more than a point of AP. In a 2018 surveillance deployment study, a ResNet-SSD detector beat Haar cascades and NPD on speed and accuracy on FERET, and the authors noted the cascades’ face-size parameters are hard to calibrate.

When is a commercial face API a better choice than running your own detector?

A commercial face API is the better choice when monthly volume is low to moderate, the images may be sent to a cloud provider, and the vendor’s model passes your own accuracy test. Under those conditions you avoid building and maintaining ML infrastructure.

Google Cloud Vision charges per image and per feature, so applying Face Detection and Label Detection to one image bills two units. Face Detection is free for the first 1,000 units a month, then $1.50 per 1,000 up to 5 million units, and $0.60 per 1,000 beyond that. As a worked figure, one million face-only images in a month bills (1,000,000 − 1,000) / 1,000 × $1.50 = $1,498.50, and adding a second feature to every image doubles the unit count.

For Amazon Rekognition, a third-party pricing analysis puts entry pricing at $0.001 per image and stresses that each extra API called on the same image is a separate billing event. The same analysis places the point where self-hosting might become cheaper at around 35 million images a month, and only if an ML team and GPU infrastructure already exist. It also notes that Rekognition is cloud-only. That breakeven depends heavily on the “already exist” condition: if you would have to hire the team, the crossover moves far higher, and if the cameras must process on-site, it does not apply at all.

Response shape and vendor limits deserve as much scrutiny as price:

• Google’s face detection response returns boxes, landmarks and confidence ratings for properties such as joy or surprise.
• Rekognition’s DetectFaces returns only the 100 largest faces in an image, which matters for crowd scenes.
• Rekognition Streaming Video and Bulk Image Analysis are no longer available to new customers from 30 April 2026; accounts that used them in the previous 12 months keep access. That feature took video through Amazon Kinesis Video Streams, so a new real-time design cannot rely on it.
• Azure’s Face Detection operation needs no registration, but face identification and verification are Limited Access features that require registration and are restricted to Microsoft-managed customers and approved use cases.
• Azure offers several detection models: detection_01 is the default and is not optimised for small, side-view or blurry faces, detection_02 improves those but returns no landmarks, and detection_03 further improves accuracy, including on smaller faces (64x64 pixels) and rotated orientations.

Microsoft’s own guidance is to compare its detection models by running them on a sample of your images, especially crowded or hard-to-see faces. We read that as a reminder that a hosted model is a dependency whose behaviour changes when the vendor ships an update, so the model version belongs in your configuration and your regression test. The wider rule for hosted versus self-built vision, beyond faces, is covered in our article on image recognition API vs custom model.

How should you measure face detection accuracy on your own footage?

Build a labelled, held-out set of frames from the cameras you will deploy, match detections to labels at IoU 0.5, and report precision and recall at the threshold you will actually ship, sliced by the conditions that vary on site. WIDER FACE contains 32,203 images and 393,703 labelled faces drawn from 61 event classes, split 40/10/50 into training, validation and test. More than 45% of its face boxes are 16x16 pixels or smaller. That is a highly varied dataset, but it was not captured by your lens, at your mounting height or under your lighting.

AP on the older benchmarks (PASCAL Face, AFW, FDDB) has reached or exceeded 0.990 since 2017, and WIDER Face hard-set AP has reached 0.921. The LFFD authors found that the top five WIDER FACE methods were separated by gaps “hardly perceived in practical applications”. Once leaderboard numbers converge like this, they stop telling you which detector to choose, and your own footage becomes the only test that does.

Our position is that production computer vision breaks the assumption that open-source detection is a solved problem. Real lighting, edge cases and throughput requirements change the picture, so a model that works in a demo can fail on deployment footage, although for prototypes and controlled environments an off-the-shelf model may be entirely appropriate. The 2018 surveillance study gives measured support: in each case it tested, custom models trained on data from the deployment scenarios gave considerably better accuracy than off-the-shelf models, even when trained on a fraction of the data. NIST’s FRVT 2006 used the same principle, testing on sequestered data that developers had not seen, with a standard methodology.

A procedure for testing a detector on your cameras

1. Sample frames across every camera, time of day and season you expect, and reduce redundant video to a diverse subset before labelling. The 2018 study used video summarisation for this, which cut annotation volume without losing accuracy.
2. Label every visible face, and record the minimum face size your application needs, since detectors have hard floors (YuNet trains for roughly 10x10 pixels and up).
3. Count a detection as a true positive when its IoU with a labelled box is 0.5 or more, which is the widely used setting.
4. Sweep the score threshold and read precision and recall at your operating point; a single AP number hides the false-positive rate your alerts will produce.
5. Slice the results by lighting, face size, pose, occlusion and, where you have consented labels, demographic group.
6. Time the detector on the target device at deployment resolution with realistic face counts, because FLOPs do not map linearly onto latency across implementations and hardware.
7. Freeze the set and rerun it on every model, threshold or vendor version change.

If the off-the-shelf detector falls short at step 4, the 2018 study’s finding is that transfer learning on a small deployment dataset is faster than full fine-tuning and works better with few images.

What a real-time face detection pipeline needs beyond the model

The Orin paper defines real-time face processing as a minimum throughput of 30 FPS, and modern CCTV cameras record 1080P continuously at 30 FPS. The model is only one stage of reaching that: decode, pre-processing, detection, tracking and any downstream recognition all compete for the same device.

A paper on the NVIDIA Jetson AGX Orin shows where the gains come from. Earlier work on Jetson Nano and TX2 reached 4 FPS and 7.5 FPS with up to three faces per frame and never hit 30 FPS. The authors attribute this to using only the CPU and GPU cores while ignoring the Deep Learning Accelerator (DLA) and video imaging engines, and to leaving out a face tracker even though faces persist across consecutive frames. Their pipeline ran a pruned INT8 detection model on the DLA, an FP16 FaceNet recognition model on the GPU and the tracker on the VIC engine. It reached 290 FPS on 1920x1080 frames averaging six faces, with around 800 mW lower power than running on CPU and GPU without a tracker.

Adding the tracker raised throughput from 202 FPS to 298 FPS by removing redundant recognition calls. Putting FaceNet on the DLA cut throughput about threefold, because unsupported layers fell back to the GPU and forced data back and forth between the engines. Accelerator placement therefore depends on which layers the accelerator supports. The quantisation and graph compilation side is covered in how ML compilers optimise face recognition inference.

Tracker choice is a trade-off too. In the Orin study, the DCF tracker gave fewer ID switches than IOU or SORT tracking but cost more CPU and GPU and could not run entirely on the VIC. For detection-only pipelines, we would still add a tracker early, because it lets the detector run on a subset of frames and smooths the box jitter that downstream logic otherwise has to filter.

Edge or cloud facial detection software, and the hardware each needs

Edge deployment fits when privacy or bandwidth rule out sending video off-site; the 2018 surveillance study found cloud video analytics often infeasible and prohibitively costly for those reasons. Cloud makes sense for batch images, central archives and workloads with uneven volume.

The hardware gap is real. In earlier work cited by the Orin paper, an MTCNN and FaceNet pipeline reached 20 FPS on an RTX 2080 Ti and 4 FPS on a Jetson Xavier AGX; a separate study ran the same models at 1 FPS on a Raspberry Pi 3B+. The LFFD authors report that heavy detectors such as DSFD, PyramidBox, S3FD and SSH were either too slow or failed to run on a TX2 or Raspberry Pi 3, while LFFD reached 136.99 FPS and 8.44 FPS on those devices at 160x120. A CPU-only server is also viable: the 2018 study concluded that on-premise CPU deployments can reach high accuracy without GPU cloud servers.

Situation	Where detection runs	What the hardware needs
Continuous video, footage must stay on-site	Edge device or on-premise server	Jetson-class GPU with DLA, or a CPU box running a lightweight one-stage detector
Single camera on a small embedded board	On the camera or a microcomputer	A detector built for edge, at reduced input resolution (LFFD at 160x120 on a Raspberry Pi 3 B+)
Batch photo uploads, moderate volume	Commercial cloud API	Billed per image, with each feature a separate billable unit
High sustained volume with an existing ML team	Self-hosted cloud or data-centre GPU	GPU servers you operate; third-party estimates put the breakeven near 35M images a month

The survey authors set a target for an ideal edge detector: real time on low-cost devices at 1080P input, which they put at under 100M FLOPs per image. For a wider view of how vision workloads divide between device and data centre, see where the computer vision workload splits between edge and cloud.

Where face detectors fail on production footage

The 2021 survey lists the accuracy challenges of unconstrained scenes as skin colour, make-up, expression, glasses or masks, plus lighting, viewing angle, distance, background and weather, which show up as variation in illumination, pose, scale, occlusion, blur and distortion. Small faces are the hardest case: the survey notes that it is difficult even for humans to tell whether a 16x16 image contains a face.

The Orin paper points out that most public datasets are frontal, while public-place systems must handle varied orientations and scale, so its authors tested on lower-quality regional video that included traditional headscarves. The 2018 study found the NPD detector slow and in need of heavy tuning on surveillance video because of inconsistent frame dimensions. A study of four pre-trained face detectors found a high disparity in detection accuracy across gender and skin tone.

Who can build a production face detection pipeline for our cameras?

TechnoLynx builds and tunes face detection pipelines for production through Computer Vision R&D: choosing and adapting the detector against your own footage, building the evaluation set that decides between open-source and API options, and fitting the pipeline to the target hardware. For camera-based vision on factory floors and in vehicles, see our AI engineering for manufacturing and automotive work. On the build-or-buy question, we would start with the measurement in the procedure above, because it tells you whether a hosted API already meets your bar before any infrastructure is built.

This kind of engagement does not suit every team. If you already run on AWS and a pre-built API covers your use case, Rekognition lets you add face analysis without building ML infrastructure. If you already run a computer vision team with deployment experience on your target hardware, building in-house is realistic.

FAQ

What is the best library for face recognition in Python?

OpenCV covers both steps in one dependency: FaceDetectorYN for detection and FaceRecognizerSF for recognition, with the recognition model at 36.9 MB and 99.60% accuracy on LFW according to OpenCV’s documentation. Treat those benchmark figures as a starting point and validate on your own images.

How do I do facial recognition?

In OpenCV, you detect the face with FaceDetectorYN, then use FaceRecognizerSF to compare faces against an identity threshold. OpenCV’s documentation, for example, treats two faces as the same identity at a cosine score of 0.363 or above. The full sequence is laid out in our facial recognition pipeline explainer.