wvp-GB28181-pro: a Java platform for GB28181, JT/808 and JT/1078 video

What WVP-PRO actually takes off your plate

A GB28181 deployment is two problems wearing one name. The first is signalling: SIP registration, keepalive, catalog queries, device control, subscription and notification, and the cascade relationship to an upper platform. The second is media: receiving RTP, remuxing it, and serving it to a browser. WVP-PRO takes the first problem and leaves the second to ZLMediaKit, which the README credits to the author Xia Chu.

The project describes itself as an out-of-the-box network video platform built on GB28181-2016, JT/808 and JT/1078. The repository is Java, MIT licensed, and the README lists a web console as a first-class feature rather than an add-on. The intended user is the integrator who has to connect Hikvision, Dahua or Uniview cameras and NVRs, present them in a browser without a plugin, and possibly push those channels up to a higher-level GB platform. The README also lists RTSP and RTMP ingestion, which is the practical answer for cameras that have no GB28181 firmware at all.

What it is not: a media server. Every stream path in the documentation runs through ZLMediaKit, and the platform's own job is to tell that server what to do. That split matters when you size hardware, because the two processes scale for different reasons.

Signalling, media and the split between WVP-PRO and ZLMediaKit

The architecture visible in the README is a control plane and a data plane. WVP-PRO holds device state, SIP sessions, cascade configuration and the web UI. ZLMediaKit holds the RTP receivers and the protocol outputs. The README states that WVP-PRO can configure ZLMediaKit automatically, which removes a common source of misconfiguration, and that the two can be deployed separately to raise concurrency.

On the device side, the README lists UDP and TCP as selectable transport for both GB signalling and GB media. That choice is not cosmetic: UDP is the default in many camera firmwares and behaves badly across lossy links, while TCP survives NAT and packet loss at the cost of head-of-line blocking. The project supports NAT traversal and public-network deployment, and it documents a UDP multi-port mode intended to improve media throughput in UDP scenarios.

On the output side, a single camera can be exposed as RTSP, RTMP, HTTP-FLV, WebSocket-FLV or HLS. The README makes a point that a stream address can be viewed directly without logging in or calling an API, which is convenient for embedding and worth thinking about if the deployment is reachable from the internet.

For scale, the README describes a streaming-node cluster with load balancing and a signalling cluster. It also claims virtual-thread support and a LAN stress test above fifty thousand devices, with an explicit caveat that production performance depends on server hardware and network bandwidth. Treat that number as the author's own test, not as a capacity plan. The README also states that the number of connected devices is limited only by server performance, which is true of any SIP platform and tells you nothing about your own ceiling.

Installing WVP-PRO and getting one camera onto a page

The README does not contain step-by-step install instructions. It points to the project documentation at doc.wvp-pro.cn and to the ZLMediaKit repository for the media server. What the repository does give you is a layout: pom.xml at the root, a web directory for the front end, a docker directory, a database directory, and shell scripts named install.sh and run.sh. The README states that the project can be packaged as an executable jar or a war, and that it supports MySQL, PostgreSQL and Kingbase among its databases.

Because the README does not publish the exact commands, the honest sequence is to read the documentation site for your chosen deployment shape before writing any configuration. The repository tells you what to expect to find there:

# repository layout, from the top level of the project
ls
# .dockerignore  .github/  .gitignore  .gitmodules  LICENSE  README.md
# bin/  doc/  docker/  install.sh  pom.xml  run.sh  src/  web/
# 打包/  数据库/  更新内容

The presence of install.sh and run.sh suggests a scripted path, and the docker directory suggests a container path, but the README does not document what either does. Do not assume flags or environment variables that are not written down.

On the camera side, the README describes the configuration surface rather than the syntax. You add a GB28181 device, and the README notes that devices can be added manually and given an individual password. From there the documented operations are preview, main and sub stream switching, PTZ control, preset query and set, and NVR or IPC recording search with playback and download at a specified time. None of that requires a plugin in the browser, which is the point of the FLV and HLS outputs.

If you want a stream without touching the API, the README says a single stream address can be viewed directly. That is the fastest way to confirm the media path works before you debug the console.

Where the open source build stops

This is the section that decides most evaluations. The README contains an explicit closed-source list, and it is long. Open source covers GB28181-2016. GB28181-2022, which the README says is certified, is closed source, as are ONVIF, Hikvision ISUP 5.0/4.0/2.0/EHome, the Dahua SDK, and a national grid B interface. GB35114 is marked as in development.

