# RootEncoder: an RTMP, RTSP, SRT and WHIP encoder library for Android apps

> RootEncoder (formerly rtmp-rtsp-stream-client-java) is a Java/Kotlin library that turns an Android app into a live streaming client. It solves the outbound side of streaming, and it hands you the server side, the UI and the lifecycle work.

**pedroSG94/RootEncoder** — RootEncoder for Android (rtmp-rtsp-stream-client-java) is a stream encoder to push video/audio to media servers using protocols RTMP, RTSP, SRT and UDP with all code written in Java/Kotlin

- Repository: https://github.com/pedroSG94/RootEncoder
- Stars: 3,042 · Forks: 944
- Language: Kotlin
- License: Apache-2.0
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/pedrosg94-rootencoder

## What RootEncoder actually does, and who it is for

RootEncoder is a client-side stream encoder for Android. It captures camera frames or device screen content, encodes video and audio, and pushes the result to a media server over RTMP, RTSP, SRT, UDP or WHIP. The README describes it as "a stream encoder to push video/audio to media servers using protocols RTMP, RTSP and SRT with all code written in Java/Kotlin". The repository was renamed from rtmp-rtsp-stream-client-java after SRT support was added, because the old name no longer described the scope.

The audience is narrow and specific: Android developers building an app that must broadcast. That means a live shopping app, a field reporting tool, a drone or body-camera controller, a game streaming client, or an internal monitoring app that publishes a screen feed. If you are building a viewer, a transcoder or a server, this library is not the component you are looking for. It assumes a media server already exists at the other end of the URL you hand it.

Because the library lives inside your app, it also inherits your app's constraints. Permissions for INTERNET, RECORD_AUDIO and CAMERA are declared in your manifest, not the library's. The minimum supported API is 16, and the extra video sources (BitmapSource, CameraXSource, CameraUvcSource) require API 21 or higher. That split matters when you support old hardware: you can stream from camera1 on API 16, but you cannot use the newer source abstractions there.

## The encoder pipeline: buffer-to-buffer, surface-to-buffer and OpenGL filters

The README lists two encoder types: buffer to buffer, and surface to buffer. They are the two ways frames enter the pipeline. In the buffer path, the app supplies frames, which is what you use when the source is not a camera preview, for example a bitmap, an image, a GIF, text, or a decoded video file. In the surface path, the camera or screen renders into a Surface that the encoder consumes, which is the normal camera streaming route.

On top of that sits an OpenGL filter stage. The README advertises "OpenGL real time filters" and links to a wiki page, and it notes that filters were refactored in library version 2.0.9 with a migration guide. This is the part most likely to break an upgrade: if you wrote custom filters against the pre-2.0.9 API, the refactor is a real porting task, not a drop-in replacement.

Codec coverage is broad and split across protocols. AV1, H264, H265, VP8, VP9, G711, AAC, HE-AAC and OPUS are listed as hardware or software encoded. Not every protocol carries every codec: SRT and UDP list H264, H265, AAC, HE-AAC and OPUS; RTSP lists those plus AV1, VP8, VP9 and G711; RTMP supports H265 and AV1 only through enhanced RTMP, with a link to the veovera specification. Before choosing a protocol, check that your codec appears in that protocol's list.

The library also exposes runtime controls that matter in production: disabling or enabling video and audio while streaming, switching camera mid-stream, and changing video bitrate on API 19 and above. All of these are the things you would otherwise have to tear down and rebuild a session to accomplish.

## Installing RootEncoder from JitPack and starting a first stream

RootEncoder is distributed through JitPack, not Maven Central. The README gives the repository and dependency coordinates for the current version. Add the JitPack repository and the library artifact to your Gradle build file:

```gradle
allprojects {
  repositories {
    maven { url 'https://jitpack.io' }
  }
}
dependencies {
  implementation "com.github.pedroSG94.RootEncoder:library:2.8.1"
  //Optional, allow use CameraXSource and CameraUvcSource
  implementation "com.github.pedroSG94.RootEncoder:extra-sources:2.8.1"
}
```

The second artifact is optional. It only exists to enable CameraXSource and CameraUvcSource, so leave it out if you are using camera1, camera2 or a buffer source. For versions 2.2.6 and earlier the artifact name was different: the README shows the old coordinate as com.github.pedroSG94.RootEncoder:rtplibrary:2.2.6. That is the single most common upgrade mistake, because the group and module both changed.

Declare the permissions in your app manifest before writing any streaming code:

```xml
<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.RECORD_AUDIO" />
<uses-permission android:name="android.permission.CAMERA" />
```

The README does not reproduce a full streaming Activity in its body. Instead it points at four runnable examples in the repository's app module, and it explicitly calls the rotation example "the recommend way to use the library" because it handles screen rotation, stream orientation, filters and changing video or audio sources on the fly. The other three cover screen capture through a background service, streaming from a video file, and a low-API path for Android API 16 and above. Start from the rotation example rather than assembling a session from scratch; the example tree is at app/src/main/java/com/pedro/streamer/rotation in the repository.

## Where RootEncoder stops: server, reconnection and platform gaps

