AKStream ships a REST API and no user interface, and its successor is a commercial product
AKStream是一套全平台(Linux,MacOS,Windows)、全架构(X86_64,Arm...)、全功能的流媒体管理控制接口平台。集成GB28181,RTSP,RTMP,HTTP等设备推拉流控制、PTZ控制、音视频文件录制管理、音视频文件裁剪合并等功能与一体
At a glance
- What is it?
- AKStream is a MIT licensed .NET 6 platform that puts ZLMediaKit behind a RESTful control API for pulling, converting and recording streams, with GB28181 device support. The repository contains a demo UI that is explicitly not production, and the project's own successor, AKStream.Next, is a separate commercial offering.
- Who is it for?
- Use AKStream when you need a control plane that speaks GB28181 and hands a single REST API to front ends written in other languages, and you are prepared to build the player and the business logic yourself. Do not use it if you want a working NVR interface out of the box, since the bundled UI is described by the README as a demo, and do not plan a product roadmap on the assumption that new protocol work lands in this repository.
- 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 17 days ago.
- What is it written in?
- Mainly C#, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.
Editorial analysis
It is an interface platform, and the README says the UI is a demo
AKStream describes itself as a full featured soft NVR interface platform, where a soft NVR is a software defined network video recorder. The interface is the product. The stated purpose is a complete set of standard RESTful web API interfaces for other languages to call, and the repository layout is consistent with that being the whole point.
The root is a Visual Studio solution, AKStream.sln, with a small number of directories that map to responsibilities: AKStreamWeb and AKStreamKeeper are the two services, LibCommon, LibLogger, LibSystemInfo and SystemInfoLibrary are shared libraries, LibGB28181SipServer and LibGB28181SipClient are the SIP side, and LibZLMediaKitMediaServer is the bridge to the media server. SipSorcery sits in the tree as the SIP library, and Test_GB28181Client and Test_LibSystemInfo are separate test projects rather than tests inside the libraries.
The point most people miss is stated plainly in the README: someone in the community wrote a matching UI, but it is only a demo, meant to show how to call the AKStream interfaces. To combine the tool with your own business you have to implement the front end UI and the business logic yourself. That is not a criticism of the project, it is the design, and it is also the single biggest factor in any adoption estimate. What you install is a media control plane, not an NVR application.
The stack is .NET 6 with C#, and the persistence layer uses the freeSql library, which supports many database engines including sqlite and mssql. The README recommends MySQL 5.7 or above.
ZLMediaKit does the media work, AKStream is the control plane
The relationship with ZLMediaKit is the key to understanding the codebase. AKStream integrates ZLMediaKit as its streaming media server and LibZLMediaKitMediaServer is the wrapper library. Everything the feature list claims about codecs and protocols is a consequence of what that embedded server does.
The supported encodings are H265, H264, AAC, G711 and OPUS. Streams come in through the built in proxy over http, rtp and rtmp, and through the ffmpeg proxy, which the README describes as covering almost all formats and transcoding. On the output side the platform converts between RTSP, RTMP, HLS, HTTP-FLV, WebSocket-FLV, GB28181, HTTP-TS, WebSocket-TS, HTTP-fMP4, WebSocket-fMP4 and MP4, so a third party app, web front end or client can be handed whichever of those suits it.
The clustering story is separate and easier to miss. AKStreamKeeper is a streaming media governance component, and the README states it can cluster multiple ZLMediaKit instances distributed across different servers for unified management and unified scheduling. So the deployment is not a single process: you have the web service, the keeper, and however many media servers the keeper is fronting.
The performance claim in the README is specific and worth repeating precisely because it is narrow: instant picture opening, and very low latency within 500 milliseconds, with a stated minimum of 100 milliseconds. Those figures are the project's own claim with no methodology attached, so treat them as a target to test against your own network rather than a specification.
The GB28181 SIP gateway was rewritten, and only 2016 is supported
The Chinese video surveillance standard GB28181 is where most of the complexity lives, and the README is unusually candid about the state of it.
The GB28181 SIP signalling gateway was rewritten and no longer uses the SIP gateway from the earlier StreamNode design, with the stated reason being greater stability and reliability. The same passage gives the significant limitation: only the GB28181-2016 standard is currently supported, because there were no devices implementing other versions to test against. The project offers the gateway's extensibility as the path forward if you need something beyond 2016.
What the standard buys you in practice is device control rather than just video. The feature list includes GB28181 RTP streaming, so cameras push media over RTP, and GB28181-PTZ control, so pan, tilt and zoom commands reach the device. For a site with a few dozen cameras, that combination is the reason to use this stack rather than a generic RTSP bridge, and it is also the reason the SIP layer is a separate library pair rather than part of the web service.
One operational note belongs here. The README states that project documentation and wiki content are updated only on GitHub and not on Gitee, although the newest code is synchronised to both. A Gitee mirror of an open source project is a sensible thing for the author to run, and a stale mirror is a real trap for a reader who lands on the wrong one, so read the documentation on GitHub.
Deployment: two Dockerfiles, a deploy script and a pinned SDK
The packaging story is conventional for a .NET service, which makes it easy to read from the file names alone. There is a Dockerfile-Web and a Dockerfile-Keeper, matching the two services, plus deploy.sh at the repository root. global.json sits next to the solution file, which in the .NET CLI pins the SDK version the build expects, and that is the file to look at before assuming the README's mention of the .NET 6 framework matches whatever runtime is on your machine.
The README does not give a build or run command, so the entry points are the two Dockerfiles and deploy.sh. For a team evaluating this, that is a mild gap rather than a blocker: the shape of the deployment is legible from the file names, and the two services map cleanly onto the two Dockerfiles.
Platform coverage is stated as Linux, macOS and Windows, on x86_64 and ARM CPU architectures, and the repository is mirrored to Gitee for download convenience in China. The topic tags reflect the same surface, listing arm64, gb28181, hls, live, m3u8, mediaserver, ptz, rtmp, rtsp, streamnode and zlmediakit.
There is one thing a buyer should notice in the repository listing: AKStream.sln.DotSettings.user is checked in. A user-specific Rider or Visual Studio settings file in source control is the kind of artefact that should be ignored, and its presence tells you the project is developed on a JetBrains or Visual Studio toolchain by at least one contributor.
AKStream and AKStream.Next are two different products with two different terms
The README is half promotion for a different project, and reading it as one document is a trap.
AKStream, the repository you are looking at, is MIT licensed and described as completely open source. AKStream.Next is described as a commercial project of AKStream, hosted at softnvr.com, which adds text based video search, image based video search, video conference rooms, AI assisted development skills, the latest GB28181 support, automatic discovery of Onvif devices and an RTC conference room. It offers a free authorisation for non-commercial use, offline activatable and permanently usable on an intranet, and is accompanied by what the README describes as a hundred thousand word integration document.
So the feature list and the licensing terms point in opposite directions. The open source repository is where the free version lives; the newer protocol work, the Onvif discovery and the meeting features are positioned with the commercial product. Anyone planning a deployment should assume that the two code bases are separate and that the roadmap advantage goes to the paid one.
No legal advice is offered, but the practical compliance read is straightforward. The MIT grant in this repository covers the code here, and the Next product's non-commercial free authorisation is a separate arrangement with its own terms. Do not assume a Next feature you read about in the README is available in the repository you cloned.
The project also points readers to a QQ group for technical discussion, noting it is full and being cleared, which is worth knowing if you were planning to get support through it.
Limitations, and the release history question
The failure modes are structural rather than accidental.
The first is that a broken deployment shows you a working API and no interface. A developer can call every endpoint and still have no NVR, because the front end is theirs to write. Budget for that, and note that a demo UI is a liability if it is mistaken for a product in a procurement conversation.
The second is GB28181 version coverage. Only the 2016 standard is supported, and the reason given is that no other-versioned devices were available to test. If your camera fleet speaks an older variant, the project tells you to extend the gateway yourself.
The third is upstream dependency risk. The media capabilities are ZLMediaKit's, and the SIP capabilities sit on a vendored SipSorcery. Neither is in this repository, so an upstream change lands in your deployment through those dependencies rather than through an AKStream release.
On releases, the repository has no GitHub releases at all. There is no tag list to consult, so the record of what changed between builds is the commit history and the wiki the README refers to. The last push was on 2026-10-06 and the repository is not archived, so work is still arriving; the absence of tags is the practical problem, not the absence of commits. A team that wants a repeatable deployment should pin to a commit hash rather than a version, because there is no version to pin.
Editorial conclusion
Use AKStream when you need a control plane that speaks GB28181 and hands a single REST API to front ends written in other languages, and you are prepared to build the player and the business logic yourself. Do not use it if you want a working NVR interface out of the box, since the bundled UI is described by the README as a demo, and do not plan a product roadmap on the assumption that new protocol work lands in this repository. Verify first which GB28181 standard your cameras speak, because the README states only the 2016 version is supported and that other versions went untested, then check global.json and the two Dockerfiles before you assume a build recipe.
Frequently asked questions
Does AKStream include a user interface?
Not a production one. The README says a community member built a matching UI but that it is only a demo showing how to call the AKStream interfaces, and that you need to implement your own front end and business logic to use it for real.
What is the difference between AKStream and AKStream.Next?
AKStream is the MIT licensed open source repository. AKStream.Next is described as a commercial project hosted at softnvr.com, adding features such as text and image video search, video conference rooms and Onvif device discovery, with a free authorisation offered for non-commercial use.
Which GB28181 version does AKStream support?
Only GB28181-2016, according to the README, because no devices implementing other versions were available to test against. The project points to the extensibility of its rewritten SIP gateway as the route to add more.
What database should AKStream use?
The persistence layer uses the freeSql library, which supports many engines including sqlite and mssql. The README recommends MySQL 5.7 or above.
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/chatop2020-akstream)Was this useful?