Some of the closed items are conveniences that the README itself notes are already present in the open build: H.265 and AAC support, main and sub stream switching. Others are not. OSD configuration, video masking, storage card management, device upgrade, target tracking, remote configuration of on-device recording plans, video parameter configuration, image flip control, and reverse playback all appear only on the closed list. The PTZ entries are described as adding display feedback over the open implementation, which suggests the open build can control the camera but shows you less about the result.

The licence section is candid in a way that is worth reading in full. The project's own code is MIT, and the README says it can be used commercially and non-commercially with copyright notices retained. It then states that the project also uses other open source code in places, and that for commercial use you should replace or remove those parts yourself, with the project and its developers disclaiming liability. That is a real obligation, not boilerplate. If you ship this commercially, the licence audit is your job.

A second limitation is stated plainly in the feature list: recording plans are supported, but forwarding recorded content to an upper GB platform is not. If your design assumes that recorded material cascades upward, the README says it does not.

WVP-PRO against EasyDarwin, AKStream and a Python GB28181 stack

The alternatives people search for alongside this project differ mainly in where they draw the line between signalling and media, and in what language you have to maintain.

EasyDarwin is a streaming media server written in Go, and the difference is structural rather than a matter of features. A Go media server is a single binary you run and configure; WVP-PRO is a Java application that depends on a separate C++ media server (ZLMediaKit) and a database, with a web front end built on vue-admin-template. If your team writes Go and wants one process to deploy, EasyDarwin's shape is closer to that. If your team writes Java and wants a management console with device and cascade semantics already modelled, WVP-PRO's shape is closer.

AKStream is also Go and also pairs with ZLMediaKit, so the media side is the same and the difference is the control plane: you get a Go service instead of a Java one, and you inherit whatever device-management depth that project has rather than WVP-PRO's.

A Python GB28181 stack sits at the other end. Python is the fastest way to prototype SIP behaviour and the slowest to run at device counts in the thousands. WVP-PRO's README claims virtual-thread support and a fifty-thousand-device LAN stress test; a Python implementation is not competing on that axis, and it is not trying to.

The honest summary is that WVP-PRO's differentiator is not the media path, which it shares with anything built on ZLMediaKit, but the breadth of the management surface: cascade to multiple upper platforms, business grouping and administrative division trees, alarm subscription, mobile position subscription, and a web console that exposes all of it.

Maintenance, releases and what upgrading costs

The last push to the default branch was on 2026-09-21, and the repository is not archived, so the codebase is being touched. Releases are less frequent than commits: the two most recent are v2.7.4-20260107 and v2.7.4-20250709, roughly six months apart. That is a normal cadence for a project of this size and it means you should not expect a fix to arrive as a patch release the week you find it.

The upgrade cost is dominated by the fact that WVP-PRO is not self-contained. A version bump can require a matching ZLMediaKit version, a database migration, and a front-end rebuild, and the README does not document a rollback procedure. The repository does contain a 更新内容 directory and a 数据库 directory, which is where you would look for change notes and schema material, but the README itself is silent on upgrade mechanics. Plan to test upgrades against a copy of your device estate rather than in place.

On licensing, the MIT terms apply to the project's own code. The README's own warning about bundled third-party code is the operative sentence for commercial users, and the requirement to reproduce third-party licences in your own licence file is stated directly. Nothing here is legal advice, and the README's disclaimer that commercial disputes arising from use of the project are the user's responsibility is explicit.

There is also a commercial dimension to maintenance. The README lists a paid community, one-to-one development coaching and closed-source cooperation, with an email address for enquiries. If your deployment depends on GB28181-2022, ONVIF or the vendor SDKs, that channel is the only documented route to them.

Editorial conclusion

Adopt WVP-PRO if you have a GB28181 device estate and staff who can read the standard, and you want the signalling layer without writing it yourself. Do not adopt it if you need ONVIF, Hikvision ISUP, Dahua SDK, GB35114 or GB28181-2022 without negotiating a commercial licence, or if you expect a single command to produce a working platform. Before committing, verify which modules you actually need against the closed-source list, confirm your database choice is among MySQL, PostgreSQL, Kingbase or DM, and check whether the recording-plan limitation (no forwarding of recorded material to an upper GB platform) affects your design.

Frequently asked questions

Official sources

1. 648540858/wvp-GB28181-pro on GitHub
2. License: MIT
3. Project website
4. README
5. Releases