Why Meta Rebuilt Its FFmpeg Strategy Around Upstream
Meta runs the ffmpeg and ffprobe binaries tens of billions of times daily, processing over 1 billion video uploads a day. That workload demanded scaling features that FFmpeg didn't provide until recently—features that Meta originally built into its own fork. But as the fork diverged further from upstream, rebasing internal changes without regressions became a growing burden, and Meta missed new codec support and reliability fixes landing in newer FFmpeg releases.
The decision to move back to upstream was guided by coordination with FFmpeg developers, FFlabs, and VideoLAN. Meta needed two capabilities from vanila FFmpeg before it could retire its internal fork entirely: efficient multi-output transcoding with parallel encoder execution, and real-time visual quality metrics.
Parallel Multi-Lane Encoding Without Redundant Work
For video uploads, Meta generates multiple DASH-adaptive encodings from a single source. Each lane may differ in resolution, codec, frame rate, or quality level. Running separate FFmpeg commands per lane—even in parallel—duplicates decoding and process startup work. Running multiple outputs in a single command deduplicates that overhead, but older FFmpeg versions serialized each encoder instance for a given frame, even though individual encoders were internally multi-threaded. That left parallelism on the table.
Meta's fork solved this with parallelized video encoding across output lanes. The fix landed upstream in incremental steps starting with FFmpeg 6.0, with final touches arriving in 8.0. The change, described as the most complex refactoring of FFmpeg in decades, was directly informed by Meta's fork design and now serves all FFmpeg users.
Migrating off the fork still required upstream support for compute quality metrics during encoding—not after. FFmpeg could measure PSNR, SSIM, and VMAF by running a separate command against two completed encodings. That's acceptable for offline or VOD use, but not for livestreaming, where quality needs to be measured in real time as frames are compressed.
With so-called "in-loop" decoding, available upstream starting with FFmpeg 7.0, a decoder can be inserted after each lane's encoder. The decoder produces compressed bitmaps, which are compared against the pre-compression frames to yield a real-time quality metric per lane within a single FFmpeg command. This closed the second gap that previously required Meta’s internal fork.
Keeping Internal Patches Where They Belong
Meta upstreams changes when they benefit the community broadly, but some patches are too infrastructure-specific to contribute. The company's support for the Meta Scalable Video Processor (MSVP), a custom ASIC for video transcoding, is one such case. It was implemented through FFmpeg's standard hardware-acceleration APIs—the same interfaces used for NVIDIA NVDEC/NVENC, AMD UVD, and Intel QSV—so most tooling works without device-specific flags. But since MSVP hardware only exists inside Meta's infrastructure, upstream developers would have no way to test or validate that code. Meta maintains and rebases these internal patches itself, using extensive validation to keep upgrades safe.
A Deprecated Fork and a Long-Term Upstream Bet
With efficient multi-lane encoding and real-time quality metrics now available upstream, Meta fully deprecated its internal FFmpeg fork for all VOD and livestreaming pipelines. The company continues to invest in FFmpeg together with open-source developers, citing over 25 years of active development and noting that improvements in resource use, codec support, and reliability directly translate to better media experiences on its platforms.
