9 puntos por GN⁺ 2025-01-15 | 1 comentarios | Compartir por WhatsApp
  • Las tareas con FFmpeg suelen volverse complejas por la combinación de opciones, y FFmpeg By Example es un sitio de documentación que permite encontrar rápidamente cómo hacer el procesamiento multimedia necesario mediante ejemplos reales de comandos
  • Ofrece un repositorio de GitHub, una comunidad en Discord y una página de contribuciones para que los usuarios puedan enviar directamente nuevas ideas de uso de FFmpeg
  • Como en el ejemplo del filtro testsrc, muestra la fuente de entrada, la resolución, la tasa de fotogramas y el archivo de salida en un solo comando, para poder seguir tal cual la estructura del comando
  • Los ejemplos cubren en general tareas de procesamiento multimedia como cálculo de bitrate, redimensionamiento de imágenes, reducción de ruido de audio, efectos de transición, mapeo de streams, aceleración por hardware y manejo de metadatos
  • Cada ejemplo está separado por etiquetas y páginas individuales, lo que facilita explorar comandos de FFmpeg necesarios según un filtro específico o un objetivo de conversión

Sitio de documentación de FFmpeg centrado en ejemplos

  • FFmpeg By Example es un sitio web que organiza, por ejemplo, diversas formas de usar FFmpeg
  • También ofrece enlaces para participación y contribución de la comunidad

Ejemplo de generación de video de prueba con testsrc

ffmpeg -f lavfi -i testsrc=duration=10:size=1280x720:rate=30 testsrc.mpg

Codificación, conversión y aceleración por hardware

Procesamiento de audio

Imágenes y animación

Filtros y efectos visuales

Extracción, análisis y metadatos

Fuentes de generación y pipes de salida

