El uso de FFmpeg en Meta: el secreto del procesamiento de medios a gran escala

• Meta ejecuta decenas de miles de millones de veces FFmpeg al día y logró migrar por completo de su fork interno a FFmpeg upstream
• Para cerrar la brecha funcional entre el fork interno y la versión open source, colaboró con FFlabs y VideoLAN para implementar en upstream codificación paralela multirriel y funciones de métricas de calidad en tiempo real
• Procesa más de mil millones de cargas de video al día y realiza codificación en múltiples resoluciones y códecs para reproducción DASH con una sola línea de comandos de FFmpeg
• La estructura eficiente de threading implementada entre FFmpeg 6.0 y 8.0 se basa en el diseño de Meta y ofrece mejoras de eficiencia de codificación para todos los usuarios
• Integró su ASIC de diseño propio, MSVP (Meta Scalable Video Processor), mediante la API estándar de hardware de FFmpeg para asegurar consistencia entre los pipelines de software y hardware
• Mediante una inversión continua en FFmpeg, desarrollado durante más de 25 años, Meta refuerza al mismo tiempo nuevas experiencias de video y la estabilidad de su plataforma

---

El rol de FFmpeg y el reto de Meta

• FFmpeg es una herramienta estándar de la industria para procesamiento de medios que soporta diversos códecs de audio y video, así como formatos contenedor, y permite editar y transformar medios mediante cadenas complejas de filtros
• Meta ejecuta los binarios ffmpeg (CLI principal) y ffprobe (utilidad para consultar propiedades de archivos multimedia) decenas de miles de millones de veces al día, y tiene requisitos adicionales que van más allá del procesamiento de archivos individuales
• Durante mucho tiempo dependió de un fork interno para implementar por su cuenta funciones que en ese momento no existían en upstream, como codificación multirriel basada en hilos y cálculo de métricas de calidad en tiempo real

La divergencia del fork interno y la necesidad de volver a upstream

• A medida que el fork interno se fue separando considerablemente de FFmpeg upstream, la brecha entre conjuntos de funciones creció gradualmente
• Al mismo tiempo, las nuevas versiones de FFmpeg ofrecían soporte para nuevos códecs y formatos de archivo, además de mejoras de estabilidad, por lo que también era necesario soportar la versión open source más reciente para aceptar sin interrupciones la diversidad de videos que suben los usuarios
• Como se volvió difícil evitar regresiones al hacer rebase de los cambios internos, Meta colaboró con desarrolladores de FFmpeg, FFlabs y VideoLAN para eliminar por completo el fork interno y pasar a usar solo la versión upstream

Construcción de transcodificación multirriel eficiente (VOD y livestreaming)

• Cuando un usuario sube un video, se genera un conjunto de múltiples codificaciones para reproducción DASH (Dynamic Adaptive Streaming over HTTP), con codificaciones distintas en resolución, códec, frame rate y nivel de calidad
  • El reproductor de video de la app puede cambiar en tiempo real entre codificaciones según señales como el estado de la red
• La forma más simple es procesar cada riel secuencialmente con una línea de comandos de FFmpeg independiente, pero incluso al ejecutar en paralelo cada proceso realiza trabajo duplicado (decodificación repetida, overhead de arranque del proceso), lo que resulta ineficiente
• Si en una sola línea de comandos de FFmpeg los frames se decodifican una sola vez y luego se envían a cada codificador de salida, es posible eliminar la duplicación de decodificación y reducir el overhead de arranque del proceso
  • Como se procesan más de mil millones de cargas de video al día, el ahorro computacional por proceso se traduce en una gran mejora de eficiencia total
