begeekmyfriend/yasea: an RTMP live streaming client for Android

What yasea does and who it is aimed at

Yasea is an Android streaming client. The README describes the pipeline in one sentence: it encodes YUV and PCM data from the camera and microphone to H.264/AAC, encapsulates the result in FLV, and transmits it over RTMP. That is the whole product. There is no dashboard, no ingest service, no player.

The audience is Android developers building a broadcaster. If you are writing an app that needs to send live video from a phone to an RTMP endpoint, yasea supplies the capture, encode, mux and publish stages so you do not have to assemble them from separate libraries. It is not a consumer app, and it is not a server. The README points at srs for the server side, telling you to build your own private RTMP server and to modify the URL yourself.

The feature list is short and concrete: Android API 21 minimum, H.264/AAC hard encoding, RTMP streaming with a state callback handler, portrait and landscape dynamic orientation, front and back camera hot switch, recording to MP4 while streaming, GPUImage filters, and acoustic echo cancellation with automatic gain control. Each of those is a behaviour you would otherwise implement yourself, which is the argument for using the library rather than the platform encoders directly.

The capture to RTMP pipeline, and the branches that change it

The data flow implied by the README runs in one direction. Camera frames arrive as YUV, microphone samples as PCM. Both go through hardware encoders to produce H.264 and AAC. The two elementary streams are muxed into FLV, and an RTMP client sends that FLV stream to a server. A state callback handler reports connection and streaming state back to the app, so the UI can react to a dropped connection rather than silently showing a preview that is no longer being published.

The repository layout matches this: there is an app module and a library module, plus a build.gradle, a settings.gradle and a gradlew wrapper at the top level. The update_so.sh script at the root is a hint that native shared objects are checked in and need refreshing when the native side changes. The primary language is C++, which is consistent with an RTMP stack and GLES rendering living below the Java layer.

Three branches change the pipeline in ways that matter. The non-gpuimage branch targets Android devices without a GL ES library, such as development boards, which removes the GPUImage filter path. The android-16 branch raises the floor to Android API 16 and above, in contrast to the API 21 minimum on master. The aac-hev2 branch exists for YouTube live broadcast, which the README notes is not compatible with conventional flash media players. That last one is the clearest signal that the default branch targets a conventional RTMP consumer, not a modern low-latency platform.

Building yasea and publishing your first stream

The README gives no Gradle coordinates and no install command, so the realistic path is cloning the repository and building the modules with the included wrapper. The repository root contains gradlew and gradlew.bat, so the wrapper is the entry point for a build from the project directory.

The README's own test instructions are minimal and worth quoting in full because they define the only supported workflow it describes: build your own private RTMP server with srs, and remember to modify the URL yourself. That means the stream URL is a value you set in the app source before building, not something the library reads from a configuration file. The README does not document where in the source that URL lives.

Once the app is running against your server, the state callback handler is what tells you whether publishing succeeded. If the stream connects but the player shows nothing, the README's only troubleshooting note applies: check your bandwidth limits and player buffering. That is a thin diagnostic surface, and it is the main friction point of the first run.

Where yasea is the wrong choice

The README does not document rollback, reconnection policy, bitrate adaptation, or error taxonomy beyond the state callback handler. If your product needs automatic recovery from network transitions, adaptive bitrate, or a defined set of failure codes your UI can branch on, you will be designing that layer yourself on top of the callback. Nothing in the README suggests the library provides it.

The version constraints are also a real boundary. Master requires Android API 21 or higher, which is fine for most current devices but rules out the older hardware the android-16 branch was created for. If you need that branch, you are on a separate line of development, not a configuration flag.

Codec compatibility is the sharper edge. The aac-hev2 branch exists specifically because YouTube live broadcast is not compatible with conventional flash media players. Read that in reverse: the default branch produces output aimed at conventional RTMP consumers. If your target is a platform with different ingest requirements, the default build may not be the right starting point, and the README does not tell you which platforms work.

Finally, the project has no releases listed and its last push was on 2026-04-13. There is no versioned artifact to depend on, so you are vendoring a commit. For a library that touches camera, audio and native code, that is a maintenance commitment, not a dependency you can bump casually.

How yasea differs from SimpleRtmp and Haishinkit

The README's acknowledgements name SimpleRtmp, MagicCamera, mp4parser and srs-sea as prior work. SimpleRtmp, from the same acknowledgement list, is an RTMP client. The difference in approach is scope: an RTMP client library handles the protocol and the handshake, while yasea also owns capture, hardware encoding, FLV muxing, orientation handling, camera switching and MP4 recording. If you pick SimpleRtmp, you assemble the rest yourself. If you pick yasea, you accept its opinions about all of those stages.

Haishinkit appears in the related searches as an Android alternative. The README does not describe its internals, so the honest comparison is at the level of what yasea itself offers: an Android-only, MIT-licensed client whose feature list is the eight items in the README. Anything beyond that list is outside what this repository claims to do.

The MP4 recording feature is worth calling out separately because it changes the architecture. Recording while streaming means the encoded stream is being written to two destinations, and mp4parser is acknowledged for the muxing side. That is a capability a bare RTMP client would not give you, and it is one of the stronger reasons to choose yasea over assembling the stack.

Licence, maintenance and what an upgrade costs

Yasea is MIT licensed. That is permissive: you can use it in closed-source apps, modify it, and redistribute it, provided the licence text and copyright notice are preserved. The repository includes a LICENSE file at the top level. This is not legal advice, and the acknowledgements list names other projects (srs-sea, SimpleRtmp, MagicCamera, mp4parser) whose own licences may apply to the portions derived from them. If you ship yasea inside a commercial app, check those upstream licences rather than assuming MIT covers everything in the tree.

Maintenance cost is the harder question. The last push was on 2026-04-13, and no releases are listed. There is no published changelog or version number to track, so an upgrade means diffing commits and rebuilding. Because the library includes C++ and native shared objects, with update_so.sh at the root for refreshing them, an upgrade can require re-checking ABI coverage and NDK compatibility, not just a Gradle version bump.

The keystore.jks file at the repository root is a reminder that the demo app is signed with a checked-in keystore. Do not reuse it for a production build.

Editorial conclusion

Adopt yasea if you need a small, MIT-licensed Android client that publishes H.264/AAC over RTMP and you are willing to wire the publisher into your own UI and lifecycle. Do not adopt it if you need an actively developed library with published releases, or if your target is a platform other than Android. Before committing, verify three things in the repository: that the library module builds against your current Android Gradle Plugin and NDK, that the native libraries under the jniLibs directories cover the ABIs your app ships, and that the RTMP endpoint you plan to use accepts the FLV muxing the client produces. The last push was on 2026-04-13, and no releases are listed, so pin the commit you build against.

Frequently asked questions

Official sources

1. begeekmyfriend/yasea on GitHub
2. Issues
3. License: MIT
4. README