Rebucca: a multi-camera video control and analysis platform with GB28181, RTSP and LLM review
Rebucca is a multi-channel video ingestion and intelligent surveillance analytics platform. Supports GB28181/RTSP and other protocols, small-model detection (e.g. YOLO), review by OpenAI-compatible LLMs, polygon monitoring zones, and structured alerts with screenshots.
At a glance
- What is it?
- Rebucca is an MIT-licensed Python platform that pulls RTSP and GB28181 streams through ZLMediaKit, runs small YOLO-family detectors, optionally re-checks detections with an OpenAI-compatible model, and emits structured alarms with snapshots when polygon rules fire.
- Who is it for?
- Adopt Rebucca if you already run ZLMediaKit and FFmpeg and want a web UI that turns RTSP or GB28181 cameras into polygon-rule alarms with snapshots, without building the pipeline yourself. Skip it if you need a managed service, a published release history, or an English-first codebase, since the README is bilingual but the changelog and configuration notes are Chinese and no releases were retrieved.
- 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 9 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 4, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What Rebucca actually does with a camera feed
The project describes itself as a multi-channel video intake and intelligent control analysis platform. In practice it sits between your cameras and a human operator. Cameras arrive over RTSP or GB28181, ZLMediaKit handles forwarding and ONVIF discovery, FFmpeg is required on PATH or configured in config.json, and a Python 3.10+ service exposes a web UI on port 10001 by default. Detection runs through YOLO in PyTorch, ONNX or OpenVINO form, and an optional large model can re-check what the small model found. Alarms are not raw detections. The README is explicit that only a business algorithm rule hit produces an alarm record; a target being detected, or motion in frame, is not enough. That distinction is the whole product: a person walking through a polygon zone, crossing a line in a given direction, or lingering too long is an event, and everything else is noise you have to filter yourself. The target user is an integrator or site operator who already has cameras and wants rule-based alerts with screenshots rather than a research notebook.
The pipeline from stream to snapshot, and where the LLM sits
The README's usage order is the clearest statement of the data flow: video management, then small model, then large model, then business algorithm, then control management, then start analysis, then alarm management. Each step feeds the next. A camera is added and confirmed to be pulling frames. A small model is uploaded or configured. A large model is configured if you want review. A business algorithm binds a detector to a rule set. The control page draws polygons and binds that algorithm to a region. Starting analysis turns the chain on. The changelog adds a detail the README does not: there is a shared inference pool link, enabled by default, that downsamples the long edge of a frame to at most 1280 before sending it, to save transport. That means detection boxes, keypoints and segmentation polygons come back in the coordinates of the scaled-down image. Version v1.004 fixed a bug where those coordinates were drawn onto full-resolution snapshots without being restored, so boxes appeared shifted toward the top-left and too small, worse at higher resolutions. The fix in remote_detector.py scales the results back, with zero overhead when no downsampling occurred, and also corrects point-in-polygon region checks that had been using the wrong coordinates. If you run an older build, that is a real accuracy problem in your alarm images, not a cosmetic one.
Installing Rebucca and getting the first alarm
The repository ships requirements-linux.txt and requirements-windows.txt, so install the one matching your platform. The README shows the Tsinghua mirror as an optional index URL.
pip install -r requirements-linux.txt -i https://pypi.tuna.tsinghua.edu.cn/simpleOn Linux the bundled ZLMediaKit binary needs to be executable. The README points at zlm/bin.x86.gcc9.4 or zlm/bin.arm.gcc9.4 and says to confirm ./rebucca_zlm runs. If it fails, the documented remedies are either making the directory executable and adding it to LD_LIBRARY_PATH, or installing libsrtp2-1 plus the Ubuntu 20 libssl1.1 package and repairing dependencies.
sudo chmod -R a+x *
echo "export LD_LIBRARY_PATH=\"$(pwd):\$LD_LIBRARY_PATH\"" >> ~/.bashrc && source ~/.bashrcBefore the first start, edit config.json for ports, ZLM and FFmpeg, and settings.json for interface branding. Then run the development server:
python manage.py runserver 0.0.0.0:10001The README gives the default login as admin with password admin888, and the UI at http://<host>:10001/. After login, follow the documented order: add a camera and confirm the stream, upload or configure the small model, optionally configure the large model, create a business algorithm, draw the polygon on the control page and bind the algorithm, then click Start analysis. Alarms appear under alarm management. Two configuration behaviours are worth knowing before you tune anything: most settings saved on the configuration page take effect as a hot update, but changing the management port or the debug log level needs a service restart, and switching the small model requires restarting analysis.
Where Rebucca breaks, and when it is the wrong tool
The most consequential limitation is stated plainly in the README: after a service restart you must click Start analysis again manually. There is no documented auto-resume. On an unattended site that is a silent failure mode, because the UI will look healthy while producing no alarms. The troubleshooting table points the same direction, listing no alarms as a symptom to diagnose by checking the stream, the algorithm binding, whether analysis was started, and whether the detected class matches. The changelog also shows how fragile the model-selection UI has been: v1.003 fixed a case where a business algorithm bound to a disabled large model could not be displayed in the dropdown, and v1.004 fixed an edit dialog that cleared previously selected detection targets on open. Those are front-end state bugs rather than analysis errors, but they cost operator time. Deployment on Linux is not a clean pip install either. The README documents needing libsrtp2-1 and a libssl1.1 package from the Ubuntu 20 pool, which is a sign the bundled ZLMediaKit binary was built against older system libraries. If you want a single container image and a published release list, this repository does not offer either: no releases were retrieved, and the README points at a Gitee mirror and a vendor site rather than a registry. Finally, the changelog and much of the operational guidance are in Chinese, so an English-only team will be reading configuration notes through translation.
How Rebucca differs from Frigate and from DeepStream
Frigate is the closest open source comparison for most readers. It also ingests RTSP, runs object detection, and produces events, but its design centres on local camera streams with a recorder and a Home Assistant integration, and it does not present GB28181 as a first-class intake protocol. Rebucca's intake is explicitly RTSP plus GB28181 with ZLMediaKit forwarding and ONVIF discovery, which fits the Chinese and broader IP-camera market where GB28181 registration is the normal way cameras join a platform. The second difference is the optional large model review stage. Frigate has no equivalent built-in step where detections are re-examined by an OpenAI-compatible model. That stage is a genuine architectural choice, and it also means Rebucca can call an external API per reviewed frame, which brings latency and cost that a purely local detector does not have. NVIDIA DeepStream is the other direction: a compiled SDK for building GPU pipelines with its own plugin graph, far more control over throughput and far more setup. Rebucca is a Python application with a web UI and a SQLite file, rebucca.sqlite3, sitting in the repository root. If you need to squeeze maximum frames per second out of a GPU, DeepStream is the right layer. If you need an operator-facing rule console with polygons and snapshots, Rebucca is closer to the job.
Maintenance, upgrade cost and the MIT licence
The last push to the default branch was on 2026-09-02, and the repository is not archived, so the codebase is current rather than abandoned. There are no retrieved releases, which means upgrades are a pull of main plus the changelog, not a versioned artefact you can pin. The changelog is the upgrade document: v1.004, dated 2026/09/02, is dominated by the coordinate-restoration fix for alarm snapshots, and v1.003, dated 2026/08/06, added a statistics dashboard at /alarm/dashboard with an alarm/openStats endpoint and completed 16 translation keys across seven languages. Version numbers live in framework/settings.py as PROJECT_VERSION, so that file is where you check what you are running. The practical upgrade cost is the restart dance: the README states that port and debug-log changes require a service restart and that switching the small model requires restarting analysis, so any upgrade that touches those areas means re-clicking Start analysis afterward. The licence is MIT, which the README describes as free for commercial use, with the full text in LICENSE. That is permissive and imposes no copyleft on your own code. It says nothing about the licences of the models you load, the ZLMediaKit binary bundled under zlm/, or the terms of any OpenAI-compatible endpoint you point the review stage at; those are separate questions and this repository does not answer them.
Editorial conclusion
Adopt Rebucca if you already run ZLMediaKit and FFmpeg and want a web UI that turns RTSP or GB28181 cameras into polygon-rule alarms with snapshots, without building the pipeline yourself. Skip it if you need a managed service, a published release history, or an English-first codebase, since the README is bilingual but the changelog and configuration notes are Chinese and no releases were retrieved. Verify three things first: that ./rebucca_zlm starts under your Linux distribution, that your detector's label list matches the classes your business algorithm selects, and that 'Start analysis' is re-clicked after every service restart, because the README states analysis does not resume on its own.
Frequently asked questions
What problem does Rebucca solve for multi-camera deployments?
It connects RTSP and GB28181 cameras through ZLMediaKit, runs YOLO-family detection, and turns rule hits into structured alarms with snapshots. The README stresses that only a business algorithm rule hit creates an alarm, so plain detection or motion does not flood the alarm list.
Does Rebucca need a GPU?
The README lists GPU as optional in the environment requirements. Detection can run through YOLO in PyTorch, ONNX or OpenVINO form, and the large-model review stage is optional as well.
Why does Rebucca produce no alarms after I restart the service?
The README states that Start analysis must be clicked again manually after a service restart. The troubleshooting table lists no alarms as a symptom to check against stream health, algorithm binding on the control region, whether analysis was started, and whether the detected class matches.
Why are the detection boxes in Rebucca alarm snapshots in the wrong place?
The v1.004 changelog describes exactly this: the shared inference pool downsamples the long edge to at most 1280 before sending, and returned coordinates were drawn onto full-resolution snapshots without being restored, shifting boxes toward the top-left and making them too small. The fix restores coordinates in remote_detector.py and also corrects the point-in-polygon region check.
What licence does Rebucca use?
The README states the project is released under the MIT License and describes it as free for commercial use, with the full text in LICENSE. That covers the project code, not the bundled ZLMediaKit binary or any model you load.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/beixiaocai-rebucca)