SmarterStreaming: a Java streaming engine sold as fourteen modules

A commercial SDK, not a library you pull from Maven

The repository is called SmarterStreaming and the product name behind it is the Daniu Live SDK, from a company referred to as Shiwo Technology, with a homepage at daniusdk.com and a stated start date of 2015. It has 11,170 stars and 2,756 forks on GitHub with only 7 open issues, which is an unusual shape for a commercial product: the forks are almost certainly people evaluating integration, not contributors.

The repository itself is small, and the tree makes the distribution model obvious:

README.md
SourceCode/
TestApp/
WindowsPusher&Player/

So there is sample source, a test application and a Windows reference project, and no build file, no manifest and no module coordinates. That is the shape of an SDK you obtain through a registration process rather than resolve as a dependency. The README links to a page describing how to get the official test build and to a tag page collecting release notes, both on the vendor site, and no releases are published on GitHub at all.

The language field says Java, which is the interesting technical constraint here. A streaming core written in Java and shipped with native wrappers for five operating systems is a portability strategy, not an accident, and it explains why you would find this in a Java or Android project rather than in a C++ one.

Latency claims, and what the codec support actually costs

The headline claim is that latency can reach 100 to 200 milliseconds, which is a genuinely different order of magnitude from the two to five seconds a typical RTMP player gives you. That figure is presented by the vendor rather than demonstrated in the repository, so treat it as a target to measure rather than a property to assume.

Two technologies do the heavy lifting. The first is Enhanced RTMP carrying H.265, which the README calls out separately for push, play, relay and recording. H.265 matters for latency in a specific way: at the same quality it needs roughly half the bitrate of H.264, so a link that cannot carry a clean H.264 stream at your resolution can often carry H.265, and lower bitrate means fewer congested seconds.

The second is the module decomposition. The topics list includes rtmp-pusher, rtmp-player, rtsp-player, rtsp-relay, rtsp-to-rtmp, http-flv and gb28181, which is a fair summary of the README's module list. Each of those is a separate deliverable you license and link, so you can pay for push only if that is all you need.

The company markets itself as one of the few vendors actually practising millisecond latency, a claim repeated often enough in the README that it reads as positioning rather than evidence. The measurable claims are the ones in the topic list and the module table.

The module list is the real product catalogue

The Windows section of the README lists the modules most clearly, and it is the best place to understand what you can build. There is an RTMP pusher that supports pushing several URLs at once, an RTMP player with H.265 extended playback, an RTSP player that also supports an OCX control interface for Internet Explorer, and a Unity3D player for Windows.

Then the less common ones. A multi-stream relay module pulls several RTMP or RTSP streams or local FLV files and forwards each to its own server, with H.265 support claimed. A lightweight RTSP server module exists so the pusher itself can serve RTSP without you deploying a separate server, aimed at paperless classroom and internal network use cases, with support on Windows for both unicast and multicast. An intranet RTSP gateway extends that by pulling external RTSP or RTMP data and injecting it into the lightweight server so multiple internal clients can reach public streams through one box.

The remaining modules are a director or switching SDK that composites several sources into one outgoing stream, a recording SDK that pulls streams and writes MP4 with snapshots, pure audio, pure video or both, converting PCMU, PCMA or Speex to AAC on the way, and an H.265 to MP4 capability, a one to one interactive SDK with echo cancellation for cross platform two-way sessions, and an SEI module for pushing and receiving data alongside the video.

That SEI module deserves more attention than its bullet gives it. It sends text or binary data inside H.264 SEI frames and parses it on the playback side, which the README gives as live subtitles, timestamps, question distribution and announcement broadcast. For an education or command and control deployment that is the difference between shipping a separate signalling channel and not having to.

Five platforms and the architectures each one gets

The platform table is short and specific, which is useful when you are checking whether your target build exists. Windows is supported in x86 and x64, debug and release. Linux, explicitly including the Kylin operating system, covers x86_64 and aarch64. Android covers armeabi-v7a, arm64-v8a, x86 and x86_64. HarmonyOS NEXT covers arm64-v8a and x86_64. iOS is arm64.

