Saying Goodbye to FFmpegKit
As of January 6, 2025, FFmpegKit is officially retired.
This decision wasn’t easy, especially considering the years of time and effort I’ve invested in the project. But after weighing all the challenges, I realised it’s no longer feasible for me to continue maintaining the project.
I wanted to share the story behind this decision, as well as outline what’s happening in the next few months, and explain what current users need to know. If you’re here for specific guidance, feel free to skip to the relevant sections below.
Why #1
“Time has been one of the two main challenges in maintaining FFmpegKit.”
Since late 2022, I’ve struggled to dedicate enough time to the project due to other commitments. While I did my best to review issues reported on GitHub every few months, keeping FFmpegKit updated with new FFmpeg versions required way more time than I could realistically allocate.
Updating FFmpegKit to support new FFmpeg versions has always been the most challenging part of maintaining the project. It involves;
- Adapting to API changes
- Solving architecture problems
- And testing everything thoroughly for all platforms supported
none of which is quick or easy. Unfortunately, I didn’t have the time to do this myself, and we didn’t receive enough contributions from the community to fill the gap.
Yes, we had PRs, and I’m so grateful to the developers who went the extra mile to debug issues and provide detailed analyses of the problems they encountered. Their work helped improve FFmpegKit in many ways, and some even implemented new features. But the FFmpeg wrapper layer (the core of FFmpegKit API) didn’t receive much support. I understand, it’s a complex piece of the project. Maybe I shouldn’t have been surprised, but the result was that FFmpegKit fell behind FFmpeg in terms of supported versions.
In 2023, we released FFmpegKit 6.0, the final version. To make it happen, I outsourced the work to contractors since I didn’t have the time to do it myself. I paid a significant amount to cover their efforts, and while they delivered the update, the release wasn’t as smooth as I had hoped. It wasn’t tested thoroughly and required patches after release. Still, I was relieved to finally fulfill a promise I had made to users earlier that year.
In 2024, I couldn’t afford to outsource again, so I attempted to update FFmpegKit myself. I began migrating the development branch to FFmpeg 6.1 in November. The process was slow and frustrating, with architecture challenges and workarounds needed for new structures introduced in FFmpeg. While I made progress, and the branch is currently stable, it still needs proper testing which I just don’t have time for.
What complicates things further is that FFmpeg 6.1 isn’t even the latest version anymore. FFmpeg has moved on to versions 7.0 and 7.1, and the gap is only getting wider. The effort required to keep FFmpegKit up to date is simply beyond what I can manage now or in the foreseeable future.
Why #2
“The other major reason is the legal complexity of working with FFmpeg.”
FFmpeg is a powerful tool, but it comes with significant challenges, especially when it comes to licenses and patents. Distributing FFmpeg binaries, as FFmpegKit does, brings a unique set of risks.
When I moved FFmpegKit under my company, Arthenica Ltd, I contacted MPEG LA to clarify the project’s position. At the time, MPEG LA confirmed that FFmpegKit, as an upstream software component, was not subject to patent fees. That assurance gave me the confidence to continue investing in the project and even plan for commercial services around it.
However, in 2023, MPEG LA was acquired by Via-LA, and everything changed. When I reached out to Via-LA in late 2024 to confirm FFmpegKit’s position under their terms, I received no response.
To get clarity, I consulted an IP law firm. Their review raised concerns about potential risks related to licensing and patents. They recommended retiring the project and removing older binaries as the safest option. They did suggest some alternative paths, but those options would have required significant time, effort, and money, neither of which I could commit.
At that point, the decision to retire FFmpegKit became unavoidable.
What’s Next?
FFmpegKit is now retired on GitHub. While the source code and release archives will remain available, all native binaries (for Android, iOS, macOS, and tvOS) will be removed from repositories according to the following schedule:
- Versions older than 6.0: Will be removed on February 1, 2025
- Version 6.0: Will be removed on April 1, 2025
As for the Flutter and React Native versions, I plan to deprecate them if possible. However, I’m still exploring what’s possible on those platforms and haven’t made any concrete plans yet.
For Existing Users of FFmpegKit
The legal and patent challenges outlined above apply to me and my company only. If you are using FFmpegKit or FFmpeg in your applications, I strongly recommend consulting with an IP professional to evaluate your specific situation.
Since FFmpegKit binaries will no longer be available in repositories after the specified dates, your CI/CD pipelines may fail if they rely on these binaries. To avoid disruptions, you’ll need to build FFmpegKit locally and use the created binaries in your applications. The Building section of the project Wiki provides detailed instructions for this process. If you have trouble finding the information, use the Search feature on GitHub.
Retiring FFmpegKit wasn’t an easy decision, but I believe it’s the right one given the circumstances. This project has been a significant part of my journey, and I’m incredibly proud of what we achieved as a community.
I hope that FFmpegKit’s source code, documentation, and the contributions made by so many talented developers will serve as a foundation for someone else to take the project forward. If someone is willing to pick up where I left off and continue maintaining it, I would be delighted to see FFmpegKit live on and evolve.
To everyone who used, supported, or contributed to FFmpegKit: Thank You!
