OpenDataCam: counting moving objects with YOLO, a tracker and polygon counters
An open source tool to quantify the world
At a glance
- What is it?
- OpenDataCam is an MIT-licensed JavaScript application that runs YOLO object detection on camera or video feeds, tracks the objects across the frame and counts them when they cross counters you draw in the browser UI. It ships as Docker images for Jetson devices and NVIDIA GPUs, and its latest tagged release is v3.0.2 from 2021.
- Who is it for?
- Adopt OpenDataCam if you need counted crossings from a fixed camera or a recorded video and you can supply a Jetson or an NVIDIA GPU, because the counting logic, the tracker and the export endpoints are already wired together. Do not adopt it if you need a maintained release cadence: the newest tagged release is v3.0.2 from 2021-09-16, and the last push to the repository was on 2026-04-23, so the development branch is where change happens.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 148 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What OpenDataCam counts, and for whom
OpenDataCam is a counting tool, not a general vision platform. The README describes it as a way to "quantify the world": computer vision detects moving objects, the application follows them across the scene, and every time an object crosses a counter the count increments. The README states that people use it mostly for traffic studies such as modal-split and turn-count work, and that it detects 50+ common object classes out of the box. If the class you care about is not among them, the README points at training your own model rather than promising a configuration switch.
The intended user is someone with a camera and a question that reduces to crossings: how many cars turned left between 08:00 and 09:00, how many pedestrians used this path, how many bicycles entered the zone. The repository is JavaScript, the UI is Next.js and React, and the deployment target is a small device in the field or a machine with an NVIDIA GPU. The homepage is opendata.cam, and the README notes that professional support requests go through a separate page. That split matters: the free path is GitHub Discussions for questions and GitHub Issues for bugs and features.
Detection, tracking and counters: how the pipeline fits together
The dependency list in package.json is the clearest description of the architecture. Detection comes from a Darknet build, and the README credits the darknet fork by alexeyab with YOLOv4 as the detector. Tracking comes from node-moving-things-tracker, a JavaScript port of the IOU/V-IOU tracker by bochinski, which the README also credits. Counting geometry uses point-in-polygon, which is how a trajectory is tested against a drawn counter region.
The application layer is Express plus a Next.js front end, with MongoDB as the store (the mongodb driver and a MONGODB_URL pointing at mongodb://mongo:27017). Darknet does not hand results to the UI directly; it exposes streams. The .env.example file names three ports: PORT_APP=8080 for the web application, PORT_DARKNET_MJPEG_STREAM=8090 for the annotated video stream, and PORT_DARKNET_JSON_STREAM=8070 for the detection JSON stream. The server reads that JSON stream with stream-json, feeds detections to the tracker, evaluates counters, and pushes updates to the browser over server-sent-events. That is why the UI shows counts moving in real time rather than on a polling interval.
The practical consequence of this design is that counters are data, not code. You draw them in the UI or create them through the API, and the README links an API reference and separate documentation for counter data and tracker data export. The tracker data export is the more interesting one for research: counted crossings are a summary, but trajectories let you re-derive a different question later without re-running detection.
Installing OpenDataCam with the Docker install script
The README's quick setup uses a shell script that downloads a Docker image and starts it. Before that, Docker and Docker-Compose must be installed. For GPU use the README additionally requires Nvidia CUDA 11 and cuDNN 8, the Nvidia Container toolkit, and the nvidia-container-runtime package; on a Jetson device it requires Jetpack 5.x. The script is fetched from a tag-specific URL, which is worth noticing: the URL pins v3.0.2.
First run: the demo video and your first counter
The install script starts a container that runs a demo video, so the first check costs nothing. Open the browser at the machine's address on port 8080. On a Jetson with a screen attached, localhost works.
wget -N https://raw.githubusercontent.com/opendatacam/opendatacam/v3.0.2/docker/install-opendatacam.sh
chmod 777 install-opendatacam.sh
./install-opendatacam.sh --platform xavierThe script asks for a sudo password during installation, and the README lists three platform values: nano for Jetson Nano, xavier for Jetson Xavier and Xavier NX, and desktop for a laptop, desktop or server with an NVIDIA GPU. After it finishes, the container starts a webserver on port 8080 and runs the demo video. What you should see in the browser is a busy intersection with counting available immediately.
./install-opendatacam.sh --platform desktopUse the desktop value when the machine is not a Jetson. The README notes the container is started in auto-restart mode, so a reboot brings OpenDataCam back up; stopping it means running docker-compose down in the folder that holds the install script. From the running UI you can drag and drop a video file into the browser window to analyze that file instead of the demo, and the configuration documentation covers switching the video input to a USB camera or another camera source. The API documentation is the path for anything the base app does not cover, and the README explicitly frames it that way: build on the API rather than forking.
Where OpenDataCam is the wrong tool
The GPU requirement is the first filter. The README's quick setup assumes either a Jetson or an NVIDIA GPU with CUDA 11, cuDNN 8 and the container runtime. There is no documented CPU-only quick start in the README, so a reader on an ordinary laptop without an NVIDIA GPU has no install path described there. That is a hard boundary, not a tuning problem.
The second limitation is version drift. The newest release listed is v3.0.2 from 2021-09-16, and the install script URL is pinned to that same tag. The default branch is development, and the last push to the repository was on 2026-04-23. So the tagged artifact and the branch have diverged for years. Anyone who needs a fix or a feature that landed after v3.0.2 has to work from the development branch and build rather than run the install script, and the README does not document how to roll the container back to a previous state if an upgrade goes wrong.
Third, the tool is scoped to counting and trajectories from a mostly static camera. The README's own framing is moving objects crossing counters. It is not a face recognition system, not a licence plate reader, and not an alerting platform. The tracker is an IOU/V-IOU variant, which associates detections by overlap between frames; scenes with heavy occlusion or a moving camera are where that association approach is weakest, and the README offers no accuracy figures for either case. If your question is "is this one specific object present" rather than "how many crossed", the tracker and counter machinery is overhead you are paying for.
OpenDataCam against OpenTrafficCam and Camlytics
The two names that come up alongside OpenDataCam are OpenTrafficCam and Camlytics, and they differ in ways that matter more than feature lists.
OpenTrafficCam is the closer comparison because it is also open source and also aimed at traffic. The difference is where the work happens. OpenDataCam is a single application you point at a live camera or a dropped video file, with counters drawn in a browser and results exported through an HTTP API. The OpenTrafficCam family is organized around processing recorded traffic video, and it includes a map-oriented component (OpenTrafficCamMap appears in the same searches). If your workflow is post-processing hours of recorded footage into a dataset, the batch-oriented approach fits better; if you want a box on a pole that reports crossings in real time, OpenDataCam's live streams and counters are the direct fit.
Camlytics is commercial desktop software. The searches around it include a price query, which is the honest summary of the difference: Camlytics is a product with a vendor behind it, and OpenDataCam is MIT-licensed code you run yourself. That trade runs both ways. With OpenDataCam you own the data and the deployment, and the README lists "You own the data" as a feature; in exchange you supply the GPU, the Jetpack version and the operational attention. With Camlytics you pay and someone else handles packaging. Neither arrangement is a defect, but choosing the open option means the CUDA 11, cuDNN 8 and Jetpack 5.x requirements in the README become your problem to satisfy.
Licence, maintenance and what an upgrade actually costs
OpenDataCam is MIT-licensed. The LICENSE file is at the repository root and package.json declares "MIT license". MIT is permissive: it allows commercial use and modification with attribution and no warranty. The parts OpenDataCam builds on carry their own terms, and the README's acknowledgments name them explicitly: the original darknet by pjreddie, the alexeyab darknet fork with YOLOv4, the IOU/V-IOU tracker by bochinski, and Next.js. If you redistribute a container image, the licences of those components travel with it, and this is a description of the repository, not legal advice.
On maintenance, the facts are narrow. The repository is not archived. The last push was on 2026-04-23. The most recent tagged release is v3.0.2 from 2021-09-16. Read together, that means the project is not abandoned, but releases are not the channel through which it changes; the development branch is. An upgrade therefore has two shapes. Staying on the install script means staying on v3.0.2 and its pinned image, which is stable and stale. Moving forward means tracking the development branch, which is where the recent commits are, and accepting that the README's install instructions describe the tagged path rather than the branch. The README does not document a rollback procedure for either case, so if you deploy to a device you cannot easily reach, keep the working image tag recorded before you change anything. The npm scripts in package.json (dev, build, start, lint, test) are the entry points for a source build, and the README points to a separate development notes page for the details.
Editorial conclusion
Adopt OpenDataCam if you need counted crossings from a fixed camera or a recorded video and you can supply a Jetson or an NVIDIA GPU, because the counting logic, the tracker and the export endpoints are already wired together. Do not adopt it if you need a maintained release cadence: the newest tagged release is v3.0.2 from 2021-09-16, and the last push to the repository was on 2026-04-23, so the development branch is where change happens. Verify three things before committing: that your platform matches one of the script's --platform values, that the demo video plays in the browser at port 8080 after install, and that the counter data export returns the fields your downstream analysis expects. If you only need a person counted at a door, a smaller detector will be less work than this stack.
Frequently asked questions
Is the Open Camera app safe?
The search question refers to a different app; OpenDataCam is not a phone camera app. OpenDataCam runs on your own hardware, and the README lists "You own the data" as a feature, with MongoDB as the local store. What leaves the machine depends on how you configure the video input and where you deploy it.
What is the OpenDataCam app and what are its features?
OpenDataCam is an open source tool that uses computer vision to detect and quantify moving objects, then counts them when they cross counters you define. The README lists multiple object classes, fine grained counter logic, trajectory analysis, real-time or pre-recorded video sources, deployment on small field devices or cloud data centers, and an API.
Is OpenDataCam open source?
Yes. The repository is opendatacam/opendatacam, package.json declares "MIT license", and the LICENSE file sits at the repository root. The README also credits the open source components it builds on, including darknet and the IOU/V-IOU tracker.
What is some open source AI camera software?
OpenDataCam is one example: it combines YOLO detection through a darknet build with a JavaScript tracker and an Express and Next.js application. OpenTrafficCam is another open source option in the same traffic-analysis space, organized around processing recorded video.
Community notes