Loading today’s stories
Build1 distinct publisher3 min readUpdated
Six of FFmpeg's core libraries take new major versions in one step. Teams shipping native code or pinned shared libraries next to the wrapper are planning a rebuild, not reading a changelog.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
FFmpegKit Extended is moving from FFmpeg 8.1.2 to FFmpeg 9.0.1 "Lei", and the same upgrade takes FFmpeg's primary libraries to new major ABI versions: libavcodec 63, libavformat 63, libavfilter 12, libavutil 61, libswscale 10, libswresample 7 [1][2]. For an app that only pushes command strings through the wrapper that is a version bump; for anyone linking libav* from their own native code or pinning those shared objects alongside the wrapper, a major ABI increment means binaries built against the previous majors cannot be assumed to link or load [17].
Six libraries change major number at once [16]. That is the whole story for build engineers, and it is worth noting what the announcement does not give you: it lists the new numbers but not the ones that shipped with 8.1.2, so the size of each step is not computable from the post [18]. Check it against your own build output rather than the release note.
The wrapper's own contract is unchanged. FFmpegKit Extended exposes FFmpeg, FFprobe and FFplay across Android, iOS, macOS, Linux and Windows, with asynchronous execution, parallel sessions, callbacks, cancellation, introspection and cross-platform playback [15]. The publisher's framing is that FFmpeg 9 capabilities arrive through the same command arguments you would pass to ffmpeg, ffprobe or ffplay, with no separate media-processing abstraction in between [3][4]. That is the useful part of a thin wrapper: the ABI churn is underneath the process boundary, not in your Dart or JavaScript.
On the feature side, FFmpeg 9 adds an animated WebP demuxer and decoder [5], which means the format can be inspected through FFprobe's existing -show_streams, -show_format, -show_frames and -show_entries interfaces [6] and played through the FFplay surface without a conversion pass first [7]. The new GPU filters are more conditional. transpose_cuda provides CUDA implementations of clock, cclock, clock_flip, cclock_flip, reversal, hflip and vflip [8]; v360_vulkan is the Vulkan-accelerated counterpart for 360 degree projection work [9]; frc_amf uses AMD's Advanced Media Framework Frame Rate Converter and is documented as doubling frame rate through hardware-accelerated interpolation, with options for DirectX 11/12 execution, interpolation fallback, motion-search quality and whether future frames are used [10][11].
None of that is switched on by upgrading. Hardware features are build-dependent: the project ships dedicated Video+Hardware and Full configurations, and documents CUDA/NVDEC/NVENC and other hardware integrations as requiring custom deployments with non-free libraries enabled [12][19]. A team that wants NVDEC -> CUDA filter -> NVENC without a round trip to system memory is signing up for a custom build and a licensing conversation, not a dependency line change.
FFmpeg 9.0.1 was released on 12 August 2026 and is described as the current stable release in the 9.0 branch [14], with an extensive set of stability, correctness, security, decoder, demuxer, GPU, streaming and format fixes on top of 9.0 [13]. The security fixes are not enumerated in the announcement [13], so treat that as a reason to read upstream release notes before deciding how urgent your rebuild is.
Watch for the per-platform soname list in the Extended build's own release artefacts, and for which packaged configurations actually enable CUDA, Vulkan and AMF paths versus requiring you to compile them yourself [12].
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
Hardware features in FFmpegKit Extended are build-dependent; the project provides dedicated Video+Hardware and Full configurations and documents CUDA/NVDEC/NVENC and other hardware integrations as requiring custom deployments with non-free libraries enabled.
FFmpegKit Extended is moving from FFmpeg 8.1.2 to FFmpeg 9.0.1 "Lei", giving Flutter and React Native applications access to FFmpeg 9 through the same FFmpeg, FFprobe and FFplay command execution model already exposed by the wrapper.
The upgrade moves FFmpeg's primary libraries to new major ABI versions, including libavcodec 63, libavformat 63, libavfilter 12, libavutil 61, libswscale 10 and libswresample 7.
For FFmpegKit Extended users, the capabilities remain accessible through familiar FFmpeg commands; the wrapper provides the execution and session layer while FFmpeg provides the media-processing command surface.
Features introduced by FFmpeg 9 can be used from Flutter and React Native by executing the same command arguments normally provided to ffmpeg, ffprobe and ffplay, with no separate media-processing abstraction required.
FFmpeg 9 adds both an animated WebP demuxer and an animated WebP decoder.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Detailed but single-source and project-authored
Every factual element rests on one dev.to post written from the project's own vantage point. The technical specificity is high (exact library major versions, named filters, concrete command lines, explicit build-dependence caveats), which raises internal credibility, but nothing is corroborated by upstream FFmpeg release notes, a repository reference, or a second publisher. Two material items are self-limiting: the 9.0.1 fix set is asserted without enumeration, and the pre-upgrade library versions are absent so the ABI step cannot be sized from the material.
Release shipped, no downstream usage evidence
The only adoption facts available are two release events: the upstream FFmpeg 9.0.1 release and the wrapper's upgrade to it. There is no download, dependency, deployment, benchmark or user disclosure evidence in the supplied material, and the most consequential capabilities are gated behind Video+Hardware or Full build configurations that no source shows anyone running.
Feature list runs ahead of what an upgrade actually delivers
The post presents FFmpeg 9's GPU, AMF, Vulkan and ONNX Runtime additions as things applications 'gain', while its own caveats state these exist only in Video+Hardware or Full configurations, some needing custom deployments with non-free libraries. Framing new-major-version libraries as an access story rather than a rebuild story also understates the migration cost, and the unenumerated security/stability fixes are asserted more strongly than they are shown. The overstatement is moderate rather than severe because the caveats are printed in the same article and the command-level claims are concrete.
Project-authored promotional changelog
The single source is a dev.to post published under the wrapper maintainer's own account and reads as project promotion for FFmpegKit Extended: it repeatedly contrasts the wrapper favourably with 'limited media API' alternatives, showcases its build tiers, and lists features an adopter would gain. That is a direct interest in adoption of the software being described, with no adversarial or independent review present in the cluster.
Coherent single account, unverified externally
Confidence is limited by structure rather than internal quality: one publisher, one interested author, no corroboration, and no adoption measurement. The specific, checkable technical details and explicit build caveats support moderate confidence in the descriptive facts, while the aggregate fix claims and absent prior library versions leave the operationally important parts unverifiable from the supplied material.
build
Deltix's iOS agent only pays off if the successful run survives as a regression test1 distinct publisher
build
Pricing the three routes to shipping iOS without a Mac, honestly1 distinct publisher
build
Every viewer hits your HLS key endpoint in the same second, and almost nobody tests it1 distinct publisher
build
Two timeout numbers, not new code, fixed a nightly job that failed 2-3 mornings a week1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 20, 2026