Xamarin.FFmpegKit.MinGpl.Android 8.1.7-beta.5.6

FFmpegKit.Android

⚠️ This project is under active development. APIs, repository structure, and NuGet packages may change without notice. Use in production at your own risk.

Xamarin/.NET for Android bindings for the native FFmpegKit library.

Original project: arthenica/ffmpeg-kit-next

About

This repository contains .NET bindings (AndroidClassParser=class-parse) on top of the FFmpegKit .aar build for Android. One project, FFmpegKit.Android, produces all eight package variants — the variant is selected with the FFmpegKitBuildType MSBuild property.

Packages target net8.0-android34.0, net9.0-android35.0 and net10.0-android36.0.

Each .NET SDK's Android workload supports only two target frameworks — the .NET 9 band ships Microsoft.Android.Sdk.net8 and .net9, the .NET 10 band ships .net9 and .net10 — so no single dotnet pack can produce all three. BuildNugets.sh packs once per band and build/merge-packages.py merges the lib/ trees and nuspec dependency groups into one package per variant.

Where the native binaries come from

The original arthenica/ffmpeg-kit repository is archived and its v5.1.LTS release assets have been deleted; its successor ffmpeg-kit-next is source-only. The .aar files are therefore pulled from the community-maintained Maven Central mirror dev.ffmpegkit-maintained — see FetchJars.sh. The version is set by FFmpegKitNativeVersion in Directory.Build.props, and FetchJars.sh must be kept in sync with it.

FFmpegKitConfig also needs the two smart-exception jars at runtime. They are not bundled in the .aar and not declared in its .pom, so they are fetched separately and embedded into the binding.

License

This section describes what the upstream project states. It is not legal advice — if the distinction matters for your product, get it reviewed.

The C# binding code in this repository is MIT. The published NuGet packages are not, because each one embeds native FFmpeg binaries built by ffmpegkit-maintained/ffmpeg, which carry their own copyleft terms. Each package therefore declares MIT AND <native license>:

The -gpl variants enable x264, x265, xvid and vidstab, which are GPL — upstream keeps them as separate artifacts specifically so they never contaminate the LGPL ones. Upstream's guidance is direct: if your app is closed-source, use a non-GPL variant.

Upstream states version 3.0 with no "or later" wording, hence the -only SPDX identifiers.

Every package ships the texts it is covered by under licenses/ — LICENSE (MIT, the bindings) and LGPL-3.0.txt or GPL-3.0.txt (the native binaries). The same texts are in this repository under licenses/. Per-dependency notices for the individual codecs (x264, dav1d, freetype, …) travel inside each .aar at res/raw/license_*.txt and end up in your app's resources.

Installation

Install the package via NuGet. There are various packages depending on what you plan to use and if you require a GPL compatible package or not. These package variants match the different variants built in the FFmpegKit repository. The -gpl variants are GPL-3.0 — see License before choosing one.

Package	Link
Xamarin.FFmpegKit.Audio.Android
Xamarin.FFmpegKit.Full.Android
Xamarin.FFmpegKit.FullGpl.Android
Xamarin.FFmpegKit.Https.Android
Xamarin.FFmpegKit.HttpsGpl.Android
Xamarin.FFmpegKit.Min.Android
Xamarin.FFmpegKit.MinGpl.Android
Xamarin.FFmpegKit.Video.Android

Usage

Include Ffmpegkit.Droid namespace

using Ffmpegkit.Droid;

Execute your FFmpeg command

FFmpegKit.Execute("-i input.mov -c:v libx264 output.mp4");

More examples and usage can be found in the FFmpegKit wiki.

Building

Prerequisites

The .NET 8, 9 and 10 SDKs, each with the Android workload installed — every band supplies a different reference pack (Ref.34, Ref.35, Ref.36). The SDK is chosen by the global.json in the working directory, so install each band from a directory pinned to it:

for major in 8 9 10; do
  dir=$(mktemp -d) && cd "$dir"
  dotnet new globaljson --sdk-version "$(dotnet --list-sdks | grep "^${major}\." | tail -1 | cut -d' ' -f1)" --force
  dotnet workload install android
