FFmpeg 9.0 makes network access safer, but this is not a drop-in upgrade

The FFmpeg project released FFmpeg 9.0 “Lei” on August 4, bringing a major ABI break, the removal of APIs deprecated during the 8.x cycle, and TLS certificate verification enabled by default. Jean-Baptiste Kempf's technical overview of the release documents both breaking changes.

That combination makes this more than a routine codec update. Applications that link against FFmpeg libraries need a rebuild, and code using removed APIs needs migration. Scripts and services that fetch media over HTTPS now reject endpoints with invalid or self-signed certificates unless their configuration deliberately disables verification.

Neither change breaks every FFmpeg workflow. Command-line pipelines that avoid removed options continue without source changes, and properly configured HTTPS services connect as before. Teams that embed FFmpeg, maintain language bindings, or depend on unusual internal endpoints still need to test 9.0 before deployment.

TLS now fails closed by default

FFmpeg supported certificate verification before 9.0, but 9.0 makes it the default for TLS connections. The project's Changelog announced this change for the next major bump, and Kempf's release overview confirms that 9.0 applies it. This is the safer behaviour: a media pipeline must not silently trust a server whose identity cannot be validated.

The new default exposes assumptions that previously went unnoticed. A transcoding worker pulling from an internal service with a self-signed certificate now fails verification. The same applies to a scheduled job hitting an HTTPS endpoint with an incomplete certificate chain.

Disabling verification restores the old behaviour but gives up the protection the new default provides. Correct the endpoint certificate or make the required certificate authority available to the environment running FFmpeg instead.

For operators, this is the part of the release worth checking before deployment. Test the actual URLs used in production and watch for TLS errors rather than assuming a successful local encode covers the network path as well.

Library users have more migration work

Major FFmpeg releases are also where compatibility assumptions become visible. FFmpeg 9.0 increments the major version of all seven libraries: libavutil 61, libavcodec 63, libavformat 63, libavdevice 63, libavfilter 12, libswscale 10, and libswresample 7. That is an ABI break across the entire library set. Software that dynamically or statically links these libraries needs a rebuild and an integration test instead of an untested shared-library replacement.

The practical impact depends on the integration. An application already using supported APIs still needs the rebuild but avoids migration work for removed APIs. Older bindings, plugins, and media applications need source changes when they reference removed identifiers or deprecated calls.

The command-line cleanup is concrete. FFmpeg removed -vsync in favour of -fps_mode, along with -top, -qphist, -filter_complex_script, and -adrift_threshold. It also removed the NPP filters scale_npp, scale2ref_npp, sharpen_npp, and transpose_npp; the new transpose_cuda replaces the last of those without the libnpp dependency. NVENC no longer supports deprecated options, legacy rate-control modes, or Video Codec SDK versions older than 11.1.

The release also adds an animated WebP decoder and demuxer, an ONNX Runtime DNN backend with GPU execution-provider support, new Vulkan and CUDA paths, and several additions around AMD's Advanced Media Framework. Availability depends on the platform, driver, enabled libraries, and build configuration.

That variation surfaced in the r/linux discussion. Commenters focused on what the expanded AMF work means for ordinary Linux installations and whether the ONNX backend makes more machine-learning-based processing practical inside FFmpeg. Those are relevant implementation questions, although the thread does not establish that any particular hardware or packaging combination will work.

FFmpeg 9.0 is therefore a worthwhile upgrade to evaluate, not one to roll out solely because the version number changed. The real test is whether downstream applications rebuild cleanly, production HTTPS inputs still connect securely, and the new acceleration paths work on the hardware and packages a team actually operates.