Hockey tracking camera
Player tracking and a virtual camera that frame a live amateur hockey game with no one filming, on one desktop per rink, within a 30 ms frame budget.
US tennis-tech startup
Computer vision that finds every rally in a recorded match and cuts the video by about 70%, on a cloud server with no GPU.

In short
The startup records amateur tennis matches so coaches and players can review them. In an amateur match the ball is in play for about a quarter of the time. A coach watching an uncut recording spends most of it scrubbing through pauses, so the product needed every match to arrive already cut down to the rallies.
Over seven months, five It-Jim engineers built the system that makes the cut. It finds the court, follows both players and returns the start and end of every rally. It was first built for an iPhone that a player sets up at any court. When the client moved to low-cost cameras installed in tennis clubs, with processing in the cloud, the same models went into a cloud service.
Ball in play: about a quarter of the match Everything else
Players, balls, poses or reps: we start with a two-week technical research on your footage and tell you what can be detected reliably, on your cameras and your hardware. Shall we look at it?
About the client
The client is a US sports startup that builds tools for tennis coaching. It records matches of amateur players and gives coaches and players video they can review. The camera stands where an amateur court allows it: at the side or behind the baseline, far below where TV cameras film from.
The startup needed computer vision of its own for that setting, and it had no in-house ML team to build it.
Main challenges the customer faced
Between points, players walk, collect balls, towel off and change ends. In the startup's hand-annotated matches, the ball was in play for 22% to 33% of the recording.
A coach reviewing a student's match had to scrub through all of it to find the points. The product needed the video to arrive cut down to the rallies, for every match.
Most tennis computer vision is trained on broadcasts filmed from high above the court in good light. The startup's footage looked nothing like that:
At the start, nobody knew which approach would hold up on this footage: motion detection, ball tracking or player tracking. The client still needed builds it could test while the research went on.
The system also had to stay cheap to run: one model filling a whole GPU for one match would work in a demo, not across many clubs.
What we did
Every two-week sprint ended with a written research report and a demo on the client's own recordings, so the client saw each decision and the evidence behind it.
The research ran in four lines: ball, court, players and trimming. Each one ended either in the product or in a written reason to drop it. From the fifth month, every release was benchmarked against the one before.
Solution
Why it matters: in the first test, most of the false "play" came from a match on the next court. A system that cannot tell its own court from the neighbour's would send coaches clips of strangers.
Classic motion detection found the ball, and also arms, shadows and wind. The fix was to locate the court first and mask out everything around it: neighbouring courts, passers-by and cars.
For full automation we trained a small neural network that finds 21 court keypoints, even when the net or the edge of the frame hides part of the court. We built its training set ourselves from about 1,300 frames with low camera angles, different light and different surfaces. The court is then mapped to a top-down view, so every player position is measured in court units.
rough point exact intersection far half, often hidden by the net. The top-down map shows both players in court units.
Solution
Why it matters: the first product put the camera in the player's hands: an iPhone on a tripod at any court, with the cut made on the phone. A model that needs a big GPU could never run there.
We tested six ball detectors on the client's footage. General detectors missed the 2-pixel ball on the far side, and the most accurate one needed a whole GPU. TRexNet, a light model that reads differences between frames, ran about 40 times faster on a CPU and found more of the real balls.
The first trimming version judged each ball path by simple physics: how long it flies, a downward parabola, the distance across the court. With ball detection and trimming together, it ran for a full hour on an iPhone 15 Pro. The iOS app built around it reached a near-final prototype.
Solution
Why it matters: a coach notices a missing rally at once, and a clip full of pauses defeats the purpose. Ball-based rules stayed brittle when the ball was hidden or far away, so the final model looks at the players instead. Their movement during a rally is steady and visible in every frame.
The far player is too small to detect in a shrunk frame. So we stack a zoomed crop of the far half on top of the full frame and detect both players in one pass, with no second model and no extra time.
Each change, such as looking ahead in time as well as back or training on 11 recordings instead of one, was measured against the previous release.

Solution
Why it matters: the cost of each match decides whether the business grows from one club to dozens.
Later in the project the client changed the setup. Instead of players filming with their phones, low-cost cameras built on Raspberry Pi are installed at the courts, and the video is processed in the cloud. The client reports the system running in more than 12 US tennis clubs.
Because every model had been kept small, the pipeline moved to the cloud without a GPU. It runs in a container on a CPU server with 4 cores and 8 GB of RAM. The client's next aim is to make the processing light enough to run on the camera itself.

Key results
A cut only helps if it is trusted. We checked how much of each match goes, whether the rallies stay, whether the system works on a court it has not seen, and what it costs to run.
Across 10 matches annotated by hand, 14.8 hours in total, the ball was in play 27.7% of the time, from 22% to 33% per match. A 90-minute match comes down to about 25 minutes of rallies.
Everything dark is cut. This match was part of the training data, so the picture shows how the cut looks, while the held-out accuracy is in result 2.
On parts of matches the model never saw in training, with warm-ups and practice left out, the final model keeps 92% of play time, and 95% of what it keeps is real play.
A new club should not need a new model. We trained the model with one match left out and tested it on that match. It scored an F1 of 0.886, close to the 0.91 of the model that had seen it.
The whole service runs on a CPU server with 4 cores and 8 GB of RAM, so the cost per match stays low as more club cameras send video.
Business results
The startup sells coaching video. With the cut automatic, every recorded match turns into a short review clip, and the service runs on cheap hardware as more clubs join.
All code, trained models and datasets were handed over into the client's own repositories, with documentation for the pipeline, so the client's team can keep developing it.
Features delivered
The technology we used
No vague promises. No pressure. Just a real conversation with our technical leadership to understand your needs and explore the best next steps.