1 comentarios

 
GN⁺ 2025-01-15
Opiniones en Hacker News
  • El placer de usar ffmpeg aumentó como un 1000%
    Antes armaba comandos de forma tediosa buscando en Google respuestas de Stack Overflow y combinándolas, pero ahora ChatGPT escribe los comandos por mí, así que es mucho más cómodo.

    • Gracias a los LLM, uso ffmpeg varias veces por semana
      Es el mejor caso de uso para mi herramienta llm cmd:

      uv tool install llm
      llm install llm-cmd

      llm cmd use ffmpeg to extract audio from myfile.mov and save that as mp3

      https://github.com/simonw/llm-cmd

    • Durante mucho tiempo puse a ffmpeg en la misma caja que las expresiones regulares: la sensación de “realmente debería aprender esto, pero creo que lo voy a odiar muchísimo”
      Entonces apareció ChatGPT y resolvió ambas cosas.

    • Me pasa igual. Este tipo de tareas la IA ya las tomó por completo, y yo solo soy un intermediario que copia y pega trazas de error.

    • Ya salieron muchas otras herramientas, pero acabo de crear un script que simplifica bastante estas cadenas de comandos: llmpeg https://github.com/jjcm/llmpeg
      Si tienes ffmpeg instalado y configurada la clave de API en la variable de entorno de OpenAI, debería funcionar de inmediato.

      Demo: https://image.non.io/1c7a92ef-0917-49ef-9460-6298c7a9116c.we...

    • Mi experiencia usando ffmpeg mejoró después de aprender cómo funcionan los filtros complejos.

  • Se me ocurrió que debería publicar una explicación de cómo convertir videocintas caseras digitalizadas en clips mediante detección de escenas
    Como quizá alguien lo busque, dejo un gist que me funcionó bastante bien [0]. Eso sí, a veces lo engañaban los flashes de cámara o las sacudidas, así que tuve que pasarle archivos separados de inicio/fin y volver a unirlos con ffmpeg [1].

    Lo raro es que, en las últimas actualizaciones de Mac, el rendimiento fue mejor sin -c:v h264_videotoolbox. Podría ser una regresión de rendimiento en Sequoia, pero no estoy seguro. La bandera equivalente en una máquina Windows con GPU Nvidia es -c:v h264_nvenc. Me pregunto por qué ffmpeg no lo detecta automáticamente. Con esto obtuve una mejora de rendimiento de unas 8 veces.
    La única vez en la empresa en que realmente desquité el sueldo fue cuando estábamos por gastar bastante más en un servidor cloud con GPU para procesar video, y descubrí que el ffmpeg instalado había sido compilado sin aceleración por GPU.

    [0] https://gist.githubusercontent.com/nielsbom/c86c504fa5fd61ae...

    [1] https://gist.githubusercontent.com/jazzyjackson/bf9282df0a40...

    • El problema de las CPU en la nube es que no tienen los codificadores de video por hardware incluidos en las CPU de consumo, así que hay que pasar a máquinas con GPU mucho más caras.
      La verdad, no hice una comparación de precios adecuada usando aceleración por hardware en la nube, así que me da curiosidad si quieres decir que sí lo probaste y que valió la pena en relación costo-beneficio.

    • Probé la detección de escenas vacías con ffmpeg
      Tengo una cámara apuntando a la ruta de vuelo de SFO, y al eliminar todos los fotogramas sin movimiento, queda solo un video continuo de aviones pasando, sin tramos aburridos.

    • -c:v h264_nvenc es útil para la codificación por lotes de varios videos a la vez, porque permite aumentar el throughput de codificación.
      Eso sí, cuando hice pruebas limitadas hace tiempo, la calidad de salida era un poco peor que con libx264. No sé si hay una forma de evitarlo, pero no fui el único al que le pasó.

    • La razón por la que ffmpeg no detecta esto automáticamente es que la codificación por hardware suele tener un rango de configuración más estrecho, implica más compromisos que los códecs de software más refinados y, aun con los mismos parámetros, no produce exactamente los mismos resultados.
      Además, muchas veces en un sistema hay varias API de hardware disponibles para elegir, y sus capacidades también difieren.

      FFmpeg es una herramienta de línea de comandos compleja y está dirigida a usuarios dispuestos a aprender los detalles, así que no estoy seguro de que tenga sentido definir valores predeterminados basados en suposiciones.

    • Al ver el snippet, parece que no hace desentrelazado
      Si el clip ya fue desentrelazado antes de digitalizarse, está bien, pero si no, estarías arruinando la calidad al codificar material entrelazado como progresivo. Conviene probar agregando el filtro bwdif para que el contenido 30i se codifique como 60p. Debería verse más parecido a la videocinta original.

  • Con el tiempo me fui familiarizando bastante con varias partes de ffmpeg. La CLI tiene su propia lógica y es dependiente del orden. No todas las CLI de Unix son así.
    Últimamente estuve probando funciones más crípticas. Por ejemplo, guardar directamente video crudo de una cámara en una máquina bastante lenta. Construí un microscopio y leo fotogramas desde la cámara en formato de video crudo (YUYV 1280x720) a 120 FPS; si los guardo tal cual en disco, crecen a gigabytes por minuto. El disco es barato, pero se siente como un desperdicio, así que estuve mirando técnicas casi sin pérdida que permitan comprimir y guardar imágenes exactas rápidamente.

    Descubrí que la conversión a RGB24 en ffmpeg es muy lenta, así que después de ajustar varias cosas en la línea de comandos me quedé con esto:

    ffmpeg -f rawvideo -pix_fmt yuyv422 -s 1280x720 -i test.raw -vcodec libx264 -pix_fmt yuv420p movie.mp4 -crf 13 -y

El video sin procesar no tiene contenedor, así que no cuenta con metadatos como “formato de píxel” o “tamaño de imagen”, por lo que hay que proporcionarlos manualmente. Depende del orden: todo lo que va antes de -i test.raw es para decodificar la entrada, y todo lo que va después es para escribir la salida. Solo realiza una conversión muy pequeña de formato de píxel (ffmpeg puede procesarla muy rápido) y escribe los datos en un formato casi sin pérdida que sí tiene contenedor. En la mayoría de los casos, el mejor contenedor resultó ser .mkv