That list tells you two things. The aarch64 Linux build is the one that matters for ARM servers and edge devices, and the presence of Kylin as well as HarmonyOS NEXT says the vendor is targeting the Chinese enterprise and government market specifically, which is consistent with the deployment scenarios listed in the README: online education, smart classrooms, carrier video cloud platforms, law enforcement recording, power inspection, water conservancy, coal mining, emergency dispatch, remote medical, financial dual recording and visual inspection along telecom, power, railway and pipeline routes.

The scenario list is long enough to be marketing, but a few of them explain real product decisions. Financial dual recording and remote medical both need the SEI or data channel for audit trails. Emergency dispatch for police and fire needs the one to one interactive module with echo cancellation rather than a one way broadcast. Smart classroom deployments need the embedded RTSP server, because a classroom has many receivers and one sender on a network that may have no external server.

Unity coverage and the accompanying blog record

Beyond the four native platforms there is a Unity layer, and the README is precise about what is covered. For Windows it lists the RTMP pusher capturing the Unity window, camera or screen, the lightweight RTSP service on the same sources, and RTMP and RTSP playback. For Linux, RTMP push and RTMP with RTSP play. For Android, push, the lightweight RTSP service and play, each able to capture the Unity window, camera, microphone or Unity audio. For iOS, RTMP and RTSP playback only, with no pusher listed.

That asymmetry is worth checking against your project. If you are shipping a mobile title that both records and broadcasts, the iOS gap on the push side is a real limitation and there is a linked PDF of the Unity3D interface documentation linked from the README that would be where to confirm it for your version.

The README also curates a long list of related blog posts on the author's CSDN blog, and several are directly useful rather than promotional. They cover implementing low latency RTMP playback of RTMP or RTSP streams in Unity3D, playing multiple RTSP or RTMP streams simultaneously on Windows under Unity3D, pushing camera and audio data at low latency, high frame rate RTMP push in Unity, collecting audio and video in Unity to run a lightweight RTSP service like an IPC camera, and capturing the camera through WebCamTexture on Android for pushing to RTMP or the RTSP service. Those read as worked examples of the exact integration problems you would hit.

What the README leaves for the vendor site

Almost everything you would need to decide whether to buy this lives outside the repository. The pricing, the trial request process, the per module licensing, the API documentation and the release notes are all on daniusdk.com, and the README does not summarise any of them. The GitHub repository is a shop window and a place to host the module overview diagrams, which are hosted as images on the vendor's own site rather than committed to the tree.

There is also no licence recorded for the repository, which is consistent with a commercial SDK where the terms come from a signed agreement rather than an open source licence. The project is not archived and the last push was on 2026-04-15, so the source in the repository is being maintained.

The honest summary is that this is a mature commercial product with a strong feature set and low latency work, presented through a Chinese-language README that functions as an index to the company's own site. If you can read Chinese and are evaluating for a Chinese market deployment, the module matrix and the blog archive are genuinely informative. If you need to understand the API before committing, you will be reading a PDF and a vendor site, and the fastest path is to request the test build and read the headers in it.

Editorial conclusion

SmarterStreaming is worth looking at when your requirement list includes several of RTMP push, RTMP play, RTSP play, relay and recording at once, because the vendor sells those as modules from one core rather than as separate products you stitch together. The H.265 work, the SEI channel and the embedded RTSP server are the parts a general purpose player will not give you. The counterweight is that this is a commercial SDK with a Chinese-language README, documentation hosted on a WordPress site, and no licence recorded against the repository, so the evaluation has real friction before it starts. Nothing here is available from a package manager: the tree holds SourceCode and TestApp directories plus a Windows pusher and player project, and the route to a build is the vendor's own process. Get the trial build, measure latency on your network with your own codec settings, and confirm the licensing terms in writing.

Frequently asked questions

Official sources

1. daniulive/SmarterStreaming on GitHub
2. Issues
3. Project website
4. README