Cómo crear un AVI sin comprimir a partir de una serie de miles de imágenes PNG usando FFMPEG

31

¿Cómo puedo crear un AVI sin comprimir a partir de una serie de miles de imágenes PNG usando FFMPEG?

Usé este comando para convertir un input.aviarchivo a una serie de marcos PNG:

ffmpeg -y -i input.avi  -an -vcodec png  -s 1024x768 pic%d.png`

Ahora necesito saber cómo hacer un video AVI sin comprimir a partir de todos esos cuadros PNG. Intenté esto:

ffmpeg -i pic%d.png -y -f avi -b 1150 -s 1024x768 -r 29.97 -g 12 -qmin 3 -qmax 13 -ab 224 -ar 44100 -ac 2 test.avi

Pero el video resultante pierde mucha calidad en relación con el AVI original.

Warren Young
fuente

Respuestas:

77

Hay varias formas de obtener un AVI "sin comprimir" ffmpeg, pero sospecho que en realidad quiere decir "sin pérdidas". Ambos términos tienen bastante margen de maniobra en sus definiciones, como verá.

Voy a anclar esta discusión con la versión 720p HD de Big Buck Bunny , ya que es un video de libre acceso con el que todos podemos probar y obtener resultados que podemos comparar. La velocidad de datos sin procesar del video de 1280 × 720p a 24 fps es casi igual a la de su objetivo declarado de 1024 × 768 a 29.97 fps, por lo que mis resultados deberían ser una guía bastante buena para las velocidades de datos que puede esperar en su metraje.

Listado automático de opciones disponibles

El siguiente comando POSIX¹ le brinda una lista que en su mayoría² coincide con lo que discutimos a continuación:

$ ffmpeg -codecs 2> /dev/null | grep '^..EV..S ' | grep -vE 'bitmap|image'

Es posible que desee ejecutar ese comando en su propia máquina para ver qué admite su compilación de FFmpeg. FFmpeg rara vez se construye con todos los codificadores posibles habilitados.

Ahora discutamos esas opciones.

Completamente sin comprimir

Si su definición de "comprimir" es la forma el vídeo está en la derecha antes de que se volvió a los fotones mediante una pantalla digital, el más cercano que veo en la ffmpeg -codecslista son -c:v r210, r10k, v410, v308, ayuvy v408. Estos son todos sustancialmente la misma cosa, difiriendo sólo en la profundidad de color , el espacio de color , y alfa canal de apoyo.

  • R210 y R10K son 4: 4: 4 RGB a 10 bits por componente (bpc), por lo que ambos requieren aproximadamente 708 Mbit / s para 720p en mis pruebas. (¡Eso es aproximadamente ⅓ TB por hora, amigos!)

    Estos códecs empaquetan los componentes de color de 3 × 10 bits por píxel en un valor de 32 bits para facilitar la manipulación por parte de las computadoras, que les gustan los tamaños de potencia de 2. La única diferencia entre estos códecs es en qué extremo de la palabra de 32 bits están los dos bits no utilizados. Esta trivial diferencia es indudable porque provienen de compañías competidoras, Blackmagic Design y AJA Video Systems , respectivamente.

    Aunque estos son códecs triviales, probablemente tendrá que descargar los códecs Blackmagic y / o AJA para reproducir archivos que los utilizan en su computadora. Ambas compañías permitirá descargar sus codecs sin haber comprado su primera hardware, ya que saben que se le puede tratar con archivos producidos por los clientes que hacer tener algunos de su hardware.

  • V410 es esencialmente solo la versión YUV de R210 / R10K; Sus velocidades de datos son idénticas. Sin embargo, este códec puede codificar más rápido, porque ffmpeges más probable que tenga una ruta de conversión de espacio de color acelerada entre el espacio de color de los cuadros de entrada y este espacio de color.

    Sin embargo, no puedo recomendar este códec, ya que no pude reproducir el archivo resultante en ningún software que probé, incluso con los códecs AJA y Blackmagic instalados.

  • V308 es la variante de 8 bpc de V410, por lo que llega a 518 Mbit / s en mis pruebas. Al igual que con V410, no pude reproducir estos archivos en el software normal del reproductor de video.

  • AYUV y V408 son esencialmente lo mismo que V308, ¡excepto que incluyen un canal alfa, sea necesario o no! Si su video no usa transparencia, esto significa que paga la penalización de tamaño de los códecs R210 / R10K de 10 bpc anteriores sin obtener el beneficio del espacio de color más profundo.

    AYUV tiene una virtud: es un códec "nativo" en Windows Media, por lo que no requiere un software especial para jugar.

    Se supone que V408 es nativo de QuickTime de la misma manera, pero el archivo V408 no se reproduciría en QuickTime 7 o 10 en mi Mac.

Entonces, juntando todo esto, si tus PNG se nombran frame0001.pngy así sucesivamente:

$ ffmpeg -i frame%04d.png -c:v r10k output.mov
  ...or...                -c:v r210 output.mov
  ...or...                -c:v v410 output.mov
  ...or...                -c:v v408 output.mov
  ...or...                -c:v v308 output.mov
  ...or...                -c:v ayuv output.avi

Tenga en cuenta que he especificado AVI en el caso de AYUV, ya que es prácticamente un códec exclusivo de Windows. Los otros pueden funcionar en QuickTime o AVI, dependiendo de qué códecs estén en su máquina. Si un formato de contenedor no funciona, intente con el otro.

Los comandos anteriores, y también los siguientes, suponen que sus cuadros de entrada ya tienen el mismo tamaño que desea para su video de salida. Si no, agregue algo parecido -s 1280x720al comando, antes del nombre del archivo de salida.

RGB comprimido, pero también sin pérdidas

Si, como sospecho, realmente quiere decir "sin pérdidas" en lugar de "sin comprimir", una opción mucho mejor que cualquiera de las anteriores es Apple QuickTime Animation , a través de-c:v qtrle

Sé que dijiste que querías un AVI, pero el hecho es que probablemente tengas que instalar un códec en una máquina Windows para leer cualquiera de los formatos de archivo basados ​​en AVI mencionados aquí, mientras que con QuickTime existe la posibilidad de que el video La aplicación que elija ya sabe cómo abrir un archivo de animación QuickTime. (El códec AYUV anterior es la única excepción que conozco, pero su velocidad de datos es muy alta, solo para obtener el beneficio de AVI).

ffmpegse qtrleintroducirá en un contenedor AVI para usted, pero el resultado puede no ser muy compatible. En mis pruebas, QuickTime Player se quejará un poco sobre dicho archivo, pero luego lo reproducirá. Sin embargo, curiosamente, VLC no lo reproducirá, aunque esté basado en parte en ffmpeg. Me quedaría con los contenedores QT para este códec.

El códec QuickTime Animation utiliza un esquema trivial RLE , por lo que para animaciones simples, debería funcionar tan bien como Huffyuv a continuación. Cuantos más colores haya en cada cuadro, más se acercará a la velocidad de bits de las opciones completamente descomprimidas anteriores. En mis pruebas con Big Buck Bunny, pude obtener ffmpegun archivo de 165 Mbit / s en modo RGB 4: 4: 4 a través de -pix_fmt rgb24.

Aunque este formato está comprimido, proporcionará valores de píxeles de salida idénticos a sus archivos de entrada PNG, por la misma razón que la compresión sin pérdida de PNG no afecta los valores de píxeles.

La ffmpegimplementación de Animación QuickTime también es compatible -pix_fmt argb, lo que le proporciona 4: 4: 4: 4 RGB, lo que significa que tiene un canal alfa. De una manera muy aproximada, es el equivalente de QuickTime -c:v ayuvmencionado anteriormente. Sin embargo, debido a la compresión sin pérdidas, llega a solo 214 Mbit / s , menos de ⅓ la velocidad de datos de AYUV con cero pérdidas en calidad o características.

Hay variantes de QuickTime Animation con menos de 24 bits por píxel, pero se utilizan mejor para estilos de animación progresivamente más simples. ffmpegparece admitir solo uno de los otros formatos definidos por la especificación -pix_fmt rgb555be, lo que significa 15 bpp RGB big-endian. Es tolerable para algunos videos, y está bien para la mayoría de las capturas de pantalla y animaciones simples. Si puede aceptar la reducción del espacio de color, puede encontrar atractiva su velocidad de datos de 122 Mbit / s .

Poniendo todo esto junto:

$ ffmpeg -i frame%04d.png -c:v qtrle -pix_fmt rgb24    output.mov
  ...or...                           -pix_fmt argb     output.mov
  ...or...                           -pix_fmt rgb555be output.mov

Efectivamente sin pérdida: el truco de YUV

Ahora, lo que pasa con RGB y 4: 4: 4 YUV es que estas codificaciones son muy fáciles de procesar para las computadoras, pero ignoran un hecho sobre la visión humana, que es que nuestros ojos son más sensibles a las diferencias en blanco y negro que a las diferencias de color .

Los sistemas de almacenamiento y entrega de video, por lo tanto, casi siempre usan menos bits por píxel para la información de color que para la información de luminancia. Esto se llama submuestreo de croma . Los esquemas más comunes son 4: 2: 0 y 4: 2: 2.

La velocidad de datos de 4: 2: 0 YUV es solo un 50% más alta que para el video sin comprimir en blanco y negro (solo Y) y la mitad de la velocidad de datos de 4: 4: 4 RGB o YUV.

4: 2: 2 es una especie de punto medio entre 4: 2: 0 y 4: 4: 4. Es el doble de la velocidad de datos del video de solo Y y ⅔ la velocidad de datos de 4: 4: 4.

A veces también ve 4: 1: 1, como en el antiguo estándar de cámara DV . 4: 1: 1 tiene la misma velocidad de datos sin comprimir que 4: 2: 0, pero la información de color se organiza de manera diferente.

El punto de todo esto es que si está comenzando con un archivo H.264 4: 2: 0, volver a codificarlo a 4: 4: 4 RGB sin comprimir no le compra absolutamente nada sobre YUV 4: 2: 0 comprimido sin pérdidas. Esto es cierto incluso si sabe que su flujo de trabajo es 4: 4: 4 RGB, ya que es una conversión trivial; El hardware y el software de video realizan tales conversiones sobre la marcha de forma rutinaria.

Realmente solo necesitas 4: 4: 4 cuando estás mirando píxeles o estás haciendo cambios de color a nivel de píxel en el video, y necesitas preservar los valores exactos de píxel. El trabajo de efectos visuales (VFX) es más fácil de hacer con un formato de 4: 4: 4 píxeles, por ejemplo, por lo que las casas de efectos visuales de alta gama a menudo están dispuestas a tolerar las velocidades de datos más altas que requiere.

Efectivamente sin pérdida: opciones de códec

Una vez que se abre a los códecs YUV con decimación de color, sus opciones también se abren. ffmpegtiene muchos códecs sin pérdida efectiva .

Huffyuv

La opción más ampliamente compatible es Huffyuv . Obtienes esto a través de -c:v huffyuv.

El códec original de Windows Huffyuv solo admite dos formatos de píxeles: RGB24 y YUV 4: 2: 2. (En realidad, admite dos tipos de YUV 4: 2: 2, que difieren solo en el orden de los bytes en el disco).

Las versiones anteriores del códec FFmpeg Huffyuv no incluían el soporte RGB24, por lo que si lo prueba y FFmpeg le dice que usará el yuv422pformato de píxeles, debe actualizarlo.

FFmpeg también tiene un códec variante Huffyuv llamado FFVHuff, que admite YUV 4: 2: 0. Esta variante no es compatible con el códec Windows DirectShow Huffyuv, pero debería abrirse en cualquier software basado en libavcodec, como VLC.

  • RGB24 - RGB 4: 4: 4 es esencialmente lo mismo que la opción de espacio de color RGB24 de QuickTime Animation. Los dos códecs diferirán un poco en la compresión para un archivo determinado, pero generalmente estarán cerca.

    También es esencialmente lo mismo que el modo YUV 4: 4: 4 utilizado por la opción V308 anterior. La diferencia de espacio de color no hace una diferencia práctica, ya que la conversión del espacio de color es fácil de hacer en tiempo real.

    Debido a la compresión sin pérdidas de Huffyuv, pude obtener un video de prueba para comprimir a aproximadamente 251 Mbit / s en modo RGB24, con una calidad visual idéntica a la que obtendría de V308 o AYUV. Si AVI es una necesidad absoluta para usted, instalar el códec Huffyuv probablemente sea menos doloroso que pagar el costo de la tasa de datos 3 × de AYUV.

  • YUV 4: 2: 2 : este modo es mucho más práctico para el video que RGB24, lo que sin duda es la razón por la cual los ffmpegdesarrolladores eligieron implementarlo primero. Como era de esperar de la reducción teórica ⅔ discutida anteriormente, mi archivo de prueba codificó a 173 Mbit / s . Eso es casi exactamente ⅔, si tienes en cuenta el hecho de que la pista de audio no cambió entre estas dos pruebas.

  • YUV 4: 2: 0 : esta opción diezma la información de color más de 4: 2: 2, bajando la velocidad de datos a 133 Mbit / s en mis pruebas.

Poniendo todo esto junto:

$ ffmpeg -i frame%04d.png -c:v huffyuv -pix_fmt rgb24   output.avi
  ...or...                             -pix_fmt yuv422p output.avi
  ...or...                -c:v ffvhuff -pix_fmt yuv420p output.avi

Aunque el ffvhuffcódec predeterminado es 4: 2: 0 a medida que escribo esto, y de hecho solo admite ese formato de píxeles en la versión de lanzamiento que estoy usando, esto está cambiando , por lo que debe incluir el indicador en caso de que esto cambie por defecto.

Ut Video

Una opción más reciente en el mismo espíritu que Huffyuv y FFVHuff es Ut Video . Al igual que Huffyuv, hay un códec de video de Windows, lo que significa que cualquier programa de Windows que pueda reproducir una película puede reproducir videos usando este códec con el códec instalado. A diferencia de Huffyuv, también hay un códec de video para Mac, por lo que no está restringido a un software basado en FFmpeg o libavcodecpara leer estos archivos en Mac.

Este códec es muy flexible en términos de espacios de color, por lo que solo daré algunos ejemplos de espacios de color comunes:

  • 4: 4: 4 RGB a través -f avi -c:v utvideo -pix_fmt rgb24da 178 Mbit / seg salida

  • 4: 4: 4 YUV a través -f avi -c:v utvideo -pix_fmt yuv444pda 153 Mbit / seg salida

  • 4: 2: 2 YUV a través -f avi -c:v utvideo -pix_fmt yuv422pda 123 Mbit / seg salida

  • 4: 2: 0 YUV vía -f avi -c:v utvideo -pix_fmt yuv420pda una salida de 100 Mbit / seg .

Sospecho que 4: 4: 4 YUV funciona mejor que 4: 4: 4 RGB en esta prueba a pesar de que estos dos son técnicamente equivalentes porque el video fuente es 4: 2: 0 YUV, por lo que organizar los datos en formato YUV permite una mejor compresión sin pérdidas agrupando los canales U y V parcialmente redundantes en el archivo.

FFV1

Otra opción interesante en este espacio es el propio FFV1códec de FFmpeg . Esto se usa principalmente como un códec de archivo en lugar de un códec de reproducción o edición, pero dado que gran parte del software se basa en la libavcodecbiblioteca que respalda FFmpeg o se puede atacar a libavcodectravés de herramientas como ffdshow, puede ser útil para usted de todos modos.

De forma predeterminada, ffmpegconservará el espacio de color de sus archivos de entrada cuando use un códec flexible como FFV1, de modo que si lo alimenta a uno de los archivos MP4 oficiales de Big Buck Bunny, que usan YUV 4: 2: 0, eso es lo que obtendrá fuera a menos que le des una -pix_fmtbandera ffmpeg. Esto da como resultado un archivo de salida de 63 Mbit / s .

Si obliga a FFV1 a usar un espacio de color 4: 4: 4 YUV con -pix_fmt yuv444p, el tamaño del archivo solo sube a 86 Mbit / seg , pero no nos está comprando nada en este caso ya que estamos codificando desde un original 4: 2: 0 . Sin embargo, si introduce un conjunto de PNG, como en la pregunta original, es probable que el archivo de salida use el espacio de color bgrao bgr0, que son solo reordenamientos de los espacios de color argby rgb24mencionados anteriormente.

H.264 sin pérdidas

Otra alternativa interesante es Lossless H.264 . Esto es más o menos una cosa de solo x264 a partir de este escrito, pero aquellos que usan FFmpeg en el lado de la codificación probablemente también usen otro software que incluya libx264el lado de la decodificación , como VLC.

La forma más sencilla de obtener dicho archivo es:

$ ffmpeg -i frame%04d.png -c:v libx264 -qp 0 -f mp4 output.mp4

La -qp 0bandera es la clave: los valores más altos dan compresión con pérdida. (También puedes dar -crf 0para obtener el mismo efecto).

Al igual que con FFV1, ffmpegtrataré de adivinar el mejor espacio de color de salida dado el espacio de color de entrada, por lo que, en comparación con los resultados anteriores, ejecuté múltiples pases de codificación en el archivo fuente de Big Buck Bunny con diferentes espacios de color:

  • yuv444p : Esto es lo que ffmpegelige cuando le da una secuencia PNG RGB, como en la pregunta original, y da como resultado un archivo de 44 Mbit / seg con nuestro archivo de prueba

  • yuv422p : Esto es similar al espacio de color predeterminado para Huffyuv, pero obtenemos un archivo de 34 Mbit / seg en este caso, ¡un gran ahorro!

  • yuv420p : Este es el valor predeterminado para los MP4 oficiales de Big Buck Bunny con los que estoy probando, y da como resultado un archivo de 29 Mbit / seg .

Tenga en cuenta que está intercambiando mucha compatibilidad para obtener archivos de tamaño tan pequeño. Es por eso que ni siquiera me molesté en tratar de meter esto en un contenedor AVI o MOV. Está tan estrechamente relacionado con x264 que también podría usar su tipo de contenedor estándar (MP4). También podrías usar algo como Matroska para esto.

Puede intercambiar parte de esa velocidad de bits para un tiempo de codificación más rápido agregando -preset ultrafast. Eso aumentó la velocidad de bits de mi archivo de prueba a 44 Mbit / s en modo YUV 4: 2: 2, pero se codificó mucho más rápido, como se prometió. Los documentos afirman que -preset veryslowtambién vale la pena, pero resultó en un tiempo de codificación mucho más largo y solo ahorró un poco de espacio; No puedo recomendarlo.

Otros

ffmpegtambién admite el modo solo de decodificación para Lagarith y el modo solo de codificación para JPEG sin pérdida . Estos dos códecs son en realidad algo similares, y deberían dar archivos un poco más pequeños que Huffyuv con la misma calidad. Si los ffmpegdesarrolladores alguna vez agregan la codificación Lagarith, sería una alternativa sólida a Huffyuv. Sin embargo, no puedo recomendar Lossless JPEG, ya que no goza de un amplio soporte de decodificación.

Perceptivamente sin pérdida: o, probablemente, puede escapar con alguna pérdida

Luego están los códecs que son perceptualmente sin pérdidas. A menos que esté observando píxeles, casi con certeza no puede darse cuenta de que estos dan resultados visuales diferentes a los de los dos grupos anteriores. Al renunciar a la idea de un cambio absolutamente cero entre el sensor de captura de video y el dispositivo de visualización, compra ahorros considerables:

  • Apple ProRes :-c:v proreso-c:v prores_ks- ProRes es un códec basado en perfiles, lo que significa que hay varias variantes, cada una con una calidad diferente en comparación con el espacio:

    • ProRes 4444 codifica nuestro video de prueba usando solo 114 Mbit / s , pero es de calidad VFX . Actualmente hay tresprores*códecsdiferentesen FFmpeg, pero solo esprores_kscompatible con ProRes 4444, mientras escribo esto, a través de la-profile:v 4444opción.

      Si se pregunta por qué se molestaría en usar ProRes 4444 sobre Lossless H.264, se trata de compatibilidad, velocidad de decodificación, previsibilidad y el canal alfa.

    • ProRes 422 ahorra aún más espacio, ya que solo necesita 84 Mbit / s para obtener un resultado que puede distinguir de ProRes 4444 solo por espionaje de píxeles. A menos que necesite el canal alfa ofrecido por ProRes 4444, probablemente no haya razón para insistir en ProRes 4444.

      ProRes 422 es un competidor más cercano a la opción Lossless H.264 anterior, ya que ninguno admite un canal alfa. Querrá tolerar la tasa de bits más alta de ProRes si necesita compatibilidad con las aplicaciones de video profesional de Apple, una sobrecarga de CPU más baja para codificar y decodificar, o tasas de bits predecibles. Esto último es importante con los codificadores de hardware, por ejemplo. Por otro lado, si puede hacer frente a los problemas de compatibilidad de Lossless H.264, tiene la opción de usar el espacio de color 4: 2: 0, que no es una opción de ningún perfil ProRes.

      Los tres codificadores ProRes en FFmpeg son compatibles con el perfil ProRes 422, por lo que la opción más simple es usar -c:v prores, en lugar de -c:v prores_ks -profile hq, o depender de la función de perfil automático prores_kspara hacer lo correcto.

    Hay perfiles de ProRes aún más parsimoniosos, pero están diseñados para video SD o como servidores proxy para archivos de resolución completa.

    El principal problema con ProRes es que aún no tiene un amplio soporte fuera de Apple y los mundos de video profesional.

  • El DNxHD de Avid es un códec similar a ProRes, pero no está vinculado al mundo de los videos profesionales de Apple. Avid ofrece códecs de descarga gratuita para Windows y Macintosh, y FFmpeg ahora lo admite a través de-c:v dnxhd.

    Debido a que DNxHD es un códec basado en perfiles como ProRes, usted elige el perfil del conjunto predefinido , y eso le dice al códec qué tamaño de cuadro, tasa de cuadro y tasa de bits usar. Para el archivo de prueba Big Buck Bunny, el -b:v 60Mperfil es el más apropiado. Como era de esperar, el archivo resultante es de aproximadamente 59 Mbit / s .

  • MJPEG de baja pérdida :-vcodec mjpeg -qscale:v 1esto es mucho más común que JPEG sin pérdida. De hecho, esta vez fue un códec de edición de video bastante común, y todavía se usa con frecuencia en cosas como cámaras de video en red. Todo ese historial significa que es fácil encontrar software que lo soporte.

    Espere una variabilidad bastante amplia en las velocidades de datos de este códec. Una prueba que acabo de hacer aquí me dio 25 Mbit / s para video de 720p. Esa es una compresión lo suficientemente alta como para ponerme nervioso por la pérdida, pero me pareció bastante buena. Basado solo en la velocidad de datos, diría que es probable que sea de calidad par a 12 Mbit / s MPEG-2 o 6 Mbit / s H.264.

Poniendo todo esto junto:

$ ffmpeg -i frame%04d.png -c:v prores_ks -profile:v 4444 output.mov
  ...or...                -c:v prores_ks -profile:v hq   output.mov
  ...or...                -c:v prores                    output.mov
  ...or...                -c:v dnxhd -b:v 60M            output.mov
  ...or...                -c:v mjpeg -qscale:v 1         output.avi

La conclusión de estos métodos es que, a menos que esté haciendo algo muy exigente, "lo suficientemente bueno" realmente es lo suficientemente bueno.


Notas al pie y digresiones

  1. El comando debería funcionar como se da en Linux, macOS, BSD y Unix. Si está en Windows, puede obtener una línea de comando POSIX a través de Cygwin o WSL .

  2. Hay varias razones por las que la lista producida por ese comando no coincide perfectamente con el conjunto de códecs que he elegido para analizar anteriormente:

    • El segundo grepestá destinado a filtrar codificadores inapropiados como los bmpque no son códecs de "video", a pesar de estar etiquetados Ven esta lista. Si bien técnicamente es probable que puedas meter muchos de estos en un contenedor como AVI, MP4 o MKV para obtener un video de un solo archivo, es probable que ese archivo no sea legible por nada que no sea un programa basado en ffmpego libavcodec.

      Hay algunas excepciones a esto, como que -f avi -c:v ljpegle da algo que podría llamar "MJPEG sin pérdida", pero por regla general, no estamos interesados ​​en guardar muchos archivos de imágenes fijas en un contenedor de A / V aquí para hacer una película. Queremos códecs de video ampliamente reconocidos aquí, no trucos semánticos.

    • El comando actualmente no puede filtrar algunos codificadores inapropiados como GIF porque actualmente no se describen en los formatos de ffmpeg -codecssalida bitmapo imagearchivo.

      GIF es un caso interesante: admite múltiples cuadros de imagen en un solo archivo GIF con información de tiempo para la reproducción de movimiento, pero por varias razones, es completamente inapropiado para nuestra discusión aquí.

    • Algunas de las opciones que se muestran son obsoletas o nunca realmente tiene mucha tracción, como por ejemplo flashsv, diracy snow, por lo que no vale la pena discutirlas anteriormente.

    • Algunas de las opciones en esa lista están destinadas solo para su uso en canalizaciones entre ffmpeginstancias o entre ffmpegy otro programa, como rawvideoy wrapped_avframe, por lo que son inapropiadas para nuestros propósitos aquí.

    • Cerca del final de la discusión anterior, amplío juiciosamente el alcance de la pregunta para incluir algunas opciones de pérdida cuidadosamente elegidas, para que no pasen el primer grepfiltro en el comando anterior.

Warren Young
fuente
1
Después de probar muchos formatos sin comprimir / sin pérdidas para encontrar uno que After Effects importaría, su Quicktime finalmente lo hizo. Como referencia lo fue ffmpeg -i input.avi -c:v qtrle -pix_fmt rgb24 output.mov.
Felwithe
9

Así que terminé haciendo mi propia respuesta demasiado tiempo.
Resumen TL; DR: para almacenar sin pérdida una secuencia de imágenes, use libx264o libx264rgbcon -preset ultrafast -qp 0. Es casi tan rápido como ffvhuff, con una tasa de bits mucho más baja y decodifica más rápido. huffyuves mucho más compatible fuera de ffmpeg, pero no admite tantos formatos de píxeles como ffvhuff. Esa es otra razón para usar h.264, suponiendo que sus otras herramientas puedan manejar el High 4:4:4 Predictiveperfil h.264 que x264 usa en modo sin pérdidas. x264 puede hacer intra-solo si se necesita acceso aleatorio rápido a marcos arbitrarios.

Tenga cuidado con un error ffmpeg que afecta a libx264rgb al leer desde un directorio de imágenes. (y quién sabe qué otros casos). Pruebe la pérdida en su configuración antes de usarla. (fácil con ffmpeg -i in -pix_fmt rgb24 -f framemd5fuente y sin compresión comprimida))

edit: utvideocodifica y decodifica bastante rápido, y es un códec mucho más simple que h.264. Es básicamente un moderno huffyuv, con soporte para espacios de colores más útiles. Si alguna vez tiene un problema con h.264, pruebe utvideo next para archivos temporales.

edit2: PNG como códec RGB parece funcionar bien, al menos en el avance de Sintel.

Vea también mi respuesta similar a una pregunta similar: https://superuser.com/a/860335/20798

Hay mucha información en la respuesta de Warren Young sobre varios formatos y códecs sin formato. Creo que la respuesta sería más útil si fuera más corta, así que estoy haciendo una nueva respuesta. Si está trabajando con un software que no admite x264 sin pérdida o ffvhuff, es probable que parte de esa información siga siendo útil.

La definición más útil de "sin pérdidas" en este contexto es que puede recuperar la entrada bit por bit. Cero preocupación por la degradación de la calidad de la codificación de video, independientemente de lo que haga.

http://en.wikipedia.org/wiki/Chroma_subsampling

Idealmente, evite múltiples conversiones de espacio de color. Los errores de redondeo pueden acumularse potencialmente. Si va a operar su video con filtros que funcionan en el espacio de color RGB, entonces mantenerlo RGB tiene sentido, siempre que las velocidades de bits más altas no sean un problema. Probablemente, en última instancia, va a producir un yuv 4:2:0video, pero mantener la resolución de croma adicional es potencialmente útil, dependiendo de los filtros que vaya a aplicar.

De cualquier manera, sin pérdidas y x264 ffvhuff tanto el apoyo RGB y YUV 4:4:4, 4:2:2y 4:2:0. Sugeriría x264, ya que es rápido para decodificar. Si está intentando reproducir video RGB HD en tiempo real, intente con opengl en lugar de xv, ya que xv en mi sistema solo acepta entrada yuv. mplayer estaba tomando tiempo extra de CPU para hacer una conversión de espacio de color.

Fuente para las siguientes pruebas de codificador: https://media.xiph.org/ . https://media.xiph.org/sintel/sintel_trailer-1080-png.tar.gz Se olvidaron de comprimir los archivos y4m para el sintel trailer, por lo que el tarball png es en realidad mucho más pequeño.

ffmpeg -i 1080/sintel_trailer_2k_%4d.png -i sintel_trailer-audio.flac \
-c:a copy -c:v libx264rgb -preset ultrafast -qp 0 \
frompng.sintel.264rgb.mkv

p.ej

peter@tesla:/mnt/GP1TB/p/encoder-sample/sintel$ time ffmpeg -i 1080/sintel_trailer_2k_%4d.png -i sintel_trailer-audio.flac -c:a copy -c:v libx264rgb -preset ultrafast -qp 0 frompng.sintel.264rgb.mkv
ffmpeg version N-67983-g2b358b4 Copyright (c) 2000-2015 the FFmpeg developers
  built on Jan 10 2015 05:32:37 with gcc 4.8 (Ubuntu 4.8.2-19ubuntu1)
  configuration: --enable-gpl --enable-version3 --enable-nonfree --disable-doc --disable-ffserver --enable-libx264 --enable-libx265 --enable-libmp3lame --enable-libopus --enable-libwebp --enable-libvpx --disable-outdev=oss --disable-indev=oss --disable-encoder=vorbis --enable-libvorbis --enable-libfdk-aac --disable-encoder=aac --disable-decoder=jpeg2000
  libavutil      54. 16.100 / 54. 16.100
  libavcodec     56. 20.100 / 56. 20.100
  libavformat    56. 18.100 / 56. 18.100
  libavdevice    56.  3.100 / 56.  3.100
  libavfilter     5.  7.100 /  5.  7.100
  libswscale      3.  1.101 /  3.  1.101
  libswresample   1.  1.100 /  1.  1.100
  libpostproc    53.  3.100 / 53.  3.100
Input #0, image2, from '1080/sintel_trailer_2k_%4d.png':
  Duration: 00:00:50.12, start: 0.000000, bitrate: N/A
    Stream #0:0: Video: png, rgb24, 1920x1080 [SAR 72:72 DAR 16:9], 25 fps, 25 tbr, 25 tbn, 25 tbc
Input #1, flac, from 'sintel_trailer-audio.flac':
  Duration: 00:00:52.00, start: 0.000000, bitrate: 721 kb/s
    Stream #1:0: Audio: flac, 48000 Hz, stereo, s16
File 'frompng.sintel.264rgb.mkv' already exists. Overwrite ? [y/N] y
No pixel format specified, rgb24 for H.264 encoding chosen.
Use -pix_fmt yuv420p for compatibility with outdated media players.
[libx264rgb @ 0x2770760] using SAR=1/1
[libx264rgb @ 0x2770760] using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowShuffle
[libx264rgb @ 0x2770760] profile High 4:4:4 Predictive, level 4.0, 4:4:4 8-bit
[libx264rgb @ 0x2770760] 264 - core 144 r2525+2 6a4fca8 - H.264/MPEG-4 AVC codec - Copyleft 2003-2014 - http://www.videolan.org/x264.html - options: cabac=0 ref=1 deblock=0:0:0 analyse=0:0 me=dia subme=0 psy=0 mixed_ref=0 me_range=16 chroma_me=1 trellis=0 8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=0 chroma_qp_offset=0 threads=3 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=0 weightp=0 keyint=250 keyint_min=25 scenecut=0 intra_refresh=0 rc=cqp mbtree=0 qp=0
Output #0, matroska, to 'frompng.sintel.264rgb.mkv':
  Metadata:
    encoder         : Lavf56.18.100
    Stream #0:0: Video: h264 (libx264rgb) (H264 / 0x34363248), rgb24, 1920x1080 [SAR 72:72 DAR 16:9], q=-1--1, 25 fps, 1k tbn, 25 tbc
    Metadata:
      encoder         : Lavc56.20.100 libx264rgb
    Stream #0:1: Audio: flac ([172][241][0][0] / 0xF1AC), 48000 Hz, stereo (16 bit)
Stream mapping:
  Stream #0:0 -> #0:0 (png (native) -> h264 (libx264rgb))
  Stream #1:0 -> #0:1 (copy)
Press [q] to stop, [?] for help
frame= 1253 fps= 18 q=-1.0 Lsize=  834790kB time=00:00:51.96 bitrate=131592.5kbits/s
video:830198kB audio:4575kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.002025%
[libx264rgb @ 0x2770760] frame I:6     Avg QP: 0.00  size:612470
[libx264rgb @ 0x2770760] frame P:1247  Avg QP: 0.00  size:678787
[libx264rgb @ 0x2770760] mb I  I16..4: 100.0%  0.0%  0.0%
[libx264rgb @ 0x2770760] mb P  I16..4: 50.3%  0.0%  0.0%  P16..4: 12.0%  0.0%  0.0%  0.0%  0.0%    skip:37.6%
[libx264rgb @ 0x2770760] coded y,u,v intra: 71.1% 68.2% 70.0% inter: 22.8% 22.8% 23.2%
[libx264rgb @ 0x2770760] i16 v,h,dc,p: 50% 48%  1%  1%
[libx264rgb @ 0x2770760] kb/s:135693.94

Tenga en cuenta que olvidé especificar -r 24fps, por lo que no mantendrá la sincronización av con el audio. (y los números de velocidad de bits (pero no del tamaño del archivo) también estarán desactivados. ffmpeg tiene un valor predeterminado de 25 fps). La CPU en esta máquina es un core2duo de primera generación (conroe) de 2.4GHz (E6600).

resultados:

4.5M    sintel_trailer-audio.flac  # this is muxed in to every mkv
948M    1080  # the directory of PNGs
940M    /var/tmp/dl/sintel_trailer-1080-png.tar.gz
7434M   sintel.y4m  # yuv444, uncompressed.  mplayer gets the colors wrong?
2342M   qtrle.mkv   # encode went at 16fps, so qtrle is slower and worse filesize
2105M   sintel.huff.mkv  # ffvhuff with default options, rgb pix fmt
1228M    sintel.utvideo.mkv  # muxed without audio, I should update the others this way
946M    png-copy.mkv  # -codec copy makes a MPNG stream.  Use -codec png for non-png sources, but it won't make PNGs as small.  Decodes very fast
824M    lossy.prores_ks.mov # yuv444p10le extremely slow to encode (2.3fps), and worse bitrate.
816M    frompng.sintel.264rgb.mkv
735M    sintel.x264rgb.medium.nocabac.mkv  # encode went at 3.3 fps instead of 18.  Better gain than for live-action, though
626M    sintel_trailer.rgb.lossless.veryslow.mkv # 1.1fps.  With CABAC, 16 ref frames, etc. etc.
512M    lossy.prores.mov # yuv422p10le, 12fps
341M    sintel.yuv420.x264.lossless.mkv
21M     lossy.rgb.crf26.preset=medium.mkv
13M     lossy.yuv420.crf26.preset=medium.mkv  # remember this is WITH 4.5MB audio

Tenga en cuenta que mediainfono sabe acerca de RGB h.264, todavía dice que los archivos son YUV.

Comprueba que realmente no tuvo pérdidas:

ffmpeg -i 1080/sintel_trailer_2k_%4d.png -f framemd5 png.framemd5
ffmpeg -i fromhuff.sintel.264rgb.mkv -an -sn -pix_fmt rgb24  -f framemd5 x264rgb.framemd5
diff -s *.framemd5
Files png.framemd5 and x264rgb.framemd5 are identical

Entonces puede recuperar la entrada PNG original de esa manera, es decir, podría hacer PNG con datos de imagen idénticos en ellos.

Tenga en cuenta el -pix_fmt rgb24para la prueba x264. El decodificador h.264 de ffmpeg genera la salida gbrp (plana, no empaquetada), por lo que los bits son los mismos, pero en un orden diferente. El "contenedor" framemd5 no impone ningún tipo de restricciones de formato, pero solo obtendrá el mismo md5 si los bits están dispuestos de la misma manera. Solo miré lo que decía ffmpeg que estaba usando para un pix fmt cuando lo alimente con PNG, luego lo usé como argumento -pix_fmtpara decodificar. Por cierto, esta es la razón por la que vlc no reproducirá archivos RGB h.264 (hasta la próxima versión, o las versiones nocturnas actuales): no es compatible con el formato de píxeles gbrp.

Para su uso libx264, no libx264rgb. No necesita instalar una versión RGB de x264, la biblioteca real admite ambos. Es solo ffmpeg que lo implementó como dos codificadores con nombres diferentes. Creo que si no lo hubieran hecho, el comportamiento predeterminado sería dejar la entrada rgb como rgb, y correr muy lentamente mientras produce una salida de velocidad de bits mucho mayor para la misma calidad. (a veces aún debe usarlo -pix_fmt yuv420psi lo desea en 420lugar de la 444salida h.264.

A menos que esté creando archivos para almacenamiento a largo plazo, use siempre -preset ultrafastpara x264 sin pérdidas. Más cuadros de referencia y búsqueda de movimiento apenas hacen la diferencia para material sin pérdidas, para material no animado con cualquier ruido. CABAC necesita una gran cantidad de CPU a tasas de bits sin pérdidas, incluso para decodificar. Úselo solo para fines de archivo, no archivos de memoria virtual. (ultrarrápido deshabilita CABAC). CABAC ofrece ahorros de 10 a 15% de tasa de bits.

Si necesita que cada fotograma sea un fotograma clave, configúrelo -keyint 1. Entonces, el software de edición de video que solo quiere cortar en fotogramas clave o w / e no lo limitará.

Para responder a la pregunta original: Esto es lo que debe hacer para tirar archivos temporales al intentar cosas por etapas (por ejemplo, un desentrelazado lento, guardar resultados sin pérdidas antes de intentar otras cosas):

ffmpeg -i dv-video-source.ts -vf yadif=2:1,mcdeint=3:1:10 -c:a copy -c:v libx264 -preset ultrafast -qp 0 deinterlaced.mkv

Si realmente necesita su salida en archivos de imagen que puede modificar con herramientas de imágenes fijas, entonces, decodifique a png. No va a perder nada más que quizás el menos significativo de los 8 bits de cada uno de los valores Y, Cb y Cr para cada píxel.

x264 sale MUY bien en esto porque hay muchos cuadros negros con un poco de texto, un aumento gradual y un aumento gradual, y una similitud perfecta entre grandes áreas de muchos cuadros, que logra aprovechar incluso con -preset ultrafast. En acción en vivo, todavía veo x264 a la mitad del tamaño de archivo de ffvhuff (yuv420).

Para cualquier persona curiosa: la codificación rgb sin pérdida de tiempo de alta CPU tenía (x264 core 144 r2525):

[libx264rgb @ 0x35b97a0] frame I:27    Avg QP: 0.00  size:604367
[libx264rgb @ 0x35b97a0] frame P:1226  Avg QP: 0.00  size:517512
[libx264rgb @ 0x35b97a0] mb I  I16..4..PCM: 46.3% 38.1% 15.7%  0.0%
[libx264rgb @ 0x35b97a0] mb P  I16..4..PCM: 24.3%  5.4%  4.5%  0.0%  P16..4: 10.5%  3.3%  5.7%  0.0%  0.0%    skip:46.3%
[libx264rgb @ 0x35b97a0] 8x8 transform intra:17.3% inter:46.1%
[libx264rgb @ 0x35b97a0] coded y,u,v intra: 81.6% 77.5% 80.0% inter: 28.0% 27.7% 28.1%
[libx264rgb @ 0x35b97a0] i16 v,h,dc,p: 35% 64%  1%  0%
[libx264rgb @ 0x35b97a0] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 31% 49% 13%  2%  1%  1%  1%  1%  1%
[libx264rgb @ 0x35b97a0] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 31% 37%  5%  5%  6%  5%  5%  4%  3%
[libx264rgb @ 0x35b97a0] Weighted P-Frames: Y:41.1% UV:40.7%
[libx264rgb @ 0x35b97a0] ref P L0: 74.5%  4.2%  9.1%  4.1%  2.1%  1.7%  1.2%  0.8%  0.6%  0.5%  0.3%  0.2%  0.2%  0.2%  0.2%  0.1%
[libx264rgb @ 0x35b97a0] kb/s:99721.66

Tenga en cuenta la fracción realmente alta de los fotogramas p ponderados, y también la fracción realmente alta de los macrobloques de omisión. Cada transición de escena es un desvanecimiento, no un corte, y x264 se aprovecha si le das tiempo a la CPU para descubrir cómo.

notas adicionales (códecs con pérdida para editar):

Para desplazarse hacia adelante / atrás a través de los clips, generalmente se prefieren los códecs intra-únicos (utvideo, ffvhuff, mjpeg, jpeg2000, pro-res, AVC-Intra). Me imagino que el AVC regular con GOP cortos (1/2 a 1 seg) también se restregaría bastante bien, siempre que el software supiera lo que estaba haciendo (decodifica el marco I más cercano al restregar rápido, decodifica dentro del GOP para llegar a un cuadro intermedio si está enfocado lo suficiente en una línea de tiempo para que sea necesario).

He publicado algunas cosas negativas sobre esto y https://video.stackexchange.com/ sobre pro-res, como "cuál es el punto si es una compresión más lenta y peor que un códec sin pérdidas", pero tiene algunas características interesantes. Apple dice que puede decodificar a media resolución usando tan solo 1/3 del tiempo de CPU de decodificación completa.

La implementación de prof de ffmpeg probablemente tampoco esté tan optimizada para la velocidad como la de Apple, por lo que mis pruebas con ffmpeg lo han hecho parecer lento. Probablemente no valga la pena usarlo si tiene un flujo de trabajo de software libre con herramientas basadas en ffmpeg, pero puede valer la pena intentarlo si está usando un software comercial.

No hago mucha edición de video, principalmente solo codificación, por lo que no tengo una idea clara de qué pruebas serían apropiadas para códecs como prores. Supongo que tal vez mjpeg sería una buena alternativa rápida, si short-GOP x264 no funciona bien. Hay implementaciones de jpeg aceleradas por asm en distribuciones de Linux, y es un códec bastante simple. Puede aumentar o disminuir la calidad según sea necesario para intercambiar calidad frente a tamaño de archivo + velocidad de codificación / decodificación. Es antiguo, pero si quieres un códec intra-único que sea realmente rápido, podría vencer a x264.

Para x264, probaría algo como x264 --crf 10 --keyint=1 --preset superfast --tune fastdecode (Intra-only, sin ninguna de las otras cosas que se --avcintra-classconfiguran). Nota superfast(sin CABAC), o fasterno, ultrafastprobablemente sea mejor para operaciones con pérdidas. Creo que ultrarrápido pierde mucha calidad sin ser mucho más rápido. Cuanto menor sea la calidad (mayor crf) que use, más vale la pena gastar un poco más de tiempo de CPU para encontrar una mejor codificación. Sin embargo, mucho de esto probablemente no sea relevante con GOP size = 1.

Con el tamaño de GOP> 1, si está arrojando tantos bits a la codificación que una mejor predicción interna no ahorrará muchos bits al codificar los residuos (porque el ruido / grano / cambios sutiles entre cuadros se conservan con mucha precisión), entonces probablemente súper rápido probablemente esté bien. De lo contrario, con --keyint=30o algo, probablemente --preset veryfast --crf 12sería interesante.

En teoría, la calidad en una configuración CRF dada debería ser constante en todos los ajustes preestablecidos. Si está buscando archivos más pequeños (decodificaciones más rápidas), tiene sentido cambiar algo de calidad y algo de tiempo de codificación.

Peter Cordes
fuente
Solo quería decir gracias por esa lista con los tamaños de archivo; cosas geniales para una referencia rápida ... ¡Salud!
sdaau
@sdaau Tenga en cuenta que el video fuente es MUY diferente de los videos típicos hechos con cámaras. Es un render 3D, con letterboxing y con muchos fundidos entre escenas cortas. Y una fracción decente de cuadros totalmente fijos con texto. Los cuadros totalmente inmóviles son bastante intracomprimibles, pero aún favorecen los códecs con fotogramas inter (más de x64) de lo que imagino que la compresión sin pérdida de metraje de la cámara (con cualquier ruido) lo haría.
Peter Cordes
+1: No tenía idea que Lossless H.264 era siquiera una cosa. He agregado información al respecto a mi respuesta. Siéntase libre de tomar algunas ideas de mi breve presentación para resolver su problema de tl; dr . En cuanto a mi propia respuesta, está destinada a ser integral, en lugar de tratar de presentar la única solución verdadera al problema. Tenemos tantos códecs diferentes porque ningún códec único satisface las necesidades de todos.
Warren Young
2

Creo que ffmpeg en realidad admite la conversión a video sin comprimir.
Utilicé ffmpeg -i input.mp4 -vcodec rawvideo out.avi y el .avi resultante fue aproximadamente el tamaño de archivo correcto. El reproductor multimedia de Windows no parecía poder reproducirlo correctamente, pero VirtualDub podía leerlo y no vi ninguna pérdida en la calidad de la imagen.

jmnben
fuente