• El fork interno de Meta añadía además optimizaciones para codificación de video paralela: el FFmpeg tradicional ejecutaba en serie por frame cuando usaba varios codificadores, pero Meta hacía correr en paralelo todas las instancias del codificador para lograr mayor paralelismo
• Gracias a contribuciones de desarrolladores de FFmpeg, incluidos FFlabs y VideoLAN, desde FFmpeg 6.0 comenzó a implementarse un threading más eficiente y quedó completado en 8.0
  • Recibió una influencia directa del diseño del fork interno de Meta y quedó registrado como la refactorización más compleja de FFmpeg en décadas
  • Ofrece una codificación más eficiente para todos los usuarios de FFmpeg

Métricas de calidad en tiempo real (livestreaming)

• Las métricas de calidad visual expresan numéricamente la calidad perceptual de un medio y se usan para cuantificar la pérdida de calidad causada por la compresión
  • Métricas de referencia: comparan la codificación original con la codificación distorsionada
  • Métricas sin referencia: evalúan la calidad sin un original
• FFmpeg puede calcular métricas de calidad como PSNR, SSIM y VMAF usando dos codificaciones existentes en una línea de comandos separada después de terminar la codificación, pero en livestreaming se necesita cálculo en tiempo real
• Al insertar un decodificador de video detrás del codificador de video de cada riel de salida, se obtiene el bitmap de frames después de aplicar compresión y se compara con el frame previo a la compresión, lo que permite calcular en tiempo real las métricas de calidad de cada riel de codificación dentro de una sola línea de comandos de FFmpeg
• Desde FFmpeg 7.0, gracias a contribuciones de desarrolladores de FFlabs y VideoLAN, se habilitó la decodificación in-loop, eliminando por completo la dependencia del fork interno para esta funcionalidad

Criterios para contribuir a upstream y parches de uso interno

• Funciones como las métricas de calidad en tiempo real y el threading eficiente mejoran la eficiencia en distintos pipelines basados en FFmpeg dentro y fuera de Meta, por lo que se aportaron a upstream
• En cambio, los parches altamente especializados para la infraestructura de Meta y difíciles de generalizar se mantienen solo a nivel interno
• FFmpeg soporta por API estándar decodificación, codificación y filtrado acelerados por hardware como NVIDIA NVDEC/NVENC, AMD UVD e Intel QSV
• El ASIC propio de Meta para transcodificación de video, MSVP (Meta Scalable Video Processor), también añadió soporte mediante esa misma API estándar, permitiendo usar herramientas comunes en diversas plataformas de hardware
  • Como MSVP solo se usa dentro de la infraestructura de Meta, los desarrolladores externos de FFmpeg no tienen acceso al hardware para probarlo y validarlo, por lo que se mantiene como parche interno
  • Al hacer rebase sobre la versión más reciente de FFmpeg, se garantiza solidez y exactitud mediante una validación exhaustiva

Inversión continua en FFmpeg

• Con las funciones de codificación multirriel y métricas de calidad en tiempo real, se logró eliminar por completo el fork interno en todos los pipelines de VOD y livestreaming
• Gracias a la API estándar de hardware de FFmpeg, fue posible soportar en paralelo el ASIC MSVP y los pipelines basados en software con fricción mínima
• Meta planea seguir invirtiendo en FFmpeg, desarrollado activamente durante más de 25 años, a través de alianzas con desarrolladores open source, para beneficiar a Meta, a la industria y a los usuarios

[GN⁺]

Comentarios en Hacker News

• A medida que el fork interno se fue quedando cada vez más obsoleto, colaboramos con los desarrolladores de FFmpeg para integrar las funciones necesarias en FFmpeg oficial
  Gracias a eso, pudimos eliminar por completo la versión interna y operar solo con la versión upstream
  Algunos dicen que “podrían haber contribuido más”, pero la esencia del open source es que todos comparten los beneficios

  • Creo que no se puede negar que Meta contribuye a la comunidad
    Ya nos hemos beneficiado de muchísimos proyectos como React, React Native y otros
  • Pero si estas funciones surgieron de las necesidades de empresas gigantescas, la mayoría de los usuarios no va a notar realmente ese beneficio
    Al final, este tipo de estructura parece favorecer solo a quienes ya tienen poder
  • Está claro que es un cambio positivo, pero detrás hubo una etapa en la que se priorizó el beneficio interno
    Aun así, el hecho de que Meta haya liberado tantas cosas al ecosistema open source sí funciona como un diferenciador en la industria
  • No hay que olvidar que ninguna big tech habría podido existir sin una base de open source
  • Contribuir al open source está bien, pero no me gustó el tono de la publicación del blog
    Expresiones como “recién ahora lo integramos upstream” daban la impresión de querer maquillar las carencias del pasado
    Mezclar lenguaje de marketing en un blog técnico resulta molesto desde la perspectiva del lector

