FFmpeg introduce una canalización de transcodificación multihilo

 (ffmpeg.org)
2 puntos por GN⁺ 2023-11-07 | 1 comentarios | Compartir por WhatsApp
  • La transcodificación multihilo del CLI de FFmpeg se presentó en su primera forma “totalmente funcional” tras cerca de 2 años de trabajo y más de 700 commits preparatorios
  • Como el alcance de los cambios es grande, todavía existe la posibilidad de que algunas funciones se hayan roto, y antes de una fusión real la prueba y revisión siguen siendo tareas clave
  • -fix_sub_duration_heartbeat tiene dificultades para evitar un comportamiento no determinista en ejecución asíncrona debido a supuestos de sincronización entre el decodificador y el codificador/muxer
  • La sobrecarga del threading suele ser pequeña, pero en trabajos con muy poca carga por paquete el costo puede hacerse notar más que la ganancia de rendimiento
  • Si el cuello de botella no está concentrado en un solo componente y cada componente no está ya multihilado, en entornos multinúcleo pueden mejorar mucho el uso de CPU y el tiempo real de procesamiento

Puntos clave del parche de multithreading para el CLI de FFmpeg

  • Tras cerca de 2 años de trabajo y más de 700 commits preparatorios, se publicó como serie de parches la primera versión “fully functional” del CLI multihilo de FFmpeg
  • Dado el tamaño de los cambios, puede haber roturas aún no detectadas, por lo que se necesitan pruebas y revisión basadas en casos de uso reales
  • En general la sobrecarga del threading es baja, pero en cargas de trabajo con muy poco trabajo por paquete esa sobrecarga puede volverse significativa
  • Si la transcodificación no está dominada por un solo componente y cada componente no está ya saturado por su propio multithreading, en sistemas multinúcleo pueden mejorar el uso de CPU y el tiempo de ejecución

Restricciones de funcionamiento y problemas conocidos

  • La opción -fix_sub_duration_heartbeat asume en la estructura actual una sincronización entre componentes separados
    • El flujo objetivo es una sincronización desde el codificador/muxer hacia el decodificador
    • Si cada componente se ejecuta de forma asíncrona, el comportamiento se vuelve inherentemente no determinista
    • Incluso ahora el comportamiento es difícil de predecir, pero si se ejecuta con la misma opción, el resultado entre ejecuciones es determinista
    • En el parche 16/24 esta opción se desactiva, y se necesita una mejor forma de manejarla

