CarGuo/GSYVideoPlayer: A Multi-Kernel Android Video Player Library

What CarGuo/GSYVideoPlayer Solves, and for Whom

Android playback is fragmented. MediaPlayer ships with the platform, ExoPlayer (now Media3) is Google's own, IJKPlayer handles formats MediaPlayer does not, and vendors such as AliPlayer cover their own cases. Each has a different lifecycle, a different surface API and a different set of quirks. GSYVideoPlayer's answer is a single player abstraction over four kernels, plus a control layer, a rendering layer and a cache layer that the README describes as customizable.

The intended audience is Android application developers building apps where video is a first-class feature rather than a one-off embed. The README lists the feature set accordingly: list playback with continuous and automatic playback on scroll, small-window and desktop multi-window playback, simultaneous playback of several videos, fast and slow playback, display-ratio switching (default, 16:9, 4:3, fill), rotation and mirroring, danmaku (bullet chat), external subtitles, filters and watermarks, GIF capture, and opening or interstitial ads.

That is a lot of surface area. If you only need to play one HLS stream in a detail screen, this library is larger than the problem. It earns its place when several of those features appear in the same product, and when you want them behind one API instead of three.

How the Kernel Abstraction and Cache Layers Fit Together

The repository is split into Gradle modules rather than one monolithic artifact. gsyVideoPlayer-base holds the shared abstraction, gsyVideoPlayer-java holds the Java-side player logic, and gsyVideoPlayer-exo_player2 and gsyVideoPlayer-aliplay are the Media3 and AliPlayer implementations. Native kernels live in per-ABI modules: gsyVideoPlayer-armv5, gsyVideoPlayer-armv7a, gsyVideoPlayer-armv64, gsyVideoPlayer-x86 and gsyVideoPlayer-x86_64. gsyVideoPlayer-ex_so carries the prebuilt native libraries, gsyVideoPlayer-proxy_cache carries the caching proxy, and gsyVideoPlayer-cast is a separate DLNA/UPnP module.

Caching differs by kernel, and the README is explicit about it. The IJK path uses AndroidVideoCache, while Media3 (ExoPlayer) uses SimpleCache. That is not a cosmetic difference: the two caches have different storage layouts and eviction behaviour, so switching kernels can mean re-downloading content that was already cached.

The cast module is deliberately optional. The core keeps only the protocol-neutral CastCapability, CastProvider and CastSession SPI and does not pull Jetty; gsyvideoplayer-cast is built on jUPnP 3.0.3 for DLNA/UPnP. Pulling the cast artifact therefore brings its dependencies with it.

On the native side, the README states that ex_so's arm64 and x86_64 builds use OpenSSL 1.1.1w and FFmpeg 4.3, and that G711a (pcm_alaw) is supported. Those are version pins you inherit, not choices you make.

Installing GSYVideoPlayer from MavenCentral

The README recommends MavenCentral over JitPack, and gives the reason directly: JitPack has a random loss of packages. MavenCentral hosting is available from version 11.0.0, and the README notes that all base class packages are published there. Add the repository first, in the top-level build file.

allprojects {
    repositories {
        ///...
        mavenCentral()
        maven { url "https://maven.aliyun.com/repository/public" }
    }
}

After syncing, Gradle resolves io.github.carguo artifacts from MavenCentral rather than JitPack. The README then says to add one of three dependency forms to the module-level build.gradle; the direct, complete form begins with the coordinate io.github.carguo:gsyvideoplayer. The README's snippet is cut off mid-line in the published text, so confirm the exact artifact name and version on the MavenCentral page for io.github.carguo:gsyvideoplayer before pasting it. The current release line is v13.2.1, published on 2026-08-19.

For a first run, the fastest route is the demo APK linked from the releases page, which the README points to under Demo APK Download Address. That tells you whether the kernels behave on your device before you wire anything into your own project. The last push to the repository was on 2026-09-01.

