FFmpeg incorpora multihilo en la CLI con el "refactor más complejo" en décadas

Soporte de multihilo en la CLI de FFmpeg

• La interfaz de línea de comandos (CLI) de FFmpeg ya tiene soporte para multihilo tras su integración en el Git de FFmpeg.
• Este cambio se realizó antes del lanzamiento de FFmpeg 7.0 a inicios del próximo año, y representa una mejora importante para este relevante proyecto de código abierto ampliamente usado para la transcodificación de video.
• Ahora que los procesadores multinúcleo son algo común, esta mejora resulta muy beneficiosa.

Un trabajo de refactorización complejo

• En una presentación técnica reciente, los desarrolladores de FFmpeg describieron este trabajo de multihilo como "uno de los refactors más complejos realizados en la CLI de FFmpeg en décadas".
• Los desarrolladores pidieron a los usuarios que lo prueben y los animaron a reportar cualquier problema encontrado en FFmpeg Trac.

Cambios técnicos implementados

• El parche integrado incluye la incorporación de una infraestructura de programación de transcodificación con reconocimiento de hilos, el traslado de la codificación a un hilo separado, además de varios otros cambios de bajo nivel.
• Convertir FFmpeg a una arquitectura con hilos significa que cada componente (demuxer, decoder, filtro, encoder, muxer) ya se ejecutaba en su propio hilo, pero ahora realmente podrá ejecutarse en paralelo.

La opinión de GN⁺

• El soporte de multihilo en FFmpeg es un avance importante que puede mejorar considerablemente la eficiencia de las tareas de transcodificación de video.
• Este complejo trabajo de refactorización planteó muchos desafíos para los desarrolladores, y demuestra que FFmpeg sigue adaptándose y evolucionando para los entornos de cómputo modernos.
• Será interesante para usuarios y desarrolladores observar qué impacto tendrá este cambio en el rendimiento real.

[GN⁺]

Comentarios en Hacker News

• Teoría sobre la optimización de multithreading/multiprocessing

  • En el pasado, leer, procesar y renderizar una sola imagen tomaba bastante tiempo, pero con los avances en hardware y software ahora es mucho más rápido.
  • Antes era eficiente que varios workers procesaran un solo frame, pero hoy un solo worker puede procesar frames de forma más eficiente que coordinando varios workers.
  • Los sistemas modernos tienen un entorno completamente distinto al de cuando FFmpeg fue creado por primera vez, así que hace falta replantear cómo definir, programar, distribuir y rastrear la carga de trabajo antes de combinarla en el resultado final.
  • Elogia al equipo de FFmpeg por aceptar este desafío. FFmpeg es la cúspide de la infraestructura de código abierto, un elemento esencial para construir la civilización.

• Grabación de la charla del evento VDD@Dublin

  • Estaba buscando la grabación de la charla, pero no era fácil encontrarla ni en el sitio del autor ni aquí.
  • Actualización: ¡La encontró en YouTube!

• Reflexión sobre mejorar el rendimiento multicore

  • Los codificadores actuales usan varios hilos para procesar el mismo frame al mismo tiempo. Lo habitual es dividir el frame en varias regiones y que cada hilo procese una región específica.
  • Como alternativa, propone procesar de forma independiente los segmentos entre keyframes. Este método puede paralelizar los códecs de una manera general y eficiente, sin la pérdida de eficiencia de compresión causada por dividir frames en regiones ni el overhead de comunicación entre hilos.
  • El problema de este método es que hay que cargar en memoria frames correspondientes a N*ciclo de keyframes, y existe un overhead adicional de memoria necesario para codificar N frames.
  • Sin embargo, en muchos casos estos inconvenientes no parecen ser un gran problema. En la mayoría de los casos, se puede tolerar usar mucha RAM y generar salida con intervalos fijos entre keyframes.
  • Al combinar el procesamiento paralelo dentro del frame con el procesamiento paralelo por segmentos de keyframes, se puede lograr un alto nivel de paralelismo minimizando la pérdida de calidad.

• El desafío del rebase continuo

  • Hacer rebase continuamente sobre los cambios que llegaban cada día fue un desafío considerable.
  • Ahora que ya se integró en FFmpeg, el trabajo será mucho más fácil de aquí en adelante.
  • Es una gran victoria y contribuirá de forma importante a mejorar la velocidad.

• Expectativa de mejora en el tiempo de inicio del streaming del búfer de display virtual en FFmpeg

  • En el proyecto LLMStack usan FFmpeg para transmitir video del navegador.
  • Actualmente hay una latencia perceptible al iniciar el pipeline cada vez que se invoca cada herramienta.
  • Las mejoras en FFmpeg definitivamente ayudarán con este trabajo de optimización.

• Promoción de un curso sobre la API de FFmpeg en C

  • Promociona un curso en Udemy donde enseña la API de FFmpeg en C.

• Curiosidad sobre el codebase de FFmpeg

  • No conoce bien el codebase de FFmpeg, pero le intriga cómo pudieron avanzar con los cambios poco a poco sin un commit gigantesco.
  • Según la presentación, hubo 700 commits, y se pregunta si fue una rama separada o si se fue integrando gradualmente al proyecto.

• Perspectiva de un operador de servicios en la nube

  • Si operas un servicio en la nube como Netflix, ya estás ejecutando miles de procesos de FFmpeg en cada máquina, así que en esencia ya es una carga multicore.

• Experiencia compartida con el procesamiento de filtros en hilos de VapourSynth

  • Lleva casi 10 años disfrutando del procesamiento de filtros en hilos en VapourSynth.
  • Esta mejora de FFmpeg también es excelente, pero no cambiará mucho el flujo de trabajo de preprocesamiento con VapourSynth + codificación con av1an para codificación de video de “calidad”.

• Pregunta sobre el soporte multicore de FFmpeg

  • Se pregunta si FFmpeg ahora puede usar multicore con todos los códecs incluidos.
  • Usa FFmpeg para codificar MP3 con LAME para un servicio de hosting de audio, y sería bueno poder mejorar el tiempo de codificación de archivos largos.