Exoplayer: Distribute ExoPlayer extensions via jCenter

[IanDBird]

The number of (native) extensions available for the library has been increasing, as seen with the introduction of FLAC support on dev. Since these often require native libraries and built via the NDK, there's quite a bit of overhead for developers to incorporate these.

Have you considered making these available as separate components via gradle? That way, application developers can simply pull these directly rather than building. For our own application, we would prefer CPU arch specific builds, rather than all.

Has this been considered?

[ojw28]

I'm not particularly knowledgeable about how this works. Would said components need to contain the native libraries that they depend on? If so then I think we'd probably want to avoid doing that; since we'd effectively be distributing other projects in our components (which may have different licenses etc). @vigneshvg might know more. If not then it's something we should consider.

[vigneshvg]

Including the libvpx (vp9 decoder) native library would be okay from a licensing point of view. (and i think it's probably okay for Opus too).

That said, i have no idea how native libraries are distributed via maven.

[ojw28]

I think we're unlikely to do this. The above discussion aside, requiring the extensions should (hopefully!) be for fairly niche or advanced cases. There's an argument for "not making it too easy", since platform decoders should be preferred where feasible.

[PaulWoitaschek]

I think it would be a really good idea to release artifacts for the extensions too.
Opus and Flac are really bad supported on Android and building from sources (and checking that in VCS so for example Fdroid can build it) is real pain.

[Behrouz-m]

Please consider providing Maven support for Extensions. thanks.

[ojw28]

Current status is as follows.

• Already distributed: OkHttp, GVR
• Can probably distribute: Cronet, VP9
• Unsure: FLAC, Opus
• Probably wont distribute: FFMPEG, as explained in https://github.com/google/ExoPlayer/issues/2781.

[PaulWoitaschek]

I'd really be glad about flac\ opus. Building and maintaining them was kind of a pain. In my case I had to make sure my project contains no binary files so fdroid can build them.

What makes them status unsure?

[mondain]

@vigneshvg you can use the maven nar plugin to package and deploy native libraries to a Maven artifact repository. Its a bit painful when you start using it, but its very nice once you have it all sorted. We have lgpl ffmpeg, libopenh264, libopus in our repo jar for win, osx, and linux. https://github.com/maven-nar/nar-maven-plugin

[AdityaAnand1]

I wonder why the extensions aren't simply built in to ExoPlayer, they aren't very big in size. Anyways, if they are a common enough use case to have their build process explained officially surely we can offer a better way for developers to use them. @ojw28 please share your thoughts :)

[ojw28]

If I remember correctly, the VP9 extension alone is larger than the library (without extensions). They're definitely non-trivial in terms of size. Some developers are extremely sensitive to library size, particularly those targeting emerging markets, which is why we've actually been going in the opposite direction (i.e. splitting the core library into multiple individual modules).

Reasoning for not distributing the FFmpeg extension is already provided in https://github.com/google/ExoPlayer/issues/2781. As already stated in this issue, we're considering distributing the Cronet, VP9, FLAC and Opus extensions. It's not high priority for us though. Usage of these extensions is very low vs usage of the library.

[PaulWoitaschek]

It's not high priority for us though. Usage of these extensions is very low vs usage of the library.

It would be really really great if you could give this a larger priority.

It massively complicates the build process for open source projects. I'm also hosting on Fdroid which means I can not ship any binaries and have to automate the whole process.
Also it slows down the whole build process.

And developers have to setup the ndk stuff etc which makes it more complicated as regular devs don't ever use the NDK.

[PaulWoitaschek]

Usage of these extensions is very low vs usage of the library.

Also I want to note that probably the usage of these extensions is very low because it's so hard to use them.

I created a project that builds the flac and opus extensions from source and lets you import them through jitpack:
https://github.com/PaulWoitaschek/ExoPlayer-Extensions

[PaulWoitaschek]

Sorry for the 3rd consecutive post, but if someone is interested in any other extension, I can add more modules that build from source. (or just create a PR)

[AOrobator]

@PaulWoitaschek Thanks for the extensions project. Would you mind creating a module for the ffmpeg extension?

[PaulWoitaschek]

@AOrobator
Nope, building these so they can run on a CI / whatever build environment and constantly updating them is real pain.
Is just stopped updating the opus and flac extensions because exoplayer uses parts of the NDK which are not compatible with some specific NDK versions, and then jitpack doesn't build, and then ...

Long story short: Please @ojw28 concider publishing these extensions. Is there any reason that stops you from publishing the opus and flac extensions?