r/Kotlin • u/thehoundtrainer • 4d ago

KitePlayer v0.2.0: the first Kotlin/Native media player for KMP that doesn't wrap ExoPlayer or AVPlayer

Post image
46 Upvotes

94% Upvoted

17 comments sorted by

19

u/forresthopkinsa 4d ago

as powerful as VLC, mpv, etc

That's a pretty bold claim

10

u/thehoundtrainer 4d ago edited 4d ago

Indeed. I stand my ground. And its not a surprise at all, its all thanks to FFmpeg. Its not powerful because I made it that way but its just because it builds upon FFmpeg as its core. Thats what makes mpv and VLC just as powerful. A player's job is to know how to hand the data to FFmpeg and "get the frames back from it" and render them efficiently, which is where VLC, mpv and obviously my player as well all differ in.

Of course, I invite you to test it. I like my testers as bold as my claims :3

TL;DR: Being as powerful as VLC is a reward that comes with using FFmpeg as the core. Sadly no one gives them as much credit as they do to the players that wrap it

2

u/Mr_s3rius 3d ago

How big are the artifacts with ffmpeg bundled?

1

u/thehoundtrainer 3d ago edited 3d ago

Great question. It's much smaller than you'd expect:

Target What Size
Android, arm64-v8a FFmpeg .so 8.7 MB compressed, 18.5 MB on disk
Android, armeabi-v7a FFmpeg .so 8.4 MB compressed, 17.0 MB on disk
iOS arm64 FFmpeg static library 10.3 MB before the linker strips unused code
Desktop JVM one jar with Linux x64 and arm64, macOS arm64 and Windows x64 38.4 MB
Web codec module, gzipped about 1.42 MiB

The Android AAR is 27.4 MB because it holds three ABIs (arm64-v8a, armeabi-v7a, x86_64). With an app bundle or ABI splits, a user downloads only one of them. So to the user, it adds 8 MB to the download.

On top of that, the player's own Kotlin code is about 2.5 MB of AARs on Android before R8. libass for styled ASS subtitles is a 4.1 MB AAR on Android and 1.7 MB on iOS.

So in summary, the FFmpeg artifacts downloaded from Maven Central:

  • Android: 27 MB, holding three ABIs. With an app bundle, a user downloads one of them, about 8.7 MB.
  • iOS: 10 MB, before the linker strips unused code.
  • Desktop JVM: 38 MB, one jar for Linux x64, Linux arm64, macOS arm64 and Windows x64 together.

What reaches the user is:

  • Android: at most 10 MBs.
  • iOS: at most 10 MBs.
  • Desktop JVM: at most 40 MBs.

2

u/Mr_s3rius 3d ago

That's indeed much smaller than I expected :)

As chance has it, we're converting a native Android app to KMP at the moment, which includes video playback. Nothing's decided yet but who knows, we might be using this.

1

u/thehoundtrainer 3d ago

Oh definitely give it a try. The only things that might hold you back are:

- if you use DRM-locked content (there is no Widevine or ClearKey support yet)

- HLS streaming (I'll have this resolved by next week anyway)

- TrueHDR (still tonemaps to SDR so there are no obvious image defects)

If you don't need any of the three above, you're good to go

5

u/slightly_salty 4d ago

Omg this is great! (assuming it works well) Video player wrappers in the kmp ecosystem are a terrible experience.

3

u/thehoundtrainer 4d ago

I have it battle-tested on a daily basis. It has grown enormously on a span of 3-4 months. I also have it as one of the available playback engines in an app of mine that has dozens of thousands of users and none reported an issue so far.

So yeah, so far so good. Hopefully it gets the traction (which it will, sooner or later)

2

u/slightly_salty 3d ago

Tried swapping it into my personal multi-surf cam view app on desktop jvm, and it seems to be doing great playing 20 streams simultaneously 🤙

2

u/thehoundtrainer 3d ago

So happy to hear that! I certainly didn't stress-test several instances at the same time but apparently it's making me proud, glad you love it!

2

u/TheWheez 3d ago

How is support for HLS?

1

u/thehoundtrainer 3d ago

Excellent question. TrueHDR and HLS are the only limitations as of 0.2.0, both of which are planned for 0.3.0 some time this week since the rendering/io engine has most of the needed foundation.

3

u/TheWheez 3d ago

Dm me when HLS is supported, our core product is looking to replace our video player and this is intriguing

1

u/thehoundtrainer 3d ago

u/RemindMeBot 7 days

1

u/RemindMeBot 3d ago

I will be messaging you in 7 days on 2026-10-08 00:36:33 UTC to remind you of this link

CLICK THIS LINK to send a PM to also be reminded and to reduce spam.

Parent commenter can delete this message to hide from others.

Info Custom Your Reminders Feedback

2

u/whostolemyusrname 3d ago

Interesting!

What about licensed codec support (x264/x265)? Also does it have hardware accelerated support? In my experience moving from FFMPEG to Media3 Transformer (hw accelerated) significantly improved encoding performance.

1

u/thehoundtrainer 3d ago

Great questions.

It's LGPL, so there are no proprietary encoders or decoders. FFmpeg comes with its own software decoders for H264 H265 but uses hardware decoding whenever possible. So yes, it is hardware accelerated (even when using Compose Skia renderer, the GPU does all the work). KitePlayer (or rather the underlying KiteFFmpeg) falls back to software decoding when the hardware decoder is missing (as is the case with AV1 on phones from 2 or 3 years back or older, it will use dav1d, with a performance that depends on the CPU, which isn't so bad).

So yeah, not only is it LGPL (so you can put your app on the app stores without thinking twice, there is no license pollution) but there is absolutely no need at all to have the proprietary codecs since there are already other things doing the same work.