The library encodes and pushes. It does not receive, transcode, record to a server, or provide playback. If your product also needs viewers, you supply the media server and the player. That is a deliberate boundary, and it is why the README links to a separate RTSP-Server project rather than bundling one.

A second boundary is platform. The README points to a separate repository, RootEncoder-iOS, for the iOS version. There is no shared code path between them, so an Android-only integration does not give you an iOS one, and behaviour will not be identical across the two.

SRT authentication is listed as an unchecked item in the README's feature matrix. SRT does support packet resend and AES128, AES192 and AES256 encryption, but if your SRT endpoint requires authentication, the documented feature set does not cover it. WHIP is marked beta, which tells you the API surface there is less settled than the RTMP, RTSP, SRT and UDP paths. The README also states that forcing hardware or software codec selection is "Not recommended", which is a hint that the automatic path is the tested one.

Finally, the README asks for sponsors explicitly, saying the library "need sponsors to get new devices or pay platforms to test and debug errors". That is a candid statement about test coverage: device-specific encoder bugs are a real category here, and the project's ability to chase them depends on hardware access. Budget for testing on your own target devices rather than assuming the upstream matrix covers them.

## RootEncoder compared with other ways to publish from Android

The closest alternative in the same space is HaishinKit, which appears in related searches for this project. The difference is platform and language: HaishinKit is a Swift library for Apple platforms, so it is the counterpart to RootEncoder-iOS rather than a substitute for RootEncoder itself. If you are shipping on both Android and iOS, you are integrating two separate libraries with two separate APIs and two separate bug surfaces, not one cross-platform layer.

A second alternative is to drive FFmpeg from the app through a JNI wrapper. That gives you a far wider protocol and muxer matrix and a command-line mental model, but you inherit a large native binary, cross-compilation for each ABI, and licence obligations that differ from Apache-2.0. RootEncoder's trade-off is the opposite: a smaller, Android-native surface that uses the platform's own MediaCodec hardware encoders, at the cost of being limited to what the README lists.

A third path is a hosted mobile recording or streaming SDK, such as the ones the README's sponsorship section mentions. Those move the encoding and delivery off your plate, but they are commercial services with their own terms, and they change the architecture from "my app talks to my server" to "my app talks to a vendor". RootEncoder keeps the server relationship in your hands.

## Licence, maintenance and the cost of upgrading

RootEncoder is licensed under Apache-2.0, and the licence file is at LICENSE.txt in the repository root. Apache-2.0 is permissive and includes an explicit patent grant, which is generally friendlier for commercial distribution than a copyleft licence, but it still requires you to preserve notices and include the licence text. This is not legal advice; check your own obligations, particularly if you modify and redistribute the library.

The repository is not archived, and the last push was on 2026-09-22. Releases are frequent: 2.8.1 on 2026-09-01, 2.8.0 on 2026-07-16 and 2.7.5 on 2026-06-18. Frequent releases cut both ways. You get fixes, but you also get a moving target. Pin an exact version in Gradle rather than tracking a branch, and read the release notes before bumping.

The upgrade cost is concentrated in two places. Artifact coordinates changed at the 2.2.6 boundary, so anything older than that needs the group and module renamed. And the filter API was refactored in 2.0.9 with a dedicated wiki migration page, so custom OpenGL filters are the other place where a version bump becomes real work. Everything else in the README reads as additive feature work across protocols.

## Conclusion

Adopt RootEncoder when your product is an Android app that must publish a camera, screen or file stream to a media server you already operate, and you are willing to own the Activity lifecycle, permission handling and reconnection logic yourself. Do not adopt it if you need a ready-made streaming app, an iOS client (the separate RootEncoder-iOS repository exists), or a server: the project only provides the client encoder. Before starting, verify the exact JitPack coordinate for the version you intend to pin, confirm the extra-sources artifact if you plan to use CameraXSource or CameraUvcSource, and check the wiki for the filter API refactored in version 2.0.9 if you are migrating an older integration.

## FAQ

### How do I add RootEncoder to an Android project?

Add the JitPack repository to your Gradle repositories block, then depend on com.github.pedroSG94.RootEncoder:library with the version you want. If you need CameraXSource or CameraUvcSource, add the extra-sources artifact as well.

### Which protocols does RootEncoder support for streaming?

The README lists RTMP, RTSP, SRT and UDP, with WHIP marked as beta. Each protocol carries a different codec list, so check the protocol's section before choosing one.

### Does RootEncoder work on iOS?

No, RootEncoder is an Android library. The README points to a separate repository, RootEncoder-iOS, for the iOS version.

## Sources

- [Issues](https://github.com/pedroSG94/RootEncoder/issues)
- [License: Apache-2.0](https://github.com/pedroSG94/RootEncoder/blob/master/LICENSE)
- [pedroSG94/RootEncoder on GitHub](https://github.com/pedroSG94/RootEncoder)
- [README](https://github.com/pedroSG94/RootEncoder/blob/master/README.md)
- [Releases](https://github.com/pedroSG94/RootEncoder/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pedrosg94-rootencoder