done

Python 3 is also needed, for the package merge step.

All variants

./FFmpegKit.Android/Jars/FetchJars.sh          # downloads the .aar/.jar files
./FFmpegKit.Android/BuildNugets.sh             # packs all 8 variants into ./artifacts
./FFmpegKit.Android/BuildNugets.sh 8.1.7-rc.1  # ...or with an explicit package version

FetchJars.sh reads the FFmpegKit version from FFmpegKitNativeVersion in Directory.Build.props, the same property the .csproj uses to pick the .aar, so the two cannot drift apart. Pass a version to override it (./FetchJars.sh 8.2.0) when trying a newer upstream build before committing to it.

A single variant

# net8 + net9 assets (.NET 9 SDK, per global.json)
dotnet pack FFmpegKit.Android/FFmpegKit.Android.csproj \
    -c Release -p:FFmpegKitBuildType=Video -p:FFmpegKitSdkBand=net9 -o artifacts

FFmpegKitBuildType is one of Audio, Full, FullGpl, Https, HttpsGpl, Min, MinGpl, Video. FFmpegKitSdkBand is net9 or net10 and must match the SDK actually running the build. Each variant builds into its own obj/ and bin/ subdirectory, so they can be built in sequence without interfering with each other.

Tests

Package tests run anywhere and inspect the packed .nupkg files — assembly present for both target frameworks, correct .aar for the variant, bound API surface, embedded smart-exception classes, nuspec metadata:

dotnet test tests/FFmpegKit.Android.PackageTests
FFMPEGKIT_VARIANTS=Video dotnet test tests/FFmpegKit.Android.PackageTests  # only what you packed

Device tests install the packed package into a small app and run real FFmpeg commands on a device or emulator (encode raw frames to mp4, probe the result, check failure reporting). They consume the package from ./artifacts via the local feed in NuGet.config, so they exercise exactly what gets published:

# builds, installs, runs and reports - the same script CI uses
FFMPEGKIT_DEVICE_RID=android-arm64 \
    ./.github/scripts/run-device-tests.sh Video 8.1.7 net10.0-android36.0

Arguments are the variant, the package version in ./artifacts, and which of the package's target frameworks to exercise. The emulator must be x86_64 or arm64-v8a; the .aar ships no other ABIs.

Example app

FFmpegKit.Android.Example is a small .NET MAUI app that runs real conversions against the package you just built — resize, grayscale and audio extraction — with a before/after video preview.

./FFmpegKit.Android/BuildNugets.sh                    # produce ./artifacts first
dotnet build FFmpegKit.Android.Example -t:Install     # deploy to a running device/emulator

It resolves Xamarin.FFmpegKit.Full.Android from ./artifacts through the local feed in NuGet.config, not from nuget.org, so it always exercises your local build. The version defaults to FFmpegKitNativeVersion; pass -p:FFmpegKitVersion=8.1.7-rc.1 to point it at a specific build.

It references the Full (LGPL) variant deliberately — swapping to a -gpl one would make the sample itself GPL-3.0.

The app is intentionally not part of FFmpegKit.sln and not built in CI: it needs the MAUI workload, which would add several minutes to every run while proving less than the device tests already do.

CI

Both call the reusable build.yml.

Publishing credentials

Publishing uses nuget.org Trusted Publishing — no long-lived API key. Each publish job requests a GitHub OIDC token (id-token: write), exchanges it via NuGet/login@v1 for an API key valid for one hour, and pushes with that.

Setup on nuget.org (Account → Trusted Publishing): a policy binds to exactly one workflow file, so this repository needs two, identical apart from the workflow file name:

No repository secrets are required. The workflows pass the nuget.org profile name (s.bokatuk, not an email address) to NuGet/login, defaulted inline since it is already public as the package author. Set a NUGET_USER secret to override it if the owner ever changes.

Policies created against a private repository start out active for 7 days only; they become permanent after the first successful publish, which supplies the repository and owner IDs that lock the policy down.

Note that prereleases pushed to nuget.org cannot be deleted, only unlisted — every pull request push publishes eight packages.