Composición de la serie de 24 parches

  • La serie está compuesta por un total de 24 parches
    • 01-09/24 son cambios preparatorios y podrían enviarse antes que el resto de la serie
    • 10-17/24 trasladan la codificación y el filtrado a hilos y realizan los cambios preparatorios necesarios
      • El threading en esta etapa es un threading “falso” en el que el hilo principal espera a que otros hilos terminen, así que no hay ejecución realmente paralela
      • Como la sobrecarga temporal puede ser grande o algunos casos límite podrían romperse, conviene enviarlos una vez que esté lista la serie completa
    • 18/24 es el parche individual más grande y añade el scheduler de transcodificación, aunque en ese punto todavía no funciona de verdad
    • 19-24/24 convierten los componentes individuales para que usen el scheduler
      • Están divididos para revisión, pero en el envío final deberían combinarse
  • El material relacionado puede verse en el video reciente de la charla de VDD y en la rama ffmpeg_threading

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-11-07
Comentarios de Hacker News

  • En un servidor ARM de 4 núcleos, fue casi 2 veces más rápido, y no parece haber mucho overhead por la paralelización
    ffmpeg_threading/ffmpeg tardó 7.771 segundos, mientras que el ffmpeg tradicional tardó 13.841 segundos, y el uso de CPU fue de 218% y 114% respectivamente

    • Aquí no se está usando aceleración por hardware del lado de la decodificación, y también se eliminó la salida de video
      Me pregunto qué pasaría si en una tarjeta NVIDIA se usara aceleración por hardware tanto para decodificación como para codificación de video: ffmpeg -hwaccel cuda -i $inputFile -codec:a copy -codec:v hevc_nvenc $output
    • Me pregunto qué parte se está multithreadizando. La compresión de video ya es multihilo; sobre la descompresión de video no estoy seguro
      El resto del trabajo probablemente tenga un costo relativamente pequeño en términos de rendimiento, así que la mejora es bienvenida, pero espero que el impacto real sea bastante limitado

  • Habría sido mejor enlazar https://ffmpeg.org/pipermail/ffmpeg-devel/2023-November/3165... en vez del tuit
    Al final, el punto central del tuit es justamente ese enlace

    • Ahora simplemente se le dice post. Ya no existe el límite de 280 caracteres, y las publicaciones largas solo aparecen plegadas por defecto

  • Para entender esto, conviene ver la presentación que dio Anton en VideoLAN Dev Days 2023: https://www.youtube.com/watch?v=Z4DS3jiZhfo&t=1221

    • La presentación estuvo buena, y me pregunto qué tenía en mente con dynamic pipelines y “scripting (Lua?)” en la parte de “Future directions”
      Me hace imaginar una dirección con manejo más potente de animaciones de propiedades
    • De verdad me he topado muchísimo con los problemas relacionados con Extras que salen en la diapositiva alrededor del minuto 33
    • Sí quiero ver la presentación, pero la calidad de audio es tan mala que cuesta concentrarse. No entiendo cómo todavía hoy se puede arruinar tanto algo así
    • No entiendo qué parte es difícil de comprender. ¿En el ámbito del transcodificado de video multithread significa otra cosa?

  • El tuit lleva a http://ffmpeg.org/pipermail/ffmpeg-devel/2023-November/31655..., y desde ahí se hace referencia al código https://git.khirnov.net/libav.git/log/?h=ffmpeg_threading

    • El tuit enlaza a la lista de correo, que es la fuente oficial del patchset. Para seguir leyendo, solo hay que elegir “Next in Thread”

  • Me pregunto si esto se aplica automáticamente, o si hay que combinar parámetros de línea de comandos de forma complicada

  • Me pregunto si existe algún software de edición de video que use ffmpeg
    En algún momento pensé en hacer algo que dibujara formas con SVG y usara ffmpeg, o que le agregara una UI, o que solo añadiera texto, pero nunca lo empecé
    Avidemux da un poco esa impresión, y el interior de ffmpeg es bastante crudo, así que no parece pensado para que una GUI lo use directamente; por eso un editor basado en eso probablemente sería tosco, raro y difícil de mantener
    Aun así, quizá podría funcionar algo como un editor modular con un visor de pipelines o un generador visual de comandos para la previsualización
    ffmpeg es potente, pero el hecho de que se use solo por línea de comandos le pone barreras a algunos usuarios. Antes escribí un script de Python que tomaba una cantidad aleatoria de clips y hacía un mosaico con el filtro xstack, y no fue nada fácil

  • Ojalá las pequeñas tareas de transcodificación para Plex se vuelvan más rápidas
    Mi tarjeta gráfica no soporta transcodificación por hardware, así que esto me da esperanza

  • Estaba buscando formas de acelerar el transcodificado, y una era la aceleración por GPU, mientras que la otra era aumentar el número de hilos
    Pero ha sido difícil encontrar la cantidad óptima de hilos

    • ¿Por qué no usar optimización de hiperparámetros para encontrar el valor óptimo? Con herramientas como Sherpa o Scikit-optimize podrías recorrer un espacio de búsqueda con número de hilos, tipo de entrada, tipo de CPU y cosas así
    • Para la mayoría de las tareas, basta con ajustar la cantidad de hilos al número de vCPU. Es decir, cuenta cada núcleo con hyperthreading como 2
      Aun así, si es posible, la aceleración por GPU es mucho mejor

  • Me pregunto cuáles son los requisitos de licencia al desplegar ffmpeg a gran escala. ¿En qué casos hay que pagar?

    • “FFmpeg is licensed under the GNU Lesser General Public License (LGPL) version 2.1 or later. However, FFmpeg incorporates several optional parts and optimizations that are covered by the GNU General Public License (GPL) version 2 or later. If those parts get used the GPL applies to all of FFmpeg.”
      http://ffmpeg.org/legal.html
      O sea, es gratis, pero si usas ciertos módulos puede haber problemas al mezclarlo con código privativo
    • Una forma común de usar ffmpeg dentro de software privativo es compilarlo estáticamente y enlazarlo al ejecutable, o hacer que el software privativo invoque un ejecutable separado

  • Da gusto ver que FFmpeg sigue mejorando. Ojalá pronto también veamos soporte para Dolby AC4