Lanzamiento de FFmpeg 8.0

 (ffmpeg.org)
2 puntos por GN⁺ 2025-08-23 | 1 comentarios | Compartir por WhatsApp
  • FFmpeg 8.0 "Huffman" agrega códecs basados en cómputo con Vulkan, decodificación y codificación con aceleración por hardware, además de varios formatos de archivo y filtros nuevos
  • La infraestructura fue modernizada por completo, y también se reforzaron el proceso de contribución y la calidad del código
  • También hubo avances importantes en el área de códecs de audio y video, como la estabilización del decodificador VVC, el decodificador xHE-AAC y el soporte para MV-HEVC y LC-EVC
  • Sigue desempeñando un papel central en el avance de la tecnología multimedia de código abierto, con mejoras continuas de funciones y de seguridad

Introducción a FFmpeg

  • FFmpeg es un toolkit completo de procesamiento multimedia de propósito general, una solución flexible y potente para grabar, convertir y transmitir audio y video
  • Con un comando simple como ffmpeg -i input.mp4 output.avi, es posible procesar video y audio

23 de agosto de 2025: lanzamiento de FFmpeg 8.0 "Huffman"

  • Se publicó FFmpeg 8.0 "Huffman". Tras varios retrasos y un proceso de modernización de la infraestructura, se concretó el lanzamiento más amplio hasta la fecha
  • Entre las nuevas funciones se incluyen la incorporación de decodificadores nativos como APV, ProRes RAW, RealVideo 6.0, Sanyo LD-ADPCM y G.728, la ampliación del soporte del decodificador VVC para IBC, ACT y Palette Mode, y códecs basados en cómputo con Vulkan como FFv1 (codificación y decodificación) y ProRes RAW (solo decodificación)
  • Se incorporaron decodificación con aceleración por hardware basada en Vulkan (por ejemplo, VP9, VVC, H264/5) y codificación (AV1, H264/5), además de diversos formatos nuevos (MCC, G.728, Whip, APV) y filtros (colordetect, pad_cuda, scale_d3d11, Whisper, entre otros)
  • También se añadió una nueva familia de decodificadores y codificadores basados en shaders de cómputo que funcionan sobre Vulkan 1.3. Esta arquitectura no requiere aceleradores especiales de hardware y funciona igual que la API hwaccel. Para usar los codificadores es necesario especificar los nuevos codificadores; por ahora solo se admiten FFv1 (codificación y decodificación) y ProRes RAW (decodificación). ProRes (bidireccional) y VC-2 (bidireccional) están en preparación
  • Esta arquitectura solo puede aplicarse a códecs optimizados para decodificación en paralelo, y se espera que en el futuro permita mejoras significativas de rendimiento y nuevos usos, como edición de video no lineal y grabación sin pérdida, en áreas más diversas
  • La infraestructura del proyecto también se actualizó de forma importante. El servidor de la lista de correo fue reemplazado por completo, y ahora se ofrece colaboración de código basada en Forgejo en code.ffmpeg.org
  • Se recomienda a los usuarios actualizar a la versión más reciente

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-08-23
Comentarios en Hacker News

  • Agradecen a los desarrolladores y colaboradores de FFmpeg

    • Siempre han usado FFmpeg cada vez que necesitan automatización de audio/video, y la mayoría de las herramientas de video en línea también usan esta herramienta como motor principal o como un wrapper con UI
    • Hoy también se enteraron de que existe el proyecto FFmpeg.Wasm (https://github.com/ffmpegwasm/ffmpeg.wasm)
    • Comparten una experiencia de enero de 2024, cuando extrajeron cuadros de una película animada de 1993 en intervalos de 15 minutos, luego los escalaron usando Real-ESRGAN-ncnn-vulkan (https://github.com/xinntao/Real-ESRGAN-ncnn-vulkan) y finalmente recompusieron los cuadros resultantes en 4K
    • Piensan que, si le hubieran añadido una UI a ese flujo de trabajo, podría haberse convertido en una herramienta como Topaz AI, que está tan de moda hoy
    • También comparten una imagen de muestra escalada (imagen de muestra)
    • Incluso cuando no usan ffmpeg directamente, con frecuencia usan herramientas que lo incorporan
      • Hace poco escalaron un anime viejo y de baja calidad extraído de un DVD usando k4yt3x/video2x; fue fácil de instalar y traía libffmpeg integrado
      • Al codificar, podían usar los mismos argumentos que en FFmpeg
      • Para elegir los mejores argumentos, codificaron una escena corta con varios conjuntos de parámetros usando ffmpeg, y luego extrajeron imágenes fijas otra vez con ffmpeg para compararlas

  • Les da gusto que FFmpeg haya introducido codificadores y decodificadores de video basados en compute shaders

    • Los códecs ampliamente soportados en hardware son más o menos H.264, H.265 y AV1, así que estaría bien que otros códecs también pudieran aprovechar aceleración de plataforma, aunque fueran un poco menos eficientes
    • El nuevo codificador ProRes les parece útil para un proyecto en el que están trabajando ahora
    • Entienden la explicación de que los códecs comunes y ampliamente usados no son adecuados para decodificación paralela, por lo que es difícil darles soporte
    • Se necesitarían decenas de miles de hilos, pero no es fácil paralelizar por las dependencias de datos entre cuadros y entre tiles
    • El codificador parece tener algo más de flexibilidad que el decodificador, pero codificar algo como VP9 (https://blogs.gnome.org/rbultje/2016/12/13/overview-of-the-vp9-video-codec/) con compute shaders suena como un reto complicado

    • Vuelven a compartir su entusiasmo por la implementación de codificadores/decodificadores de video con compute shaders

      • En el pasado solo existían interfaces de hardware in-silicon estandarizadas, así que recuerdan que les causó gracia cuando preguntaron si un codificador/decodificador basado en Vulkan sería de propósito general
      • Es realmente genial que estas mejoras también estén disponibles en hardware viejo, y esperan que esto abra una ruta hacia nuevos códecs y mejoras generales de calidad

    • No han seguido las tendencias más recientes en decodificadores desde hace más de 10 años, pero intuitivamente esperan que la aceleración por GPU ayude mucho en el posprocesamiento final que convierte todo en datos de píxeles

      • Parecería posible hacer la descompresión inicial en CPU y luego enviar los datos ya descomprimidos a la GPU para la conversión final, como aplicar motion vectors, iDCT, etc.
      • Si el cuadro final ya está como textura en GPU, el overhead de visualización también sería bajo
      • Les da curiosidad saber qué tan acertada era esa intuición

    • Siempre les sorprende el talento de los maintainers de FFmpeg; es increíble que hagan gratis un trabajo tan difícil

    • Estas notas de lanzamiento les parecen muy interesantes

      • En las últimas semanas hicieron un decodificador ProRes con compute shaders de WebGPU, y funciona lo bastante rápido (aunque creen que Apple probablemente use su propia aceleración por hardware)
      • Este camino también parece encajar bien con el nuevo códec APV de Android
      • La especificación del bitstream de ProRes fue enviada a SMPTE, pero fue difícil encontrar información sobre ProRes RAW
      • Les parece muy interesante que estén apareciendo implementaciones basadas en software y compute; probablemente los desarrolladores de ffmpeg hicieron ingeniería inversa
      • Viendo el código por encima, no parece muy distinto de ProRes normal
      • Documento de especificación de ProRes

  • Cada vez que usan FFmpeg terminan impresionados (aunque tengan que volver a revisar el manual o pedir ayuda a un LLM, incluso cuando usan una GUI que genera comandos a partir de opciones visuales)

    • Parece que ya se volvió la multiherramienta esencial de transcodificación
    • Consideran que fue una buena decisión introducir procesamiento basado en Vulkan 1.3
    • Ayer también se enteraron de que Asahi Linux on Mac soporta el mismo estándar

    • Dejan una observación ingeniosa: los argumentos de FFmpeg son la “ingeniería de prompts” original

    • Los LLM y herramientas de línea de comandos complejas como FFmpeg o ImageMagick son una combinación fantástica

      • Sienten que es una UI/UX futurista casi perfecta, donde basta con describir en lenguaje natural lo que se quiere hacer para que se vuelva realidad de inmediato
      • Imaginan, por ejemplo, un flujo donde se recortan todas las imágenes de una carpeta a cierto tamaño, se ajusta la saturación, se guardan como TIFF, se ensamblan en un loop de video y luego se codifican para web, todo de una sola vez

    • Los LLM funcionan muy bien como interfaz para FFmpeg

  • Comparten, medio en broma y medio en serio, que desperdician el 50% del esfuerzo construyendo comandos CLI complejos con ffmpeg y el otro 50% peleando con el escape del shell

    • Sobre todo al poner texto sobre video, el escape del texto les parece especialmente difícil
    • Se preguntan si alguien ha encontrado una forma realmente buena de invocar ffmpeg desde Python con muchos argumentos, incluidos filtros (¿r-strings? ¿heredocs? etc.)

  • Preguntan si existe un buen frontend GUI para manejar fácilmente las distintas funciones de FFmpeg

    • A veces solo necesitan hacer remux, o simplemente combinar streams de video/audio con el mismo códec

    • Destacan que unir videos suena fácil, pero en realidad tiene muchas variables y problemas

      • Puede haber problemas en ciertos entornos de reproducción por variables como timebase, offsets de inicio, recorte de cuadros, diferencias de FPS, B-frames, open GOP, etc.
      • En audio también existen varias variables, como diferencias de sample rate
      • Se mencionó el programa Lossless-Cut, y su función de verificación de compatibilidad parece útil
      • Pero convertir primero el video a MPEG-TS y luego unirlo sirve para esquivar varios problemas, y puede hacerse rápido en un ramdisk
      • También comparten una secuencia de línea de comandos de ffmpeg que puede usarse como ejemplo

    • Handbrake cumple bien ese papel

      • En cuanto a funciones es suficiente y, aunque se siente algo viejo, sigue siendo útil

    • Si usan Mac, recomiendan ffWorks (https://www.ffworks.net/index.html)

      • Permite acceder fácilmente a la mayoría de las funciones y también soporta procesamiento por lotes y presets
      • El desarrollador da soporte muy activo, por eso es una de sus apps favoritas, e incluso donan porque les parece que vale mucho la pena
      • Handbrake y Losslesscut también son excelentes, pero sienten que en otras plataformas no hay ninguna app que compita con el nivel de acabado de ffWorks

    • Piensan que su mejor frontend es ChatGPT

      • Si describen en lenguaje natural lo que quieren hacer, genera comandos de ffmpeg con muchísima precisión

    • Recomiendan revisar Lossless-cut

  • Comparten un enlace para revisar el changelog de FFmpeg (https://github.com/FFmpeg/FFmpeg/blob/master/Changelog)

  • Expresan brevemente que es una noticia interesante

    • Se preguntan si ese video es sátira o si va en serio

  • Dan su opinión personal de que ffmpeg podría ser la cuarta librería más usada después de ssl, zlib y sqlite (asumiendo que en 2025 el video realmente está en todas partes)

    • Les cuesta estar de acuerdo, porque el procesamiento de video suele ser necesario sobre todo en servidores que reciben medios

      • Mencionan que la mayoría de los teléfonos no procesan video con ffmpeg

    • curl podría estar por encima, y “SSL” además reparte sus cifras entre distintas implementaciones

    • Proponen como fuente de datos los logs de métricas de fastly de la infraestructura de NixOS (https://github.com/NixOS/infra/blob/main/metrics/fastly/README.md)

    • Piensan que hay bastantes librerías más usadas que ffmpeg, como Qt, libpng o libusb

    • También podría valer la pena revisar las estadísticas de paquetes de Arch Linux (https://pkgstats.archlinux.de/packages)

  • Les parece especialmente genial la implementación con compute shaders de Vulkan, sobre todo en FFv1 y ProRes RAW

    • Como evita por completo los decodificadores de hardware de función fija, se preguntan cómo impacta eso en el ancho de banda de memoria
    • Les sorprende que estén logrando mejoras de velocidad muy grandes, porque el coding aritmético adaptativo por contexto de FFv1 parece intrínsecamente secuencial y difícil de acelerar
    • Se preguntan si la estrategia es paralelizar varios símbolos al mismo tiempo o por slices, y qué trade-offs hizo el equipo de ffmpeg, dado que tradicionalmente acelerar coding aritmético en GPU ha sido difícil
    • Si alguien ha perfilado esa implementación, les gustaría escuchar sobre la ocupación en la etapa de decodificación entrópica y la elección de ancho de banda

  • ffmpeg es la base de muchísimas herramientas

    • Mucha gente no sabe cuánto ha contribuido ffmpeg a la industria de medios
    • Es una herramienta a la que siempre vuelven cada vez que necesitan automatización de audio/video