h.264 - plus - codificación sin pérdida h264

h.264 formato (8)

Acepto que a veces la pérdida de datos es aceptable, pero no se trata simplemente de cómo se ve inmediatamente después de la compresión.

Incluso una pérdida de datos visualmente imperceptible de color puede degradar el metraje de tal manera que la corrección de color, la codificación de pantalla verde, el seguimiento y otras tareas de publicación se vuelven más difíciles o imposibles, lo que agrega gastos a una producción.

Realmente depende cuándo y cómo se comprime en la canalización, pero en última instancia tiene sentido archivar la calidad original, ya que el almacenamiento suele ser mucho menos costoso que la resolución.

¿Es posible hacer una codificación completamente sin pérdida en h264? Sin pérdidas, quiero decir que si le doy una serie de cuadros y los codifico, y si extraigo todos los fotogramas del video codificado, obtendré exactamente los mismos fotogramas que en la entrada, píxel por píxel, fotograma a fotograma . ¿Es eso realmente posible? Toma este ejemplo:

Genero un montón de marcos, luego codifico la secuencia de imágenes en un AVI sin comprimir (con algo así como virtualdub), luego aplico h264 sin pérdida (los archivos de ayuda afirman que la configuración --qp 0 hace la compresión sin pérdida, pero no estoy seguro si eso significa que no hay pérdidas en ningún punto del proceso o que solo la cuantización es sin pérdidas). Luego puedo extraer los fotogramas del video h264 resultante con algo como mplayer.

Intenté con Handbrake primero, pero resulta que no es compatible con la codificación sin pérdida. Intenté x264 pero se cuelga. Puede ser porque mi archivo AVI fuente está en el espacio de color RGB en lugar de YV12. No sé cómo alimentar una serie de mapas de bits YV12 y en qué formato a x264 de todos modos, así que ni siquiera puedo intentarlo.

En resumen, lo que quiero saber si es que hay una manera de hacerlo

Serie de mapas de bits sin pérdida (en cualquier espacio de color) -> alguna transformación -> codificación h264 -> decodificación h264 -> alguna transformación -> la serie original de mapas de bits sin pérdida

Si hay una manera de lograr esto?

EDITAR: Hay un punto MUY válido sobre H264 sin pérdidas que no tiene demasiado sentido. Soy muy consciente de que no hay manera de que pueda decir (con solo mis ojos) la diferencia entre un clip sin comprimir y otro comprimido a una velocidad alta en H264, pero no creo que no carezca de uso. Por ejemplo, puede ser útil para almacenar video para editar sin tomar grandes cantidades de espacio y sin perder calidad y gastando demasiado tiempo de codificación cada vez que se guarda el archivo.

ACTUALIZACIÓN 2: Ahora x264 no falla. Puedo usar como fuentes ya sea avisynth o sin pérdida yv12 lagarith (para evitar la advertencia de compresión del espacio de color). Howerver, incluso con --qp 0 y una fuente rgb o yv12 Todavía tengo algunas diferencias, mínimas pero actuales. Esto es preocupante, porque toda la información que he encontrado sobre la codificación predictiva sin pérdida (--qp 0) afirma que toda la codificación debe ser sin pérdida, pero no puedo verificar esto.

Esta no es exactamente una respuesta a su pregunta, sino más bien una razón por la cual ser con pérdidas puede ser mejor que sin pérdidas.

Aquí hay una comparación de la misma imagen pero codificada de manera diferente con un formato con pérdida y sin pérdidas.

PNG (sin pérdida) 148 kB:

JPEG-8 (con pérdida) 36 kB:

JPEG-10 (con pérdida) 65 kB:

JPEG-12 (con pérdida) 122 kB:

Ahora abra la imagen PNG (sin pérdida) y la imagen JPEG-10 (con pérdida) en dos pestañas nuevas en su navegador web. Voltee hacia adelante y hacia atrás, puede ver una leve diferencia pero apenas. Mi punto es que nunca dirías la diferencia en calidad sin mirarlos a los dos al mismo tiempo y examinarlos de cerca. La compresión de datos sin pérdida no vale la pena en la mayoría de los casos porque los formatos con pérdida pueden darle la calidad exacta a un costo menor (tamaño de archivo).

FFmpeg tiene un modo "sin pérdidas" para x264, consulte FFmpeg y x264 Guía de codificación

§ Lossless H.264

en esencia es -qp 0

No conozco sus requisitos de compresión y descompresión, pero un archivador de propósito general (como 7-zip con LZMA2) debería ser capaz de comprimir como pequeño o, en algunos casos, incluso más pequeño que un códec de video sin pérdida. Y es mucho más simple y seguro que una cadena completa de procesamiento de video. La desventaja es la velocidad mucho más lenta, y que debes extraer antes de verla. Pero para las imágenes, creo que deberías intentarlo.

También hay formatos de imagen sin pérdida, como .png.

