# zhxacg/module_mediaplayer: six video kernels behind one Android wrapper

> A Java module that puts ijkplayer, androidx media3, exoplayer2, vlcplayer, ffplayer, and the platform MediaPlayer behind one init call and one start builder, aimed at Android TV and phones. The differences between kernels are tabulated instead of smoothed over, so picking one is a real decision with real tradeoffs.

**zhxacg/module_mediaplayer** — Built on ijkplayer + media3 + exoplayer + vlcplayer + ffplayer, for video playback on the Android TV and phone platforms.

- Repository: https://github.com/zhxacg/module_mediaplayer
- Stars: 73 · Forks: 23
- Language: Java
- License: not declared
- Published: 2026-08-24 · Updated: 2026-08-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/zhxacg-module-mediaplayer

## android mediaplayer is the only column without software decoding

The support table sets six kernels side by side, android mediaplayer, androidx media3, exoplayer2, ijkplayer, ffplayer, and vlcplayer, against four capabilities: audio hardware decoding, audio software decoding, video hardware decoding, and video software decoding. Hardware decoding is checked for the first four columns and left unchecked for ffplayer and vlcplayer. Software decoding is checked in every column except the platform android mediaplayer, which carries a cross on both software rows. That asymmetry is the one to plan around. Select the platform MediaPlayer as your kernel and any codec the device cannot decode in hardware has no fallback inside this module. The software rows for media3 and exoplayer2 were filled in later, on 2024-07-17, when audio and video software decoding were added to both.

## ffplayer and vlcplayer sit entirely on the software half

Those two columns are the mirror image of the platform MediaPlayer. ffplayer and vlcplayer are unchecked on audio hardware decoding and on video hardware decoding, and checked on audio software decoding and video software decoding. Nothing in the module maps them onto a hardware path, so a device with a flaky or absent hardware decoder is the case they address, at the cost of CPU work. The timeline shows the same pattern: ffplayer_1.0 arrived 2023-03-14, vlc-3.5.1 on 2023-02-03 and vlcplayer-r3.5.1 on 2023-03-10, with vlc-r3.4.9 earlier at 2022-07-21. For the VLC side the resource links point at the vlc-android repository and at the org.videolan.android libvlc-all artifact, which is where those binaries come from.

## ijkplayer mini, lite, and full differ in three columns

The ijkplayer table splits the builds by size against aac, h264, h265, http, https, and dash. mini covers aac, h264, and http. lite adds https and dash to that set and still crosses out h265. full is checked across all six columns. So h265 is a full-only decision, while https and dash need lite or better. The changelog agrees on one point: dash support landed only in the full variants, with the entry noting ijkplayer dash support for the *_full versions. The ijk side also carries its own build history, cmake based ijkplayer builds from 2022-10-27, armv7, arm64, x86, and x86_64 targets added 2022-11-03, a log switch on 2022-11-09, hardware decoding added 2022-02-11, and ffmpeg 3.4.13 and 4.4.4 variants tracked separately.

## media3 lite keeps hls but drops rtmp, exoplayer2 lite keeps both

The media3 table runs mini, lite, and full against ffmpeg-audio, ffmpeg-video, hls, dash, smooth-streaming, and rtmp. mini checks only hls. lite adds dash and smooth-streaming but crosses out both ffmpeg extensions and rtmp. full is checked everywhere. The exoplayer v2 table is laid out the same way and diverges in useful ways: its lite row checks ffmpeg-audio, hls, dash, smooth-streaming, and rtmp, while ffmpeg-video stays crossed out until full. The practical reading is that rtmp at lite level is an exoplayer2 option and not a media3 one, and that video software decoding through ffmpeg needs full in either case. Neither table offers mini anything beyond hls.

## setDecoderType reaches only three of the four kernel types

Initialization is a single builder chain, and each setter narrows what you can choose.

```java
PlayerSDK.init()
                // 日志开关
                .setLog(true)
                // 数据埋点（监听播放器操作日志）
                .setBuriedEvent(null)
                // 播放器类型（MediaPlayer Media3Player ExoPlayer IjkPLayer）
                .setKernelType(PlayerType.KernelType.IJK)
                // 渲染类型（TextuteView SurafecView）
                .setRenderType(PlayerType.RenderType.SURFACE_VIEW)
                // 解码器类型（仅针对 Media3Player ExoPlayer IjkPLayer）
                .setDecoderType(PlayerType.DecoderType.IJK_ALL_FFMPEG)
                // 画面比例（自动 全屏 原始 1:1 4:3 5:4 16:9 16:10）
```

Four kernel types are named in the setKernelType comment, MediaPlayer, Media3Player, ExoPlayer, and IjkPLayer, but the decoder comment restricts setDecoderType to the last three, which lines up with the platform MediaPlayer having no software decode path to select. The two render options are spelled TextuteView and SurafecView in that comment, and the aspect ratio comment enumerates automatic, fullscreen, original, 1:1, 4:3, 5:4, 16:9, and 16:10.

## setLive decides whether you get a duration back

Starting a session is a builder with one required field.

