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
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 .
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.
ffmpeg -i input.avi -c:v qtrle -pix_fmt rgb24 output.mov.