FFmpeg incorpora multihilo en la CLI como su "refactorización más compleja" en décadas

Artículo original ↗ Discusión en Hacker News ↗

La interfaz de línea de comandos de FFmpeg acaba de ganar soporte de multihilo de extremo a extremo en lo que los contribuyentes describen como su refactorización más compleja en décadas, permitiendo que distintas etapas del pipeline multimedia (E/S, filtros, codificación) se ejecuten en paralelo en lugar de casi siempre en secuencia. Los comentaristas exploran dónde importará esto en la práctica y dónde no, contrastando la codificación por lotes/en la nube a escala con flujos de trabajo puntuales o sensibles a la latencia, y señalando que muchos códecs individuales ya eran multihilo. El cambio también provoca un debate más amplio sobre lo difíciles que son realmente las refactorizaciones de concurrencia, si herramientas como los LLM podrían automatizar ese trabajo en el futuro y cómo se compara FFmpeg con alternativas como VapourSynth o las pilas de codificación a gran escala personalizadas usadas por Netflix y YouTube.

IA, LLM y refactorización de código

  • Gran parte del hilo debate si los futuros LLM podrían realizar refactorizaciones complejas como la nueva reforma multihilo de la CLI de ffmpeg.
  • Los defensores dicen:
    • GPT-4 actual ya es útil para refactorizaciones pequeñas (p. ej., desduplicar componentes de React, convertir scripts secuenciales en formas paralelas).
    • La principal limitación es el tamaño del contexto; con ventanas más grandes y automatización en torno a las pruebas, los LLM podrían manejar bases de código mucho mayores.
    • La refactorización está bien definida (transformaciones que preservan el comportamiento), lo que la convierte en un buen caso de uso para herramientas automatizadas.
  • Los escépticos argumentan:
    • Los LLM carecen de una “comprensión” real y tienen dificultades con código no trivial, hecho a medida o intensivo en concurrencia.
    • A menudo producen código plausible pero incorrecto, especialmente fuera de la distribución de entrenamiento.
    • Las refactorizaciones complejas de concurrencia y el trabajo de rendimiento requieren un razonamiento semántico y matemático más profundo que una limpieza basada en patrones.
  • Algunos sugieren combinar LLM con herramientas existentes (p. ej., sistemas de parches semánticos) en lugar de depender solo de los LLM.

Qué es realmente este cambio de multihilo

  • Muchos códecs (H.264, etc.) ya eran multihilo; esta refactorización paraleliza el pipeline de ffmpeg en sí (lectura, decodificación, filtrado, codificación, escritura) para que las etapas puedan ejecutarse concurrentemente.
  • Las mayores ganancias esperadas: grafos de filtros complejos y configuraciones con múltiples salidas; menos en transcodificaciones simples de entrada única y salida única.
  • En el hilo aparece cierta confusión sobre si esto afecta a códecs concretos (p. ej., MP3/LAME); varios comentarios señalan que muchos códecs antiguos no están bien adaptados a una codificación multihilo eficiente.

Valor práctico: nube vs. individuos

  • Un lado: los servicios a gran escala (estilo Netflix/YouTube) ya logran utilizar varios núcleos ejecutando muchos procesos de ffmpeg; el multihilo en la CLI añade complejidad para poca ganancia a esa escala.
  • El otro lado: para usuarios individuales o servicios pequeños que ejecutan pocos trabajos concurrentes, un proceso único de ffmpeg más rápido es muy valioso (p. ej., codificaciones puntuales más rápidas, pipelines de CI, streaming de escritorio).

Pipelines alternativos y paralelismo por fragmentos

  • Algunos describen haber usado VapourSynth, gstreamer y herramientas como av1an para obtener durante años paralelismo por hilo o por escena/fragmento.
  • Discusión sobre dividir el trabajo por segmentos de keyframes frente al threading intra-frame:
    • El paralelismo por fragmentos puede mejorar la codificación offline y se usa en algunos pipelines, pero añade latencia y complejidad para streaming en vivo o de baja latencia.
    • Se destacan las compensaciones entre calidad, latencia y utilización de CPU; no hay un consenso claro sobre el “mejor” enfoque.

Notas sobre el proceso del proyecto y el ecosistema

  • La refactorización fue grande (cientos de commits) y se mantuvo mediante parches al estilo de lista de correo, en lugar de flujos de trabajo modernos con PR.
  • Algunos lo ven como “a la antigua”, pero lo aceptan como parte de proyectos de larga vida como ffmpeg.