```java
// step1 参数
        StartArgs build = new StartArgs.Builder()
                // 必传：视频url
                .setUrl("")
                // 视频title
                .setTitle("")
                // 渲染类型（TextuteView SurafecView）
                .setRenderType(PlayerType.RenderType.SURFACE_VIEW)
                // 起播快进
                .setSeek(0L)
                // 单片循环
                .setLooping(false)
                // 静音
                .setMute(false)
                // 媒资是直播，则获取不到时长duration
                .setLive(false)
                // 自动播放
                .setPlayWhenReady(true)
```

Only the URL is marked mandatory. setSeek takes a long for the starting offset, setLooping is the single item loop, setMute is the mute switch, and setPlayWhenReady(true) is autoplay. setLive carries the caveat that a live asset returns no duration, so any progress bar logic has to be gated on that flag. The excerpt stops at an assignment to a variable named build, without showing the call that consumes it, so the last step of the chain is left to you.

## The one shell command launches the demo activity

The README contains no build command, no install step, and no dependency coordinates. The single shell line in it appears under a heading about optimization, and it starts the sample activity rather than the library.

```bash
adb shell am start -n com.kalu.mediaplayer/com.kalu.mediaplayer.MainActivity
```

The package name, com.kalu.mediaplayer, is the one thing the snippet reveals about the demo, and the same fence pairs the command with a blog article link. Practically it means you attach a device or emulator and launch the demo directly, and that adding the module to your own app is left as an exercise. There is no Maven or Gradle coordinate printed in the README, so the integration path has to come from the repository itself. The upstream projects are linked instead, exoplayer.dev and the Google ExoPlayer repository for that kernel, the bilibili ijkplayer and FFmpeg tag listings for that one, and the vlc-android repository with its libvlc-all artifact for the VLC path.

## A Gradle wrapper, three module directories, and no license file

The top level holds .gitignore, README.md, app/, build.gradle, gradle.properties, gradle/, gradlew, gradlew.bat, lib_mediaplayer_ui/, repo/, and settings.gradle, which is the usual shape for a Gradle project with the wrapper checked in. Primary language is Java. lib_mediaplayer_ui/ is the reusable player surface and was refactored on 2021-09-29 in the same entry that moved exoplayer to 2.15.0, while app/ is the demo that the adb line targets. Two details deserve a look before you build on this. There is no license file among those entries, so the terms for reuse are not stated anywhere in the repository. The three tagged releases, dev_ijkplayer_v1.0.0, dev_vlcplayer_v1.0.0, and dev_mediaxplayer_v1.0.0, all carry the same date, 2023-11-28, even though the changelog keeps recording new work afterwards, including media3 1.11.0 on 2026-9-12. The last push to master is dated 2026-09-10.

## Conclusion

This fits an Android TV or phone app that needs to swap playback backends for codec or streaming reasons rather than one that needs a single well understood pipeline. Pick ijkplayer full for h265 or dash, exoplayer2 lite or full for rtmp, and stay off the platform MediaPlayer unless the device decodes everything you ship in hardware. Before you depend on it, note that no license file appears among the top level entries, that the README documents no build or install command, and that the three tagged releases all date from 2023-11-28 while the changelog continues into 2026.

## FAQ

### Which playback kernels can zhxacg/module_mediaplayer switch between?

PlayerType.KernelType names four of them, MediaPlayer, Media3Player, ExoPlayer, and IjkPLayer, and setKernelType is where the choice is made. The support table also tracks ffplayer and vlcplayer, listing all six against hardware and software decoding for audio and video.

### Does zhxacg/module_mediaplayer do software decoding?

It does for androidx media3, exoplayer2, ijkplayer, ffplayer, and vlcplayer on both the audio and video rows, while the platform android mediaplayer is marked as not supported for either. Decoder selection goes through setDecoderType, which applies only to Media3Player, ExoPlayer, and IjkPLayer.

### Which ijkplayer build should zhxacg/module_mediaplayer users pick?

mini covers aac, h264, and http. lite adds https and dash but not h265. full is the only build checked for h265 as well as the other five columns, and the dash entry in the changelog notes that ijkplayer dash support arrived only in the full variants.

### How does zhxacg/module_mediaplayer configure a playback session?

PlayerSDK.init takes setLog, setBuriedEvent, setKernelType, setRenderType, and setDecoderType, and StartArgs.Builder takes setUrl as the only required field, followed by setTitle, setRenderType, setSeek, setLooping, setMute, setLive, and setPlayWhenReady.

### What is the newest change recorded for zhxacg/module_mediaplayer?

The entry dated 2026-9-12 adds media3 1.11.0. Earlier entries add multi track video, audio, and subtitle support for exoplayer2 and media3 on 2025-05-16, the subtitle offset api appSuntitleOffsetMs(long offsetMs) on 2025-10-21, and GLSurfaceView on 2024-07-18.

## Sources

- [Official README](https://github.com/zhxacg/module_mediaplayer#readme)
- [Project repository](https://github.com/zhxacg/module_mediaplayer)
- [Release notes](https://github.com/zhxacg/module_mediaplayer/releases)

---

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