Meta's FFmpeg at Scale โ Tens of Billions of Executions Per Day
Ditching the internal fork, multi-lane parallel encoding, real-time quality metrics, and custom ASICs
How Meta uses FFmpeg, based on Meta's Engineering Blog.
Tens of Billions Per Day
Meta runs ffmpeg (conversion CLI) and ffprobe (metadata query) tens of billions of times daily. They process over 1 billion video uploads per day, encoding each into multiple resolutions, codecs, and quality levels for DASH playback.
The Internal Fork Problem
Meta ran an internal FFmpeg fork for years because upstream lacked features they needed:
Thread-based multi-lane encoding
Real-time quality metric calculation
But the fork diverged further from upstream over time. New codec and format support only landed upstream, and rebasing kept causing regressions. They needed upstream's latest to handle the diverse formats users upload.
They collaborated with FFlabs and VideoLAN to fully retire the internal fork and switch to upstream only.
Multi-Lane Transcoding
DASH playback requires encoding each video into multiple resolutions, codecs, framerates, and quality levels. The app's video player switches encodings in real-time based on network conditions.
The simplest approach runs each lane as a separate FFmpeg process. But this repeats decoding per lane and adds per-process startup overhead.
Decoding once in a single FFmpeg command and distributing to each encoder eliminates decode duplication and reduces process overhead to one. At 1B+ uploads daily, per-process savings compound massively.
Parallel Encoding Threading
Stock FFmpeg ran multiple encoders serially per frame. Meta's fork ran all encoder instances in parallel.
FFmpeg developers (including FFlabs, VideoLAN) implemented more efficient threading starting in FFmpeg 6.0, completed in 8.0. Directly influenced by Meta's fork design, it's recorded as the most complex FFmpeg refactoring in decades.
This improvement benefits all FFmpeg users, not just Meta.
Real-Time Quality Metrics
Quality metrics like PSNR, SSIM, VMAF quantify compression quality loss. Stock FFmpeg calculated these post-encoding in a separate command. Livestreaming needs real-time calculation.
Meta's solution: insert a decoder after each output lane's encoder. Decode the encoded frame and compare with the original โ this yields per-lane quality metrics in real-time within a single FFmpeg command.
FFmpeg 7.0 enabled "in-loop" decoding through FFlabs and VideoLAN contributions, fully eliminating fork dependency for this feature.
Custom ASIC โ MSVP
Meta designed MSVP (Meta Scalable Video Processor), a custom video transcoding ASIC. It integrates through FFmpeg's standard hardware API (same interface as NVIDIA NVDEC/NVENC, Intel QSV, etc.).
Software and hardware pipelines work through identical FFmpeg CLI, maintaining cross-pipeline consistency.
MSVP is internal-only hardware, so these patches stay internal.
Upstream Contribution Criteria
Meta's criteria is clear:
Universal improvements โ upstream (multi-lane threading, real-time quality metrics)
Meta-specific infrastructure โ internal patches (MSVP support)
Continued investment in FFmpeg's 25+ year codebase strengthens both Meta's platform and the broader ecosystem.
How It Works
Meta runs ffmpeg/ffprobe tens of billions of times daily, encoding 1B+ videos for DASH
Single command decodes once โ distributes to multiple encoders, eliminating decode duplication
Parallel threading in FFmpeg 6.0-8.0 was based on Meta fork design
Insert decoder after encoder for real-time quality metrics (PSNR/SSIM/VMAF)
Custom ASIC (MSVP) integrated via FFmpeg standard hardware API
Universal improvements go upstream, Meta-specific patches stay internal