Como no me gusta la línea de comandos, al final usé ffmpeg-python e hice que el siguiente código armara la línea de comandos:

self.process = (
ffmpeg.
input(
"pipe:",
format="rawvideo",
pix_fmt="yuyv422",
s="{}x{}".format(1280, 720),
threads=8
)
.output(
fname, pix_fmt="yuv422p", vcodec="libx264", crf=13
)
.overwrite_output()
.global_args("-threads", "8")
.run_async(pipe_stdin=True)
)

Y en la práctica hago write() de los fotogramas en la entrada estándar de ese proceso. La máquina tiene 12 núcleos y el control del microscopio siempre usa al menos 2, así que tuve que limitar la cantidad de hilos

Todavía sigo buscando una codificación YUV sin pérdida mejor y más rápida

  • Que dependa del orden es apropiado. Los pipelines de Unix también dependen del orden de sus componentes, y una invocación compleja de FFMpeg hace algo parecido
    A mucha gente le gusta la estética de las “interfaces fluidas” como ffmpeg-python, pero en Python a menudo se considera poco pythónica. Entiendo que ffmpeg-python está diseñado para reflejar de cerca el orden de la línea de comandos

    La preferencia que refuerzan la biblioteca estándar y el diseño de los tipos incorporados es una fuerte https://en.wikipedia.org/wiki/Command%E2%80%93query_separati.... Con ese principio, se vería más o menos así:

    ffmpeg(global_args=..., overwrite_output=True).process_async(piped_input(...), output(...))

    Si la entrada se convierte en un proceso de configuración separado, aparece otro tipo en tiempo de ejecución y también puede indicarle al código de procesamiento que debe leer desde la entrada estándar

  • No hace falta buscar más: FFV1 https://trac.ffmpeg.org/wiki/Encode/FFV1

  • Solo quiero recomendar una palabra: ramdisk
    Si haces procesamiento intermedio pero tienes archivos que no quieres conservar, la respuesta es un ramdisk. Es realmente genial

  • Pensé que sería un sitio web que reunía y mantenía el conocimiento acumulado por usuarios avanzados de FFmpeg, pero el primer ejemplo en el que hice clic me decepcionó de inmediato
    https://www.ffmpegbyexample.com/examples/l1bilxyl/get_the_du...

    No deberías invocar dos herramientas más solo para procesar cadenas. FFprobe por sí solo puede darte directamente la duración o el valor que quieras:

    ffprobe -loglevel quiet -output_format csv=p=0 -show_entries format=duration video.mp4

    No hay que quedarse con lo primero que funciona; después de que funcione, hay que pensar si existe una forma de mejorarlo

    • Soy el autor del texto original. Creo que llamarlo “una locura” es un poco exagerado
      Aun así, me gusta más la solución que propusiste
  • Está bueno. Me recordó a mi chuleta de ffmpeg. Creo que cualquiera que use ffmpeg con frecuencia tiene una colección de notas parecida
    https://github.com/fastily/cheatsheet/blob/master/ffmpeg.md

  • FFmpeg es una de esas herramientas que uso tan de vez en cuando que la sintaxis exacta jamás se me queda en la cabeza. Al final le pido a un LLM que me dé la línea de comandos que necesito
    La única herramienta igual de difícil fue MegaCLI de LSI Logic, con estilo de los años 90. También la usaba casi nunca, pero era de esas que había que escribir exactamente bien bajo presión

    • Llevo más de 15 años usando FFMPEG y aun así casi no recuerdo los comandos. De todos modos, los LLM son realmente increíbles cuando se trata de FFMPEG
      Si les digo a ChatGPT y Claude: “remuxea el video a mkv, incluye subtitle.srt en el archivo y solo quiero de 0:00:05 a 0:01:00”, lo hacen de maravilla. Por si da curiosidad, el resultado fue este: ffmpeg -i input.mp4 -i subtitle.srt -ss 00:00:05 -to 00:01:00 -map 0 -map 1 -c copy -c:s mov_text output.mkv

      Me pregunto qué tan pequeño podría ser un LLM si su único objetivo fuera generar comandos de ffmpeg. ¿Tal vez podría ser tan pequeño como para ponerlo en una página web estática y ejecutarlo localmente?

    • Desde hace 15 años mantengo un documento personal de notas con la sintaxis que uso a menudo. Si aun así no alcanza, hago grep en el historial de bash

    • Me pasa igual. Lo único que se me queda en la cabeza es convertir del formato X a .mp4. Todo lo demás tengo que volver a buscarlo cada vez
      XKCD relacionado https://xkcd.com/1168/

    • Hace unos días dije, medio en broma medio en serio, que si un LLM tan solo me dijera qué flags de ffmpeg quiero, quizá valdría la pena quemar toda la selva tropical

  • No hay que olvidar que también existe GStreamer. Como está basado en pipelines, la línea de comandos y la documentación son un poco más fáciles de entender que ffmpeg, y las combinaciones también son un poco más sensatas
    Para trabajos de video pesados, dejé ffmpeg por completo y solo uso GStreamer

    • GStreamer puede dar más control y una API más amigable al crear pipelines mediante programación
      Pero para tareas puntuales, ffmpeg parece mucho más amigable. Por ejemplo, ffmpeg tiene valores predeterminados razonables para x264, pero con gst-launch, para hacer una codificación x264 de buena calidad, de verdad hay que saber lo que uno está haciendo
    • Pensaba que FFmpeg también estaba basado en pipelines. ¿No tiene grafos de filtros? ¿Me estoy perdiendo de algo?
      Se pueden configurar grafos complejos de fuentes, sinks y filtros de transformación
    • GStreamer se siente como un proyecto abandonado. Hace poco también tuvo una vulnerabilidad importante y la documentación está bastante rota
  • Hay un repositorio de GitHub de un libro de ffmpeg que podría complementar bien este sitio:
    https://github.com/jdriselvato/FFmpeg-For-Beginners-Ebook

  • ffmpeg siempre me ha parecido como una aplicación GUI metida a la fuerza en formato TUI
    También he usado la API en C varias veces de forma desagradable; en varios aspectos es intuitiva, pero es demasiado fácil representar estados inválidos. Ojalá existiera un framework de codificación AV1 en tiempo real que “simplemente funcione”

    • Básicamente es casi la única herramienta en la que primero busco HandBrake, la alternativa con GUI. La excepción es cuando hago procesamiento por lotes
      También hay varias GUI puras para ffmpeg. Hay algo en el trabajo con video para lo que la línea de comandos no encaja bien con mi forma de pensar

    • Como API, puedo recomendar GStreamer. Usé los bindings de Rust, así que no estoy tan familiarizado con la API en C, pero me pareció buena
      Hay partes verbosas por culpa de GObject, pero una vez que lo entiendes puedes interactuar de forma consistente con todos los objetos de la API. Hay muchísima complejidad necesaria (el video es difícil), pero el diseño, la implementación y la documentación están bastante bien hechos

      Para casos de uso comunes, los Bins (decodebin, transcodebin, playbin) lo hacen bastante fácil. Incluso los casos de uso más complejos son posibles gracias a la flexibilidad del diseño

    • Me gusta la observación, pero una TUI es algo gráfico, y ffmpeg es simplemente una CLI
      Sería genial que hubiera una herramienta TUI. Algo como https://github.com/Twinklebear/fbed, pero con funcionalidades más completas

  • En sistemas Linux, me gusta hacer una compilación estática de ffmpeg. A veces la versión de la distribución es demasiado vieja o le faltan los módulos que prefiero
    Esta versión en contenedor me resultó muy útil: https://github.com/wader/static-ffmpeg