• Ojalá que Fabrice Bellard reciba una compensación suficiente cuando se retire
  Su software les ha hecho ganar dinero a muchísimas empresas

• Está bien que las nuevas versiones de FFmpeg ahora soporten varios códecs y formatos,
  pero si Meta lo ejecuta miles de millones de veces al día, me pregunto si ha participado de forma sostenida en estas mejoras

  • [comentario eliminado]

• Que se ejecute decenas de miles de millones de veces al día es una escala impresionante
  Yo noto el overhead incluso cuando solo corro unos miles de trabajos diarios de ensamblado automático de video
  La función single-decode multi-output redujo el tiempo de procesamiento en un 40%

  • A esta escala, el uso de RAM también debe ser inimaginable
    Por suerte, la caída reciente en los precios de la memoria ha hecho que la relación costo-beneficio de mejorar open source sea todavía mayor

• El enfoque de aumentar la paralelización ejecutando instancias del codificador en paralelo es razonable
  Pero a mí me gustaría ver una función de paralelización en el eje temporal (time-axis parallelization)
  Si se divide el video de entrada por keyframes y se codifica en paralelo, se podría aumentar la velocidad sin perder calidad

  • Pero, ¿se puede predecir de antemano la ubicación de los keyframes?
    Normalmente el codificador los coloca de forma dinámica para maximizar la eficiencia, así que el particionado previo podría ser difícil
  • Me pregunto si el análisis de movimiento que hace el codificador al analizar cuadros P/B podría calcularse una sola vez y reutilizarse en varias codificaciones

• Gracias al equipo de Meta por contribuir a ffmpeg y ffprobe
  Ojalá también consideren apoyo financiero para calidad de código, documentación y eventos comunitarios en el futuro

• La frase “el fork interno se fue quedando cada vez más viejo” me resultó muy identificable
  Como dato, en FFmpeg 8 el mapeo de color entre HDR y SDR ya se maneja perfectamente

  • Antes sufría por el problema de copia automática de metadatos, así que da mucho gusto que ya esté resuelto
  • Qué bueno saber de esto después de tanto tiempo; el avance es impresionante

• Me parece interesante la noticia de que el Sovereign Tech Fund de Alemania hizo una donación a FFmpeg

  • El STF de Alemania donó unos 150 mil dólares, pero solo un año del costo laboral de un ingeniero de Meta ya sería más del doble
    Probablemente Meta tenga un equipo dedicado a codificación de medios y esté aportando contribuciones con un valor anual de más de 1 millón de dólares
  • Pero la cuenta oficial de FFmpeg mencionó que “agradecen el apoyo de Meta, pero no está en un nivel sostenible”
    Ver tuit relacionado
  • Me da curiosidad cuánto donó realmente Meta
    Según dicen, el STF de Alemania aportó €157,580 en 2024/2025
  • Es un poco irónico que Meta gane miles de millones de dólares y aun así done menos que un fondo estatal
  • [comentario eliminado]

• Por suerte, los servidores de FFmpeg solo están procesando contenido liviano, así que siguen aguantando
  Si fueran videos pesados, ya se habrían sobrecargado

• El mismo post de HN también se publicó hace 6 días
  No entiendo por qué dan downvote por poner este enlace

  • Según tengo entendido, los reposts están permitidos siempre que no los publique repetidamente el mismo usuario
  • [comentario eliminado]