SYSTEM Cited by 1 source

FFmpeg¶

Definition¶

FFmpeg is the open-source command-line multimedia toolchain for decoding, encoding, transcoding, muxing, demuxing, streaming, filtering, and analysing audio and video. A single binary (ffmpeg) can orchestrate arbitrary pipelines of demuxers → decoders → filters → encoders → muxers, supporting the overwhelming majority of codecs and container formats in production use.

The project has 25+ years of active development and is the de-facto industry standard for media processing, used inside every major video platform's pipeline and as a library ([libavcodec]/[libavformat]) underneath countless applications (Source: sources/2026-03-09-meta-ffmpeg-at-meta-media-processing-at-scale).

Meta's use at scale¶

Meta executes ffmpeg and its sister utility ffprobe tens of billions of times per day, and processes over 1 billion video uploads daily. Each upload kicks off multiple FFmpeg invocations to produce the DASH encoding ladder, making per-process efficiency a fleet-level architectural concern (Source: sources/2026-03-09-meta-ffmpeg-at-meta-media-processing-at-scale).

Threaded multi-lane transcoding (6.0 → 8.0)¶

FFmpeg historically executed each encoder serially per frame when multiple encoders were attached to the same command, even though individual encoders were internally multi-threaded. Meta's internal fork added per-frame encoder parallelism — all encoders processing the same frame in parallel — as its headline optimisation, and this was the feature that kept Meta on a private fork for years.

Starting in FFmpeg 6.0 and completed in FFmpeg 8.0, upstream FFmpeg developers (with contributions from Meta, FFlabs, and VideoLAN) delivered "the most complex refactoring of FFmpeg in decades" to bring efficient threading into the upstream codebase. This closed the gap that motivated Meta's fork. See patterns/deduplicate-decode-across-encoder-lanes.

In-loop decoding for real-time quality metrics (7.0+)¶

FFmpeg has long supported visual quality metrics (PSNR, SSIM, VMAF) as a separate post-encode command comparing two existing encodings. For livestreams this doesn't work: quality signals need to be available during the encode.

From FFmpeg 7.0+, FFmpeg supports "in-loop" decoding — inserting a video decoder after each video encoder in a multi-output pipeline. This gives access to frames-after-compression for comparison against frames-before-compression, producing per-lane reference metrics in a single FFmpeg command during the encode. See concepts/in-loop-quality-metrics and patterns/in-loop-decoder-for-realtime-quality-metrics.

Hardware-acceleration APIs¶

FFmpeg supports hardware-accelerated decoding, encoding, and filtering through standard APIs across devices. Named in the Meta post:

NVIDIA NVDEC + NVENC
AMD Unified Video Decoder (UVD)
Intel Quick Sync Video (QSV)
Meta MSVP (Meta-internal only)

This is the hardware-accelerated video codec API primitive: each accelerator implements a standard interface, so pipeline code minimises device-specific flags and common tooling applies across platforms with minimal quirks.

Relationship to Meta's internal fork¶

For "many years" Meta maintained an internal FFmpeg fork to get threaded multi-lane encoding and real-time quality metrics before upstream had either. With both features landed upstream, Meta fully deprecated its internal fork for all DASH VOD and livestreaming pipelines.

MSVP-specific integration patches remain internal — see patterns/keep-infrastructure-specific-patches-internal — because MSVP hardware is Meta-only and upstream developers cannot validate changes without it.

Seen in¶

sources/2026-03-09-meta-ffmpeg-at-meta-media-processing-at-scale — Meta Engineering's 2026-03-09 post on retiring the internal fork and integrating MSVP into upstream hardware APIs.