๐Ÿ“ก

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

1

Meta runs ffmpeg/ffprobe tens of billions of times daily, encoding 1B+ videos for DASH

2

Single command decodes once โ†’ distributes to multiple encoders, eliminating decode duplication

3

Parallel threading in FFmpeg 6.0-8.0 was based on Meta fork design

4

Insert decoder after encoder for real-time quality metrics (PSNR/SSIM/VMAF)

5

Custom ASIC (MSVP) integrated via FFmpeg standard hardware API

6

Universal improvements go upstream, Meta-specific patches stay internal

Use Cases

Large-scale VOD pipeline โ€” simultaneous multi-resolution, multi-codec encoding from single input Livestreaming โ€” real-time quality monitoring via in-loop decoding Hardware acceleration โ€” integrating custom ASICs into existing pipelines via standard API