Where GSYVideoPlayer Is the Wrong Choice

The library's breadth is also its cost. Every kernel you enable is another dependency, and the IJK and ex_so paths bring native libraries per ABI. If your app only needs Media3, adding GSYVideoPlayer means carrying an abstraction you do not use, plus the possibility of native artifacts you did not ask for.

The README itself flags a hosting risk that is easy to miss: JitPack is described as having a random loss of packages, which is why the project moved to MavenCentral. That is a reason to pin versions and avoid relying on a JitPack coordinate in a build you cannot easily change.

There is also a documentation gap. The README is a feature table plus dependency notes; it does not document rollback, migration between kernel versions, or what happens to an existing cache when you switch kernels. If your product depends on cache continuity across an upgrade, that is something you will have to establish from the code, not the README.

Finally, the project is Java-first. There is a gsyVideoPlayer-compose module in the repository layout, but the README's feature table and usage notes are written around the Java/Gradle path. A Compose-only team should check that module's state before assuming parity.

GSYVideoPlayer Compared with Media3 Alone

The most direct alternative is using AndroidX Media3 (ExoPlayer2) by itself. GSYVideoPlayer lists Media3 as one of its kernels, so the two are not competitors in the sense of doing different things; they differ in what is layered on top.

With Media3 alone you get the player, the track selection, HLS and DASH support, and SimpleCache. You write your own control layer, your own full-screen handling, your own list playback behaviour, your own subtitle rendering and your own ad insertion. GSYVideoPlayer ships those as part of the library: the README lists full-screen and non-full-screen layout switching, pure playback without operation controls, danmaku, opening and interstitial ads, and unified external subtitle overlay for SRT/WebVTT across IJK, Media3 and MediaPlayer, with Media3 embedded cues bridged to the same UI.

The difference in approach is therefore about control versus assembly. Media3 gives you fewer moving parts and a smaller dependency graph; GSYVideoPlayer gives you a pre-built control and feature layer that assumes you want those features. If you need to swap kernels later, GSYVideoPlayer's abstraction is the point. If you never will, it is overhead.

Maintenance, Release Cadence and Licence

The repository is not archived, and the last push was on 2026-09-01. Recent releases are v13.2.1 and v13.2.0, both on 2026-08-19, and v13.1.0 on 2026-06-30. That is a release line that has moved within the last few months, and the version numbering has reached 13.x, which tells you the API has had a long life. The README also links a version update document and a recent playback features document in doc/, so upgrade notes exist as separate files rather than being buried in the README.

The upgrade cost you should budget for is kernel-related. Native pins (OpenSSL 1.1.1w, FFmpeg 4.3 for ex_so arm64/x86_64) change only when the project rebuilds those binaries, and the cache implementation is tied to the kernel you choose. Moving between IJK and Media3 is not a flag flip if you depend on cached content.

On licensing: the project is Apache-2.0, which the README's badge confirms. Apache-2.0 is permissive and includes an explicit patent grant, but the bundled native components have their own upstream licences. FFmpeg builds in particular carry codec licensing questions depending on how they were configured, and the README does not state the configure flags used for the ex_so builds. That is a question for your own legal review, not something this article can settle.

Editorial conclusion

Adopt GSYVideoPlayer if you need one Android playback API across multiple kernels, or features such as danmaku, external SRT/WebVTT subtitles, filters and pre-roll ads that you would otherwise assemble yourself. Do not adopt it if you want a minimal, single-kernel Media3 wrapper, or if you cannot accept the extra native .so modules that the IJK and ex_so artifacts bring. Before committing, verify which artifact on MavenCentral matches your ABI set, whether your Gradle repositories include mavenCentral plus the Aliyun mirror the README lists, and whether the 16 KB page size path in 16kpatch/ applies to your target devices.

Frequently asked questions

Official sources

1. CarGuo/GSYVideoPlayer on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases