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.Así que terminé haciendo mi propia respuesta demasiado tiempo.
Resumen TL; DR: para almacenar sin pérdida una secuencia de imágenes, use
libx264olibx264rgbcon-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 comoffvhuff. Esa es otra razón para usar h.264, suponiendo que sus otras herramientas puedan manejar elHigh 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 modernohuffyuv, 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:2y4: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.
p.ej
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:
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:
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, nolibx264rgb. 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 en420lugar de la444salida 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.mkvSi 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):
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). Notasuperfast(sin CABAC), ofasterno,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.
fuente
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.
fuente