The Problem
Traffic‑monitoring teams need an automated way to count vehicles in video streams without building a full‑stack pipeline from scratch. Manual frame‑by‑frame annotation is time‑consuming and error‑prone, especially for live feeds.
What This Does
The repository contains a single Jupyter notebook YOLOv8ObjectCountingSegmentationSpeed.ipynb that demonstrates end‑to‑end vehicle counting using the YOLOv8 detector together with DeepSORT for multi‑object tracking. The notebook loads a pretrained YOLOv8 model, runs inference on each video frame, feeds detections to DeepSORT, maintains object IDs across frames, and increments a counter whenever a new car ID appears. Results (annotated video and simple statistics) are saved to disk. The accompanying README.md provides a one‑sentence description and a link to the notebook.
How It Is Wired
- Entry point – Opening and executing the notebook cells is the only way to start the workflow; there is no script or CLI.
- Key steps inside the notebook 1. Import section – pulls in
ultralytics(YOLOv8) and a DeepSORT implementation (e.g.,deep_sort_realtime). 2. Model loading –model = YOLO('yolov8n.pt')(or similar) creates the detector. 3. Video source –cv2.VideoCapture(<path>)opens the input video file. 4. Inference loop – each frame is passed tomodel(frame); the returned bounding boxes are filtered for the “car” class. 5. Tracking – detections are handed to a DeepSORT tracker object (tracker.update(detections)) which returns persistent IDs. 6. Counting logic – a Pythonsetstores seen IDs; when a new ID is observed, the car counter increments. 7. Output – annotated frames are written to a new video file viacv2.VideoWriter; a simple dataframe of counts is displayed at the end.
No external services, databases, or network calls are used; the notebook reads only local video files and writes local outputs. Because the notebook is the sole artifact, the “wiring” is confined to the linear execution order of its cells. No modular functions or reusable libraries are defined, so the blast radius of any change is limited to the notebook itself.
How To Use It
# Clone the repo
git clone https://github.com/moses-y/ObjectCountingYOLOv8DeepSORT
cd ObjectCountingYOLOv8DeepSORT
# Install required Python packages (not listed in the repo; infer from imports)
pip install ultralytics opencv-python deep-sort-realtime tqdm
# Launch Jupyter and open the notebook
jupyter notebook YOLOv8ObjectCountingSegmentationSpeed.ipynb
Place the target video file in the same directory or adjust the path in the notebook’s “Video source” cell. Run the cells sequentially; the final cell writes output.mp4 (or the name you set) and prints a count summary.
Missing pieces – The repo does not include a requirements.txt or environment.yml, so the exact version pins are unknown. No configuration file is present; all parameters are hard‑coded in notebook cells.
Real‑World Use
A city‑traffic office could drop a 30‑second surveillance clip into the notebook’s folder, run the notebook, and obtain a quick vehicle count for that interval. The resulting count can be fed into a dashboard or stored in a CSV for later trend analysis.
# Example snippet to log results
import pandas as pd
df = pd.DataFrame({"video": [video_path], "car_count": [car_counter]})
df.to_csv("daily_counts.csv", mode="a", header=False, index=False)
Code Health & Issues
- Medium – Strip notebook outputs before committing –
YOLOv8ObjectCountingSegmentationSpeed.ipynbis 26 MB, dominated by stored cell outputs. - Medium – Move large binaries to Git LFS or external storage – the same notebook exceeds 5 MB, inflating clone size.
- Medium – No test files detected – repository‑wide, untested code paths.
- Medium – No CI/CD pipeline – no
.github/workflows or other automation. - Medium – No LICENSE file – usage and redistribution rights are unclear.
No lockfile, Dockerfile, or committed secrets were found.
The Bottom Line
The repo is a minimal, proof‑of‑concept notebook that shows how to combine YOLOv8 detection with DeepSORT tracking for vehicle counting. It is useful for quick demos or as a learning reference, but it lacks production‑grade scaffolding: no tests, no dependency lockfile, no CI, and large binary data committed directly. Teams planning to adopt it should extract the core logic into reusable modules, add proper dependency management, and store media assets outside the repository.