The pipeline
How Chrio tracks a cricket ball and puts the result on air.
Six stages between a camera feed arriving at the ground and a finished overlay leaving for the gallery, all running on a single workstation with one GPU at 30 frames per second. This page is the engineering detail, in order, including what each stage costs in time.
Why consensus
A ball is only a ball when three detectors agree.
A cricket ball on a broadcast feed is a small, fast, frequently-occluded object against a background that changes with every camera angle and every hour of daylight. A single detector run over that footage produces two kinds of error that matter: it misses balls, and it invents them. Missed balls break the track. Invented balls put a wrong call on air.
Chrio runs YOLOv8, YOLOv11 and Detectron2 in parallel on every frame and keeps a detection only when the ring agrees. That trades some recall for a large gain in precision, which is the right trade when the output is going to a broadcast: a missed delivery is a gap, a wrong delivery is an embarrassment.
What consensus loses, SAHI recovers. Sliced inference runs the detectors again over sub-regions of the frame, which is how the balls too small for a full-frame pass get found before the track breaks.
The six stages
Feed in, overlay out.
-
01
Feed in
The broadcast or camera feed arrives on the machine at the ground over NDI or SDI capture. No truck, no uplink.
NDI (Network Device Interface) and SDI (Serial Digital Interface) are the two standards a production gallery already speaks; supporting both means the feed arrives without anything being rebuilt around it.
-
02
Three detectors vote
YOLOv8, YOLOv11 and Detectron2 run in parallel on every frame. A detection is kept only when the ring agrees.
-
03
SAHI recovery
Sliced inference recovers detections the full-frame pass missed, before the track breaks.
SAHI (Slicing Aided Hyper Inference) runs the detector over overlapping sub-regions of a frame, the standard technique for small objects at broadcast resolution.
-
04
Predict
An LSTM interpolates gaps in the trajectory; XGBoost classifies the shot and scores its difficulty from 1 to 10. Game state is part of the input: the right shot on ball 3 of over 2 is not the right shot on ball 6 of over 19.
-
05
Render
The recommended shot is posed on the 3D batter and rendered in Blender, in the broadcast's own kit.
-
06
NDI out
The overlay leaves as an NDI stream. Chrio rewrote a Python NDI library and removed a critical memory leak in it to make this stage hold under continuous match-length load.
That last part matters more than it sounds. NDI is the standard most production galleries already accept, so the output arrives as just another source: your director drops it into the replay slot without changing anything about how the gallery works.
Latency
Where the time goes.
Five different latency figures describe five different things, so here they are in one place. Where a figure has not been published yet, the row says so rather than borrowing a number from a neighbouring measurement.
| Stage | Measured cost | What the figure measures |
|---|---|---|
| Detection consensus | Not yet published | Per frame, three detectors in parallel |
| SAHI recovery | 1.5 ms | Additional cost of sliced inference. What the figure is measured per, whether frame, slice, or only on frames the ring missed, is not yet published. |
| Model inference, total | 33 ms per frame | Down from 200 ms before CUDA optimisation |
| Shot prediction | Not yet published | LSTM interpolation plus XGBoost classification |
| Render | Not yet published | Blender, one delivery |
| End to end, delivery to on-air overlay | 4.5 s | Ball bowled to overlay available to the gallery. Whether this is a median or a best case, and the conditions, are not yet published. |
| Sustained throughput | 30 fps on one GPU | Continuous, single Nvidia GPU |
Hardware: one workstation, one Nvidia GPU, two monitors, one capture card. Models trained with TensorFlow and Roboflow. Written in Python.
Tooling credits, not partnerships.
Limits
What the pipeline does not do.
Worth stating, because a vendor that only publishes its strengths is asking to be found out later.
-
It needs a clean feed
A clean SDI or NDI feed of the camera behind the bowler's arm. Heavily compressed or upscaled sources degrade detection.
-
It needs calibration against the ground
Most of the setup hour is calibrating against the pitch markings. Move the camera and it needs redoing.
-
It does not run unattended
Every call is reviewed by the operator on the video manager before release.
-
It does not adjudicate
CritShot is analysis, not officiating. Decision review is CritDRS, which is in development.
Talk to the people who built it.
If you want to go through the signal path, the calibration requirements or the failure modes, the call is with an engineer.