Para codificar RGB sin pérdida con x264, debe usar la versión de línea de comando de x264 (no se puede confiar en las GUI en este caso extremo, probablemente se desordenarán) r2020 o más reciente, con algo como eso:

x264 --qp 0 --preset fast --input-csp rgb --output-csp rgb --colormatrix GBR --output "the_lossless_output.mkv" "someinput.avs"

Cualquier pérdida / diferencia entre la entrada y la salida debe ser de alguna conversión de espacio de color (ya sea antes de la codificación o en la reproducción), configuraciones incorrectas o algún encabezado / metadato perdido. x264 no admite RGBA, pero RGB está bien. La compresión de YUV 4: 4: 4 es más eficiente, pero perderá algunos datos en la conversión del espacio de color ya que su entrada es RGB. YV12 / i420 es mucho más pequeño y, con mucho, el espacio de color más común en video, pero tiene menos resolución de croma.

Más información sobre la configuración de x264: http://mewiki.project357.com/wiki/X264_Settings

Además, evite lagarith. Utiliza x87 punto flotante ... y hay mejores alternativas. http://codecs.multimedia.cx/?p=303 http://mod16.org/hurfdurf/?p=142

EDITAR: No sé por qué fui votado. Por favor deja un comentario cuando hagas eso.

Para generar H.264 sin pérdidas con la GUI de HandBrake, configure Video Codec: H.264, Calidad constante, RF: 0, Perfil H.264: automático. Aunque Apple no admite este archivo de forma nativa, puede volver a codificarse como near-lossless para la reproducción.

Ventana de actividad de la GUI de HandBrake:

Perfil H.264: automático; Codificación a constante RF 0.000000 ... perfil Alto 4: 4: 4 Predictivo, nivel 3.0, 4: 2: 0 8 bits

Perfil H.264: alto; La codificación a RF constante 0.000000 ... sin pérdidas requiere un perfil alto444, deshabilitando ... perfil Alto , nivel 3.0

Si no puede obtener una compresión sin pérdida utilizando un codificador y decodificador h.264, tal vez podría considerar dos alternativas:

(1) En lugar de pasar todos los datos en formato h.264, algunas personas están experimentando con la transmisión de algunos de los datos con un "canal lateral" residual :

(archivo h.264) -> decodificación h264 -> alguna transformación -> una aproximación con pérdida de la serie original de mapas de bits
(archivo residual comprimido) -> decodificador -> una serie de mapas de bits residuales sin pérdida
Para cada píxel en cada mapa de bits, approximate_pixel + residual_pixel = un píxel bit por bit igual al píxel original.

(2) Use el formato de compresión de video Dirac en el modo "sin pérdida".

Si x264 tiene codificación sin pérdida pero no le gusta su formato de entrada, entonces la mejor opción es usar ffmpeg para manejar el archivo de entrada. Intente comenzar con algo como

ffmpeg -i input.avi -f yuv4mpegpipe -pix_fmt yuv420p -y /dev/stdout / | x264 $OPTIONS -o output.264 /dev/stdin

y agregando opciones desde allí. YUV4MPEG es un formato sin comprimir sin pérdidas adecuado para tuberías entre diferentes herramientas de video; ffmpeg sabe cómo escribirlo y x264 sabe cómo leerlo.

Voy a agregar una respuesta tardía a esta después de pasar todo el día tratando de descubrir cómo obtener YUV 4: 4: 4 píxeles en x264. Mientras que x264 acepta 4: 2: 0 píxeles sin procesar en un archivo, es realmente bastante difícil obtener 4: 4: 4 píxeles. Con las versiones recientes de ffmpeg, lo siguiente funciona para una codificación y extracción completamente sin pérdida para verificar la codificación.

Primero, escribe tu yuv en bruto 4: 4: 4 píxeles en un archivo en un formato planar. Los planos son un conjunto de bytes Y, luego los bytes U y V donde U y V usan 128 como valor cero. Ahora, invoque ffmpeg y pase el tamaño de los marcos de YUV sin formato, utilizando el formato de píxel "yuv444p" dos veces, de la siguiente manera:

ffmpeg -y -s 480x480 -pix_fmt yuv444p -i Tree480.yuv / -c:v libx264 -pix_fmt yuv444p -profile:v high444 -crf 0 / -preset:v slow / Tree480_lossless.m4v

Una vez que se realiza la codificación a h264 y el ajuste como un archivo de Quicktime, se pueden extraer los mismos bytes exactos de la siguiente manera:

ffmpeg -y -i Tree480_lossless.m4v -vcodec rawvideo -pix_fmt yuv444p / Tree480_m4v_decoded.yuv

Finalmente, verifique los dos archivos binarios con diff:

$ diff -s Tree480.yuv Tree480_m4v_decoded.yuv Files Tree480.yuv and Tree480_m4v_decoded.yuv are identical

¡Solo tenga en cuenta que necesita escribir los bytes YUV en un archivo usted mismo, no permita que ffmpeg haga ninguna conversión de los valores YUV!