ijkplayer: a Gradle snippet with jcenter in it, and a licence question the author leaves open

The Gradle snippet names a dead repository and a removed keyword

The download section for Android is the first thing a new user copies, and it cannot be followed as written.

The block tells you to add a repository called jcenter to all projects, then adds dependencies using the compile keyword. Both of those are historical. The repository service shut down years ago, and the compile keyword was replaced in the build tool long before the versions of it that exist now. The coordinates themselves are plausible: a Java artifact plus one per processor architecture, with the armv7a pair marked as enough for most devices and the rest optional, and a final line that begins to declare an ExoPlayer-backed implementation before the file cuts off mid-declaration.

The iOS half of the same section contains five words: in coming.

So the practical situation is that there is no binary distribution to reach for on either platform. An Android developer has to locate the artifacts independently and write their own build configuration, and an iOS developer has to compile from source. Everything after this section is a source build, and the build instructions assume a specific historical toolchain.

This is a project that stopped moving rather than one that is broken. The last push was 2024-08-13 and there are no releases to compare against.

You choose your codec set by symlinking a config file

There is no menu of features. The codec set is chosen by which file a config directory points at, and then FFmpeg is recompiled.

There are three named options. One is for more codecs and formats. One is for a smaller binary that still includes HEVC. One is for a smaller binary and is described as the default. Each is the same three-step procedure: change into the config directory, remove the current symlink, create a new one pointing at the file you want, then change into the Android contributions directory (or the iOS one, which is commented) and run the clean script.

cd config
rm module.sh
ln -s module-lite.sh module.sh
cd android/contrib
# cd ios
sh compile-ffmpeg.sh clean

So the decision about which formats your application can play is a build-time decision made by editing a symlink, and changing your mind means recompiling FFmpeg from scratch. There is no runtime negotiation and no fallback list.

One line in that section is worth noticing: the project asks people who want to share their configuration to open a pull request. That is the extension mechanism for this part of the build, and it tells you the configuration is considered part of the project rather than a local setting.

Subtitle rendering and filters are on the not-on-plan list

There is a section titled NOT-ON-PLAN, and it is a short and specific list of things the author will not build.

Obsolete platforms are excluded: Android below a named API level and iOS below a named major version. Obsolete processors are excluded, three architectures are named, and the parenthetical is worth quoting for its tone, since the author says they do not even have those kinds of devices to test on.

Then two functional exclusions. There is no native subtitle rendering, and there is no filter support.

That second one is a bigger constraint than it sounds. A filter graph is what lets you scale, crop, composite, watermark and re-encode on the fly, and a project without one is a decoder and a renderer: it takes a container, gives you frames, and plays audio. If your application needs to do anything to the picture between decode and display, this is not the component for it.

The subtitle exclusion is the one most users discover late, because subtitle support is often assumed rather than checked. The features list mentions neither, and the not-on-plan list is the only place either appears.

The author says they do not know whether the licences are compatible

The commercial use section is three sentences and it is the most important paragraph in the file.

It says the player is licensed under a copyleft licence at version 2.1 or later, so the player itself is free for commercial use under those terms. It then says the player is also based on other different projects under various licences, and that the author has no idea whether those licences are compatible with each other or with your product. And it says you should always ask your lawyer about these things before using it in a product.

The derivation list behind that paragraph is long enough to explain the hesitation. The player is built on or derived from four copyleft projects including FFmpeg and libVLC, a zlib-licensed library, a BSD-style library, an ISC-licensed assembly file, an Apache-licensed player for the alternative backend directory, a copyleft profiler in the example directory that is not included by default, and a component of unknown licence in the iOS demo.

The repository root holds a copy of six different licence texts plus a notice file, which is the practical consequence of that mixture. So the honest position is the author's own: the player's own terms are clear, the assembled terms are not, and the answer is not in the repository.

The build environment documented here is from 2016

There is a section listing the environment the project was built in, and every entry has been superseded.

The common entry is a Mac operating system from the middle of 2015. The Android entries are a native development kit from the r10 generation, a studio release from early 2016, and a build tool version from late 2015. The iOS entries are an Xcode from 2016 and a package manager install performed by piping a downloaded script into a Ruby interpreter, followed by installing git. Before the build section it asks you to install a package manager, git and an assembler, and to export two environment variables pointing at the mobile SDKs.

The feature matrix is consistent with that era. Android support is listed across a range of API levels ending well before current releases, with hardware decoding from API 16. iOS support ends at a version numbered in the tens, with VideoToolbox decoding from a named point and one alternative player marked obsolete since a named iOS release. The Android Studio instructions in the build section set a compile SDK version, a build tools version and a target SDK version, all at the same round number.

None of that is wrong, and all of it is a decade old. The build scripts themselves are shell, so they are portable; the native toolchain they expect is not.

Ten init scripts, and the feature set is chosen by running them

The repository root is a list of shell scripts, and reading the names is the fastest way to understand how this project is configured.

There is one script to initialise the Android build and one for iOS, and then eight more that are clearly optional: alternative backends, a JPEG codec, a scaling library, a media library, an audio library, a profiler, an audio library for iOS, and a cryptographic library for each platform. Plus a configuration initialiser, a version script, and a separate build script for one processor architecture.

So the feature set of a build is the set of initialisers you ran, not a list in a build file. That has two consequences. A fork's configuration is a shell script and a symlink rather than a portable manifest, and an incremental change means re-running an initialiser and recompiling.

The source tree itself is conventional by comparison: platform directories for Android and iOS, a directory for the shared player, one for profiling, and directories for configuration, documentation, extras and tools. The unusual part is entirely in the root, where the build is assembled rather than declared.

Support is public only, and the build badges point at a service that is gone

Two closing details tell you what to expect from the project as an ongoing dependency.

The support section is a request, in two languages, that people not send email and instead discuss technical questions publicly on the issue tracker, with the reason given as a preference for public discussion. There is no maintainer response time promised and no private channel offered.

The build status table at the top of the file links to continuous integration jobs on a service that no longer exists under that name, for both platforms. So the badges in the file are not evidence that the builds pass; they are links that will not resolve.

Taken with the absence of releases and a last push in August 2024, the picture is consistent. This is a source snapshot of a project whose own build environment is from 2016, distributed under a licence the author themselves declines to vouch for in a product. It remains a readable reference for how a hardware-accelerated FFmpeg player is put together on two mobile platforms, and that is a real thing to be, but it is not something to adopt without doing the work yourself.

Editorial conclusion

Use ijkplayer if you need FFmpeg decoding and rendering inside your own application on both mobile platforms, you are willing to compile FFmpeg and the player yourself, and you have read the licence section and had it reviewed for your product. Do not follow the Gradle snippet as written, because the repository it names and the dependency keyword it uses no longer exist, and the iOS package is not provided at all. Before you start: pick a codec configuration deliberately, because it is chosen by symlinking a config file and then recompiling FFmpeg; note that native subtitle rendering and filter support are on the not-on-plan list, so this is a decoder and renderer rather than a filter engine; and plan for a build environment several major versions behind current tooling.

Frequently asked questions

Official sources

1. Official README
2. Project repository