Prebuilt libijkffmpeg.so is FFmpeg 4.3 (June 2020); the 4.3 branch is unmaintained

Author: kobihikriCreated Jul 29, 2026Updated Jul 29, 2026

Hello, and thank you for GSYVideoPlayer.

This is about the prebuilt FFmpeg in the JNI libraries, and I want to be upfront that the remediation here is genuinely awkward — I'll come to that at the end.

What I observed

The repository commits prebuilt libijkffmpeg.so binaries (roughly 6–10 MB each) under gsyVideoPlayer-ex_so/src/main/jniLibs/ and gsyVideoPlayer-x86_64/src/main/jniLibs/, for multiple ABIs. They ship in the AAR consumers depend on.

FFmpeg writes its library version into the binary:

$ strings libijkffmpeg.so | grep -oE 'Lavf[0-9.]+'
Lavf58.45.100

libavformat 58.45.100 identifies the release. Checking upstream's libavformat/version.h at each tag, n4.3, n4.3.1 and n4.3.2 all carry exactly 58.45.100 — so this is the FFmpeg 4.3 line, first released June 2020.

Why it matters for a video player specifically

FFmpeg is a demuxer and decoder. In a player it parses untrusted input — network streams and user-supplied files — which is exactly the surface its CVEs concern.

FFmpeg's own security page shows 4.4 alone fixed twelve CVEs affecting 4.3:

CVE-2020-13904, CVE-2020-14212, CVE-2020-20450, CVE-2020-21041, CVE-2020-21688, CVE-2020-21697, CVE-2020-22038, CVE-2020-22042, CVE-2020-23906, CVE-2020-24020, CVE-2020-35964, CVE-2020-35965

and many more across 4.4.x, 5.x, 6.x, 7.x and 8.x since. The 4.3 branch is no longer maintained; endoflife.date no longer lists a 4.x cycle at all (its oldest entry is 5.0, EOL 2023-04-02).

What I did NOT establish

  • No exploitability or reachability analysis. ijkplayer builds FFmpeg with a reduced module set, so some of those CVEs may be in demuxers or decoders that aren't compiled in. I am not claiming any specific CVE is triggerable here.
  • I did not verify whether the binaries carry local patches on top of 4.3.
  • I could not narrow the patch level within 4.3 — 4.3.0/4.3.1/4.3.2 share this libavformat version.
  • Nothing was executed; I downloaded the .so and read it with strings.

Why it's invisible to tooling

A committed .so has no manifest. Dependabot has nothing to read, no source scanner parses an ELF binary, and the version is only recoverable by running strings and knowing that Lavf58.45 maps to FFmpeg 4.3.

The awkward part

These come from ijkplayer, which is itself no longer actively maintained — so "just update the dependency" isn't really available to you in the way it normally would be. Realistically this means either rebuilding ijkplayer's FFmpeg against a maintained branch, or migrating the playback core. That's a substantial decision rather than a version bump, and it's yours to weigh; I'm raising it so the choice is at least visible, not to suggest it's easy.

Disclosure: AI-assisted (Claude Opus 5). I read the version string from the committed binary, verified the libavformat→FFmpeg mapping against upstream tags, and took the CVE list from ffmpeg.org/security.html myself before posting.